A discussion about Rastan

[Kang]

Looks good

[gimbal]

Originally Posted by jayminer

Did some more work on how the forest level could look, the background is still kinda ugly though but I feel like it's getting there...

http://driar.se/rastanmockup/rastan4_new.png

Loving the shaded trees in the background, very atmospheric.

[saimon69]

Forest looks good, if you keep background parallax sprites with their own palette most of the stuff on screen should be covered - just say goodbye to color cycling in the waterfalls though
I could also add some copper gradient in the sky, was not in the arcade
Plus, level 2 have a sunset setting; you CAN change a bit base palette so to make it look more sunset-y and at the same time will give more atmosphere even if will not be canon, in my opinion;

[jayminer]

Originally Posted by saimon69

Forest looks good, if you keep background parallax sprites with their own palette most of the stuff on screen should be covered - just say goodbye to color cycling in the waterfalls though
I could also add some copper gradient in the sky, was not in the arcade
Plus, level 2 have a sunset setting; you CAN change a bit base palette so to make it look more sunset-y and at the same time will give more atmosphere even if will not be canon, in my opinion;

Yes color cycling is a thing I'm not sure how it could be solved with such a limited palette, I was thinking that for the water on the first level maybe it would be possible to start the color cycling where the water begins since the player and enemies are always above it (I think, haven't really studied this). Maybe it would require some minor tweaks to the level so the player never can be below the water.

And yes I agree that some changes of the base palette and maybe some copper gradient in the background could be nice. I believe that a port/conversion of an arcade game doesn't always have to strive to look exactly like the arcade, it should use the features of the hardware it's ported to. That's why I redrawn some things I'm not that fond of or that looked really bad after the color conversion.

[jayminer]

I did try out converting the first castle level to my palette, I have changed it a bit but I don't think it's very noticable except on Rastans hair which has lost its reddish tint. I feel like I almost have to add the disclaimer that this is now a very early version just to try out the palette, I haven't done much to touch up the graphics yet and things could improve a lot with some manual work.

The only problem I see with the castle is the fires, they are animated which I guess will be a strain on the blitter, and there are not many reddish colors in the palette at the moment. I was thinking that the fire seems to mostly be below the player and enemies so maybe it would be possible to reuse colors with the copper to get that to look decent but I'm not sure and I'm pretty certain there are areas where this wouldn't work.

http://driar.se/rastanmockup/rastan5.png

[Tigerskunk]

Originally Posted by jayminer

I did try out converting the first castle level to my palette, I have changed it a bit but I don't think it's very noticable except on Rastans hair which has lost its reddish tint. I feel like I almost have to add the disclaimer that this is now a very early version just to try out the palette, I haven't done much to touch up the graphics yet and things could improve a lot with some manual work.

The only problem I see with the castle is the fires, they are animated which I guess will be a strain on the blitter, and there are not many reddish colors in the palette at the moment. I was thinking that the fire seems to mostly be below the player and enemies so maybe it would be possible to reuse colors with the copper to get that to look decent but I'm not sure and I'm pretty certain there are areas where this wouldn't work.

http://driar.se/rastanmockup/rastan5.png

I think using that red and yellow plus a brown skin tone that the Rastan BOB already uses would be fine to do a fire, no?

[chb]

Originally Posted by jayminer

The only problem I see with the castle is the fires, they are animated which I guess will be a strain on the blitter, and there are not many reddish colors in the palette at the moment. I was thinking that the fire seems to mostly be below the player and enemies so maybe it would be possible to reuse colors with the copper to get that to look decent but I'm not sure and I'm pretty certain there are areas where this wouldn't work.

From a quick look at the game, it seems that in the castle sections fire and parallax do not appear at the same time. So it's maybe possible to use sprites for the fire? I guess 3 colors + transparent is sufficient. But it's probably not completely straightforward for the programmer, as there are fires at different heights, wider than 128 pix etc. that can't be tackled with a "one-size-fits-it-all" approach.

[Tsak]

Originally Posted by jayminer

I did try out converting the first castle level to my palette, I have changed it a bit but I don't think it's very noticable except on Rastans hair which has lost its reddish tint. I feel like I almost have to add the disclaimer that this is now a very early version just to try out the palette, I haven't done much to touch up the graphics yet and things could improve a lot with some manual work.

