graphics for an Amiga/megadrive vertical scrolling shmup-some questions

[Adrian Browne]

Hi guys. I am starting work on a vertical scrolling shmup for Amiga, Megadrive and Dreamcast. Its just me doing pixel art right now- Nivrig may eventually code this.

Questions: Is it plausible to have 32 colours on-screen without copper on a500 for such a game or would 16 colours be necessary? Are there any colour divisions or assignments i need to know or could 32 or 16 colours be liberally used?

Another possibility is to go base Aga. I was thinking single screen with 64 colours which might make things easier when porting to Megadrive. Iv'e read a bit about megadrive- are there divisions or can all 64(61 + transparency's) colours be mixed freely across all layers etc. Also with aga single layer is it possible to still achieve say parallaxing clouds or layers via some tricks etc?

It will be a space shmup or possibly a helicopter based one- iv'e yet to fully decide. I'm trying to build the game to spec- battle squadron is a good example of an a500 vertical shmup but i guess it uses mainly 16 colours?

Perhaps AGA to MD to DC is the way to go. Please feel free to inform me of anything after which I'm sure I will be a little less stupid.

[Samurai_Crow]

The Scorpion Engine supports Megadrive as well as Amiga. No Dreamcast support though. The development is cross developed from Windows.

16 colors are faster than 32 by 20% speed improvement. That's why doing more colors should be done using the copper if possible.

If using AGA to do a vertical shmup with side scrolling also, I'd recommend blitting the HUD to a wide sprite overlapping the left border. That way you can cover more of the border with graphics while using fast-page fetching.

[Master484]

Is it plausible to have 32 colours on-screen without copper on a500 for such a game or would 16 colours be necessary?

Yes, 32 color shmups are perfectly possible on an A500.

Battle Squadron uses 32 color mode. Although the player ships and all bullets on screen (both player and enemy shots) were made with multiplexing sprites.

And even with all those sprites Battle Squadron is a 50/25 FPS hybrid; enemies move at 25 FPS, but the scrolling and the sprites move at 50 FPS, making it look and feel like a true 50 FPS game.

So if you want a 32 color mode shmup on an A500, with the amount of action on screen set to the "Megadrive standard", then you almost certainly have to do similar sprite trickery if you want the game to run at 50 FPS (or appear as 50 FPS). So when designing it, at least make the player ship a sprite right away, so that at least it can move at 50 FPS. Project X, R-Type and Blastar are good examples of how a 50 FPS player can make 25 FPS game feel almost as smooth as true 50 FPS.

Are there any colour divisions or assignments i need to know or could 32 or 16 colours be liberally used?

There is only one limitation: on OCS/ECS Amigas sprites always use colors 16-31. This is true for all screen and color modes. So for example on a 16 color game the bitmap colors are at 0-15 and sprite colors at 16-31. But on 32 color mode the color slots overlap, so bitmap colors will be at 0-31, and sprite colors at 16-31. So in a way, on a 16 color game you get extra 16 colors with sprites, while in a 32 color game the sprite colors are "lost" because they are the same as the bitmap colors.

However, this limitation is for OCS/ECS only; on AGA the sprite colors can be set to other spots too, regardless of color mode. So for example, on AGA you can set sprite colors to 32-47, giving you 16 extra colors on a 32 color game. And of course on AGA you can have other stuff too, such as 64 pixel wide sprites instead of 16 pixel wide, which might help a little bit, especially if the standard is raised to Dreamcast instead of MegaDrive.

Also with aga single layer is it possible to still achieve say parallaxing clouds or layers via some tricks etc?

The easiest way to do that would be the AGA sprites. Four 64 pixels wide sprites side by side would cover 256 pixels, five would cover 320 pixels.

The second easy option is to use AGA 16+16 color dual playfield mode, which gives you two layers of parallax all the time, and sprites can be used for something else.

---

