TG-16 vs Genny vs Snes.... Animation?

Quote:

---

Originally Posted by SilverCoin

I find it hard to believe that a Genesis/Snes is about the same as Capcoms CPS1 hardware..

---

Cps1 = 68k - 10mhz
z80 - 4 mhz


Genny = 68k - 7.68 mhz
z80 - 3.58 mhz

Closest port of cps1 on genesis - Chiki Chiki boys*

* = my opinion:p

Even if it uses the same main cpu, chances are they a lot of the code is still going to be re-written. Arcade games are notorious for huge sprite animation sheets (not the images themselves, but lookup tables for the animations and movement,etc). The graphic functions will also have to be rewritten. The arcade has a different tilemap size, cell size, more subpalettes, etc. The sprites functions will have to be re-written too; different sprite limits,subpalette requires, etc. The Genesis video is VRAM based while the arcade is rom based. This is a big difference.

In other words, a lot of the game code is going to be re-written and changed. When you play a Genesis game and it feels like the arcade, it isn't because the CPU's are the same. Logic is logic and doesn't matter what processor you're running it on - as long as it's fast enough. And timing is tied to vblank/refresh. If the arcade uses something close to 60hz, then a home port has no problem adapting. Funny, people in PAL land with games that are optimized to run the same speed as 60hz games - never seem to notice the difference in play mechanics or even complains. Even though there is a slight difference. After all, it's running at the same speed but at a lower frame rate which means some sort of interpolation in timing. The differences in resolution from arcade to home also changes the game control logics as well. Fixed point movement is on a different scale, etc.

Programmers of game conversions tend to approximate and/or simplify game control timing (even logic) for ports. It all depends on the developer.

Art of Fighting for the PCE ACD, has 68k code that's almost line for line converted to the PCE's CPU. They really went out of their way to keep the original game logic VS rewritting it from scratch. (Yes, I have seen the actual source code for this game. No, it's not available for public). I'm not sure about the other Neo Geo ports on the ACD though.

For the Super Nintendo, it's OAM is set up like this

vhppcccn nnnnnnnn
v: vertical sprite
h: horizontal sprite
p: bg priority
c: subpalette select
n: sprite name

when it should've been set up like this

vhpcccnn nnnnnnnn
v: vertical sprite
h: horizontal sprite
p: bg priority
c: subpalette select
n: sprite name

why did Nintendo need a second priority bit?

Quote:

---

Originally Posted by tomaitheous

4bit color cells. Smallest cell, IIRC, is 16x16. And IIRC, it has 256 subpalettes (4096k of ram). It also has two banks of these subpalettes. You can switch the subpalette bank on a scanline basis, but not on a cell basis.

---

and that's 4096 kbits of RAM? (512 kB) And what are you referring to by that? (as I understand it, there's 8-kB of palette memory, which makes sense, with 256 palettes with 16-entries each with 16-bits per entry -slected from the master palette- 256*16*16/8/1024=8)

According to several sites (including wiki) the smallest sprite tile size is 1x2, with the largest being 16x512, and supported by this rather reputable looking page: http://arcadedev.emuvibes.com/documents/neogeo.html

Also that page mentiones an 8-bit palette number used, which is a bit over my head, but is what made me think it might use 256 color subpalettes. (unless I am assuming right, and the Neo uses unpacked 4-bit pixels -4-bit/byte)

Also noticed that it lists 512 kbits of VRAM for both AES and Neo Geo CD, while I've seen several sites list the CD as having 512 kbytes.
edit: just noticed wiki listed it as 512 Kb, so that would be correct, but rather misleading without scrutinizing closely.