Should I use Shapes or Sprites?

[madaxe]

Hi everybody;

I made a little shoot'n'up game for PC Windows and for ZX Spectrum and I'm trying to convert it to Amiga using Blitz Basic 2.
I'm making some experiences with the Display Library and my question is if is better to use only Shapes or use GetaSprite and then to use Sprites?
What method is faster? In what method can I use more colors? It is possible to have all the graphics in 256 colors like the PC version or I need to reduce the number of colors?

By the way you can check my little game here:
https://madaxe-pns.github.io/sardonic/

Best regards,
José Mário aka MadAxe

[idrougge]

256 colours is mostly beyond what an Amiga can handle in an action game, especially if your only tool is Blitz.

Sprites are limited in their amount of colours as well as their size. Bobs (or Shapes in Blitz terminology) are slower since they have to be masked, drawn and then deleted from the screen, but have the same amount of colours as the screenmode in question.

Many Amiga shmups use a mix of both, for example making the enemies bobs and the player a sprite, or using sprites for shots.

[Daedalus]

Nice, and welcome along!

Sprites are faster, in fact they're sort of free in a way because they don't require any blitter or CPU time to draw them. But they're also quite limited: you can only have 8 on screen at the one time (or 16 if you keep the first 8 to the top of the screen and the second 8 to the bottom. They're also limited to 16 pixels wide and 3 colours, though you can join them in pairs to get 15 colours but only 4 on screen. Their palette is also allocated from a fixed set of pens.

AGA allows 64 pixel wide sprites and the ability to assign different sets of pens to the sprites. AGA will also allow you to use 256 colours on the screen at once instead of OCS/ECS's 32 (which include the sprite colours), though going by the screenshots, it looks like most of the colours are used up on the gradient in the side panels. This could easily be done on the Amiga using a copper setup and just a single colour, perhaps giving a similar result even on OCS/ECS Amigas.

In reality though, the Amiga's blitter is probably fast enough to deal with the number of objects you have on screen, so that might be the way to go, blitting shapes as you need them.

Edit: Yes, the hybrid approach is useful too, using the sprites for some items (bullets, powerups and so on).

[Tigerskunk]

Those pc screenshots really look like you don't need 256 colours for a conversion.
more around 16.

You can achieve that gradient on the sidebar with changing one colour in a copperlist.

[madaxe]

Hi fellows;

Thank you very much for your great help and precious information about Blitz Basic, I found it very usefull
By the way, these are my main graphics. Which of them do you think should be bobs and which of them should be sprites?


Our ship: 16x16x3 colors
Our fire: 1x8x1

Enemy 1: 24x16x3 , Boss 1: 48x32x3
Enemy 2: 24x16x3 , Boss 2: 48x32x3
Enemy 3: 15x24x3 , Boss 3: 30x48x3
Enemy 4: 24x24x3 , Boss 4: 48x48x3
Enemy fire: 1x8x1 , Boss 5: 80x32x3

Powerups: 12x12x2

Thanks in advance,
José Mário

[Daedalus]

If you're aiming for OCS/ECS compatibility, sprites won't do for most of the enemies, but they'll work well for your own ship, and powerups and bullets so long as you don't try to have more than 8 displayed at a time. I would say all enemies should be bobs, and then you can see how the performance is.

[madaxe]

Thanks again

I have a question about Dual PlayField and Palette Assignment.

Background Bitmap: bit01.lbm - 8 colors, palette range: 0-7



Foreground Bitmap: bit02.lbm - 8 colors, palette range: 8-15



But the final result is something like this:



My code is:

BitMap 0,320,256,4
BitMap 1,320,256,4


LoadBitMap 0,"bit01.lbm"
LoadBitMap 1,"bit02.lbm"

InitPalette 0,32

LoadPalette 0,"bit02.lbm",8
LoadPalette 0,"bit01.lbm",0

InitCopList 0,44,256,$35,8,32,0

CreateDisplay 0
DisplayPalette 0,0

DisplayBitmap 0,0,xb,yb,1,0,xf,yf

What am I doing wrong?
Can I only use 16 color for both BitMaps?


Thanks,
José Mário

[Daedalus]

It has to be the same 16 colour palette to cover both sets of 8 colours. Are your bitmaps 3 or 4 bitplanes deep? when you load the palette from a bitmap, it will load all colours in the palette, not just the ones used. Try setting the bitmaps up as 3 bitplanes deep instead and see if that helps.

Also, I'm not sure if you are actually using the correct colours - the 2nd playfield uses pens 8-15, but they're mapped from pens 0-7 in the bitmap. So both bitmaps should use colours 0-7. I *think* you have that right, I'm just not sure...

[E-Penguin]

Palettes are a pain in the arse.

BitMap 0,320,256,4
BitMap 1,320,256,4