About the Sega MegaDrive I don't know that much, but the 64 colors are divided to four 16 color palettes, and apparently the sprites and tiles get their colors depending on which palette they are currently assigned to. And also the system has two playfields, just like the Amiga, but I'm not 100% sure how the palettes work on them.

[Adrian Browne]

Originally Posted by Master484

Yes, 32 color shmups are perfectly possible on an A500.

Battle Squadron uses 32 color mode. Although the player ships and all bullets on screen (both player and enemy shots) were made with multiplexing sprites.

And even with all those sprites Battle Squadron is a 50/25 FPS hybrid; enemies move at 25 FPS, but the scrolling and the sprites move at 50 FPS, making it look and feel like a true 50 FPS game.

So if you want a 32 color mode shmup on an A500, with the amount of action on screen set to the "Megadrive standard", then you almost certainly have to do similar sprite trickery if you want the game to run at 50 FPS (or appear as 50 FPS). So when designing it, at least make the player ship a sprite right away, so that at least it can move at 50 FPS. Project X, R-Type and Blastar are good examples of how a 50 FPS player can make 25 FPS game feel almost as smooth as true 50 FPS.

There is only one limitation: on OCS/ECS Amigas sprites always use colors 16-31. This is true for all screen and color modes. So for example on a 16 color game the bitmap colors are at 0-15 and sprite colors at 16-31. But on 32 color mode the color slots overlap, so bitmap colors will be at 0-31, and sprite colors at 16-31. So in a way, on a 16 color game you get extra 16 colors with sprites, while in a 32 color game the sprite colors are "lost" because they are the same as the bitmap colors.

However, this limitation is for OCS/ECS only; on AGA the sprite colors can be set to other spots too, regardless of color mode. So for example, on AGA you can set sprite colors to 32-47, giving you 16 extra colors on a 32 color game. And of course on AGA you can have other stuff too, such as 64 pixel wide sprites instead of 16 pixel wide, which might help a little bit, especially if the standard is raised to Dreamcast instead of MegaDrive.

The easiest way to do that would be the AGA sprites. Four 64 pixels wide sprites side by side would cover 256 pixels, five would cover 320 pixels.

The second easy option is to use AGA 16+16 color dual playfield mode, which gives you two layers of parallax all the time, and sprites can be used for something else.

---

About the Sega MegaDrive I don't know that much, but the 64 colors are divided to four 16 color palettes, and apparently the sprites and tiles get their colors depending on which palette they are currently assigned to. And also the system has two playfields, just like the Amiga, but I'm not 100% sure how the palettes work on them.

Pardon my ignorance but if i do a single screen aga set-up should I begin with a 32 colour palette given a base A1200 is the target specification? Or if i go for 64 colours would that be too many colours for the memory to work with? If i assign specific colours to sprites can i freely use these colours elsewhere? I gather that sprites can be 16x16,32,32 up to 64x64 on aga?

Does a 64 x 64 sprite need to be a clone or can it just be a single 64 x 64 + screen height image? Sorry for all the questions lol. I might make this thread the development thread so I can stay on the right track with community advice etc. I attached two test images

[Samurai_Crow]

The maximum height of sprite hardware can handle is 512 pixels regardless of the horizontal resolution. The horizontal resolution on the AGA chipset is determined only by the fetch-rate if the memory. The fastest rate is 64-bit fast-page mode and when that is used, 64 pixels is the sprite width.

What wasn't mentioned previously was that AGA can have dual-playfield mode with 16 colors each. Unlike ECS and OCS, AGA can select a different 16-color bank with the copper for each row of pixels displayed. This allows color palette changes to be double-buffered so that color changes can be performed during the visible part of the display. The bank selections are for background playfield, foreground playfield, even numbered sprites and odd-numbered sprites. (If the sprites are stacked, the even-numbered sprite bank is used for all 15 foreground colors, with transparent color zero.)

[Adrian Browne]

[Master484]

