When I’ve done this in the past I would make vector images in inkscape, then write a script that would use inkscape export a low resolution raster image. The script would also pick a color palette that would minimize error of the entire sprite map. Scripting with vector images is nice because simple animations can be made by modifying transforms in svg.
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).
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
I appreciate you approached this from a personal enjoyment perspective and that the pipeline is what really interests you, but isn’t how low resolution pix art is drawn. It’s a common misconception that low resolution art is just high pixelated equivalents of resolution art but actually it’s more of a caricature that is hand drawn at that resolution (like those cartoonists you see at some tourist hotspots who draw exaggerated portraits).
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.
Yep, my cringe is triggered by "retro" pixels that are perfectly square with impossibly sharp edges/borders between neighbours. The CRT shaders we have these days are pretty good at turning raw pixels into something that looks "about right" so there's no excuse [not even laziness] for dumping raw unfiltered pixels to the screen.
Think of it as another style altogether. Graphics back then used to look the way they looked because of technical limitations. We don't have those anymore. I personally don't miss the barely readable text despite it was set in huge letters. But I still enjoy a good hand crafted pixel art.
> Graphics back then used to look the way they looked because of technical limitations. We don't have those anymore.
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.
It’s more than that. Graphics were designed to take advantage of the technical limitations. Eg Using the blending effects to create new colours in the CRT or chess-board ‘stipple’ effect of alternating between foreground and background pixels knowing that the CRTs will produce an accidental alpha blend effect.
Some old games look crap on modern hardware because ironically modern displays end up limiting the after effects that retro games would employ.
Sure, but this is a remake, not an emulation of an old game. It does not need to try to reproduce the old style, rather it should work with what we have now.
Indeed. My point wasn’t intended to read as a disagreement to yours but rather a complimentary “old games did stuff that will look wrong on modern hardware because they intentionally exploited the limitations of older hardware” point
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.
There's an active community at tecmobowl.org, they have been releasing updated versions of Tecmo Super Bowl (originally 1991) annually. Updated player rosters. Lots of graphics mods. Tons of gameplay "hacks".
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!
My favorite football game is Madden 95, and my favorite year of watching football as a fan was 2003 so I always wanted to create an updated ROM. Do you know of any good resources? How do you figure out what the data format is for stats, just trial and error?
asking a Tecmo guy about Madden, that's like asking a vegetarian how to cook a great cheeseburger :)
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.
I still use my old copy of Deluxe Paint II under Dosbox. It’s a bit rough, because of the LBM format, which adds an extra step in a more modern tool to add transparency and convert to PNG, but works well for my needs.
Also, the DP2 drawing primitives are soooo easy to use that I find any other tool too cumbersome.
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
Somewhat related: I have on occasion needed to make low resolution, pixel-perfect images for various projects. But when I export from Photoshop, all of the rough edges get smoothed out, no matter what file format I choose. Very frustrating. Does anyone know what I'm doing wrong, or if there's a setting I have to twiddle?
Are you saving as a jpeg? The compression will do that, try saving as a png or gif instead. Also, under image settings make sure your interpolation is nearest neighbor, not bicubic.
Not sure about Photoshop, but in general I'd say ensure that canvas size and export size are the same. If they are not, then the ratio between them must be an integer and the resize filter is set to nearest neighbor.
I recollect my Paint Shop Pro on the Apple ][e. You would turn a rectangular pixel on or off. You moved in any one of four directions. That was it. After I was done with my book reports, I would spend hours attempting to render the book covers in Paint Shop Pro to print with my essay. This was high art at the time.
I don't follow gaming, but I notice a lot of single-developer 2D games that show up on HN have pixellated sprites for a retro look. Is there another group of single-developer 2D games that use vector graphics?
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.
https://youtu.be/gCO8X6JQAhM
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