Comparison of 4th generation ("8/16-bit") system hardware

[Thenewguy]

The sprites can be multiplexed so long as they all look the same

Either way, like I said, there were still some disagreements, the guy I mentioned said the sprite slots could be changed during gameplay, but that it was time consuming and problematic, I think he said something about sprites who's vertical placement stayed around the same could be updated, and like I said earlier he talked about dropping the frame rate to help as well.

On top of that, GX4000 sprites are double width in comparison to NES/SMS sprites, which tend to be doubled up most of the time, so that would help a little.

Its funny, when you first look at the specs it seems like the sprites are one of the better aspects, and the resolution, and sound are unthinkably bad, then, after looking into it you find the resolution/sound isn't necessarily as bad as you thought, but the sprites are worse

[Kamahl]

Its funny, when you first look at the specs it seems like the sprites are one of the better aspects, and the resolution, and sound are unthinkably bad, then, after looking into it you find the resolution/sound isn't necessarily as bad as you thought, but the sprites are worse

Yup, seems to be it. Still, even with raster effects, 4 colors isn't really acceptable. It's manageable if the game always scrolls horizontally, but for a platformer? Big problem. That shit was barely ok on the A8, much less a 4th gen system. Heck, even the commodore 64 can do better high-res than that.

[Thenewguy]

Dunno, whilst C64 is 16 colours, its 2 colours per 8x8 block, whilst even without interrupts the Amstrad can put all 4 next to each other, so it can dither its colours much better, and has more detail in each square.

I think one of the bigger problems with the CPC's Mode 1 is the fact that it has to re-use the 4 colours for the software sprites too, which limits where you can place colours (or they'll make the player sprite/bullets invisible), and leads to unrealistically coloured sprites, with the CPC+'s new sprites they can concentrate on the background with the 4 colours, with careful dithering, whilst the sprites would look realistically coloured from their own pallette.

But yeah, I guess a lot of the high resolution talk from before was based on the assumption that the sprites were more versatile than they ended up being, as we were originally talking about overlaying some sprites set to maximum zoom to add bits and pieces of colour to the 4-colour background.

[Kamahl]

Dunno, whilst C64 is 16 colours, its 2 colours per 8x8 block, whilst even without interrupts the Amstrad can put all 4 next to each other, so it can dither its colours much better, and has more detail in each square.

You should check out some of the High Res "demo" games on the C64, even with only 2 colors per 8x8 block it makes a huge difference. Since I can't remember their names, look at dizzy, particularly the border:



The c64 version looks substantially better.

[Thenewguy]

That game really isn't optimised for Amstrad at all though, its just a lowest common denominator rush job.



Regardless of the border (which only exists because these are ports of the Spectrum game anyway), the main game could've looked more like this on a normal CPC (and take into account I have crappy art skills)



When the main game is so clearly half assed, it doesn't give me much confidence that the border was as good as it could get.

With the CPC+/GX4000 hardware, the colour counts would skyrocket, this game requires next to no sprites at all, I think for the gameplay 4 or 5 would actually do. replace Dizzy with a 4 or 5 colour sprite, replace the flames with two three colour (yellow, red, orange) sprites, and multiplex them for the bottom two, replace the painting with 4 sprites, replace the chandelier with 2 or three sprites.

and with those elements replaced, the staircase could now be any colour you want (instead of sharing with the sea in the painting), and white could be replaced with another colour of you choice too, not to mention you'd have the choice of colours from a 4000 sized pallette instead of, what? 27? so the colours would better fit too.

Thats not taking into account interrupts, which you might be able to use to get you another colour.

[Kamahl]

There's 5 colors in your pic , but still, yes, the game was not optimized. They could also use different colors each screen, since it doesn't scroll, but that would ruin the stupid border lol.
Static screen games like dizzy lend themselves really well to color splits. This is not a good idea if the sprites depend on it too, but that's not the case for the GX4000.

[Thenewguy]

Jeez Kamahl, couldn't you have let this slide?! do you know how long this took to sort out?!





And yeah, how the heck did I manage to put 5 colours into that earlier picture without realising?! LOL, I only had to keep count of 4 colours for gods sake!

[Kamahl]

Hey, you managed to take out 1 color and at the same time make it look better, I'd say that's good .

[TVC 15]

BUMP!

Found this thread so I might be able to ask some technical questions regarding the Mega-CD. Basically as always with my big mouth, I've jumped into a tech discussion over on assembler games regarding the MEGA-CD's internal hardware. The gentleman in question seems quite knowledgable about the Megadrives hardware and I'm in completley over my head (as always), but basically hes wrote off the Mega-CD hardware's M68K processor, as being fairly ineffective for anything other than CD housekeeping duties and dealing with the Rioch PCM chip.

Its not out of question that in a lot of ways the Mega-CD design was bottlenecked and a compromise due to the limited expandibility of the ext. port on the Megadrive, the poster in question asserts the same point in fairness.

Heres the thread.... http://www.assemblergames.com/forums...-Neptune/page2 at the end of the 2nd page.

Is the gent correct in what he asserts, and have I made a massive lay-man blunder? I'm sure the Mega-CD is a little bit more capable than he gives it credit for however.