Pardon my ignorance but if i do a single screen aga set-up should I begin with a 32 colour palette given a base A1200 is the target specification? Or if i go for 64 colours would that be too many colours for the memory to work with?

64 color graphics will consume only about 15 % more RAM than 32 color graphics. The difference between 32 and 64 colors is just one bitplane, 5 planes vs 6 planes. And on AGA machines you always have a minimum of 2 MB of Chip RAM, while in OCS you only have 512K (half meg). And even if the OCS machine has extra RAM, that will be either Fast or Slow RAM, which can't be directly used for graphics, sound or music.

So on OCS you might encounter memory issues with 64 colors, but on AGA you should be fine.

And since you're planning to make a Megadrive conversion, it's a good idea to divide the 64 color palette into four 16 color "sub palettes", so that everything is Megadrive compatible from the start. So have one palette at 0-15, second one at 16-31, third one at 32-47, and fourth one at 48-63. And then use the first and second one for the backgrounds, and the third and fourth one for the moving objects. (This is how I think it actually works on the Megadrive)

Also doing it this way will save memory, because your objects can be made as 16 color bobs instead of 64 color bobs. When you have a 16 color bob, it should be possible to display it through any of those 16 color sub palettes, allowing you to change object color themes on the fly. I have tested this in Blitz Basic, using a command called "ExcessOnOff", but I'm not sure how you would do it other coding languages.

If i assign specific colours to sprites can i freely use these colours elsewhere?

No. If you set the sprite colors "outside" of your main display palette, then you can use those colors only for the sprites, and nothing else. So for example if your 64 color palette is at 0-63, and your sprite colors at 64-79, then the sprite colors are for sprites only.

Does a 64 x 64 sprite need to be a clone or can it just be a single 64 x 64 + screen height image? I attached two test images

They can be either. So you can have a big 64*512 sprite, or you can have one sprite that is multiplied down the screen by a sprite multiplexer. So in the "clouds" example image you can do the clouds with two sprites, that you then multiplex as many times as you want: one sprite for the top layer clouds, and second one for the bottom layer. And in the "blue tunnel" image you can use just one long sprite, no cloning needed.

And also, maybe you already know this, but Amiga sprites can be either 4 colors or 16 colors. The 16 sprite colors are divided to four sub palettes, each of which is 4 colors. Sprites 0 and 1 use the first 4 colors, sprites 2 and 3 the next 4 colors, and so on. And to make a 16 color sprite, you combine one of the sprite pairs. So for example you can combine sprites 0 and 1 to get one 16 color sprite.

This is important when you're designing your palettes, especially if your sprite palette is located "inside" the main screen palette and shares the same colors with it (as it would be in OCS 32 color mode). For example, if you decided to use all eight 4 color sprites for player bullets, and every bullet is of the same color, then you have four sets of four colors which are all identical. But this isn't that much of a problem in AGA, where the sprite palette can always be put outside of the main display palette.

[Adrian Browne]

Originally Posted by Master484

64 color graphics will consume only about 15 % more RAM than 32 color graphics. The difference between 32 and 64 colors is just one bitplane, 5 planes vs 6 planes. And on AGA machines you always have a minimum of 2 MB of Chip RAM, while in OCS you only have 512K (half meg). And even if the OCS machine has extra RAM, that will be either Fast or Slow RAM, which can't be directly used for graphics, sound or music.

So on OCS you might encounter memory issues with 64 colors, but on AGA you should be fine.

And since you're planning to make a Megadrive conversion, it's a good idea to divide the 64 color palette into four 16 color "sub palettes", so that everything is Megadrive compatible from the start. So have one palette at 0-15, second one at 16-31, third one at 32-47, and fourth one at 48-63. And then use the first and second one for the backgrounds, and the third and fourth one for the moving objects. (This is how I think it actually works on the Megadrive)

