The Neo Geo was just a glorified Genesis.

[Guntz]

Don't forget Taito and the Bubble Bobble/Puzzle Bobble Series. ADK as well.

Hmm yes, funny to have forgotten Taito. They had some nice stuff on Neo, but barely any of it was on AES. As for ADK, I was under the impression they were mostly a second party developer.

[j_factor]

no doubt it can output more intense gameplay.

Are you sure you're not thinking of the Turbo Duo? Its games are much more intense than Sega's. It's got the arcade feel!

[kool kitty89]

Not so much the palette but the lack of color (the ST palette is as bad as the genesis). They compensated for the lack of color by changing it when they could (every scanline)

I meant that the ST's 9-bit RGB isn't as good for raster effects (like palette swaps) as the Amiga's 12-bit RGB, though still useful . . . unlike some platforms that couldn't really make use of that at all due to the limited color set (like the C64, TMS9918, etc).
The VCS/A8's large master palette (especially the emphasis on shades) made for great raster gradients as such.

And then there's cases like the NES, which has the color capabilities to be very useful for palette swap effects, but lacks hardware support for raster interrupts (and had a programming environment that didn't favor VSC-style cycle timed effects ) . . . and it doesn't seem that many/any mappers were used to change that limitation either.

But it completely lacked backgrounds, so those needed to be faked with sprites, countering a good amount of that advantage. That also made scrolling a bitch - guess why Metal Slug doesn't let you scroll in any direction (hint: the background is entirely made out of stripes).