The only problem I see with the castle is the fires, they are animated which I guess will be a strain on the blitter, and there are not many reddish colors in the palette at the moment. I was thinking that the fire seems to mostly be below the player and enemies so maybe it would be possible to reuse colors with the copper to get that to look decent but I'm not sure and I'm pretty certain there are areas where this wouldn't work.

http://driar.se/rastanmockup/rastan5.png

Lovely work you've done there mate. 100% approved!
Note you can get even more colors with some clever copper tricks to the backgrounds/tileset or use of sprites (sprites use colors 16-31 btw, so these can be added as extras to your palette). However (imho) it really looks fantastic already, even with this 16 color palette alone.

Regarding your post above, besides sprites, fire anims can also be done with tiles which should be almost no extra burden to blitter (unmasked, no opacity, single blit, no clear operation).

Oh and you've mentioned at the beginning of the thread you use 15 colors + transparent. You don't need to. You can safely use all 16 colors. Just make sure the black you're using is color #0 as OCS uses that for the overscan area.

[Vamplover]

Game is a goodie!

[jayminer]

Originally Posted by Tsak

Lovely work you've done there mate. 100% approved!
Note you can get even more colors with some clever copper tricks to the backgrounds/tileset or use of sprites (sprites use colors 16-31 btw, so these can be added as extras to your palette). However (imho) it really looks fantastic already, even with this 16 color palette alone.

Regarding your post above, besides sprites, fire anims can also be done with tiles which should be almost no extra burden to blitter (unmasked, no opacity, single blit, no clear operation).

Oh and you've mentioned at the beginning of the thread you use 15 colors + transparent. You don't need to. You can safely use all 16 colors. Just make sure the black you're using is color #0 as OCS uses that for the overscan area.

Well (attached) sprites are used for the parallax-layer in all of my mockups, even the castle one even if it only shows through the windows. That's also the reason why it's 15 colors + transparent, the transparent color is the one the sprites will show through.

Blitting the fire animation would be awesome if it could be done but even if the blitter doesn't have to work as much for those types of blits I feel like with all the enemies that are rather big and rastan himself moving around it still might be on the edge of what it can do, but then I'm far from en expert on how much that can be blitted in a frame. I'm mostly basing my assesments on when I tried to do things in AMOS and BlitzBasic back in the day and how much I could blit then, probably not the best comparison on what the blitter actually can do.

But part of the fun about thinking about a port like this to the amiga I also think is about the sacrifices that are going to have to be made, maybe enemies could just stop spawning close to the fire so there would be less to blit if it gets too much otherwise.

[dlfrsilver]

Originally Posted by jayminer

I did try out converting the first castle level to my palette, I have changed it a bit but I don't think it's very noticable except on Rastans hair which has lost its reddish tint. I feel like I almost have to add the disclaimer that this is now a very early version just to try out the palette, I haven't done much to touch up the graphics yet and things could improve a lot with some manual work.

The only problem I see with the castle is the fires, they are animated which I guess will be a strain on the blitter, and there are not many reddish colors in the palette at the moment. I was thinking that the fire seems to mostly be below the player and enemies so maybe it would be possible to reuse colors with the copper to get that to look decent but I'm not sure and I'm pretty certain there are areas where this wouldn't work.

http://driar.se/rastanmockup/rastan5.png

Very good. Can you adjust the tones so that they are brighter (or brighter as in the arcade ?)

Cheers !

[malko]

@jayminer : you have done a really good job ! Really impressive palette .
Hope this can be turned into an OCS version.

[Tsak]

Originally Posted by jayminer

Well (attached) sprites are used for the parallax-layer in all of my mockups, even the castle one even if it only shows through the windows. That's also the reason why it's 15 colors + transparent, the transparent color is the one the sprites will show through.

As I mentioned, you can still have proper transparency without having to sacrifice 1 color. I.e. you can utilise all 16 colors freely.
Bobs and tiles usually have masks to define their transparent parts and any reserved color is just used as an intermediate during the mask generation, after which it becomes free to be used normally. So there's no point in sacrificing a color from your palette as there are other ways to define the mask data.

