Sprite hardware vs blitting sprites

[Nightfox]

Hi there

I was just beginning experimenting making a platformer game on amiga and would like advice regarding sprites.

What is the best practice regarding when to use a hardware sprite vs blitting the sprite to your Playfield using the blitter/CPU?

Only 8 hardware sprites per line (4 if you want 15 colour ones) does seem like quite a large limitation and wondered if its inefficient to just blit everything and leave hardware sprites alone?

[jotd]

sprites are really a great cpu/blitter time saver. If you want 50fps, you have to make use of the sprites some way.

You don't have to blit and you don't have to preserve the background/blit a part of it because the character "eats" it when blitted.

Sprites are mostly used in commercial games for:

- main character (examples: Jim Power, Oscar, use 4 sprites for the main character, project X uses sprite for the player ship)
- background (with multiplexing)

And most games use interleaved bitplanes so there's only one blit to do instead of <nb planes> blits. Allows a maximum parallellization with the CPU.

not too much for enemies, as if there are several enemies on the screen you can't easily reuse the same sprite data, unless this is a special game where enemies can't be on the same raster line.

You can also use the CPU to draw stuff while the blitter is drawing somewhere else instead of stupidly waiting for the blitter to finish (like I'm doing ...

Of course, combining sprites, BOBs and CPU-blitted objects makes the code very specific and complex, but you'll get speed.

mcgeezer has made a brilliant BOB/sprite engine where it seems that the engine can choose to use sprite or BOB depending on the position... sounds tricky!

[roondar]

Yes, always use as many hardware sprites as you can. They're so efficient compared to using bobs that it's almost always worthwhile at least properly considering their use.

[phx]

Note, that you cannot use sprites for the main character (or enemies) when you want to draw them between a foreground and background tile layer. This and the color palette restriction always prevented usage of sprites for anything else than scores, status displays and parallax layers in my own games.

[Pyromania]

What games have you done phx?

[malko]

^ have a look at Celtic Heart (code available as well) or Solid Gold, or Trap Runner, etc.

[Tigerskunk]

If your objects are distributed more on the vertical than the horizontal side, you can do some nice sprite multiplexing with OCS hardware.
You'd be astounded on how many 32px wide 15 colour objects you'd get with multiplexing two of them..

And it gets much better if you have only 3 coloured ones or 16px width.

[jotd]

yes, problem with sprites is that it makes your engine non generic. You can't reuse an horizontal scroller as is for a vertical one because you've used sprite tricks (reuse, priority). With BOBs you don't have this issue. But you'll waste time.

[Nightfox]

Originally Posted by phx

Note, that you cannot use sprites for the main character (or enemies) when you want to draw them between a foreground and background tile layer. This and the color palette restriction always prevented usage of sprites for anything else than scores, status displays and parallax layers in my own games.

I guess you could use any free sprite slots to draw a layer in front of the hero if it's thin enough.. like walking behind a tree

[WayneK]

Originally Posted by jotd

yes, problem with sprites is that it makes your engine non generic. You can't reuse an horizontal scroller as is for a vertical one because you've used sprite tricks (reuse, priority). With BOBs you don't have this issue. But you'll waste time.

But if you're determined to make your engine 100% generic, and you're trying to code an optimised engine for a 198x/199x target platform, you should probably find an easier way to hurt yourself

[DanScott]

If you want to make a killer Amiga game, you have no choice but throw out the idea of a "generic" engine... perfomance has to be optimised for the game you are choosing to write

[jotd]

or have a generic basic engine that does the basic stuff (control, sound, blits) and add blitter, scrolling and copperlist stuff for your specific usage for each game.

That way you can have a mockup running quickly, and add the optimizations later. Blitter/sound doesn't rely on copperlists (except if you want to blit with copper...)

[pink^abyss]

Originally Posted by DanScott

If you want to make a killer Amiga game, you have no choice but throw out the idea of a "generic" engine... perfomance has to be optimised for the game you are choosing to write

That is very true. And if you design a game around the limits of your specific hardware then you will come up with something unique.


ps.:

Nice 64k intro Dan! The wobbly credits were the best

[Tigerskunk]

I once had a BOB engine running next to a multiplexer sprite engine, and a flag in the object's struct determined if it's a BOB or sprite, and depending on that the object was handled.
That works quite well, you need to have the assets done in Sprite format though.

A completely generic engine is not that easy to accomplish, imo, and not sure if I would want that.

[dodke]

I'd say, if you have an optimised tile engine (raster split, corkscrew etc) with interleaved bitplanes drawing only one or two tiles per frame, you should have plenty of time to use bobs for 'enough' stuff moving around the screen for a very decent game at least in 16 colours. Then you can use sprites for overlays or some special effects.
If you use dual playfields then the amount of colours in them is probably too strict for a main character as well so you should use sprites for that at least.

[Nightfox]

Originally Posted by dodke

I'd say, if you have an optimised tile engine (raster split, corkscrew etc) with interleaved bitplanes drawing only one or two tiles per frame, you should have plenty of time to use bobs for 'enough' stuff moving around the screen for a very decent game at least in 16 colours. Then you can use sprites for overlays or some special effects.
If you use dual playfields then the amount of colours in them is probably too strict for a main character as well so you should use sprites for that at least.

A bit off topic but you mentioned the game being 16 colours. I'm still new to learning how the Amiga performs under different conditions. So I haven't learnt yet how to balance quality with performance. Does that mean my tiny little game engine that doesnt do anything yet using my placeholder graphics in 64 colour halfbrite mode is too much to achieve good performance? I'm not relying on that screen mode since my graphics I did in deluxe paint are still only temporary placeholder ones and will get replaced.

On that note, is there a guide somewhere on the do's and don't's of amiga game coding? It's so different from making an OpenGL game today where I can throw anything I want at it haha

[Tsak]

It really depends on the type of game and your target platform. If it's an action/shooting game with loads of moving stuff, if it involves scrolling, you want it at 50fps and your target platform is a500 then 16 colors is obligatory. You can then use copper tricks for more colors on screen. And sprites have their own palette so colors will be more overal if you do use them as well. 64 colors is only good (but still not ideal due to ram limitations) for something like a point'n'click adventure game (on OCS).

Any mix of the above parameters (f.e. have the game running at 25fps instead of 50fps) could allow for more flexibility in terms of color usage. Always keep in mind that the two competing obstacles you have is performance and ram.

[DanScott]

Originally Posted by pink^abyss

Nice 64k intro Dan! The wobbly credits were the best

Ah thanks!! That's one of the 2 parts I didn't code

[olleharstedt]

Sprite vs blit also has consequences for collision detection.

[Nightfox]

Awesome cheers. And if I was to make an AGA version of the game, is 256 colours too much for a 50fps platformer?