380 Sprite Version of Neo Thunder - Page 1

I made a video of my 380 sprite demo version of Neo Thunder. The original game (coded by Sebastian Mihai in 2011) had a lot of slowdown, so I was attempting to remove it as a coding exercise. After a lot of work(!), I found I could make a 380 sprite version at 60fps with no slowdown. (24 display lines left at end of each frame worst case scenario)

The game has 32 background sprites, 21 player bullets, 155 enemies, 170 enemy bullets and 2 player ship sprites (nose + tail stuck together) all at once = 380 sprites

It has full collision detection. (Invincibility is turned on but enemy-bullets + enemies will still hit the player)



All enemies are moved and collision-checked independently. It was just easier to put them all into a regular formation to test (+ to fit them on the screen)

I plan to make this version into a little game similar to the original, but tbh it will probably be worse than the original! More sprites do not make a better game and I don't want to spend a lot of time on it. The ship does have a much faster firing-rate to make up for the large number of enemies + bullets it will face though.

hello,

how do you test collisions ? is it pixel perfect ?

or just a smaller square box than the sprite size ?

it is just to evaluate what the 68000 can do in the NG , i already did some pixel perfect collisions on Atari Jaguar but i used the risc gpu at 26 mhz.

thanks

What would be more important is to know what you mean by pixel perfect. If it's overlaying two bitmaps (the ship and the bullet or enemies) I have a feeling that the 68k would struggle.

yes, pixel perfect is that one pixel touch another pixel, both non transparent on each sprite.

you start with X/Y comparison, and when in the same area as the source, you switch to "and" operations

ericde45 (./2) :
hello,

how do you test collisions ? is it pixel perfect ?

or just a smaller square box than the sprite size ?

it is just to evaluate what the 68000 can do in the NG , i already did some pixel perfect collisions on Atari Jaguar but i used the risc gpu at 26 mhz.

thanks

Hi, just with bounding boxes (Smaller than the sprite size : the bounding boxes fit the graphic size).

I think you said this, but if you really want pixel perfect collisions, you should do a bounding box collision first and then if that hits - do a pixel perfect collision check after.

No shmups use pixel perfect detection even in the arcade as far as I know e.g. Cave games use bounding boxes too. You dont really need pixel-perfect collision for shmups. Better to make it fast + simple.


I do my Player Bullet VS Enemy collisions like this :

1. First check *each enemy* against the *vertical* range of the player's fire (e.g. the highest bullet Y position and the lowest bullet Y position on screen).

2. For each enemy that passes that test, do a brute force collision check of that enemy with *every* player bullet as fast as possible (I did this in 68000, but about 50% of this program overall is in C).


Using this technique means the maximum number of collisions checks done ( Player bullets vs Enemies only) are about 550 per frame. Very manageable!

Also in this game, 94% of collision checks are terminated on the X-axis checks alone, so I heavily optimized on X axis checks (+ I do those first).


Hope that gives you some ideas. All shooters are different though!

j'attends la démo neogeo (CD) du coup

kuk (./6) :
j'attends la démo neogeo (CD) du coup

If you mean for Neo Thunder? The game should run just the same as the cart version. It's in the old dev kit so I think I just need to use the CD "make" file rather than the cart "make" file.

I'll do that at the end of the project when I finish though 👍

UPDATE: Neo Thunder Fast now uses 400 sprites! (with sprite multiplexing).

The maximum number of enemy bullets has been increased from 170 to 190.

It will now need a little optimization work to get it to always run at 60fps again. I was just trying to get the new routines working, so I didn't make them very efficient yet.





⬆️ In this screenshot, you can see the extra multiplexed sprites are coloured pink/magenta? (I am not good with colours) and the yellow line shows where the raster interrupt fires. On this display line, the VRAM is updated in order to re-use/multiplex sprites that have already been drawn higher up the screen.

The "189" value is the number of enemy bullets - 1 = 190 enemy bullets

Well done !

Zerosquare (./9) :
Well done !

Thank you 🙂 🙏 I had some time left at the end of each frame so I thought it was worth trying

I was thinking last night, there is another way to get more sprites on screen. But it seems too slow

You can use sprites 381-511. But the graphics chip only parses sprites 0-380. So the extra sprites would need to be written into the display list for *every line* the graphic image appears on. To calculate and do this would be very slow!

There might be some situation where this approach could be useful though?


i originally learnt this from mvstech.txt :

You can manually edit the active sprite list to specify sprites to draw,
and can specify any sprite number in the 0-511 range rather than being
limited to the first 381 sprites. However as only the first 96 entries
are parsed, you cannot force more than 96 sprites to be drawn per frame.

http://furrtek.free.fr/noclass/neogeo/mvstech.txt

EDIT : Looking at the memory map of the lower part of VRAM (character and attributes data) - the fix layer takes up memory slots from $7000 to $7FFF. So it seems that extra sprites 381-447 are available for use in this way