How many sprites can the Neo Geo update per frame?

[psycopathicteen]

At first glance it might seem like the Neo Geo can update "all of them," but today I realized that the Neo Geo's oam is 48kB, and that it would take a long time to update all of them. I don't know if the Neo Geo has DMA or not, nor if I know if you can write during active display, but now I realize that this could be a bottleneck to the system.

[koitsu]

Note: I know jack squat about the NeoGeo (and there are multiple system types, some which have capabilities/hardware others might not).

Skimming http://wiki.neogeodev.org/ turns up some interesting things:

1. DMA is available but only on systems that have CD drives, I guess the LC8953 chip. DMA cannot be done outside of VBlank, so anything timing-sensitive would need to be done entirely in software during HBlank. No idea if you can write to VRAM when the GPU is actively drawing or not, but the system does appear to have a native interrupt timer that can fire at specific intervals allowing for precise scanline effects (not sure if mid-scanline or not), but has many caveats.
2. The native CPU (68000) can push, according to the DMA wiki page, around 2MBytes/second using repeated MOVE.L instructions (that's a 32-bit move).
3. How sprites work on this system is quite different from anything else I've worked on, but I'm not all that surprised since it's mainly arcade-quality stuff rather than (less expensive) consumer hardware (don't ask me about the NeoGeo AES).

References for all of this:

https://wiki.neogeodev.org/index.php?ti ... _rendering
https://wiki.neogeodev.org/index.php?title=DMA
https://wiki.neogeodev.org/index.php?title=Sprites
https://wiki.neogeodev.org/index.php?ti ... ics_format
https://wiki.neogeodev.org/index.php?ti ... ne_effects
https://wiki.neogeodev.org/index.php?ti ... interrupts
https://wiki.neogeodev.org/index.php?ti ... n_pitfalls

And here's the memory-mapped register doc:

https://wiki.neogeodev.org/index.php?ti ... _registers

[mikejmoffitt]

Fortunately, working with the AES and the MVS is the exact same deal. There is a minor difference in how sprite data is retrieved from the cartridge, mainly that a part that is usually on-board the MVS is expected to be in the AES for serialization of tiles (this also affects the tables for sprite shrinking).

I don't think there's a lot available especially to facilitate sprite attribute updating itself, but the system has a very powerful mechanism for chaining sprites together, as well as auto-animating tiles. The arrangement of a sprite's tiles in VRAM are reminiscient of the Genesis / Mega Drive - the tiles progress in vertical stripes from top to bottom. Look at this article on the "Sticky bit".

What I'd really love to see is something like the Mega Drive - oriented SGDK, but targeting the Neo-Geo. The attraction is the completeness of the toolchain and relative ease of setup.

Koitsu, I thought the 68000's longword moves were performed as two 16-bit word moves with an auto-increment. Is there really a substantial speed difference?

[tepples]

As I understand it (I have looked at ARM7TDMI timing charts but not 68K), the savings come from the von Neumann architecture, which interleaves fetching of instructions and data. Move 32 bits in one instruction and you need not fetch another instruction to move the other 16 bits. Move 256 bits in one instruction (LDMIA/STMIA on ARM or MOVEM.L on 68K) and you save even more time.

[koitsu]

Koitsu, I thought the 68000's longword moves were performed as two 16-bit word moves with an auto-increment. Is there really a substantial speed difference?

Don't know -- I know jack squat about the 68000. All I did was read some documentation/web pages describing the move opcode: http://mrjester.hapisan.com/04_MC68/Sec ... Index.html

How I interpret the information shown there: .b uses bytes (8 bits), .w uses words (16 bits), and .l uses "long word" (32 bits). How this is implemented internally (e.g. move.l might move two 16-bit words (high word, then low word)) is irrelevant to me because the end result would be the same (32 bits of data got moved). Is that not correct?

[psycopathicteen]

