You are not logged in.

Read the FAQ and Knowledge Base before posting.
WiFi not emulated and not supported!!
We won't make a 3DS/2DS emulator.

#1 2017-09-19 08:34:41

Registered: 2016-03-18
Posts: 12

xBRZ for Sprites

I wanted to kindly ask the desmume devs, if you are currently working on xBRZ for sprites.
The implementation for textures are really really great. Bravo for that!
I am just curious if this is possible for sprites in desmume as well. I really don't want to say, please do it.
It is just interesting to read what the obstacles are and what you tried so far?

I also like to read the progress report from dolphin, pcsx2, rpcs3 etc.
It is just curiosity. smile

Last edited by papermanzero (2017-09-19 08:37:53)


#2 2017-09-19 21:06:28

Registered: 2011-06-04
Posts: 345

Re: xBRZ for Sprites

The only reason why xBRZ can be used for 3D textures is because that portion of 3D rendering is not scanline-based. But due to the way the NDS handles 2D graphics and the way we emulate it in DeSmuME, which are both scanline-based, there are currently no plans for doing xBRZ upscaling on 2D layers and sprites. This is an absolute certainty in this release cycle. Attempting to implement such a feature would involve rewriting nearly the entirety of the GPU compositor from scratch in order to perform non-scanline based operations whilst respecting the fact that hardware NDS's 2D compositor expects everything to be scanline-based.

This is all extremely difficult stuff. Difficult, but not impossible. But again, I must reiterate that this will not happen in this release cycle because of the following reasons:
1. xBRZ does work on directly upscaling 3D textures. This works especially great when running mostly 3D games at the higher internal resolutions (4x or higher).
2. xBRZ (along with other filters) also works on the output framebuffer. For games that use mostly 2D graphics, just set your GPU Scaling Factor to 1 and you can upscale 2D layers and sprites with their proper edge boundaries and blending.

Therefore, there is no need to prioritize this feature because existing features account for most use cases. As the current GPU compositor stands, there will be zero consideration for this feature, since it would be impossible to implement with the current GPU compositor. In the next release cycle, there is a chance that the GPU compositor will get reworked to support compositing operations on the host GPU. If such a thing does happen, then only at that time will xBRZ upscaling on 2D layers/sprites be considered again as a potential feature.


Board footer

Powered by FluxBB