MiSTer FPGA Forum

https://youtu.be/eaJAns0HLuQ

This video triggered me to remember an idea I have had for years now, but lacked the low-level understanding of the hardware to make happen. You wouldn't want to play the games this way due to the amount of lag you would face, however as we approach higher and higher screen resolution, applying these filters in post-processing can result in a near-vector-graphic look. Not quite though - the title screen alone betrays this.

The idea I have had kicking around for at least a decade is to take a single game and its sprite sheets, and redraw the sprite sheets in actual vector. Then create a 1:1 map between the memory location of the bitmap sprite sheet and the vector sprite sheet. When the game calls for a bitmap sprite, instead of drawing that, look at the map, pull the vector "sprite" instead. This should result in the game being able to scale to virtually any screen resolution, and potentially being able to draw additional details on-screen that would have been impossible before.

...am I crazy, or is this possible? I recall back in 1999 someone attempted something similar with Pac-Man DX, but instead of vector, they simply used higher-resolution bitmaps.

Sure, this entirely breaks the concept of hardware-recreation and historical preservation, but like what we see happening with the PSX, it could create something of a truly "super" Famicom.

Is there a technical limitation I am overlooking here? I am not asking anyone to actually make this. It would be tedious and time-intensive, not to mention redrawing entire game sprite sheets! Best to start with a super-simple game with no fancy mappers. When I had the original idea over a decade ago, it was for SOTN, and calling that ambitious is an understatement:

You're going to need to fool the game and tweak the hardware into rendering these vector sprites like nothing changed. That's likely going to cause timing issues at the very least.

Wow, I personally just hate this type of pixel art profanation

Possible? Lots of stuff is possible.

The technical limitation is, as Bas rightly pointed out, the potential for causing issues with achieving timing closure. It would likely require a fork of the core with a bunch of stuff ripped out and a bunch of features of the MiSTer framework disabled or taken out. It's not as much the logic space, it's the complexity of so many things in parallel.

I don't see any reason to want to achieve this since I think the image looks a lot worse in that "vectorized" form.

Neat idea, but I think it would be much simpler to use an upscaling algorithm on the whole screen that fills in the extra resolution through interpolation and other methods. Using something like what Topaz Labs does with their so-called AI might be interesting too.

Thank you all for the input. Bas, your remarks on closing timing loops isn't something I had really considered. It seems really easy for something like this to desync for the game logic in a hurry. :\

numbski wrote: ↑Fri Jan 13, 2023 12:20 am

The idea I have had kicking around for at least a decade is to take a single game and its sprite sheets, and redraw the sprite sheets in actual vector. Then create a 1:1 map between the memory location of the bitmap sprite sheet and the vector sprite sheet. When the game calls for a bitmap sprite, instead of drawing that, look at the map, pull the vector "sprite" instead. This should result in the game being able to scale to virtually any screen resolution, and potentially being able to draw additional details on-screen that would have been impossible before.

Might want to check out this guy's work on Vector Kong.