If you're doing dual play field, on ocs/ecs, you're limited to 8 colours per plane. You seem to be using 4 plane bitmaps though - I suspect this is the issue.

[madaxe]

Well, I think I am doing something wrong.

I tried to change some things like to reduce the number of BitPlanes from 4 to 3, load a Palette from a previous one saved from Deluxe Paint and even set a Palette manualy with a For and Next cycle but the result is allways the same: the Foreground BitMap displays all the 8 colors pefectly but the Background BitMap only displays 4 colors.

Note: I am using a emulator and not the real machine. I tried both WinUAE and WinFellow but the result is the same.

[Daedalus]

Ah, I was barking up the wrong tree there, thinking primarily about the palette. You gave me a hint when you say that there are only ever 4 colours on the rear display...

Your problem is here:

InitCopList 0,44,256,$35,8,32,0

The $35 is the type, or flags field. $20 for dual playfield and $10 for smooth scrolling makes $30, and then you add on the number of bitplanes you want to use. These are split between the two displays, which is why you're limited to 8 colours in each layer - 3 bitplanes each. Ordinarily you're limited to 5 bitplanes for OCS and ECS without using EHB mode, but for dual playfield displays you can use all 6. With only 5 bitplanes assigned, your front display gets 3 and your rear only 2, meaning only 4 colours, and a plane of information going unused.

Try $36 and see if it fixes the problem.

[madaxe]

Oh Yeah, It works perfectly Thank you very much Daedalus
Replacing $35 by $36 was the solution for the problem. All the colors are now displayed correctly.

In fact I just find out that information on the Amiga Hardware Reference Manual:
http://amigadev.elowar.com/read/ADCD.../node0079.html


By the way, to code a simple vertical star field scroll I need always to use a Dual Playfield or is there a simple way to do this using a Simple PlayField?

Thanks in advance,
José Mário

Thanks in advance,
José Mário

[Daedalus]

Originally Posted by madaxe

Oh Yeah, It works perfectly Thank you very much Daedalus
Replacing $35 by $36 was the solution for the problem. All the colors are now displayed correctly.

In fact I just find out that information on the Amiga Hardware Reference Manual:
http://amigadev.elowar.com/read/ADCD.../node0079.html

Good stuff It's probably still a good idea to keep everything using the correct depth anyway (so both your bitmaps being 3 deep instead of 4), as it will save memory and might prevent strange behaviour later on.

By the way, to code a simple vertical star field scroll I need always to use a Dual Playfield or is there a simple way to do this using a Simple PlayField?

It's probably simplest to have a scrolling background using dual playfields, since that's effectively for free, but it's not the only way. You can also use a single playfield and buffered blits to draw your shapes directly on the background and then automatically erase them and repair the background, but that's a bit slower than the simpler blit and erase you can do with dual playfield. Still, it's also more flexible, allowing all 32 colours to be used everywhere, and if you only have a few shapes to blit, it should still be plenty fast enough.

[madaxe]

Thanks

I have one last question... for now

If I use a Dual PlayField for my main game is it possible to have a main menu bitmap using 16 color with only one IniCopList or is necessary to create two IniCopList? How to switch beetween them?

[Daedalus]

You'll need to create a new display for that. You can do it easily enough though, just create the CopLists for the different setups you want, and use a CreateDisplay command to go from one to the other.

[madaxe]

So, my code will be something like this:

InitCopList 0,$4 ; Menu
InitCopList 1,$36 ; Game

CreateDisplay 0
DisplayPalette 0,#MENUPAL
DisplayBitmap 0,#MENUBIT

While JoyB(1)<>1
   ; Press Fire to Start
Wend

CreateDisplay 1
DisplayPalette 1,#GAMEPAL,
DisplayBitmap 1,#FORE,0,xb,yb,#BACK,xf,yf

So, is it possible to call the same CreateDisplay command several times in the code?

[Daedalus]

Yep, that shouldn't be a problem. When the game is won or lost, use CreateDisplay 0 etc. to switch to the menu screen.

[madaxe]

Thanks, I'll do my best to make a simple but enjoyable game... I hope

Do you know why when we use Queue Blit the space erased is bigger than the shape itself? If my shape is 16x16 the space erased in the background is about 32x16. Is there any way to avoid this?

[Daedalus]

I think it will always be a multiple of 16 pixels wide. Are you sure your shape isn't 17 pixels wide by any chance? Even if it's empty / transparent pixels...

If you're trying to keep the background undamaged, try using buffered blits instead. They're a bit slower, but they leave the background back as it was before the blit, instead of simply erasing it.

[madaxe]

Yeap, it makes sense, but my shape is 16 pixels wide.

I'm using buffer blits for the most of the shapes but I'm also using queue blits for a few shapes that don't have a background bellow them. The problem is when they move they damage with empty space some stuff like the score panel and sometimes they even mess with other shapes. I'll redesign them to avoid this or use buffer blits. Thanks.