The filter applies to everything because it doesn't know how to tell a sprite from the background layer. You'd have to hook into the game code itself to filter things independently. Each game does things in its own way so it would have to be written individually for each game. A stupid amount of work.

Some hardware had dedicated "hardware sprites" but only the most shitty games used ROM routines back then, the best game programmers wrote their own routines which were faster, took up less memory and went way past the "limitations" of the hardware.
Sometimes whole backgrounds or other game elements were made entirely out of sprites, or sprites were multi-layered, as seen on for example Hunter's Moon and a lot of late Ocean/Imagine games on the C64.

AFAIK on late 80's 3D arcade games like SEGA's Power Drift, Out Run and Galaxy Force, maybe there is a simple text/character top layer, but everything else is sprites, the road, the sky, planets, palm trees, everything.

With so many different approaches it would be very difficult to filter the way you want. You'd need intimate knowledge of the emulated hardware platform, the assembly language the games are programmed in, and then come up with a way to split the layers and present each layer to the filtering code running on the host system.
And there's no guarantee that the sprites you want to filter will be on the same layer in level two of your game.

I want to eventually write code to do this but I don't currently program.

Minor issue...

You'd also need a separate upscaler for every game because they may not handle the sprite data in the same way. It would most likely not be stored in the same memory locations for every game in existence. You'd end up with something like bleemcast! with versions specific to one game only and that would really suck and is one of the reasons why bleem! died out so fast.

Emulators for specific game engines, like ScummVM might pull off something like that.
They already handle game-specific drawing routines, so they can more easily tell apart the background from the foreground sprites.

Scalers is something I really don't want to see in emulation. But accurate scrolling and adapting to the LCD refresh frequency are features they should really work on.

No point in having fancy graphics if the scrolling isn't smooth.

i'd like to see crt mocking more often. MAME/MESS, Dosbox+yhkwong and bsnes are the only ones I know of that can. It's something I dreamed of here in Vogons some time ago finally becoming a reality.

There's more use in that than the novelty of a scaler.

There are engine remakes for some games
Free In The Dark - Alone In The Dark (abandoned)
REminiscence - Flashback
to name a couple
Check this link for more. Maybe one of your favourite games is in the list and playable.

I've noticed that some console emulators (namely VisualBoy Advance) allow you to view sprites stored in memory, so would sprite upscaling work for those? I understand it wouldn't be perfect, as some games use sprites for background elements or whatever, and some even eschew hardware sprites altogether, but I think it would work for many situations.

Sorry for the necropost. 😜 I just stumbled across this thread and felt like chiming in.

maintaining blends between block seams would work against that. Applying scaler to vram contents then emulating with it would look like the attack of badly compressed jpegs

leileilol wrote:

maintaining blends between block seams would work against that. Applying scaler to vram contents then emulating with it would look like the attack of badly compressed jpegs

Isn't that how most scalers end up looking anyhow? 🤣

mr_bigmouth_502 wrote:

leileilol wrote:

maintaining blends between block seams would work against that. Applying scaler to vram contents then emulating with it would look like the attack of badly compressed jpegs

Isn't that how most scalers end up looking anyhow? 🤣

Quoted for truth. I loathe all "enhancing" scalers and most sourceports (zDoom and eDuke32 are fine, but I still prefer the original keyboard controlled versions, being a physically disabled guy using the arrows + Ctrl to shoot + Shift to jump is very good for me).

For some platforms sprite replacement is possible. Check out HDNes, which upscales sprite tiles in NES games. Some example images in this NESDev thread.

It's been ages now, but I believe there was also an arcade emulator that allowed for similar tile replacements for a few arcade titles (PacMan, I think a few other games). But it's been just under a decade since I recall hearing of it.

mr_bigmouth_502 wrote:

leileilol wrote:

maintaining blends between block seams would work against that. Applying scaler to vram contents then emulating with it would look like the attack of badly compressed jpegs

Isn't that how most scalers end up looking anyhow? 🤣

I think the difference would happen where there are filter errors due to similar colored edges lining up between spites, other sprites, and backgrounds.

kolano wrote:

It's been ages now, but I believe there was also an arcade emulator that allowed for similar tile replacements for a few arcade titles (PacMan, I think a few other games).

That was EmuDX, available for Pac-Man and Donkey Kong. And that was definitely ages ago.

In those cases the operation was relatively "simple" since it was being done to two specific games with relatively simple programs that have been thoroughly disassembled at this point.

Jorpho wrote:

That was EmuDX, available for Pac-Man and Donkey Kong. And that was definitely ages ago.

It was in 2000, and it was for Pac-Man, Donkey Kong, Frogger, Ms Pac-Man, Galaxian and about 15 others that were work in progress

Jorpho wrote:

In those cases the operation was relatively "simple" since it was being done to two specific games with relatively simple programs that have been thoroughly disassembled at this point.

Possibly a little harsh

EmuDX is alive and well in the Raine emulator, but also as an upcoming android release.

Stay tuned, as they say..

I'd give you crap for registering just to bump a two-year old thread, but when it's MikeDX... I'll forgive it. Welcome! 😁

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.

Scalers are absolutely horrendous, but to each there own I guess.

About the only thing that can handle this type of graphics correctly is a good ole' interlaced CRT display, and emulating that on a flat panel is about as pointless as emulating a turntable for better sound quality.

Now, in a general sense, is there a more efficient way to apply these scalers? nope. You either become familiar enough with the hardware that you're able to tell exactly how everything's laid out and how to single out a sprite from video memory (not always possible realistically speaking), or it's just mere output filtering.

Stiletto wrote:

I'd give you crap for registering just to bump a two-year old thread, but when it's MikeDX... I'll forgive it. Welcome! 😁

Sorry I never saw this, my life has been on turbo for the past while..

Thanks for the welcome 😉