You are not logged in.

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

#1 Re: Technical » OpenGL Integration? » 2011-01-22 23:15:25

Ah. That makes a lot more sense. Definitely interpreted that wrong. I get touchy when it sounds like people bag the main library I've used for the last 5 years. Although what you say holds solid for me wanting to boost the speed on my laptop. It doesn't have the grunt of my desktop, hence the GPU acceleration.

I'll give you half of that statement though. OpenGL code is perfectly portable, but limited by the quality of the implementation. For example I've seen a few bugs in Apples implementation over the years. Luckily DeSmuME uses it fairly little, meaning I shouldnt run into any problems if it's all basic OpenGL. Most of the issues I've seen are with rarely used methods.

I saw that code as well, you can usually tell OpenGL to store framebuffers in a specific format, but now that I think about it, I didn't see actual OpenGL framebuffer object code being used so I'll double check that and start there. Thanks!

#2 Re: Technical » OpenGL Integration? » 2011-01-22 10:37:24

Oh ok, I downloaded the 0.9.6 source on the download page, modified 25th of March last year I believe. I'll download the svn as I just found that smile

Asynchronous readbacks give the results immediately, unlike synchronous which waits. In OpenGL you can get back the framebuffer instantaneously if you know how, it actually makes the glReadPixels call asynchronous to be exact, and you can also map that directly to the memory on the GPU, the risk being that it is so instantaneous, you can get back an incomplete buffer if your OpenGL calls have not completed at that stage, which you can ensure anyway.

A 66fps to 73fps boost isn't bad in my opinion, on my Macbook Pro I get about 40-50fps at times and an extra 7 gets you that much closer to 60, although I doubt I would see that increase on my system, so maybe a 4fps increase if I'm lucky.

I don't want to start a flame war, I'm here because I'm interested in DeSmuME and am keen on wanting to do a little to help. But OpenGL is far from old and in no way meant for crappy computers. I'm a computer graphics developer primarily, and I work extensively with OpenGL on performance critical applications. That's like saying Direct3D is dead and should be replaced with a software rasterizer, which in turns makes all GPU's redundant. Nothing beats GPU acceleration in my opinion and OpenGL code itself is 100% portable, if not, I would be in a world of pain tongue

#3 Re: Technical » OpenGL Integration? » 2011-01-22 07:48:36

I assumed that was the meaning, it just seemed out of place with display lists being a cache of fixed function commands in OpenGL.

Vertex batching is what I am thinking at the moment. Vertex Buffer Objects can provide drastic improvements, usually at least 200%, in my personal projects, over 1000% in some cases. Even several different batches is faster than no vertex batches. Don't get me wrong, this is where I am going to start as it's my specialty, but I plan to look at a lot more things to change. Also the code I have only renders triangles, the quad code is commented out so I assumed gfx3d was already converting the quads to triangles.

You've got me curious about the framebuffers now, I'm doubting the use of asynchronous readbacks from the GPU from what I saw in the code, which can significantly increase performance when used correctly.

I don't plan on sacrificing quality smile

#4 Re: Technical » OpenGL Integration? » 2011-01-22 06:43:32

Hey Zeromus,

Thanks a lot for your response. I had mentioned I only took a quick look, so I probably saw the aggdraw and gfx3d files and assumed these were all that it was using.

Having a look at the OpenGL section of the code, I see for example it uses the fixed function pipeline for rendering triangles and even though it says in the comments that it is using display lists, it simply isn't (maybe a mix-up in terminology in the comments?). This is exactly the kind of thing I was looking at finding and optimising.

However if I can't speed this up, I might as well take a look at the pthreads integration. That shouldn't be too hard.

#5 Technical » OpenGL Integration? » 2011-01-22 05:01:41

swiftless
Replies: 8

Hey everyone,

I've been interested in the DeSmuME project ever since I found out it worked on OSX, however looking at the source code it is using a drawing library that doesn't support hardware acceleration, if my memory is correct, it is a C++ library of some sort last time I checked.

I'm not sure on the development progress of DesmuME, or if it is even still being developed, but was wondering if there were any plans to integrate possibly OpenGL? The big kick in the guts is the rendering stage on my Macbook, however I haven't had an in-depth look at the code, just a peek at this stage.

I might have a go at optimising it myself for OSX if there aren't any plans at this stage.

Cheers,
Swiftless

Board footer

Powered by FluxBB