[Q] Will Drastic ever support non-buffered rendering?

[huckleberrypie]

abeit the fact open gl works fine on nds4droid, just a little slow becaecause of nds4drpid being unoptimised

Well, NDS4Droid's dynarec is slow as mollasses compared to Drastic's, but Exo didn't opt to use software rendering for no reason.

[kaikun97]

abeit the fact open gl works fine on nds4droid, just a little slow becaecause of nds4drpid being unoptimised

Well, NDS4Droid's dynarec is slow as mollasses compared to Drastic's, but Exo didn't opt to use software rendering for no reason.

I know but SW rendering kind of defeats any viable way of adding Hi res rendering or similar.

[Exophase]

Why not? you can use open gl for 3d acceleration. nds4droid works with it along with practically every windows ds emukator and with most gpus in phones it wont be an issue. Rendering jusy 3D graphics in open gl could work. if you just use software the whole time we'll never be able to get high quality or hi red rendring and uts something a lot of us want now

Because:

1) There's a bunch of compatibility issues. Some of it due to restrictions with OpenGL ES - 2.0 is the worst, but 3.0 is still missing useful things, and the adoption really isn't wide enough that I want to do something that requires it. Then there are some things that you will never really get working just right with hardware rendering, like DS's totally different style of rasterization.

2) On DS the 3D and 2D engines are combined (and not in a trivial way), in order to emulate this with OGL you need to copy back the render target into CPU-visible space which, depending on the device/drivers/etc, can be extremely slow. DS games also often update textures every frame, which can also lead to a fair amount of extra overhead, although that's not as severe. The point is, if the speed isn't there it defeats the entire point.

I don't know about every Windows DS emulator using it, the situation is more like the emulators did OGL renderers a long time ago because it was easier to get something done with, then put more energy into getting decent software rendering working. It was never chosen for the purpose of enhancement, only very recently has anyone even done it (and using a bunch of heuristics). I haven't used nds4droid, but looking at the shaders in the source it's clear the OGL ES2 renderer isn't going to be the most compatible thing in the world, but there I'm sure there was a lot of motivation to add it because the software renderer isn't very fast. You say it works fine, but really how much in-depth testing do you actually think was done with it?

And it's not right that resolution enhancement can't be done with software - of course it can, you just have to pay the price in terms of CPU utilization. Why not wait and see if I go anywhere with it before drawing conclusions? One thing at a time here. Even if hypothetically I were to experiment with OGL ES I'd still do it in software first.

[zxcvbad]

Some of it due to restrictions with OpenGL ES - 2.0 is the worst, but 3.0 is still missing useful things, and the adoption really isn't wide enough that I want to do something that requires it.

What extensions are missing in GLES 3.0 that DraStic would need? What about GLES 3.1 with AEP and features like fragment/vertex shaders?