On a practical -artistic- level, either use a color outside your palette's range (f.e. if you've got a 16 color palette it can be color #16 and above) or simply use the alpha channel (if you work f.e. on pc with pngs or gifs). Then the coder (depending on his framework) can use the alpha or extra color to define the masks during conversion, leaving the full range of your palette intact.

Of course when talking about the above it should be mentioned that we're talking strictly about bobs and tiles. When it comes to sprites, they do need a color reserved, either this is (on OCS) color #16 for attached images or #16, #20, #24 and #28 for normal 3-color sprites. So to summarise, bobs and tiles can have all 16 colors, while sprites are limited to 15 colors or less.

Originally Posted by jayminer

Blitting the fire animation would be awesome if it could be done but even if the blitter doesn't have to work as much for those types of blits I feel like with all the enemies that are rather big and rastan himself moving around it still might be on the edge of what it can do, but then I'm far from en expert on how much that can be blitted in a frame. I'm mostly basing my assesments on when I tried to do things in AMOS and BlitzBasic back in the day and how much I could blit then, probably not the best comparison on what the blitter actually can do.

But part of the fun about thinking about a port like this to the amiga I also think is about the sacrifices that are going to have to be made, maybe enemies could just stop spawning close to the fire so there would be less to blit if it gets too much otherwise.

Well -from what I know- non-opaque tileset blits like that are quite fast, so I doubt if they ever become a factor on the game's speed (worth considering at least). Especially if they are used just for details.

Enemy count and size -on the other hand- is important, so anyone thinking about doing a conversion has to take this first into account.
Imho for OCS (and regarding it stays 16 colors) this game is 100% doable if you keep it at 25fps. I bet almost no compromise will have to be made in regards to stuff on screen then. Plus the scrolling speed and character movement is already noticeably slow (even on the arcade) so we're talking about a pretty accurate and smooth port in this case. Next bet would be to have the enemies at 25fps and scrolling at 50 (which might be exactly what the arcade also does). But someone will have to test what's the blitting limit in this case.

[saimon69]

Originally Posted by Tsak

As I mentioned, you can still have proper transparency without having to sacrifice 1 color. I.e. you can utilise all 16 colors freely.
Bobs and tiles usually have masks to define their transparent parts and any reserved color is just used as an intermediate during the mask generation, after which it becomes free to be used normally. So there's no point in sacrificing a color from your palette as there are other ways to define the mask data.

On a practical -artistic- level, either use a color outside your palette's range (f.e. if you've got a 16 color palette it can be color #16 and above) or simply use the alpha channel (if you work f.e. on pc with pngs or gifs). Then the coder (depending on his framework) can use the alpha or extra color to define the masks during conversion, leaving the full range of your palette intact.

Of course when talking about the above it should be mentioned that we're talking strictly about bobs and tiles. When it comes to sprites, they do need a color reserved, either this is (on OCS) color #16 for attached images or #16, #20, #24 and #28 for normal 3-color sprites. So to summarise, bobs and tiles can have all 16 colors, while sprites are limited to 15 colors or less.



Well -from what I know- non-opaque tileset blits like that are quite fast, so I doubt if they ever become a factor on the game's speed (worth considering at least). Especially if they are used just for details.

Enemy count and size -on the other hand- is important, so anyone thinking about doing a conversion has to take this first into account.
Imho for OCS (and regarding it stays 16 colors) this game is 100% doable if you keep it at 25fps. I bet almost no compromise will have to be made in regards to stuff on screen then. Plus the scrolling speed and character movement is already noticeably slow (even on the arcade) so we're talking about a pretty accurate and smooth port in this case. Next bet would be to have the enemies at 25fps and scrolling at 50 (which might be exactly what the arcade also does). But someone will have to test what's the blitting limit in this case.

And i would add you can arrange the palette so that some enemies/objects could be simply drawn with 8 or even 4 colors; might need a more advanced graphic engine, but we did something like that with powder and was moving considerable amounts of stuff on screen

[Tsak]

Originally Posted by saimon69

And i would add you can arrange the palette so that some enemies/objects could be simply drawn with 8 or even 4 colors; might need a more advanced graphic engine, but we did something like that with powder and was moving considerable amounts of stuff on screen

