glshim
- Thread starter lunixbochs
- Start date
- Joined
- Jan 18, 2010
- Messages
- 11,411
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
ptitSeb
Serial Porter
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...
Pickle
Mega GP Mania
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.
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:
ptitSeb
Serial Porter
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?
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?
ptitSeb
Serial Porter
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...
ptitSeb
Serial Porter
Sure, go on.
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
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
Last edited by a moderator:
ptitSeb
Serial Porter
Mmm, I have to check, maybe the latest commit have broken something (because I got it running well previously).
ptitSeb
Serial Porter
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.
ptitSeb
Serial Porter
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
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
- Joined
- Sep 18, 2011
- Messages
- 742
0x2002 is GL_R
ptitSeb
Serial Porter
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.
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:
ptitSeb
Serial Porter
@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).
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).
