scanline compression
#mastodon #threads #projects
Nov 3, 2019
so 1980’s arcade racers basically worked by drawing the road with “raster” effects. that is, changing the scroll position of the background graphics while the screen was drawing, one scanline at a time. the actual road graphics were essentially a flat trapezoid.
a slightly weirder way of looking at it:
the road was a prerendered video designed around the constraints of a specific video compression algorithm. the compression algorithm works by turning each scanline of the video into an indexed lookup, normalizing each scanline by horizontal position to improve the performance of a de duplication algorithm, adding a horizontal position to the the scanline index lookup to reverse. then sorting the scanlines for optimal tile map de-duplication
actual racing games didn’t use that strategy, but they could have, and ended up with the same result.
at later, unreleased racer actually did use this strategy, in order to add “fake” 3d features to the track.
i wanna know how far this strategy could be taken. could you port fzero to the NES with this?
here’s what the pre-raster mutation graphics of rad racer look like. the road curves are achieved by resetting the scroll register for each scan line.
or, alternatively, the scroll register is the lookup index for a single line in a “video”
rad racer actually squeezes more detail from this map by palette swapping each scanline as well.
looks like NES game “days of thunder” actually used some kind of prerendered video technique.
m.imgur.com/5UpfV1y I wonder if this is less clever than it looks.
ah, days of thunder uses a huge rom, and bankswitches for each frame of animation.
So I decided to try and implement this notion of a video/image compression algorithm. I don’t expect to outperform anything, I’m more interested in the compression artefacts.
It’s kinda cool so far
so this is turning out pretty cool
here it is with some different settings. that smudge at the bottom is the “actual size” compressed png that I reconstitute into the two images on the right.
drool
More results of my scanline oriented image compresser.
thinking about what kind of constraints I should model into this thing. specifcally where it comes to palette changes per scanline. it occured to me that, if my image is 256 pixels wide, with a 256 color palette, the encoder could stealthily stash all the pixels for the row in in row palette. that would be silly. at the moment i just have a per row multiplier for colors, which permits vertical gradients akin to what you’d see in some of the snes mode7 games done to simulate atmospheric depth.
but then there’s levels of freedom between a simple multiplier and full palette change. what’s going to be interesting to try is to see if i can actually tween from one image to another.
so my notion at the moment is that per row i’d have a 6 element vector/matrix.
offset, zoom, left color add, left color multply, right color add, right color multiply.. or not. i am probably overthinking this.
more progress on my slitscan compresser. I’ve turned off linear interpolation on decompression so you can see the crispy pixels. I added a per scanline search through a 2d matrix of brightnesses and offsets, which seems to help it find better offsets. but uh, it’s starting to get real slow.
now back to trying to figure out the travelling salesman problem. hrmph.
here’s the blog article that I remmebered reading- it’s.. less impressive than I remember. I must have had my mind explode with possibilities that day.
like, what I would really like to see is something that combines f-zero with the stargate sequence of 2001 a space odyssey in HD. but i also wanna play with scanline sorting techniques. too bad I am bad at programming.
@zensaiyuki That’s wild considering Argonaut managed to squeeze a 3D engine out of the Game Boy for their port of the sequel. O.o
- i didn’t know about that one. i wish I knew what to google, the whole scanline based video compression idea has taken over my mind.
Just “Race Drivin Game Boy”?
sorry, my toot was confusing. i saw the gameboy game. primative, but having intimate knowledge of the gameboy’s capabilities? no idea how they pulled that off.
what I meant was “scanline based video codec for arcade games” doesn’t really give anything interesting.
that saiddddd you could kinda do a 3d polygonal flat shaded engine on a gameboy by treating the tile map as a 20x18 pixel display, and then refining the handfull of “edge” pixels that are left.
your code would need to be meeeeega optimised though. from the looks of things they could only pull off a few frames per second.
Sega Megadrive/Genesis homebrew demo “G-zero” somehow pulled off the f-zero effect despite the fact the megadrive doesn’t have any rotation hardware. i suspect palette cycling combined with the technique above, but i am not really sure.
now I am thinking about an image compression algorithm that basically takes all the lines in an image and combines them into a single pixel sorted super line, with each line in the original image expressible as deleting sections from the super line.
so I guess this would be like
- make the first line of image line a, and the second line of the image line b
- take the diff of line a and line b
- apply the additions to line a, but not the subtractions to produce a superline.
- the superline is now line a, and the line after line b is the new line b.
- unless there are no more lines, go back to 1.
- output the compressed stream as the superline followed by the diff between the superline and each line of the original image.