[Stef]

I do not totally agree with what Nemesis said. It's true the sub cpu is mainly used for data loading from CD and PCM chip samples feed.
But you still can use it for heavy calculation as the geometry table for the vector chip, also you can generally do tasks request with the communication registers and share data using the Word RAM. Your program has to be well designed to efficiently use the sega CD horse power as you should avoid long wait on both cpu but it is indeed possible. The program and data loading can be handled with low cost on sub cpu as you have DMA capabilities to directly load CD data in PRG RAM (as in PCM RAM).
Probably a few game actually uses intensively the sub cpu but this is more due to the lack of experience on this machine (which had a short life time) than technical design flaw.

[Kamahl]

Probably a few game actually uses intensively the sub cpu but this is more due to the lack of experience on this machine (which had a short life time) than technical design flaw.

Games like SoulStar and Batman & Robin are probably using it a lot.

[sheath]

Interesting, I dove into a Sega CD versus Arcade Card CD discussion over at PC-EngineFX last night. It looked like the Sega CD's Program RAM was being dismissed in the discussion of whether Super Street Fighter II Turbo could be ported. They brought up an interesting stat that one character's animations is around 125KB in Street Fighter II. But anyway, if the Sub CPU isn't useful for game processing, what is the Program RAM for?

[Chilly Willy]

Interesting, I dove into a Sega CD versus Arcade Card CD discussion over at PC-EngineFX last night. It looked like the Sega CD's Program RAM was being dismissed in the discussion of whether Super Street Fighter II Turbo could be ported. They brought up an interesting stat that one character's animations is around 125KB in Street Fighter II. But anyway, if the Sub CPU isn't useful for game processing, what is the Program RAM for?

Game processing.

It's useful if you MAKE it useful, and not useful if you don't. It's all on the programmer to make best use of what's available. Let's say you decided not to do much game processing on the SCD CPU - then maybe you can load data into the program ram and allow the MD CPU to use that as well as the word ram. The MD CPU can halt the SCD CPU and use the program ram (in four 128KB banks) like regular ram.

[sheath]

Well, that changes everything. I just posted this over at PCEngineFX, just trying to get all the facts on the table.

Let me break down the memory available on the Sega CD and compare it to the Arcade ROM for Super Street Fighter 2. The Sega CD has 512KB Program RAM plus 256KB Word RAM that can affect the Genesis CPU/VDP every 1/60th of a second. 1X CD-ROM speed is 150KB per second, so it would take at least two seconds to fill the Word RAM for a level and an additional four seconds to fill the Program RAM. I'm not sure it matters here, but DMA from the VDP to the Cart port or CPU or Sub CPU Word RAM is 7.2KB per 1/60th a second. I've also seen some discussion about tiles being better compressed in the Genesis' format than in either the SNES or TG16 but I haven't seen any mathematical discussion on how much compression this would allow from a cartridge or the Sega CDs Word RAM directly to the VDP without adding load times.

SSF2T is 5.6 MBytes zipped and 11.7MBytes unpacked. There are 15 files, and I have no idea what each file is for. The first two are 128KB, the next seven are 512KB, files eleven and twelve are 2048KB, and the final four files are numbered differently but each weigh in at 1024KB all unpacked. Compressed none of those files go over 350KB except for the two 2 MByte files.

Obviously since the Genesis and SNES cartridge games were only 5 Mbyte and 4 Mbyte respectively there was a rather huge amount of downsizing in the conversion process. I'm not sure if compressed tiles in the Sega CD's program RAM would help or hurt the attempt of trying to get as much of the Arcade's sprite size and background detail on screen at once. 320 wide resolution and cropping would already help in regard to reducing the file sizes if compressing the tiles up until the are DMAd to the VDP would not.

I'm not seeing a problem with memory management here that would be any different than any other Arcade to home conversion at the time. The Arcade Card CD would make porting the animation and original sprites much easier but forget about more than one background layer. The Sega CD would make the background layers possible, even if some animation would need to be cut in the process. Obviously only the Arcade Card CD would have any hopes of keeping nearest neighbor colors to the Arcade original.

Both systems could easily handle and enhance the Genesis or SNES games graphics.

[Barone]

About the loading part, you can store all sprites of your character in the first loading and leave it there, just replacing the other data for each new fight; this usually reduces the loading times by a good margin. It's something common in reasonably well developed fighting games for CD-based systems. You could do the same for all voice samples of the announcer and player's character if there was enough RAM. Then you'd just need to transfer it to the PCM RAM, but that only consumes CPU time and doesn't require loading from the CD.

I'm not sure but I think that you could use the Genesis CPU to take care of all special attack effects (fire balls and everything) and let the Sega CD's CPU do the rest. Silpheed, Wing Commander, SoulStar and Stablade do something similar to that.
That would probably avoid any slowdown even using exactly the same sprite sizes and number of animation frames for the characters and the backgrounds that the arcade had.
You could also use the Genesis sounchip to do part of the sound effects and open up some space in the PCM RAM (thus using it mainly for the voices). The SFX that could be done using FM stuff rather than PCM samples would also reduce the amount of data needed to be loaded and also the RAM space required to store all SFX needed for a given fight/round.