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.
kevincrans says:
Dec 22nd 2019
Merry Christmas and happy birthday! I don't have much intel about it, but maybe some R4 cards can expand the VRAM so you can higher the resolution trough the magic of homebrew, but I don't have intel on it again. I think adding filtering would be neat, add a switch to disable it though, because some people like me think pixelated 3d looks epic. Good luck!
kevincrans says:
Dec 22nd 2019
Wait a minute, when will time stop existing? Ooh, paradox!
Arisotura says:
Dec 22nd 2019
thanks :P

no way to expand the VRAM though (or it would be ass-slow due to having to go through the cart bus), and doing so would be pointless anyway, the screens are 256x192 and the renderers are hardwired to run at that resolution, so... yeah.

and, of course, filtering would be optional.
MelonMan says:
Dec 22nd 2019
Merry Christmas!!
Hope you get through that 11hr journey.
Just a question I wanted to ask:
How far away would melonDS 0.8.4 be?
MelonMan says:
Dec 22nd 2019
I never knew melonDS was that old.
I came to know about it when it was 0.7.
A dragon says:
Dec 22nd 2019
Have you taken my suggestion and looked into seeing if Vulkan can help you get past the limitations of OpenGL, madam? Since Vulkan's supposed to be OpenGL's successor, there might be more you can do with it. Also, merry Christmas to you too.
AsPika2219 says:
Dec 23rd 2019
Merry Christmas and happy new year! Plus, annular solar eclipse is coming on Dec 26 (after christmas)!
I hope next version have more functions and game improvements! Keep moving forward and take care!
Oeil2Fenix says:
Dec 23rd 2019
Merry Christmas !
I have tested MelonDSi now but it only displays the DSi splash screen.
After that, it displays only a white screen and emulator seems to be in a loop on the debug (with unknown ARM7 IO read16 and write16 and WIFI ON and OFF).
I try to found where can be the mistake, but I dont see it :)
I don't know if the problem is the emulator that is not supporting the firmware (it is EUR) or the files. The nand.bin is fine as I have extracted it before installing Unlaunch on a DSi XL and contains the no$gba footer (it works on no$gba emulator).
Anyway, it's a good job :) !
kevincrans says:
Dec 25th 2019
If you have the DS and DSi bios files (don't need and couldn't find the DSi firmware), check boot game directly, this way all DS games work without sound, I wasn't able to run DSi .app, nor DevKit SRL files, so I don't know lol. Don't explain me how to get the DSi firmware from the device.
darc says:
Jan 1st 2020
Happy New Year! Just wondering would you be interested to add custom textures replacment in the future if possible? Thank you for developing melonds this is by far the best ds emulator out there!
MelonMan says:
Jan 1st 2020
Happy New year! Can't wait for what's in store for melonDS in 2020!
MelonMan says:
Jan 1st 2020
Also, I installed Linux mint to my PC and the opengl renderer works like a charm! Probably something to do with the fact that Linux has open source drivers
Generic aka RSDuck says:
Jan 1st 2020
> Also, I installed Linux mint to my PC and the opengl renderer works like a charm! Probably something to do with the fact that Linux has open source drivers

for me it's the opposite: OGL renderer works flawlessly on windows but graphics are glitched on linux. OpenGL drivers are weird.
Sorer says:
Jan 2nd 2020
If you are using AMD GPUs you would get more performance on Linux than Windows.
But I find the Opengl renderer very good on Windows too though.
MelonMan says:
Jan 2nd 2020
I have an Intel integrated CPU (HD Graphics 2000). For some reason on Windows I have opengl version 3.1 (which never seems to work properly) and on Linux I have opengl version 3.3. That's probably not melonDS's fault because now Dolphin is working as well.
> Generic aka RSDuck , about Linux: what GPU do you have? Have you installed latest drivers? What distro of Linux do you have as well? What opengl version does it say you have (You know when you start up melonDS through the terminal)? And by the way the game that I tested was Mario Kart DS.
Post a comment