Also doing it this way will save memory, because your objects can be made as 16 color bobs instead of 64 color bobs. When you have a 16 color bob, it should be possible to display it through any of those 16 color sub palettes, allowing you to change object color themes on the fly. I have tested this in Blitz Basic, using a command called "ExcessOnOff", but I'm not sure how you would do it other coding languages.

No. If you set the sprite colors "outside" of your main display palette, then you can use those colors only for the sprites, and nothing else. So for example if your 64 color palette is at 0-63, and your sprite colors at 64-79, then the sprite colors are for sprites only.

They can be either. So you can have a big 64*512 sprite, or you can have one sprite that is multiplied down the screen by a sprite multiplexer. So in the "clouds" example image you can do the clouds with two sprites, that you then multiplex as many times as you want: one sprite for the top layer clouds, and second one for the bottom layer. And in the "blue tunnel" image you can use just one long sprite, no cloning needed.

And also, maybe you already know this, but Amiga sprites can be either 4 colors or 16 colors. The 16 sprite colors are divided to four sub palettes, each of which is 4 colors. Sprites 0 and 1 use the first 4 colors, sprites 2 and 3 the next 4 colors, and so on. And to make a 16 color sprite, you combine one of the sprite pairs. So for example you can combine sprites 0 and 1 to get one 16 color sprite.



This is important when you're designing your palettes, especially if your sprite palette is located "inside" the main screen palette and shares the same colors with it (as it would be in OCS 32 color mode). For example, if you decided to use all eight 4 color sprites for player bullets, and every bullet is of the same color, then you have four sets of four colors which are all identical. But this isn't that much of a problem in AGA, where the sprite palette can always be put outside of the main display palette.

And also, maybe you already know this, but Amiga sprites can be either 4 colors or 16 colors. The 16 sprite colors are divided to four sub palettes, each of which is 4 colors. Sprites 0 and 1 use the first 4 colors, sprites 2 and 3 the next 4 colors, and so on. And to make a 16 color sprite, you combine one of the sprite pairs. So for example you can combine sprites 0 and 1 to get one 16 color sprite.

Is this the same for AGA?

So in essence I should reserve one of my 4, sixteen colour palettes for sprites only? The next question is: what should I define as sprites? All parallax layer graphics? Or both parallax layers and the player ship? Or bullets?

So on AGA we have only access to a fixed number of sprites- is that limit per screen only? Does it reset upon entering a new screen and thus you regain your sprite count? I will make a visual representation of the sprite set-up with images and text in Pro-motion ng for reference.

Iv'e attached a word document with the information you have given me so far-

[jotd]

Originally Posted by Samurai_Crow

If using AGA to do a vertical shmup with side scrolling also, I'd recommend blitting the HUD to a wide sprite overlapping the left border. That way you can cover more of the border with graphics while using fast-page fetching.

exactly what Banshee is doing

[gimbal]

Originally Posted by Adrian Browne

Hi guys. I am starting work on a vertical scrolling shmup for Amiga, Megadrive and Dreamcast. Its just me doing pixel art right now- Nivrig may eventually code this.

Would love to see some dev diary material about that at some point, doing pixel art for these kind of games has become a major area of interest for me lately. I limit myself to enhancing existing graphics for the time being but I'd like to expand into some original work at some point.

[Samurai_Crow]

Originally Posted by Adrian Browne

And also, maybe you already know this, but Amiga sprites can be either 4 colors or 16 colors. The 16 sprite colors are divided to four sub palettes, each of which is 4 colors. Sprites 0 and 1 use the first 4 colors, sprites 2 and 3 the next 4 colors, and so on. And to make a 16 color sprite, you combine one of the sprite pairs. So for example you can combine sprites 0 and 1 to get one 16 color sprite.

Is this the same for AGA?

No. The 4-color sprites can be split into separate color palette banks for even and odd numbered sprites. Only 16-color sprites are forced to use the same 16 colors for all sprites, the even sprite color bank.

Sprite pairs can be selected to be a 16-color or 2 4-color sprites individually. In other words, you can use sprites 0 and 1 as a 16-color sprite and use sprites 2-7 as individual 4-color sprites.