You did mean to actually write "stripes" and not "sprites" right? (as in vertical strips -since sprites would be most efficient as vertical strips of 16 pixels wide -if you tiled with smaller sprites, you'd hit sprite limitations much sooner since you only have 384 sprites and even using 16x16 cells would eat that up really fast -unlike the FM Towns with 1024 sprites to work with )
And using strips/stripes like that could indeed make vertical scrolling a pain. I actually hadn't thought of that . . .

Without convenient tiling, you wouldn't be able to wrap the screen easily for diagonal scrolling . . . albeit you could extend sprites even further into overscan, but then you'd hit the sprite limits sooner too. (assuming you used 16x224 sprite cells for the BG, you'd need 2 or 3 times that for seamless vertical scrolling -3x if you allowed free scrolling in any direction, 2x if you only scrolled in 1 vertical direction)

So that's another real-world disadvantage for the Neo Geo hardware over the Genesis . . . and yet another aspect that would make the system very unattractive as a mainstream home console . . . and why games at similar ROM sizes to most Genesis games could actually have been worse on the Neo Geo due to said inefficiencies. (albeit, several contemporary arcade boards would have been much closer to making realistic home consoles -like the System 16 or CPS)


It should also be noted that the display list based "sprite" generation of the Atari 7800's MARIA, Atari Jaguar's Object Processor (and Atari Panther) wouldn't suffer those same problems since they don't have a hard limit on sprites in the way the Neo Geo does . . . though per-line bandwidth is practically limited as with most systems. (so you could simulate a "normal" tile based BG system on those platforms if you needed to -though using 8x8 cells would mean a LOT of objects to manage and a corresondingly more complex display list)

[Kamahl]

On the Neo Geo doing multidirectional scrolling isn't hard at all, just use sprite sizes twice as big vertically as the screen resolution is and replace the area they point to when the limit is reached. This does mean you need to keep a single gigantic image as the background in the cart, but that's kinda what you're supposed to do on the Neo Geo anyway .

[Sik]

You did mean to actually write "stripes" and not "sprites" right?

Yes.

since sprites would be most efficient as vertical strips of 16 pixels wide

Looking at the docs, the Neo Geo hardware only understands stripes, which are always 16 pixels wide. You can chain multiple stripes to make handling of larger sprites easier (since you only have to specify the coordinates once to move them all), but ultimately the hardware works in terms of stripes.

you only have 384 sprites

384 stripes, not sprites. Additionally, there's a limit of 96 stripes per scanline (1536 pixels).

And using strips/stripes like that could indeed make vertical scrolling a pain. I actually hadn't thought of that . . .

Which is why there isn't much vertical scrolling in the game... Usually when there is it's just a diagonal that barely moves vertically (though there are exceptions). Take into account I'm not talking about small stripes, they're as high as the screen.

On the Neo Geo doing multidirectional scrolling isn't hard at all, just use sprite sizes twice as big vertically as the screen resolution is and replace the area they point to when the limit is reached.

Stripes can't be larger than 256 pixels, so you'd need two of them.

This does mean you need to keep a single gigantic image as the background in the cart, but that's kinda what you're supposed to do on the Neo Geo anyway .

Metal Slug does that anyways!

Also calculated what'd happen if it used 32×32 "chunks". That'd take up 140 stripes to cover the entire screen. That leaves 244 stripes for the parallax and the sprites.

EDIT: for the record, they promoted this all-sprites idea as being an advantage:

"Characters are more freely distributed than are those produced using boards which have separate scroll and sprite patterns."

Considering what appeared in fourth generation consoles, they may have still gotten some advantage (given that the amount of sprites is huge), but it definitely was weak in comparison to what other arcade systems had. (note that it refers to the stripes as sprites)

EDIT 2:

The display can be dimmed by using the shadow bit output.

It's S/H all over again! (guess that explains the weird format of the RGB palette entries, but sadly it doesn't seem to be very clear...)

EDIT 3: diinlned? Seriously? This is what you get when you copypaste using OCR.

[Kamahl]

Neo Geo sprites supposedly go up to 512 pixels in height.

[Sik]

Rechecking the docs, and yeah, seems like 32 characters (512 pixels) is the limit, though apparently if you set the height as 33 then it enables some special looping mode where the sprite's bottom will connect to the top, like it was scrolling o_O Also the docs insist that the sprite limit is 380, not 384... I already found that number several times, so I doubt it's a typo.

And to whoever thinks the Sega docs are horrible: you haven't seen the Neo Geo ones. UGH.

[kool kitty89]

Rechecking the docs, and yeah, seems like 32 characters (512 pixels) is the limit, though apparently if you set the height as 33 then it enables some special looping mode where the sprite's bottom will connect to the top, like it was scrolling o_O Also the docs insist that the sprite limit is 380, not 384... I already found that number several times, so I doubt it's a typo.

That looping feature would seem rather limited . . . like for a simple repeating scrolling BG, perhaps less so if you could loop a set of chained stripes (so a longer loop rather than just a fixed 512 pixel stripe).
It also makes it more like scrolling a framebuffer . . . and if stripes could be red from RAM, you could potentially software blit to said looping framebuffer. (or have an actual blitter included -and that's one neat thing you can do in the Jaguar, use the blitter to build sprite objects from a set of smaller tiles/textures)

Looking at the docs, the Neo Geo hardware only understands stripes, which are always 16 pixels wide. You can chain multiple stripes to make handling of larger sprites easier (since you only have to specify the coordinates once to move them all), but ultimately the hardware works in terms of stripes.

So it's somewhat like Amiga sprites (fixed horizontal size, vertical size as large as the screen), though different in other respects.


Another option for Neo Geo games would be to design everything (or nearly everything) as separate objects that get composited and manipulated similarly to player sprites. (rather than solid BG layers, you'd have a composite of separate objects) That could be taxing on sprite bandwidth too, so you'd have to optimize art design around it.
However, it could also be advantageous in terms of making more efficient use of color and animation since you'd have the BG as a composite of flexible objects. (hmm, are stripes limited to 15 colors per stripe, or 15 colors per character?)

[Kamahl]

hmm, are stripes limited to 15 colors per stripe, or 15 colors per character?

Character, though I'm not 100% sure.

[Sik]

That could be taxing on sprite bandwidth too, so you'd have to optimize art design around it.

Yeah, but remember you have enough bandwidth to cover 4.8 times the screen width in a scanline. The fullscreen sprite limit would be more of a bitch, I think.

hmm, are stripes limited to 15 colors per stripe, or 15 colors per character?

Seems you can specify these values for each character in a stripe:

• Which character to use
• Which palette to use
• Horizontal flipping
• Vertical flipping
• Automatic animation

These parameters are specified for the entire stripe instead:

• Horizontal position
• Vertical position
• Horizontal shrink (16 steps)
• Vertical shrink (256 steps)
• Number of characters
• Chain bit

[kool kitty89]

Yeah, but remember you have enough bandwidth to cover 4.8 times the screen width in a scanline. The fullscreen sprite limit would be more of a bitch, I think.

I was also mistaken in thinking of the stripes as individual bitmap objects rather than built from tiled characters . . . so you already would have a good bit of flexbility for character-oriented optimization to make the most of ROM. (albeit, compositing still offers some flexibility beyond tile based optimization, but tiling alone makes for much more efficient animation and color use)


And, in any case, you'd still need all graphics uncompressed in any case. (since everything is red directly from ROM -unless you added RAM on cart and a suitable interface to flip between the CPU and VROM busses)

Seems you can specify these values for each character in a stripe:

• Which character to use
• Which palette to use
• Horizontal flipping
• Vertical flipping
• Automatic animation

These parameters are specified for the entire stripe instead:

• Horizontal position
• Vertical position
• Horizontal shrink (16 steps)
• Vertical shrink (256 steps)
• Number of characters
• Chain bit

These are 16x16 character cells, right? (so like the PC Engine's sprites, but unlike the Genesis's 8x8 sprite cells -and obviously unlike the PCE/MD/SMS/SNES -or most arcade- tilemaps)

So you'd potentially have greater flexibility for MD sprites (and obviously BG tiles -also 8x8) due to the smaller cell size and greater potential for re-used patterns. (granted, in the context of the way the Neo Geo was actually used, this is a non-issue since most graphics were treated as solid bitmapped images rather than using tiling at all -which, of course, wouldn't be at all realistic for a normal home console, and would also potentially make it less cost effective in the arcade -compared to hardware making more efficient use of ROM . . . though that's always software/programmer dependent too)


The use of characters in combination with the looping stripe feature could also make vertical scrolling more doable too. (using characters in a conventional tilemap fashion, swapping them out as needed at the top/bottom)

[Sik]

These are 16x16 character cells, right? (so like the PC Engine's sprites, but unlike the Genesis's 8x8 sprite cells -and obviously unlike the PCE/MD/SMS/SNES -or most arcade- tilemaps)

Yes, when the manual refers to characters it means 16×16 tiles.

The only place using 8×8 tiles is the FIX map, which is a 40×28 tiles non-scrollable tilemap that always appears above sprites. It's usually only used for the HUD.

The use of characters in combination with the looping stripe feature could also make vertical scrolling more doable too. (using characters in a conventional tilemap fashion, swapping them out as needed at the top/bottom)

Indeed. Actually, the fact you can specify each character in the stripe separately (flipping included) actually makes it much easier to fake a scrolling tilemap using stripes... so maybe this is a non-issue in the end.

EDIT: also the X coordinate is 9 bits only, and I assume that's how the video hardware processes it, so I assume that combining this with the chain bit would effectively let you fake a "proper" tilemap (since after 512 pixels it'd loop - that'd take up 32 stripes though, unless you set the height of non-visible stripes to 0 so they don't count).

The main issue then would be to do linescrolling...

[TrekkiesUnite118]

So was I correct about the VDP2 bitmap mode or not?

[sheath]

I am not entirely certain, but I seem to recall the VDP 2 being able to scale and rotate 512x512 tiles, which ought to be on the level of handling a bitmap.

[Sik]

I am not entirely certain, but I seem to recall the VDP 2 being able to scale and rotate 512x512 tiles, which ought to be on the level of handling a bitmap.

The VDP2 can apply mode-7 style effects on all layers - even the VDP1 framebuffer, if I recall correctly.