glshim


Evening all,

I've been playing with dosbox from SVN that is supposed to be able to use glshim but can't get the screen fully stretched so my question is: what exactly can glshim do for dosbox? :)

Thanks!
 
Evening all,

I've been playing with dosbox from SVN that is supposed to be able to use glshim but can't get the screen fully stretched so my question is: what exactly can glshim do for dosbox? :)

Thanks!

Well according the ODROID forum it's supposed to fill in as an opengl renderer as I take it the ODROID lacks true opengl and has opengles. this can handle scaling supposedly faster than doing this via software. 

Maybe the forum this was announced on could help you out: http://forum.odroid.com/viewtopic.php?f=52&t=4786

 
 
Dosbox use glshim ? Last time I checked, Dosbox had an OpenGL output, using shader, for scaling. So basically glshim will be useless (no shader in glshim). But that was some time ago, maybe things have changed since then...
 
dosbox at the lowest level just uses opengl to render the internal frame buffer to the screen. Your likely to lose performance during the conversion to a opengl texture for every frame.

Edit: the best option for dosbox is to use Notaz's SDL which can hw scale the screen for free. I use this option personally but i dont think i published it since it wasnt totally user friendly.
 
Last edited by a moderator:
I agree with @Pickle. (The "Experimental" version of DosBox in Streak DosBox PND should use Notaz' SDL, if I remember correctly what I compiled)
 
Hi Seb,

I guess the latest UFO AI master might me a little heavy for the pandora? In case it isn't be aware there's one problem with the native GLES SDL2 build - all screenshots end up black. The mega surprise comes from the glshimmed vanilla OpenGL version which works flawlessly (in all other departments as well!)Seeing as you were the original porter, have you got any idea why this could be happening?
 
Hi Seb,

I guess the latest UFO AI master might me a little heavy for the pandora? In case it isn't be aware there's one problem with the native GLES SDL2 build - all screenshots end up black. The mega surprise comes from the glshimmed vanilla OpenGL version which works flawlessly (in all other departments as well!)Seeing as you were the original porter, have you got any idea why this could be happening?

Ah good to know. I will probably try to update my port of UFO-AI (using glshim maybe).

About the GLES port, I guess the screenshot are made using a glReadPixels with not GL_RGBA GL_UNSIGNED_BYTE... In most GLES implementation, you can rely only on this to make glReadPixels and then convert the data to, for example GL_RGB GL_UNSIGNED_SHORT_5_6_5...
 
Thanks - with your permission I'm going to open a new issue in ufoai bug tracker, citing this info.
 
Hi,

I've managed to build and run torcs 1.3.6 on my Odroid C1 using the latest glshim.

The game seems to run but there's a problem with all text fields missing (menus unusable) and a few other artifacts. Have a look at the screenshots.

After switching to mesa and back again it's possible to change the configuration and actually use the menus blindfolded but it's far from perfect :)

torcs.jpg

torcs2.jpg
 
Last edited by a moderator:
I'm still using the 'debug' build with all the printf's enabled so lots of console messages are available in case you needed them.
 
Last edited by a moderator:
I'm still using the 'debug' build with all the printf's enabled so lots of console messages are available in case you needed them.

I will first try to reproduce on my side, and if I do, I'll do a PVR Capture to check what is happening (with the capture, I have a GUI showing me all individual GLE command, GLEs states, and so on, very handy for debugging that kind of things).

If I cannot reproduce, I'll ask you the logs.
 
Nice tools! :)  BTW, foobillardplus seems to be the other affected program (from about a dozen I've checked over the last few days)

EDIT: I've learnt a new word - swizzle :)
 
Last edited by a moderator:
And so is foobillard (non ++).

I have seen some interesting error:

libGL swizzle error: (GL_LUMINANCE, GL_UNSIGNED_BYTE -> 0x2002, GL_UNSIGNED_BYTE)
libGL: unsupported pixel format 2002
libGL: unsupported pixel format 2002
libGL: unknown pixel format 8194
So, probably the source of the issue :)
 
yep.

I tried to make some things with the internalFormat of the texture... I have change the strategy, it should be better now (commit pushed). At least foobillard is ok now.
 
yep.

I tried to make some things with the internalFormat of the texture... I have change the strategy, it should be better now (commit pushed). At least foobillard is ok now.

Apart from the mini map in torcs everything's back to normal. It used to work, right?

I did update libstdc++ a few days ago and as I have never seen this message before:

refresh: ssgCullAndDraw invalid enumerantor

grDrawBackground: ssgCullAndDraw invalid enumerant
I'm not sure if it's torcs specific or the update broke something.
 
Last edited by a moderator:
@petevine, yes, I have done a few changes here and there. Mostly for speed, but not only.I have hacked FBO support for offscreen rendering of the mirror and map, and hacked a bit the map rendering. The problem is that the "glutGet(GLUT_WINDOW_ALPHA_SIZE) " function, called in src/modules/graphic/ssggraph/grtrackmap.cpp will probably not give a relevent result. So I have changed

if (glutGet(GLUT_WINDOW_ALPHA_SIZE) == 0) {
// There is no alpha, so we fix it manually. Because we added a little border
// around the track map the first pixel should always contain the
// clearcolor.
to

if (1/*glutGet(GLUT_WINDOW_ALPHA_SIZE) == 0*/) { // *SEB Pandora
// There is no alpha, so we fix it manually. Because we added a little border
// around the track map the first pixel should always contain the
// clearcolor.
You should be able to see the minimap with this change (if you want the fbo change, tell me, I don't have a diff, but I can put relevent source file here).
 
Back
Top