From what I read in another document, the VRAM port can be written to every 12th cycle and is 16 bits wide. 12 just happens to also be the number of cycles it takes to move a word with the 68000, so there that means it can update 33kb per frame, but 5kb during vblank.

[ccovell]

I dunno about the timing of everything, but just by observing games you can see what a lot of them do.

Sengoku 2 changes sprite X-scale values in HBlank, allowing for a "perspective" effect. So, HBlank (mid-screen) sprite RAM writing is valid and possible.

Many games, if you watch near the top of the screen, have a shearing effect on objects, meaning there wasn't enough time to update sprites in VBlank, and it's spilling into the screen. No glitches beyond that.

[mikejmoffitt]

I dunno about the timing of everything, but just by observing games you can see what a lot of them do.

Sengoku 2 changes sprite X-scale values in HBlank, allowing for a "perspective" effect. So, HBlank (mid-screen) sprite RAM writing is valid and possible.

Many games, if you watch near the top of the screen, have a shearing effect on objects, meaning there wasn't enough time to update sprites in VBlank, and it's spilling into the screen. No glitches beyond that.

I've never seen this on any games, but I don't own a lot of Neo-Geo games. Which ones in particular have this shearing problem?

[Sik]

Koitsu, I thought the 68000's longword moves were performed as two 16-bit word moves with an auto-increment. Is there really a substantial speed difference?

By general rule it just increases the instruction duration by 4 cycles (every access to memory takes up 4 cycles, no exception), regardless of what addressing mode is being used. So yes, it's pretty much guaranteed to be faster than discrete move accesses.

Also trivia of the day: the Super A'can has a system similar to the Neo Geo in that sprites are their own tilemaps (or at least that's what I can gather from the little that's emulated in MESS).

[mikejmoffitt]

Koitsu, I thought the 68000's longword moves were performed as two 16-bit word moves with an auto-increment. Is there really a substantial speed difference?

By general rule it just increases the instruction duration by 4 cycles (every access to memory takes up 4 cycles, no exception), regardless of what addressing mode is being used. So yes, it's pretty much guaranteed to be faster than discrete move accesses.

Also trivia of the day: the Super A'can has a system similar to the Neo Geo in that sprites are their own tilemaps (or at least that's what I can gather from the little that's emulated in MESS).

Whoa, 68000 with a little 6502 buddy! You don't see that every day.

[NeoOne]

At first glance it might seem like the Neo Geo can update "all of them," but today I realized that the Neo Geo's oam is 48kB, and that it would take a long time to update all of them. I don't know if the Neo Geo has DMA or not, nor if I know if you can write during active display, but now I realize that this could be a bottleneck to the system.

Just saw this when I was searching for some Neo Geo information and thought I would answer!

I am currently doing some work on a Neo Geo game. The vertical blank period is 40 display lines in length and it takes about 12 display lines to update the X *and* Y cords for all 380 sprites. (This is doing it absolutely optimally). As for the character tiles. In a real game situation it would be hard to update those optimally but I think you could easily update 400 of them alongside *all* the X and Y coords of each sprite. However this is not *all* of the tiles, since each sprite is made up of 32 of these (16 x 16 pixel) tiles. Each Neo Geo sprite is 16 pixels by 512 pixels in size (yes over twice the height of the screen!)

You can write to VRAM (+ update sprite info) at any time on the Neo Geo but of course, you should do it smartly avoid sprite tearing.

Don't forget though, that the Neo Geo can join together any number of sprites and then move them with just one write for X and Y and it also has automatic animation (either a 4 or 8 tile sequence). So bullets for example could use auto animation, so there is no need to update the tiles yourself in those cases

Also when animating sprites - like on all systems - you don't animate them every frame and you can easily synchronize animations so they don't need updating on the same frame as a lot of other objects

Only the Neo Geo CD has DMA and I've read it is actually slower than using the 68000 to transfer data(!) But apparently it's useful to stop people taking Neo Geo CD games and putting them straight on the cartridge system