Originally Posted by Adrian Browne

So in essence I should reserve one of my 4, sixteen colour palettes for sprites only? The next question is: what should I define as sprites? All parallax layer graphics? Or both parallax layers and the player ship? Or bullets?

For bullets. That way you can use 4-color sprites and have twice as many sprites.

Originally Posted by Adrian Browne

So on AGA we have only access to a fixed number of sprites- is that limit per screen only? Does it reset upon entering a new screen and thus you regain your sprite count? I will make a visual representation of the sprite set-up with images and text in Pro-motion ng for reference.

The sprite limit is on horizontal scanlines. Vertically, sprite hardware can be reused many times with as little as 1 scanline between images.

The fixed number of 16 color palettes is if you choose to have separate foreground and background layers as "dual playfield" mode. If you chose to use a palette depth greater than 16 colors, you then have to scroll the foreground objects with the blitter instead of having a foreground playfield.

If you do go for a higher depth display, the blitter-objects (or bobs as they can also be called) will take longer to blit because they have to address the entire depth of the display. The 4-color sprites will have 2 fixed palette banks regardless, allowing each sprite to have separate, unshared colors. If you only use 16-color sprites, you forfeit one of the palette banks because you aren't using separate colors for the odd-numbered sprites any more.

[Master484]

So in essence I should reserve one of my 4, sixteen colour palettes for sprites only?

No, there is no need to do that.

To clarify:

On AGA you can always make the sprite colors separate from your main palette. So in 64 color mode your palette setup will look like: 64 + 16. So you'll still have your four 16-color palettes, and in addition to them a separate 16 color sprite palette. So in total you have 80 colors, of which 16 is for sprites only.

So: when sprite colors are outside of the main palette, only then they're reserved for sprites only. And when they are inside the main palette, then they simply use the same colors as your other graphics do.

[Adrian Browne]

Originally Posted by gimbal

Would love to see some dev diary material about that at some point, doing pixel art for these kind of games has become a major area of interest for me lately. I limit myself to enhancing existing graphics for the time being but I'd like to expand into some original work at some point.

Cool. What have you worked on?

[Adrian Browne]

Originally Posted by Master484

No, there is no need to do that.

To clarify:

On AGA you can always make the sprite colors separate from your main palette. So in 64 color mode your palette setup will look like: 64 + 16. So you'll still have your four 16-color palettes, and in addition to them a separate 16 color sprite palette. So in total you have 80 colors, of which 16 is for sprites only.

So: when sprite colors are outside of the main palette, only then they're reserved for sprites only. And when they are inside the main palette, then they simply use the same colors as your other graphics do.

Ah so I could just use the 64 colours divided into 4 groups of 16 for the whole game. So, the first two palettes for background graphics and the other two palettes for moving objects- Are moving objects defined as bullets, enemies and player ship? I mean technically graphical layers like clouds are also moving objects- would these parallax layers use colours from the first two palettes only? I'm guessing. -- I will do some mock-ups soon and arrange the palette.

[Samurai_Crow]

You should use bobs for your foreground graphics. All of the players and enemies will share a palette that way, but that frees up the sprites to be used as bullets or hud-style sidebar overlays.

There are 16 total banks of palette entries to use so if you double buffer each row of pixels, you can bank-swap a whole bank at the end of the pixel row. That way you can do most of your palette changes during the visible part of the display without having to worry about the changes being visible.

[Adrian Browne]

Originally Posted by Samurai_Crow

You should use bobs for your foreground graphics. All of the players and enemies will share a palette that way, but that frees up the sprites to be used as bullets or hud-style sidebar overlays.

There are 16 total banks of palette entries to use so if you double buffer each row of pixels, you can bank-swap a whole bank at the end of the pixel row. That way you can do most of your palette changes during the visible part of the display without having to worry about the changes being visible.