I doubt anything like that will be needed. Metro Siege f.e. does more than 60 blits for character and enemy parts alone (with no frame loss), while keeping 6 of them on screen. Rastan arcade hardly ever shows more than 4 big enemies at the same time and as you can see from the pic below they are quite smaller.

[mcgeezer]

How would the background landscape be done in Rastan? Risky Woods style with repeating sprites or is the proposition Jim Powers style Dual Playfield on OCS with 8/7 colours?

Rastan scrolls at quite a fast rate at what appears to be 2 pixels each frame for the foreground and 1 pixel for the background, the scrolling would have to go at 50fps for it to look right.

Rastan is one of them games where it looks doable on OCS but deceptively isn't. I'm happy to be proved wrong though.

The first place a coder needs to start is devising a memory map for the game.

[chb]

Originally Posted by Tsak

As I mentioned, you can still have proper transparency without having to sacrifice 1 color. I.e. you can utilise all 16 colors freely.
Bobs and tiles usually have masks to define their transparent parts and any reserved color is just used as an intermediate during the mask generation, after which it becomes free to be used normally. So there's no point in sacrificing a color from your palette as there are other ways to define the mask data.

If you place sprites behind your foreground, everything having color 0 is transparent and shows the sprites. Hence, you cannot use that color.

BTW, I guess it could be possible to use only 4 colors + some copper color changes for the backgrounds, if exact reproduction of the original is not the goal. Kid Chaos is a good example how nice a 4-color bg can look like (it is dual playfield, not sprite bg, but only 5 bitplanes). That saves quite a bit of copper cycles and makes 128 pix wide patterns possible, or frees some sprites for other stuff.

Videokid uses such an approach: https://codetapper.com/amiga/sprite-tricks/videokid/

Anyway, what mcgeezer said is probably very true. Before deciding on the graphics setup, one should do at least a back-on-the-envelope calculation on memory consumption and memory bandwidth to see if an approach is feasible.

BTW, really nice work with the graphics so far!

[jayminer]

Breaking down what would actually work on an OCS Amiga is something I wish I was better at and I love when more technical people share their wisdom about what would be feasable for a port such as this. I kinda know how the Amiga hardware work but I'm bad at knowing more in-depth exactly what is possible with the copper and blitter. I guess the copper is almost out of action completely when sprites are used as a background parallax layer. The entire copperlist would just be updating the sprites, right?

How easy would it be to scroll the sprites using the copper, would it need big changes to the copperlist every frame? In a worst case scenario the background parallax could be static but that would be kinda lame.

But other than that, I don't think memory should be an issue if the game is allowed to load between levels. There are about 5-6 different enemies on the first level of various size but often only half of them are animated, like the legs only. The levels don't use that many different tiles and everything seems to be built of 32x32 big tiles and using 4bpp they shouldn't take up too much space.

I might be totally wrong and too optimistic here but to me this game seems very doable in a good version on an A500, atleast with 1MB. Maybe not arcade perfect but a very playable version.

[chb]

Originally Posted by jayminer

I guess the copper is almost out of action completely when sprites are used as a background parallax layer. The entire copperlist would just be updating the sprites, right?

Depends on the sprite color depth and screen width. When using 16 color sprites, there are probably no free slots for the copper left - at least that's the case with Risky Woods, the only game I know of with such a setup. Having only 4-color sprites should give the copper enough time to do some color changes.

Furthermore, a 16 color bg will not leave any memory bandwidth to blitter or CPU in the display area, so performance takes a hit.

Originally Posted by jayminer

How easy would it be to scroll the sprites using the copper, would it need big changes to the copperlist every frame? In a worst case scenario the background parallax could be static but that would be kinda lame.

Scrolling a sprite background is usually done by having pre-shifted copies of the bg layer, so the copper list itself is mostly static. But it needs some memory for that, 64k for a 256 pix high layer.

The codetapper site has some very good documentation on that, have a look at Risky Woods (16 colors), R-Type and Videokid or Jim Power (both 4 colors).

[saimon69]

The background layer seems a good case for PCHG on the sprites going down, a bit in the style of Agony, with color change every n pixels -see here:

Agony - Franck Sauer website