Shmup console, give me your specs EDIT: *PICS*

[Shatterhand]

Ugh, my head aches just to think about coding something like this.

I said that because some MSX games, besides using sprites, also used Shapes, something I could never understand exactly what it was.

And I believe few games used just a few moving pixels to represent bullets, which should be faster I believe, but I don't know how you would sprite collision.

Come to think about it, does Donpachi ever goes above 128 sprites on screen?

And if the screen resolution is just 256x256 , maybe 128 sprites could be enough....

[mice]

I might include some bios-code to handle a thing like that actually. Mem-copy code that takes width, height and offset. Kind of like a blitter but with code.

This is oNyx picture, but set to a 256x224 screen size, and it clearly is more than 128sprites on it. Too bad...


I might be able to up it to 256 sprites though, but not 384 as I originally thought.

[Shatterhand]

But Onyx's shmup is, well, a little overboard, isn't it?

I personally have lots of great shmup ideas that would work with just 256 sprites. 384 would be awesome, but it can work very well with 256 (Even more considering we can have sprites as big as we want)

And honestly, flicking sprites can work sometimes. Elfmania on Amiga (A beat'em up, not a shmup) is regarded as one of the most beatiful games ever on a ECS system, and lots of stuff flicked on screen, not to mention some animated backgrounds would just slowdown the animation, or just STOP completely when the action was too much crowded...

and I personally NEVER noticed nothing of this up until before The One Magazine had a feature on amiga games which were technically impressive, and asked Andrew Braybrook to look at those games. Elfmania was one of the games, and then he explained how they made some incredibly animated backdrops with so much action on screen... lots of stuff flicker and the animation stop sometimes... but in the middle of the action, it's hard to notice. (And like I said, I had never noticed before I read that article).

So, I think flicker can work if someone needs more sprites, it just has to be done rightly... (I.E. people don't like to die because of bullets he couldn't see )

[AntiPasta]

wow, great to hear some update on this project! How did you get GCC to cross-compile to this (assuming you mean GCC)? I hear that's a helluva hackjob...

[ELLioT]

About the sprite number limitation:
As far as I know, on most hardware systems the max sprite number is for 1 raster line, not the whole frame.
This means that you can trigger an interrupt at a given raster line to setup new coords & address for 1 sprite (that has already be drawn) to display it a second time.
Imagine that the 1st Vertical position of your sprite is Y=49 and the sprite height is H=16, you trig an interrupt at the raster Y+H=65 to setup the same sprite at a subsequent Y coord.
On the Amiga, we used this technique to display a complete 2D starfield on the whole screen using only 1 sprite. It was especially easy thanks to the Copper co-pro which was designed to access hadware registers synchronized with the X-Y position of the raster. Battle Squadron also displayed all its ground ennmies using 1 & only sprite if I'm not mistaken.

With such tecniques, the limitation on 128 per horizontal raster line is way enough, imo. It requires some hardware feature to work though : H-Blank Interrupt + a bit of Asm code...
OR : you could give a sprite NOT just 1 setup registers set (coords, adress...), but an array of registers sets. The hardware would automaticly load&setup the next set when the last line of the sprite has been drawn. That's about what the Copper did on the Amiga.