Legacy Graphics Formats Used in 80s?

[segaloco]

Howdy folks, I was curious if anyone has any solid details on the precise formats that were used when initially creating assets for the 2C02 back in the day. Were they using CGX? Or was there some other intermediate format involved? Or was it more likely shops were rolling their own CAD programs like SRD that would've been more tightly coupled to the character format? Granted, there may not be a precise answer as different shops may have taken different approaches, but if anyone has the scoop on what some of the larger names used, I'd be interested.

Where I'm going with this is I want to explore building a rudimentary tile editor, something that runs well on X11, and if possible, I'd love for it to support the formats "of the day" such that if, say, a source code dump to an old game pops up, those graphics can be edited just as easily as something someone is working up today. Granted, such a tool would also support loading up a CHR bank in native format, but it'd be cool if it could support some common intermediates, especially any that were commonly used when developing in the day.

[Dwedit]

I only know about the formats widely used on Windows/DOS PCs.

PCX dates back to 1985.
GIF dates back to 1987.
Don't have a year for BMP. Maybe 1985 as well.

[Drag]

I immediately thought of Deluxe Paint and found ILBM, which seems period appropriate.

Other than that, there were probably a whole slew of tools that ran on Japanese-only computers, like the PC-88, the Sharp X68000, etc, which had their own proprietary formats.

[calima]

One proprietary NES game source from 91 to which I have access uses the ILBM formats Drag linked. BBM/THN/LBM file extensions, file says IFF data.

[nesrocks]

Coding a NES graphics editor is a fun exercise. I don't really see the point of using intermediary file formats though. Many developers coded their own dedicated editors and I suspect they worked directly in the system's native format.

[tepples]

Even if you use generic tools that edit a tileset and tilemap in NES format, those tools may not understand the layers of data compression used by a game's engine. For example, Full Quiet uses things like three nested layers of metatiles (inspired by what Blaster Master does), multiple maps that share one set of tiles and metatiles, and a global tile pool (for sharing 8×8-pixel tiles between tile sets). Some of these aren't very amenable to merging updates submitted by team members into a project, particularly anything involving the global tile pool. Nor do generic tools necessarily understand the background animation model used by a particular engine, either the part that controls CHR animation or the part that controls tilemap, nor how the engine represents each map's terrain collider and enemy placements.

So you end up doing one of three things. You could add another member to your team who can make custom GUI tools (and make them run on both Windows and Linux). Or you could delay the game for possibly months while your engine programmer learns a GUI toolkit in which to write these tools. Or you could do what Retrotainment did: use the generic editing tools that your artists already know and have your engine programmer write command-line converters in a language like Python, as command-line tools are a bit less taxing to make work across operating systems. The Full Quiet build process reconverts the maps that share a tile set from a PNG image when a map is modified, spits out diagnostic images when a constraint was violated, and then rebuilds the tile pool every time any map is modified.

[segaloco]

Yeah my scope would be incredibly narrow. Support raw CHR, maps, and maybe provide a default 2C02 palette to pick colors from. Anything with metatiles, compression formats, etc. gets into game specifics and would be served by filtering something first before loading it in. I kinda go the UNIX approach with a bunch of little pipeable modules rather than this one huge codebase with all the extensions packed in.

Another reason I'm curious about older intermediates is say, what would've been the go-to for a graphic tile artist targeting *both* the 2C02 and TMS9918. You're limited by the least common denominator between the two, so 2bpp Famicom palettes, but still one could at the very least draw 8x8 tiles in 2bpp and they've got a starting place where if they'd like. I'm going to start looking at Sega Master System particulars a little more as I go to get a feel for what a editor supporting rudimentary tiles between the two materially looks like.

[Drag]

If an artist wanted to target multiple platforms at the same time, a workflow that comes to mind is to use a multi-layer document, where each layer is one of the platforms you're targeting. No need to lowest-common-denominate yourself.

[segaloco]

Well I mean the format would capture the largest subset so probably 4bpp storage so it can account for them all, I mean more like if the asset itself was meant to be *useful* on both platforms in any way it couldn't use more than 2bpp color or you lose all that extra detail on the NES, and really the palette too would need to be limited to 4 colors *from the 64 color Famicom palette* although this is technically less important if you're not trying for color parity, literally just pixel for pixel parity, maybe you just approximate the actual NES colors in a TMS9918 palette and only use four entries from it.

That's part of the complication, your tool can't force you down to 2bpp or then you're forced to use 2bpp even when you have greater color resolution. If the intermediate format is 4bpp, it can still be used restricted down to four colors, you're just kinda inefficiently carrying a couple extra zero bits on each pixel. Still, then everything works if the maximum color resolution any given pixel would have is 16 colors instead of four like a TMS9918 palette vs a 2C02 palette.

Anywho I'll keep thinking on the problem, one thought I have instead of actually writing up a grand editor is work out a way to export graphics to such a common 4bpp indexed color graphic format for multiple platforms and then just have tools on the other end too, you export a tile map as a 16x32 4bpp indexed color image, use an editor that properly supports using the packed in indexed palette, then have a flip side tool that takes said 16x32bpp 4bpp indexed color image and works it back down to 2C02 2bpp data. Even better if you're able to edit the palette entries through whatever editor but that is less important in the long run, the palette really exists in that scenario to define the two bits, but it is only meaningful if that's actually the 4 byte palette that'll be sitting on the PPU waiting for you when you load that tile up.

Anywho, thanks for the feedback, I'll let folks know if i get some sort of proof of concept going in say GIMP.

[Oziphantom]

there were lots of formats used back in the 80s.
Koala format is basically the defacto for C64 bitmaps for example. But every "editor" had it own format, ACP, Scaracin, Cheese, AmiPaint, etc see http://fileformats.archiveteam.org/wiki ... cs_formats for a more complete list

Different versions of programs probably we not compatible either. i.e GeoPaint C64 and C128 are not compatible with GeoPaint Apple][ or GeoPaint IBM. Printshop 64 vs Printshop Apple][ probably likewise. As it was really difficult to get the data transferred between the two machines it wasn't worth keeping them binary compatible.

However for the NES the early file format was called "hex on graph paper". In the west LLBM was probably the most common format used from mid NES and SNES era. Still is used today in games.

If you want to use something that would be as close to "period" accurate in X-11 then GraphX2 would probably be "the best you can get" then make a bunch of convertor tools to take the llbm format to ->nes chars, nes maps, nes pal, sms chars, sms maps, sms pal etc