mr_bigmouth_502 wrote:

That's what I was thinking as well. 🤣

Anyway, back on topic, I've tried looking up information for this HDNes emulator, and it seems like it's hard to find actual builds of it, or the texture packs to go with it. Now, as for the idea of upscaling and filtering individual sprites, I can see why it may be difficult to do, but a pretty generic solution would be to apply filtering to the individual background layers, as well as the tilemaps stored in memory. Now, I'm not sure how much it would actually improve the visuals, but it would be an interesting thing for an emu author to try. Maybe one could even mix and match different filtering techniques, using one for sprite layers, another for backgrounds, etc.

The original versions were called "MyNES". https://www.youtube.com/watch?v=haGHtKWmj5M . It's on Sourceforge but the functionality was stripped following a lackluster response by the community.

While it's a pretty simple thing to implement per-sprite scaling on a console (or at least to scale the sprite and background separately), it's not so simple to do this on a PC because you don't know the origin of the graphics (to say nothing of the rasterizer effects like screen melts and heat waves). You could obtain some success in some cases by substituting the graphics at file level, but then you'd need to know the palettes used... Any way you look at it, you're looking at per-game profiling on par with a translation, probably requiring similar techniques in all their difficulty and complexity. Compressed data in particular would be very difficult to work with.

it's too bad the authors of MyNES/HDNes stripped support for sprite replacements. I really wanted to try out the alternate graphics for Zelda II.

Quick update.. A new version of "3DNES" is out.

I know, it isn't really about HD graphics in particular, but I thought I should mention this.

Source: https://geod.itch.io/3dnes

For some reason the 3DNES videos and screenshots remind me of claymation, and I like it 😁

1) Even if the algorithm works well, separately scaled sprites will look like cardboard cutouts. Not very tasteful, if you ask me.
2) Logic might be quite complex, because on most 2D consoles sprites are made from small tiles, and if you scale each tile separately, you'll get horrible "poortly compressed JPEG" look mentioned before.
But this is doable. Long time ago I had plans to do something like that for 2D PS1 games, but never actually implemented. gpubladesoft today does hi-res framebuffer though, but there is no focus on detecting sprites and improving 2D games, as far as I know.

IMO,

Except for a few specific cases where artifacts were a required part of the visual component (most Apple II, 8-bit Atari, C64, and CGA/EGA games) to display the necessary colors and pixel shapes (anything where you see alternating lines of different colors was intended to use the CRT blur,) I find that the only scaler that should be used is nearest-neighbor in 1:1 pixel scaling. This is much easier to do with GPU's due to the inherently parallel math. But not everything scales correctly on LCD screens, hence the need for some half-measures to ensure that the GPU/Monitor upscaler isn't used (which are designed for scaling lossy video, not games.)

That said, most of the "improvement" type scalers which try to create detail or artifacts that were never in the original game nor were intended are completely missing the point of emulating the software in the first place.

You can only enhance a game by knowing aspects of the game itself. This is why "high resolution textures" work on N64 and Playstation emulators, because these games were originally designed to be 3D, but only a few games are materially improved by doing so (eg Paper Mario), because there is no change in geometry.

NES/SNES and arcade games based on hardware of that era can't be a one-size-fits-all solution. The Mario games may be able to work under 3DNES, but it would have to be fine-tuned to every single game because what looks OK on one might make it unplayable on another. Think about how transparency is handled in 8-bit games, usually by flickering.

I had a ridiculous argument with someone on the point of pre-up-scaling sprites for use in a higher resolution game engine (Waifu2x being the scaler, RPG Maker engine series.) You're increasing the size, thus wasting space, and the effect might not even be desired. That is why pixel-art scalers should be left to the whim of the user and not dictated to the user, especially when there is a performance penalty for using larger sprites.

More to the point, if current pixel art rescalers don't use the GPU, then they are effectively costing the emulator performance that could otherwise improve the emulator with more accurate timing.

Kisai wrote:

More to the point, if current pixel art rescalers don't use the GPU, then they are effectively costing the emulator performance that could otherwise improve the emulator with more accurate timing.

The obviouis rejoinder is that rescalers are much easier to implement than "more accurate timing".

Kisai wrote:

You can only enhance a game by knowing aspects of the game itself. This is why "high resolution textures" work on N64 and Playstation emulators, because these games were originally designed to be 3D, but only a few games are materially improved by doing so (eg Paper Mario), because there is no change in geometry.

Works against it IMO. It also has the side effect of making the low polyness more apparent with more detail crammed into it, outline the faces with noise.

there's a funny minecraft "meme" that exhibits this nicely

While I agree on most of the topics,

Kisai wrote:

More to the point, if current pixel art rescalers don't use the GPU, then they are effectively costing the emulator performance that could otherwise improve the emulator with more accurate timing.

Well, there is a limit to how much emulation time you need to reach "100%" compatibility. Beyond that it's all about how good you are at guessing hardware quirks, not about how much more CPU clocks you can waste. Also, in actual implementation, the scaling result will probably be cached, and doing things on GPU usually costs latency(=input lag), which is more important than raw throughput. Also, implementing algorithms on GPU is harder and eats development time while simultaneously complicating support, because GPUs change more rapidly and their drivers are full of bugs. In contrary, x86 assembly code written 15 years ago will still work, with blazing speed.

Kisai wrote:

(anything where you see alternating lines of different colors was intended to use the CRT blur,)

Not only CRT blur. It is supposed to be processed by analog NTSC comb (or at least notch/bandpass) filter.

Certain games use background tiles for characters such as bosses. Still, some other games exceed the maximal per-sprite color limit by overlaying a sprite tile over others, such as in Megaman on the NES. Still, other games have to group multiple sprites together to make larger elements such as characters.