Paprium: The Official Thread Mk 2

[Barone]

1) Making low contrast shades are a pain in the ass to get to look good. In really awful cases you can end up spending the whole day just figuring out which color combinations work well. Also arcades usually have a tad of palettes, having to redraw the graphics to use less hues so they fit in less palettes means having to extend the range covered by the colors.

2) We may be going off the wrong gamma values. As was mentioned long ago, MAME uses the wrong colors (too bright) for a lot of games. On the flipside, I've noticed that BlastEm tends to make games look a bit brighter (the color ramp on a real Mega Drive is not linear, unlike what most other emulators display). I wouldn't be surprised if the colors aren't anywhere as off.

3) Also deadlines meaning they may decide to just put in whatever seems somewhat OK and move onto other stuff =P (and ports tend to have tighter deadlines than brand new games)

4) When conversion tools were used to port arcade/computer graphics data to the Mega Drive, the automated conversion from 12-bit palette (or even 15-bit palette) to the MD's 9-bit palette usually came with errors and that would require manual fixing.
Pitfall: The Mayan Adventure, for an example, has many invalid color values in the palette data store in the MD version of the game (Example: 333 when only valid option would be either 222 or 444. In such cases, VDP will understand it always with the lower value, so 222 - which darker than the "original" 333. Many times when studying the original art you'll conclude that the best value would have been a 444 instead of 222; or maybe something else that is not even a gray tone in the MD's palette).
But manual fixing required time that many developers probably didn't have.


An example of what Sik said in 1):
Arcade/PC/SNES
MD original/MD hack



It took me many hours of trial and error with modern tools to come up with the funky palette (pink-ish and green-ish tones mixed there, lol) which gave me a somewhat good result with the volcano/mountains in the background.

And, even so, you notice how you don't have enough palettes for a second layering of depth in terms of coloring (like the arcade and PC versions have for the mountains which are even more distant) (SNES version got the coloring kinda wrong there, WTF!!!; using darker tones instead of brighter ones).
Also, the flowers and other plants have to share the same sub palettes.
The foliage on the floor no longer has enough shades to deliver the same contrast you had in the arcade, which makes it look worse no matter which green tones you pick.
Part of the texturing of the tree's leaves was lost when the art was converted to the MD's palette.
...
It's a depressing and very time consuming task. I really don't blame the developers that much anymore.

[Gadispalembang]

Apparently, Neo Geo games had 700+ Mb. I wonder if Genesis could handle such large amounts of data. And what it could do with so much.
And doesn't Genesis graphics style, with sprites, tiles and backgrounds, have some advantages over the sprite-only Neo Geo style?

Megs (megabits), not megabytes. Divide whatever megs are presented on the cover of the game
and divide by eight. Eight megs equates to one megabyte. The whole meg thing was mostly for
marketing and companies such as ISP's still use it to this day. It's to make the numbers seem
bigger than they actually are.

[Black_Tiger]

It's just laziness, apathy, lack of skill, etc. Most people don't realize how flawed or imperfect arcade games were in the first place. In the past when I've pointed out glaring flaws in games like Golden Axe and Final Fight, people argued the gamma/emulation thing. But I have both aecade boards and have played them in many different abinets, including dedicated System 16 and CPC setups and they look the same as mame/misc compulatiobs and the same flaws are there and can't be fixed with monitor adjustments.

Ports to 16-bit consoles were an opportunity to rebalance the visuals, fix flaws and make improvements. I've ported lots of high-color/higher-bit graphics to 9-bit color PCE spec, purposely choosing the most challenging or seemingly impossible examples and have found that the only problems come from flaws in the source material and/or things staggered in a way that only suites the original hardware. There are simple solutions in most cases and the rest only require adjusting the pixelart of select aspects. Which tend to be low-detail kind of gibberish stuff anyway.

Exactness isn't necessarily what looks best and even recreating Genesis games in PCE color can be as challenging as subtly shaded SNES games.

The Genesis can do most types of games fine in the right hands. It's only types of games like streeting fighting or beat 'em ups that really strain the 4-palette bottleneck.

Making original pixelart for PC Engine, I usually find it more challenging to make shades less subtle than super subtle, particularly for sprites.


Earlier people were talking about good faux-pixelart versus gimmick pixelart and how making good pixelart for old hardware is something else. The divide between crappy "NES-like" modern pixelart and the best original pixelart is still minor compared to the best new pixelart and what it takes to make real pixelart for real console specs.

One thing people don't take into account is the limitations of the dev tools anyone might have. When you get down to the real restrictions of a specific game and then have to work within memory constraints of something like a CD game, it is a world of difference from the only limitation you choose to give yourself is 'chunky pixels'.

[paulojr_mam]

Megs (megabits), not megabytes. Divide whatever megs are presented on the cover of the game
and divide by eight. Eight megs equates to one megabyte. The whole meg thing was mostly for
marketing and companies such as ISP's still use it to this day. It's to make the numbers seem
bigger than they actually are.

I imagined it would be the case. But still, it must be more than the average Genesis/SNES cartridge. But by how much? What was the largest Neo Geo cartridge in Megabits and how does it compare to Genesis's biggest, Super Street Fighter II, and its 40 Megabits?
Apparently, 700 Megabits are 80+ Megabytes and 40 Megabits are 5 Megabytes, which is still a huge difference. Genesis could probably be on par with Neo Geo if a cartridge had so much Megs, given what it achieved with 40- Megs.

