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 2007-04-01 21:33:16

masscat
Member
From: UK
Registered: 2007-03-17
Posts: 73
Website

Using openGL to draw to screen (not doing 3D)

I have put a patch up on the sourceforge page which uses openGL to render the NDS screen (as a textured quad). This patch is for the cli version only.
Since openGL supports BGR 1_5_5_5 formatted pixel data the NDS image can be used directly (removes the SDL call to convert the pixel format). Scaling of the window is achieved with very low cost (hardware dependent) - you can play on a tiny little NDS if you want or, maybe more usefully, a larger one.

On a nvidia 7600go system, playing the zookeeper give ~65 fps (opengl) compared to ~56 (software).
On a ATI 9200se system, it is ~27 (opengl) fps compared to ~30 (software).

As you can see it does cause the emulation to run slower on older systems.

So before I consider putting this into the CVS I would like to get some feed back.

Should software/openGL render be user selectable?
What does it run like on your system (I use linux and cannot build Windows binaries)?
How do you do openGL under GTK (for the gtk and gtk-glade version)?

Ben

Last edited by masscat (2007-04-01 21:34:06)

Offline

#2 2007-04-01 21:57:55

shash
Administrator
Registered: 2007-03-17
Posts: 897

Re: Using openGL to draw to screen (not doing 3D)

The main problem that I see, is that a large ammount of hardware doesn't support 1_5_5_5 (yes, you'd be surprised how many of the cheap integrated cards don't even support 16bpp textures). I would prefer to leave it selectable.

BTW, in august I did a branch of my code to make a openGL only blitter, but I always got slight speed decrease on my hardware, so never cared to support it tongue

Offline

#3 2007-04-01 21:58:37

XTra KrazzY
Member
Registered: 2007-03-23
Posts: 108

Re: Using openGL to draw to screen (not doing 3D)

masscat wrote:

I have put a patch up on the sourceforge page which uses openGL to render the NDS screen......

1. Should software/openGL render be user selectable?
2. What does it run like on your system (I use linux and cannot build Windows binaries)?
3. How do you do openGL under GTK (for the gtk and gtk-glade version)?

Ben

1. Yes, as most emulators do, DeSmuME supports engine switching as it is modular in its source...
2. Haven't tried to compile it yet... Patch takes over my files tongue
3. (I'm not an official, I just know the source a bit) It is done in OGLRender.c and OGLRender.h

I like your code, but it still requires SDL for some reason(and I can't compile a windows binary because libgen.h is missing...), I'll look at it later.

Your additions are great[er than mine], keep up!

P.S. What's different in CLI anyway?


If you are reading this signature, you SERIOUSLY need to get a life.

Offline

#4 2007-04-01 22:55:55

masscat
Member
From: UK
Registered: 2007-03-17
Posts: 73
Website

Re: Using openGL to draw to screen (not doing 3D)

If the 1_5_5_5 format is going to be a problem then it would be easy enough to provide a number of options to the user:

a) full openGL
b) convert to 24 RGB (using the SDL call or similar) then use openGL for display.
c) full SDL (as is now)

Options 'a' and 'b' allow for fast scaling of the window which is a useful feature. Although 'b' will be slower than 'c' probably.
Option 'c' will work on everything but no/or slow window scaling.

EDIT:
After a bit of thinking:
My understanding of openGL is that when you create a texture with glTexImage2D, the internal format parameter is just hint at the desired internal format. And if this is set to GL_RGB there the implementation is at liberty to choose which ever internal format it feels is "best". So if I create the texture as GL_RGB the implementation gets to choose and may select a "better" internal format than GL_RGB5.

As for the pixel format GL_UNSIGNED_SHORT_1_5_5_5_REV, this is specified in openGL 1.2 and greater. Therefore any implementation of openGL 1.2 or greater will support importing data in that format and converting it to some internal format (maybe the same, maybe different - see above).

Therefore the options 'a' and 'b' above would be handled by the same code.

So I propose:
Change the glTexImage2d internal type to GL_RGB and let the openGL implementation decide what is best.
Put in a user option to select openGL or software render (SDL, GTK or whatever).
Default to software render (as this will work).
Check openGL version and if less than 1.2 fall back to software render.

NOTE:
Although I refer to software render it may actually be hardware accelerated (e.g. hardware blit). It is just a convenient name to differentiate the two methods.

Last edited by masscat (2007-04-02 11:10:35)

Offline

#5 2007-04-05 09:23:53

damdoum
Member
Registered: 2007-03-21
Posts: 4

Re: Using openGL to draw to screen (not doing 3D)

