NES gimmicks, Scaling. Impossible feat? Maybe not?


Now a thing that I had few days in rolling in my mind about possibilities in realms programming for NES has been...
The title spoiled it! Scaling! Now I'm not a professional NES programmer yes... However I am quite aware of it's typical limitations and what it can do, why and how to a certain degree.

But when it comes to automatic scaling... It actually doesn't sound as far fetched of an idea as it would've been back in the 90's.

Now one thing is for certain, you ain't going to make 8x8 sprite to a size of 16x16 sprite, that'd be utter lunacy. Well... Not really but if I'm calculating things right in my head, I'd say it is.
But technically, with few gimmicks and I'm not talking about making a new sprite for every size to create the illusion of scaling effect, you could technically reduce the size of a certain sprite especially of it has only a one color.

From what I understand and have seen in some examples, typical sprite in coding looks something like this...


That should be a 8x8 pixel sprite. It's simple and pretty self explanatory. Doesn't look like much that you could do something about except flip it.
Now of course some of you might already be screaming from top of your lungs "The bloody muppets are you talking about you dang lunatic of a pseudo programmer!? That's not how it works at all!" And you'd probably be right about it.

However for the sake of this little thought experiment, what if, we wrote a code that would squeeze those zeros and threes probably, to a smaller scale?

How would you tackle this problem and do you think, there would be any sort of workable solution for this?


Now one thing that comes in to my mind is, what if we reduce those numbers to the up-left corner?
Now everything that comes from the downright needs to be changed in to value of zero. Naturally.
Everything after that... Well... With a quick and flawed logic, things should cycle from 0 to 3 so if next value is 0 and value next to it is 2 then zero should become two and if it's one then it should become three and if it's two then it should cycle to 1 so on. X and Y axis to the center of the hitbox should be easy to recalibrate per every cycle sprite gets smaller so that thing shouldn't be an issue...


New member
It is so funny you mention that! Just this morning I was working through this idea. I recently set up my game to load CHR tiles to the PPU during gameplay and thinking about how CHR tiles are set up led me to wonder about manipulating the CHR before transferring it during vBlank. Sprite scaling would benefit my game greatly if I worked out. I had seen that demo linked above a few months ago and figured it was well outside of my understanding but I've learned a lot since then and after studying it a bit it seems possible to me now. Tepples used lookup tables to manipulate the data being loaded to the PPU. A single tile is 16 bytes long and is organized as two sets of 8 bytes. The setup is explained here
So from your example above, 01230123 breaks up into 00110011 and 01010101. If you use each byte as the y in a lookup table such as
lda ReduceBy02,y
you could get something that works out to something like 02302300 . Just shift the sprite next to it to the left two pixels and you've got a scaled metatile. Tepples also scaled vertically by having a variable count as the lines are copied and skipping one at set intervals then shifting the nearby sprites up to cover the 00000000's left behind. After four steps of scaling the sprites would all reset and another predrawn sprite graphic would load and start the process again. That way, among other things, you don't just have a ton of sprites sitting on top of one another making you run into sprite limits real quick.

So anyway, yeah. Seems possible. I was just trying to figure this all out. I figured I would try to implement it in the next couple weeks or something but now you've got me thinking about it again.


Active member
There are a couple NES games which fake sprite scaling effects, usually the "into the screen" shooters.
Using limited animation frames to fake it is by far the simplest approach. Using lookup tables of pre-calculated stuff is much, much faster than calculating things on the fly.
If you're going to implement such a feature, either make it a core aspect of the game (like those shooter games), or make it really subtle (a la Rare).
It's not worth using impressive techniques if it doesn't compliment the game well.
Top Bottom