[Pokun]

Since the backgrounds are composed of sprites instead of the tiles, and sprites are thin, there are a lot of sprites that needs to be moved just for scrolling the screen. But I guess you just use the sticky/chain bit for moving the entire background at once, effectively turning a single sprite's X and Y to a scroll offset register.

[NeoOne]

Since the backgrounds are composed of sprites instead of the tiles, and sprites are thin, there are a lot of sprites that needs to be moved just for scrolling the screen. But I guess you just use the sticky/chain bit for moving the entire background at once, effectively turning a single sprite's X and Y to a scroll offset register.

You need 21 sprites displayed side by side for a fullscreen horizontally scrolling background. Ideally you move them in 2 groups (like you say using the sticky bit). Honestly though, the CPU is fast enough to move them 1 by 1. It's not going to take much time to do.

You could join up 32 sprites and move them all as one group - that wraps round on itself automatically. However the extra sprites off the side of the screen will count towards the horizontal sprite limit. So it's a bit wasteful. Some commercial games do it this way though

Vertical scrolling - the sprites join up perfectly top to bottom so it's very easy to do

Really the great thing about using sprites for everything, is that everything on screen (including the backgrounds) can then be scaled in-and-out using the Neo Geo's sprite scaling ability. Also makes the system very flexible.

[Pokun]

You need 21 sprites displayed side by side for a fullscreen horizontally scrolling background. Ideally you move them in 2 groups (like you say using the sticky bit). Honestly though, the CPU is fast enough to move them 1 by 1. It's not going to take much time to do.

You could join up 32 sprites and move them all as one group - that wraps round on itself automatically. However the extra sprites off the side of the screen will count towards the horizontal sprite limit. So it's a bit wasteful. Some commercial games do it this way though

I see thanks, that's good to know.

Vertical scrolling - the sprites join up perfectly top to bottom so it's very easy to do

So vertical scrolling is as easy as incrementing/decrementing the Y-value of the sprites and they will wrap around automatically, then you just switch out the top- or bottommost sprite character cel before they get into view.

Really the great thing about using sprites for everything, is that everything on screen (including the backgrounds) can then be scaled in-and-out using the Neo Geo's sprite scaling ability. Also makes the system very flexible.

Right, some fighting games like The Last Blade zooms the whole screen in a way that is more common with 3D-fighting games. Neo Drift Out also does this and League Bowling zooms part of the screen when rolling the ball.
Most games seems to mainly use it for scaling things like enemy sprites, but they can be pretty much any size thanks to the flexible spriting hardware.

[NeoOne]

So vertical scrolling is as easy as incrementing/decrementing the Y-value of the sprites and they will wrap around automatically, then you just switch out the top- or bottommost sprite character cel before they get into view.

Yes that's right, you just write a row of 20 tiles at once (1 to each sprite). The VRAM port has an auto-increment so you can set it so it automatically changes the write address to the next sprite along. So its 20 writes (12 CPU cycles each)

Right, some fighting games like The Last Blade zooms the whole screen in a way that is more common with 3D-fighting games. Neo Drift Out also does this and League Bowling zooms part of the screen when rolling the ball.
Most games seems to mainly use it for scaling things like enemy sprites, but they can be pretty much any size thanks to the flexible spriting hardware.

Yes the Art of Fighting and Samurai Shodown games are also very famous for this. Its all sprite reduction really, so the sprites never get the huge chunky pixels. Some games even fake traditional sprite scaling (like in Outrun etc) and make the sprites look blocky when they are large. I remember Alpha Mission 2 (ASO 2) does this when the ship zooms in at the start of the level



A disadvantage (+ advantage!) of the Neo Geo cartridge system is that all graphics are displayed straight from the ROM. This is very fast (you never need to move any graphics to VRAM first) but it means you can't edit any graphics or make your own bitmaps. If you want a bitmap you can actually change, you have to do your best to fake it with sprites or/and palettes.