Prototyping NES games with PC pseudo-arcade games
Moderator: Moderators
Re: Prototyping NES games with PC pseudo-arcade games
Cool. I am however still confused. The MAME source code is huge and graphics chips' sources are located in 'mame0168s\src\devices\video' as far as I can tell. However, there is many chips, there is absolutely no explaination of which chips is used where and how they work, just source code. How is that useful ? If you are able to tell how those chips work just looking at this source code, then you are really a genius.
In the rare case where information about graphics are available on System-16 website, such as for the Namco System 1, there is still no information about the used chip for graphics, only that a motorolla 6809 processor controls them.
EDIT : I found out about 'mame0168s\src\mame\drivers' which is where the most interesting stuff is. Nevertheless it's a shame there is no more documentation that comments in the source code itself (which are very well commented indeed).
In the rare case where information about graphics are available on System-16 website, such as for the Namco System 1, there is still no information about the used chip for graphics, only that a motorolla 6809 processor controls them.
EDIT : I found out about 'mame0168s\src\mame\drivers' which is where the most interesting stuff is. Nevertheless it's a shame there is no more documentation that comments in the source code itself (which are very well commented indeed).
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Prototyping NES games with PC pseudo-arcade games
And as a result, 2048 x 2048 pixel tilemaps... (The CPS 1 and 2 have one)AWJ wrote:Capcom liked to use big tiles
Uhh... Was this a 80's only thing?mikejmoffitt wrote:For most games it was expected that the game run full speed
Really? I though they were mostly the same as console hardware, except usually with less work ram and chr rom. For "specific type of game", I'd say something straightforward where you constantly need to be moving, so no RPGs or a lot of platformers. Racing games did seem to have their own dedicated hardware though. (And Sega did made a new arcade machine for just about every game.) Overall, they seem like they were made with more than one type of game in mind, even some of the less advanced ones.mikejmoffitt wrote:Arcade games, unlike console games, were almost always running on hardware designed explicitly for the game, or on a powerful general purpose platform. The game's design shaped the hardware for the most part, and hardware-specific limitations did not have a large roll in giving games character.
Never mind...AWJ wrote:starfield generator
Anyway, about hardware from about the time period, this is about what I think of: (although I'm not even sure if such a machine exists)
320 x 224 pixel resolution
2 BG layers
512 x 512 pixel tilemaps
8 x 8 BG tiles
128 sprites
16 x 16 sized sprites
320 sprite pixels per scanline? (maybe more)
512 palette entries (256 colors or BGs, 256 colors for sprites)
12 bit color
4bpp graphics for everything
Maybe this is too beefy though, a lot more "average" than low end. Keep in mind though, like what had been said earlier, a lot of games wouldn't actually make you think that they aren't running on a system that powerful. R-Type II ran on the same hardware as the first game, even if (in my opinion) R-Type II looks much more technically impressive. (The first game looked like it was using the Genesis's color capabilities, even though the hardware has 512 palette entries and has 15 bit color depth.) Just look at the Namco System 1's games, and than the actual hardware... It's like they weren't even trying. (Or just wanted bragging rights or something.)
Re: Prototyping NES games with PC pseudo-arcade games
This is fairly close to the Genesis (except sprite count and palette size) or to the SuperGrafx, which is two TG16 VDCs feeding the VCE palette chip through a priority encoder. In fact, the Genesis hardware was reused in low end arcade boards: Mega-Tech System used a time-buy system that was essentially Sega's version of the PlayChoice, and System C and Mega Play used the more traditional lives buy system.Espozo wrote: Anyway, about hardware from about the time period, this is about what I think of: (although I'm not even sure if such a machine exists)
320 x 224 pixel resolution
2 BG layers
512 x 512 pixel tilemaps
8 x 8 BG tiles
128 sprites
16 x 16 sized sprites
320 sprite pixels per scanline? (maybe more)
512 palette entries (256 colors or BGs, 256 colors for sprites)
12 bit color
4bpp graphics for everything
Likewise from Final Fight to Street Fighter II Turbo on Capcom's CPS1.R-Type II ran on the same hardware as the first game, even if (in my opinion) R-Type II looks much more technically impressive.
Re: Prototyping NES games with PC pseudo-arcade games
I guess it was uncommon to try to push arcade hardware to its limit. Games were developed on with a deadline etc, and if it was too hard to implement something on hardware they'd either a) Buy better hardware to run the game or b) Remove features from the game so that it fits the planned hardware. Trying to exploit every bug of chips to make something crazy wasn't the philosophy - as nobody would notice.Just look at the Namco System 1's games, and than the actual hardware... It's like they weren't even trying. (Or just wanted bragging rights or something.)
On consoles however the players would notice, as they can compare with other games using the same hardware.
This leads me to another question : Was there a time where 3BPP graphics were the most used between the 2BPP age and the 4BPP age?4bpp graphics for everything
It seems that (320, 288, 256) x (224, 240) were all equally common.320 x 224 pixel resolution
I guess the main advantage of having 224 vertically is to avoid overscan issues on NTSC.
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Prototyping NES games with PC pseudo-arcade games
It's kind of sad that even in its 14 year run, the Neo Geo was never really pushed very far. I don't know why I just thought about that. But yeah, it seems that once arcade game creators ran into a problem making a game, they'd just create a more powerful system, even if the game could have been recreated on the older system (often even perfectly) but more care would have had to been put into it. Sometimes, I almost feel that they make the newer hardware for a game that they think isn't going to work on the older hardware, but it ends up it could perfectly fine. Fire Barrel for the Irem M107 doesn't use 4BG layers or more than 256 sprites at one time, even though the system it was built for was solely based around that, and both the Irem M92 and M107 are pretty much the same thing, so why it ended up being for the M107 is beyond me. There's a game that's actually on both arcade boards, as in it's ported, not that it's the exact same board because of differences where registers are and stuff like that. Sega were always the people who made a new board at the slightest technical obstacle they'd run into. They even made a redesigned Naomi for "enhanced fire and water effects": http://www.system16.com/hardware.php?id=724 (I remember that firefighter game and the pod race game being pretty fun, as they were at Chuck E Cheese.)Bregalad wrote:I guess it was uncommon to try to push arcade hardware to its limit. Games were developed on with a deadline etc, and if it was too hard to implement something on hardware they'd either a) Buy better hardware to run the game or b) Remove features from the game so that it fits the planned hardware. Trying to exploit every bug of chips to make something crazy wasn't the philosophy - as nobody would notice.
To be honest, I don't even know of any hardware that uses 3bpp graphics. I wouldn't be surprised if Konami did with one of their many game specific boards.Bregalad wrote:This leads me to another question : Was there a time where 3BPP graphics were the most used between the 2BPP age and the 4BPP age?
And, somehow, the only system I know that uses 320 x 240 is the Irem M92 (and M107), which was in 1991.Bregalad wrote:It seems that (320, 288, 256) x (224, 240) were all equally common.I guess the main advantage of having 224 vertically is to avoid overscan issues on NTSC.
Re: Prototyping NES games with PC pseudo-arcade games
Super Mario World for Super NES uses mostly 3-bit graphics, filling the fourth bitplane with either 0's (if the sprite uses colors 1-7 of a 15-color palette) or the first 3 planes OR'd together (if the sprite uses colors 9-15). But I imagine that unless the system uses a separate chip for each bit plane, it's easier to design systems whose bit depth is a power of two.Bregalad wrote:Was there a time where 3BPP graphics were the most used between the 2BPP age and the 4BPP age?
Namco's 288x224 pixel boards use a 6.144 MHz pixel clock, which is very close to true square pixels (about 1/800 off the 945/154 = 6.136 MHz clock implied by Rec. 601). The 288x224 plane also sits squarely inside the overscan on a properly calibrated NTSC monitor. But a lot of arcade platforms care little for square pixels (hence 256 or 336 or even CPS's 384 pixel widths). And even on those that do, the fraction of a CRT scanline used for active picture can be adjusted more easily than the crystal from which the pixel clock is derived. This means the pixel aspect ratio on the monitor in the cabinet may differ from what you see on a TV when playing through a SuperGun-type arcade-to-TV adapter.It seems that (320, 288, 256) x (224, 240) were all equally common.320 x 224 pixel resolution
I guess the main advantage of having 224 vertically is to avoid overscan issues on NTSC.
Re: Prototyping NES games with PC pseudo-arcade games
Not necessarily, the whole point of planar arrangement is that it makes arbitrary bit depths much easier (power of two or not). Available die space (to cache the pixels) is probably a bigger deal in this case.tepples wrote:But I imagine that unless the system uses a separate chip for each bit plane, it's easier to design systems whose bit depth is a power of two.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Prototyping NES games with PC pseudo-arcade games
Sega System-16Espozo wrote:And, somehow, the only system I know that uses 320 x 240 is the Irem M92 (and M107), which was in 1991.
NeoGeo (some games)
Cave shmups
BTW, I think Gun Force 2 got pretty close to maxing out the M92, except for color palette. Galaxy Force 2 would've been maxed out if it wasn't for that game having 3 CPUs.
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Prototyping NES games with PC pseudo-arcade games
I didn't think the Neo Geo could run at 240 pixels tall, and I forgot about the Sega System-16... You know, what's with all the Neo Geo games that have 8 pixels on both sides of the screen clipped off by the fix layer? I realize that that makes the resolution "more 4 x 3", but is the actual image also stretched accordingly? Anyway, if it is, the 8 pixels would be masked off by the edge of the TV anyway, so it doesn't matter.psycopathicteen wrote:NeoGeo (some games)
Is "Cave" a company? I've never heard of them...psycopathicteen wrote:Cave shmups
It does a fine job, but it maxes it out in the same way that Super R-Type maxes out the SNES, except not quite as wasteful: The smaller explosions (that look almost exactly like the larger 64 x 64 pixel ones) are made out of something like 8 16x16 sized sprites, (randomly assembled together to where parts of them even overlap) instead of 1 48x48 pixel sprite, which makes absolutely no sense. Normally, this might not be the biggest problem, but the game often calls for a ton of these explosions. On the first stage with the train, at all the oil drums stacked up, they all explode with a bunch of them, and there's sprite drop out like crazy. The game is pretty clever in that it has large, 128x128 "cluster explosions", which consists of a bunch of 64x64 pixel explosions, pixel for pixel (and some horizontally flipped) over one another, kind of like the Yoshi's Island title screen, except that it isn't being computed. I'm not sure if this was out of laziness, or if it's meant to impress people who know how these systems work. (But don't know that it isn't 8 + 64x64 explosions put together). It's still cool nonetheless. I'm relating the multi sprite small explosions to the choice of 8x8 and 16x16 in Super R-Type. The other way I'd say that they're connected is poor CPU usage, even with all the explosions and stuff. There are a lot of explosions and shrapnel, but it shouldn't take too much processing power to handle them, especially when everything is in vram. (I know the V33 is basically an 80186, but I think I heard it's about twice as fast given the same clockspeed. The V33 runs at 9Mhz, so how would that stack up to the 12Mhz 68000 in the Neo Geo?)psycopathicteen wrote:BTW, I think Gun Force 2 got pretty close to maxing out the M92, except for color palette.
And yeah, it doesn't use too many colors. I always found it strange that 2048 colors are used instead of 4096, which seemed to be the norm on a system of this power from the time period. If I made or make a game for it, just about every BG tile and sprite would have their own palette. I bet a picture transformed to use 128 palettes would turn out really nice. (I bet the bigger problem would be 4bpp graphics than the amount of palettes.)
-
- Posts: 592
- Joined: Thu Aug 28, 2008 1:17 am
- Contact:
Re: Prototyping NES games with PC pseudo-arcade games
The system16 and the NeoGeo both might have 320px wide modes, but those pixels aren't the same resolution. The NeoGeo's pixel res is only 6mhz.psycopathicteen wrote:Sega System-16Espozo wrote:And, somehow, the only system I know that uses 320 x 240 is the Irem M92 (and M107), which was in 1991.
NeoGeo (some games)
Cave shmups
__________________________
http://pcedev.wordpress.com
http://pcedev.wordpress.com
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Prototyping NES games with PC pseudo-arcade games
Yes: CaveEspozo wrote:Is "Cave" a company? I've never heard of them...
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Prototyping NES games with PC pseudo-arcade games
Does the m92 have sizes from 16x16 to 64x64 in multiples of 16x16? Then that is a waste. The only thing it helps is ROM size, because it takes up 8 cells instead of 9 cells, but arcade games typically went crazy with ROM sizes anyway.Espozo wrote: It does a fine job, but it maxes it out in the same way that Super R-Type maxes out the SNES, except not quite as wasteful: The smaller explosions (that look almost exactly like the larger 64 x 64 pixel ones) are made out of something like 8 16x16 sized sprites, (randomly assembled together to where parts of them even overlap) instead of 1 48x48 pixel sprite, which makes absolutely no sense.
Re: Prototyping NES games with PC pseudo-arcade games
I'm surprised. I'd expect 320px horizontally to yield square pixels, as 240 * 4:3 = 320. Guess I was wrong.tepples wrote: Namco's 288x224 pixel boards use a 6.144 MHz pixel clock, which is very close to true square pixels (about 1/800 off the 945/154 = 6.136 MHz clock implied by Rec. 601).
If I ever do what I mention in the title I'll probably use 256x224 in order to convert it easily from the NES, but I could also use 384x224 and scale everything horizontally times 1.5 (my 32x32 metatiles would become 48x32). Other resolutions would be impratical and require significant modifications of game levels, or very strange metatile sizes such as 40x32 (320 px horizontally).
Re: Prototyping NES games with PC pseudo-arcade games
It's not how many pixels a picture generator is actually sending; it's how many it could be sending throughout the 52.148 microsecond active scanline period. Consider a GameCube running in a 240p (or "double-struck") video mode. This produces 640x240 pixels (and about 700x240 across the whole active picture area). Say a game leaves all but the center 320 pixels blank. Then the video chip is technically sending 320 pixels, but because each pixel is transmitted for such a short time, they're narrower.Bregalad wrote:I'm surprised. I'd expect 320px horizontally to yield square pixels, as 240 * 4:3 = 320. Guess I was wrong.tepples wrote: Namco's 288x224 pixel boards use a 6.144 MHz pixel clock, which is very close to true square pixels (about 1/800 off the 945/154 = 6.136 MHz clock implied by Rec. 601).
384x224 would work well if you're trying to simulate the CPS1. And in theory, there's nothing wrong with 40x32 pixel metatiles on a Genesis VDP.If I ever do what I mention in the title I'll probably use 256x224 in order to convert it easily from the NES, but I could also use 384x224 and scale everything horizontally times 1.5 (my 32x32 metatiles would become 48x32). Other resolutions would be impratical and require significant modifications of game levels, or very strange metatile sizes such as 40x32 (320 px horizontally).
So let me sum up: You won't go wrong if you simulate a Mega Play.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Prototyping NES games with PC pseudo-arcade games
If it weren't for overscan.Bregalad wrote:I'm surprised. I'd expect 320px horizontally to yield square pixels, as 240 * 4:3 = 320. Guess I was wrong.tepples wrote: Namco's 288x224 pixel boards use a 6.144 MHz pixel clock, which is very close to true square pixels (about 1/800 off the 945/154 = 6.136 MHz clock implied by Rec. 601).
Wait, wouldn't a perfect 4:3 ratio be 288x216, not 288x224?