an alternative to texture quad is gldrawpixels.
on some hardware texture quads are more efficient, on some drawing pixels is better
so we need an "a bis)" and "b bis)" with drawpixels instead of texture quads.

could we design a customizable stacking operation mechanism ?
like :

-software master bright
-2D decode 24 bit color
-gldrawpixels

or

-gltexture2d with 1_5_5_5
-gl master bright

...etc

Offline

#6 2007-04-05 10:09:54

shash
Administrator
Registered: 2007-03-17
Posts: 897

Re: Using openGL to draw to screen (not doing 3D)

Masscat: I know it's a core feature after 1.2, the problem is that many drivers aside ATI and NVidia ones convert the data to GL_RGBA in the glTexImage. It wouldn't be a problem if it was used like in games: upload once, use a lot of times. The problem is that we are going to use it to stream data, so it might be slow. I needed exactly that format for some stuff I did at work, and found that problem, even on ATI 9X00 series. The performance loss in that card line in particular was about 60%, converting it to GL_RGBA in software fixed the issue, but that needed a bit more of CPU power, which we dedicate to emulation.

Offline

#7 2007-04-06 13:10:27

masscat
Member
From: UK
Registered: 2007-03-17
Posts: 73
Website

Re: Using openGL to draw to screen (not doing 3D)

shash:
I was being lazy and hoping the driver texture conversion would be good enough, but at 60% then it is worth doing a custom conversion in software.
So back to three screen drawing options:
a) full openGL
b) convert to RGB then openGL texture
c) as is now

With a user option to select openGL and a sub option to select software RGB conversion.

damdoum:
The main reason I was doing the textured quad was to allow for cheap scaling of the window. By using glDrawPixels it would be similar to what is there now but using openGL instead of the SDL/other function calls (maybe quicker or slower depending on hardware/drivers etc.).
As you suggest, the screen brightness function can easily be performed using openGL and a bit of blending - again acceleration dependent on hardware.
To save complication of the core emulation, the core emulation could produce the screen image (BGR 1_5_5_5 format as now) and a set of brightness levels per screen line (0 to 255 - I am assuming that the master brightness can be changed and take effect at any time and using a value per line as a compromise). It is then up to the particular platform port to decide how best to combine them. This would stop any platform/hardware specific stuff wondering into the emulation and still allow for acceleration where available.

On another note:
I did not realise that the gtk-glade version can already uses openGL to do its screen drawing. It allows for scaling the windows (by fixed amounts) and changes to the orientation of the NDS screens (nice for Braintraining) with little or no impact to frame timings.

Offline

#8 2007-04-06 17:28:03

damdoum
Member
Registered: 2007-03-21
Posts: 4

Re: Using openGL to draw to screen (not doing 3D)

1- pixel drawing,
it works fine, and using glPixelZoom (or smthg like) can do cheap scaling, but no rotation hmm

2- gtk-glade,
well, we have the same concerns about rendering, and software scaling just happens to slow
things down by a lot. Master brightness, when software done, is not cheap too... That is why it
is in gtk-glade done with hardware if the libs are present.

3- current problems with gtk-glade,
the problems is thatmerging things with recent 3D development is not so easy. We have problems
of contexts, direct or indirect rendering, doing gl commands that must not interfere with each other,
plus the fact that in gtk-glade the screens are actually split... (maybe it will change if we dont find a
solution to this context problem)

4- master-brightness,
as it is currently in gtk-glade, i have made the assumption that it is in effect for the whole screen, so
if it changes between lines, it will not be reflected hmm  However, developers of nds games must be clever
enough to avoid this when possible, so the real cases where it is not done right should be quite very few.

Offline

#9 2007-04-09 03:04:34

jmk
Member
Registered: 2007-04-08
Posts: 1

Re: Using openGL to draw to screen (not doing 3D)

For what it's worth, I ran into the exact same issue in my Mac OS X port when using an OpenGL texture for display. This worked fine when I did the exact same thing that masscat did, using the appropriate GL formats to use the emulator's framebuffer directly as a texture. However, I hit a 20% slowdown on my particular system -- which is better than the 60% that shash saw on other hardware, but still slow enough to be bothersome.

Instead of relying on my OpenGL implementation's pixel conversion routines, I wrote a very simple, unoptimized routine that just swaps the color components to match the preferred packed pixel format. To my surprise, the pixel conversion became an almost negligible blip in the profiler, and things are basically back to full speed again.

If the emulator had the option to generate ARGB/1_5_5_5_REV output, as masscat suggested, this would be even better -- well, for some of us, at least. smile

Offline

Board footer

Powered by FluxBB