How I make graphics for retro systems and retro-styled games
nicole.express
nicole.express
The results weren’t amazing, but it’s mostly because I’m not a great artist and had more fun making a workflow than producing actual work.
The results felt authentic. Looking up the video capabilities of the system you’re targeting the style of is an important step that a lot of retro style games don’t do. For instance: the SNES can only have a palette with 256 colors and the colors that can be in that palette is 15-bit RGB (64k unique colors).
https://en.wikipedia.org/wiki/List_of_video_game_console_pal...
If I were to pick this back up I'd probably spend time getting comfortable with blender to use that instead of inkscape. Many games in the 80s and 90s used pre-rendered 3D assets, so it would still adhere to some art styles. I know it's not the hand-drawn pixel art that many are familiar with, but there isn't much in the way of tool development there to interest me :p
There are some exceptions to this, like Mortal Kombat. But that’s what made that game so distinctive and it’s certainly not a style that would pay off for every game.
With regards to 3D modelling, that came really late in the 90s. It was only the last few titles on the popular 16 but platforms that had 3D rendered assets and even there, they’d still be rendered back down to 2D assets and then often manually edited afterwards (eg reducing and changing the colour palette so that larger assets can be loaded and animated via palette swapping rather than wasting expensive video memory on sprite data).
But ostensibly retro graphics were hand drawn, often on grid paper, before being encoded on a computer.
https://www.fortressofdoors.com/doing-an-hd-remake-the-right...
Also it's about the best rpg ever released: ffvi <3
Probably more people played “retro” games on emulators than actually owned them so life has just gotten extremely meta
Some old games look crap on modern hardware because ironically modern displays end up limiting the after effects that retro games would employ.
You're right that it's the result of technical limitations, but a lot of the time that's what the artists worked with, and subsequently what the techniques they used were based on.
Personally I don't mind the difference too much. I use a CRT TV for older games, but normally with RGB input rather than composite. But there's definitely an argument to be made in favor of composite video for some systems: that it's closer to the way you were presumed to experience it.
Off the bat, an example I can think of where the difference is really obvious is with the light effects in the bar at the beginning of Streets of Rage II. With a high quality RGB monitor or "ideal pixels" the light cones appear as checkerboard patterns where every other pixel is transparent. With composite video, these patterns instead blend together into what looks like a transparent layer, which is a much better effect.
I use GrafX2 and GIMP to make my game graphics, then when I want them munged into some exotic, export them to pnm or xpm and use some tool (often written in Guile) to do the munging of the source image.
There is also something to be said for in-engine asset generation. This especially works well for retro style games that run on powerful computers, it's probably less useful for actual retro games. For example, I'm developing a retro platformer mechanically based off of one you've all heard of (but with a new main character and premise). I thought it might be useful to have smooth rotations of character and other sprites for an advanced modern graphical effect... but a goal for me is to write the game as if it were the actual 90s, using C and Xlib, which doesn't offer a native image transform primitive. Then I realized... what if I were to precompute the rotated images on initialization, cache them in X pixmap atlases and use a simple XCopyArea to draw the rotated sprite when I need one, making it look like the engine is doing dynamic rotation (with enough precomputed rotations)? Ohohoho! Delightfully devilish, bitwize!
Another thing I've experimented and had great success with in another game of mine is something I call greeblization: procedurally generating interesting looking backgrounds from a few different tiles by having a few basic tile types that are the same mechanically but vary in appearance. A long narrow strip of "ground" tile types could become a bridge, for instance. So the level is a JSON file that describes blocks of a certain tile type, and the engine generates the tile map by filling in details with variants of the tile type for the block. I don't claim credit for this concept, however; the way ground tiles work when you place them in Super Mario Maker was an inspiration.
Mostly focused on the NES original but also SNES and other platforms.
As someone who just recently got into this hobby, I agree with the author that YY-CHR is essential!
all I can say is that the Tecmo community has been chipping away for 30 years at learning all the internals without any source code or reference, gaining knowledge little by little, and fortunately, sharing it so people can build upon other people's discoveries. Don't know if a similar resource exists for Madden.
Might be the place to start. Madden 08 is the biggest target as far as I know, but someone there might be able to point you in the right direction.
Also, the DP2 drawing primitives are soooo easy to use that I find any other tool too cumbersome.
This is great!
These days I tend to use GIMP for pixel editing, personally, which works well enough.
I made some python scripts that inputs images I want to show up on the NES and outputs a grayscale image that I can copy & paste to YY-CHR to output a binary that I can dump to NES binary (I could probably replace YY-CHR entirely and dump a binary myself). The intention was the artist could put all the things that we want to show in the background layer and it would give us a tile map. You could also feed it an existing tile map & color palette and it would give you updated version of them to show the new image.
It was also dumping a RLE data if you want to show a specific image on the screen. For example you could grab a screen shot from SMB, feed it to our script and it would give you RLE & tiles needed to feed it to NES
It worked well for me & an artist I worked with on a game jam. The artist drew the background for the main game and were were able to use it in the game. I was super happy about it