requin_frederic2 wrote:

> I have read your thread about the NeoGeo on Pacedev. Very interresting.
> You said the sprite engine was causing you problems. How come ?

Mostly because I've been procrastinating in putting it off! :( I can boot
Joy Joy Kid and it's running happily - I can even start a game. But as you
probably know, the NeoGeo is really one big sprite engine, and tilemaps are
seldom used, so you don't get to see a lot on the screen other than the score...

I do need to bite the bullet and get a start on it. I have already added
some dual-port sprite memory and have confirmed that the sprite registers
are updated while the game is running...

It's probably no coincidence that my NES implementation is at pretty much
the same point. :(

> FYI, the 1943 sprite engine I wrote can handle 128 sprites and the whole
> graphics chipset takes less than 3000 LEs. Of course, it is not
> implemented like an Amiga or C64 sprite engine. The sprites are rendered
> sequentially, one line ahead, in a line buffer.

Nice! The NeoGeo will work exactly the same way. In fact, if you look at the
NeoGeo reverse-engineering documents and the timings it's pretty clear that
the actual hardware does exactly that.

It's one of those things that is probably not _too_ difficult once you get a
start on it. What has deterred me a little is the code-build-test cycle
times with the TG68 core and everything else... I need to come up with a way
of testing the sprite engine without a CPU core or SDRAM controller. Again,
not difficult, just need to do it.

Regards,

--
| Mark McDougall | "Electrical Engineers do it
| <http://members.iinet.net.au/~msmcdoug> | with less resistance!"