[maxi]

This guy did a tech demo of Metal Slug for the MD and Sega CD a few years back. It's just one screen but he achieved a good use of the colors: http://www.theelf-megadev.com/mslug.htm

[Gadispalembang]

I imagined it would be the case. But still, it must be more than the average Genesis/SNES cartridge. But by how much? What was the largest Neo Geo cartridge in Megabits and how does it compare to Genesis's biggest, Super Street Fighter II, and its 40 Megabits?
Apparently, 700 Megabits are 80+ Megabytes and 40 Megabits are 5 Megabytes, which is still a huge difference. Genesis could probably be on par with Neo Geo if a cartridge had so much Megs, given what it achieved with 40- Megs.

The biggest Neo Geo cartridge appears to be KOF 2003 with 716megs which is 89.5 megabytes.

Partially why Neo Geo games are so large is because the developers tend to retain a lot of
unused data. The largest games would still be larger than anything else at the time on the
same format until the mid 2000's with the DS. As far as commercially available hardware goes
for the home market.

[OverDrone]

Actually I think Fast Striker is the biggest Neo cart at 1500 Megs.

[XeroShinobi]

Yeah, but that's a much later indie release from 2010. King of Fighters 2003 is the largest officially released Neo Geo game before the platform was no longer officially supported.

In terms of the size of actual games and not just the ROM they were on, many N64 games were "bigger" in the sense that they didn't have nearly as much junk data and were actually using pretty decent compression at the time. N64 cartridges, while never reaching the peak Neo Geo sizes, also got a hefty amount of storage. Resident Evil 2 had a 512Mb (64MB) cart in 1999. Conker's Bad Fur Day and Pokemon Stadium 2 had 512Mb carts as well.

[Team Saber Rider]

Resident Evil 2 had a 512Mb (64MB) cart in 1999. Conker's Bad Fur Day and Pokemon Stadium 2 had 512Mb carts as well.

Resident Evli 2 was quite remarkable because they managed to put the content of 2 CDs on 64MB. The videos were still quite watchable.

[Sik]

Resident Evli 2 was quite remarkable because they managed to put the content of 2 CDs on 64MB. The videos were still quite watchable.

Relevant: http://www.gamasutra.com/view/featur...l_studios_.php

[Team Saber Rider]

Thanks will have a look!

[Mask of Destiny]

Megs (megabits), not megabytes. Divide whatever megs are presented on the cover of the game
and divide by eight. Eight megs equates to one megabyte. The whole meg thing was mostly for
marketing and companies such as ISP's still use it to this day. It's to make the numbers seem
bigger than they actually are.

There are actually some legitimate reasons for using bits rather than bytes in certain contexts. For memories (ROM, RAM, EEPROM, etc.), this is done because different memories have different organizations. A 1 megabit chip could be 1024Kx1, 256Kx4, 128Kx8 or 64Kx16. All have the same storage capacity. For ISPs, the reason is slightly different. Pretty much all digital communications is done over some sort of serial interface and because serial interfaces send a bit at a time (except for stuff like PCIe I suppose which has multiple serial lanes...) they are almost universally rate in bits per second rather than bytes. You see this all over the place. Ethernet is in bits per second. SATA is in bits per second, but PATA (which is parallel) is in bytes per second.

[XeroShinobi]

There are actually some legitimate reasons for using bits rather than bytes in certain contexts. For memories (ROM, RAM, EEPROM, etc.), this is done because different memories have different organizations. A 1 megabit chip could be 1024Kx1, 256Kx4, 128Kx8 or 64Kx16. All have the same storage capacity. For ISPs, the reason is slightly different. Pretty much all digital communications is done over some sort of serial interface and because serial interfaces send a bit at a time (except for stuff like PCIe I suppose which has multiple serial lanes...) they are almost universally rate in bits per second rather than bytes. You see this all over the place. Ethernet is in bits per second. SATA is in bits per second, but PATA (which is parallel) is in bytes per second.

Yeah, but ISPs that limit bandwidth will advertise that in bytes, but the speed in bits. It's unnecessary confusion that borders on intentional obfuscation towards the typical consumer. Megabytes are far more well known by the public than megabits, and it's easy for ISPs to do the conversion themselves for advertising purposes, but they don't.

[Sik]

ISPs advertise speed in bits because not all the bits being sent are actually data (e.g. start and stop marks). Bauds would be closer, though I believe that's still not entirely correct.

[XeroShinobi]

That's inconsequential when it comes to modern internet speeds. If you have an 80 Mbps download speed, that's going to be 10 megabytes per second. If need be, they could have an asterisk in fine print describing that a few bits at any given moment aren't data.

There is a lot of misleading information in the technology sector when it comes to advertising that is explained away using technical details. It's still an excuse for deception. Harddrives are labeled as x terabytes using decimal notation when they are in fact seen as binary once installed, and that will cause many people to believe they have less storage than advertised. Technically they don't, but the confusion could be eliminated with more practical advertising.

In the harddrive case I suspect manufacturers will start advertising capacities in binary (tebibytes) sooner or later. We're getting to the point where the difference between decimal and binary notation for typical harddrive capacities will exceed an entire terabyte.