melonDS wishes you a merry Christmas!
Not quite Christmas yet, but whatever. Soon enough time itself will stop existing, so these considerations are futile.

We're also past melonDS's third birthday. Time flies, it's crazy.

So what's new on that front? Well, not a lot, alas. I want to improve the OpenGL renderer, but for now, I started working on things, hit a roadblock as to how to do certain things, and, surprise, lost motivation. So until I get that back, there won't be a whole lot happening.

Also, Christmas might be more or less of a shitshow, as I'm trying to make it to my hometown to see my family whom I haven't seen in ages. I'm eagerly waiting for that, but it's not going to be that simple. Remember the general strike from Dec 5? Lo and behold, it's still going, and the train I had booked was cancelled due to it. I booked a bus instead, which is going to be a lot of fun (11-hour trip during the night, in conditions where I can hardly sleep). Besides, the crazy Macron government is indirectly pushing these bus drivers to drive as long as possible without rest (mostly to make up for the strike), by passing a bill to remove the requirement for breaks every 2h, thus completely disregarding security for the sake of profit. So, if I happen to die in a bus crash, you know who to blame.

Anyway, back to OpenGL. So, what I wanted to do:

1. Taking care of dual-screen 3D, and more generally any case where display capture is used. Currently, 3D frames that go through display capture end up downscaled back to 256x192, obviously because they need to fit in VRAM, and anything that uses them expects them to be that resolution.

There are ways to address that for the common use cases, though. As long as a captured frame isn't accessed by the CPU, it is possible to bypass VRAM entirely and instead use something like an OpenGL texture, without causing any visible problems. Sure, it's not too accurate to how the DS works, but neither is the general idea of upscaling. I am fine with this as long as we keep the accurate pathway (basically, the software renderer).

Anyway, the issue there is that I have to envision all the possible use cases. And for example, one possibility is to capture to a VRAM bank, with capture blending set to blend between the frame being rendered and a previous frame sitting in a VRAM bank (which may be the same bank we are capturing to).

I could always start with a simple use case (like dual-screen 3D). The issue is that I always feel the need to envision the whole scope of the project, all the use cases etc, because I fear that if I start building something for one use case, it may later prove unsuitable for other uses cases, and cause me to have to start again from scratch.

So, while simple display capture can be implemented as a simple colorbuffer copy, any case that relies on blending will need more work. I will need to think of a workaround for the case where we read and write to the same VRAM bank, because doing so is a no-no in OpenGL.

Oh well.

2. Add filtering to 2D elements. This is less simple than it sounds, due to how layer compositing is handled in OpenGL mode. I thought about adding something simple first, basically, linear filtering. But a clear issue is how to handle borders between 2D and 3D. Keeping them pixelated is the easiest way but also the least nice one. The more obvious choice would be to smoothly fade from one to the other, but due to them being distinct layers with specific blending rules, it's easier said than done. I'll have to experiment there, but filtering on 2D elements is something I definitely want to pull off. I plan on adding other filters, like xBRZ. Those would do wonders on a game like NSMB, for example.

Oh well, we'll find ways.

Other improvements would be adding texture filtering and fixing some rendering bugs, nothing big.

Also, we need to push the JIT some more. The JIT beta seems to have gotten much less traction than I anticipated.
MelonMan says:
Jan 2nd 2020
Sorer : Yes, better performance on Linux for AMD. Their excuse is "Vulkan is the future".
Also Generic, could you upload a picture somewhere (like on Linux with Opengl at the mariokart ds character select screen?
poudink says:
Jan 3rd 2020
well, they're not wrong. is opengl used for anything other than compatibility with older computers at this point
Sorer says:
Jan 3rd 2020
OpenGL is used with every modern emulator lol.
The API just got more functionality and it's easier to use than Vulkan and it also supports MacOS (kinda).
MelonMan says:
Jan 3rd 2020
poudink: There should be compatibility with older pcs. Not everyone can buy a powerful graphics card and have to use integrated graphics on old pcs.
Sorer: Apple decaprecated OpenGL (and CL) but there is an implementation of Vulkan through MoltenVK (I think it translates Vulkan to Metal)
poudink says:
Jan 3rd 2020
you don't need a powerful graphics card to use vulkan by any stretch of the imagination, but I also never said there shouldn't be compatibility with older PCs, just that opengl's demise is inevitable.
kevincrans says:
Jan 5th 2020
Happy new year, Arisotura and Generic!
Post a comment