Ok. So Iv'e attached a screenshot of the palette. From the top, the first palette is 32 colours(31+transparency) and is for background and foreground. (Foreground done using bobs)

The second palette also of 32 colours is for enemies, bosses and the player ship.

The final 16 colour palette is reserved for bullets and a HUD overlay perhaps at the left hand side of the screen.

What are the parameters for bobs, given its A.G.A.? Thanks for the help guys- bear with me.

[Samurai_Crow]

Bobs are the same as the foreground. Dual-playfield mode cannot use palettes bigger than 16 colors. If you do, you are limited to a single playfield of up to 256 that is slow to update.

Also, the first color of the sprite palette is transparent.

[Master484]

Are moving objects defined as bullets, enemies and player ship? I mean technically graphical layers like clouds are also moving objects

Moving objects (bobs) can be anything that you want to move. Small (bullets and ships) or big (bosses or even full screen cloud layers).

Although doing huge moving stuffs (such as full screen parallax layers) with bobs can be very slow, even on AGA. So if you're planning to have levels with two full screen parallaxing layers of background graphics, then using Dual Playfield and the 64 pixel wide AGA sprites is recommended. But if it's only a few clouds, the doing them with bobs is totally OK.

There are games that draw many layers of parallax with bobs (Xenon 2, Toki, Darius+ etc), but doing it this way is always slow, even on AGA.

would these parallax layers use colours from the first two palettes only?

Bobs and background graphics use your main palette. So if you use a 64 color single playfield, then these things can use all 64 colors (or 63 since the color 0 is transparent). It's up to you if you want to divide the colors into four 16 color palettes. But as mentioned, this is how the Megadrive palettes work, if you're planning to release the game for it.

What are the parameters for bobs, given its A.G.A.?

If you mean the bob sizes, this is limited only by memory. And colors are limited only by your screen mode. So 64 colors game screen = 64 color bobs.

[Adrian Browne]

Originally Posted by Master484

Moving objects (bobs) can be anything that you want to move. Small (bullets and ships) or big (bosses or even full screen cloud layers).

Although doing huge moving stuffs (such as full screen parallax layers) with bobs can be very slow, even on AGA. So if you're planning to have levels with two full screen parallaxing layers of background graphics, then using Dual Playfield and the 64 pixel wide AGA sprites is recommended. But if it's only a few clouds, the doing them with bobs is totally OK.

There are games that draw many layers of parallax with bobs (Xenon 2, Toki, Darius+ etc), but doing it this way is always slow, even on AGA.

Bobs and background graphics use your main palette. So if you use a 64 color single playfield, then these things can use all 64 colors (or 63 since the color 0 is transparent). It's up to you if you want to divide the colors into four 16 color palettes. But as mentioned, this is how the Megadrive palettes work, if you're planning to release the game for it.

If you mean the bob sizes, this is limited only by memory. And colors are limited only by your screen mode. So 64 colors game screen = 64 color bobs.

Ok so its 64 COLOURS DIVIDED INTO 4 SUB PALETTES OF SIXTEEN COLOURS EACH+ A SEPARATE 16 COLOUR SPRITE PALETTE THAT’S RESERVED FOR SPRITES (BULLETS).
PALETTES: 0-15 & 16-31 USED FOR BACKGROUNDS AND FOREGROUNDS.
PALETTES: 32-47 & 48-63 USED FOR MOVING OBJECTS. (PLAYER SHIP, BOSS’ & ENEMIES)
SPRITES: COLOURS 64-79 (RESERVED FOR SPRITES ONLY) (BULLETS)

That may make it easier to convert graphics to megadrive. 32 colours is plenty for backgrounds/foregrounds anyways. Would it be plausible to do animated water tiles in an ocean level;? With clouds simultaneously moving or without? (perhaps without clouds on those particular screens would improve performance?)

[Samurai_Crow]

Palette cycling is quick. You can change banks with the background palette in a single copper instruction.