glshim

[lunixbochs]

You can't use EGL with remote rendering. Only works on GLX right now.

@nighteagle I moved and haven't set up my GLES dev hardware yet so I haven't got a chance to fix this

 

[lunixbochs]

Just tagged release 0.42 which has remote rendering included, better synchronization, and all of my wrapping tests pass. If anyone previously playing around with remote rendering could try it again, that would be wonderful.

 

[ElPoco]

Still the same procedure as before? Do you have any binaries or should we compile it?

 

[lunixbochs]

Same procedure, still no binaries because people are testing on many platforms.

 

[MarKov]

Hi,

What's the story with Warzone 2100? It should be able to run on GL 1.x, no?

Thx

 

[ekianjo]

Hi,

What's the story with Warzone 2100? It should be able to run on GL 1.x, no?

Thx

already on the repo

 

[MarKov]

I meant the vanilla version of the game working with glshim.
My question stemmed from the fact latest glshim from @ptitSeb was causing crashes (going 3D) but once I used a 2 month-old version I had on my system, it started working ok indeed.

 

[ptitSeb]

I meant the vanilla version of the game working with glshim.
My question stemmed from the fact latest glshim from @ptitSeb was causing crashes (going 3D) but once I used a 2 month-old version I had on my system, it started working ok indeed.

Oh, my latest version crashes on Warzone 2100? I have to check, I have never tried it.

 

[ptitSeb]

@MarKov : I reproduce the issue with WarZone 3.1.3 (latest version that doesn't need OpenGL 2.0). My latest commit about the DXTc seems to be not perfect for now. I'll work on that this weekend.

 

[MarKov]

Good to know, thx! BTW, either I'm missing something or 3.1.3 is the latest version.

 

[ptitSeb]

Good to know, thx! BTW, either I'm missing something or 3.1.3 is the latest version.

Yes, 3.1.3 is currently latest stable release. But if you you take current git source (ongoing dev. for 3.2), this version will require OpenGL 2.0 to run.

 

[ptitSeb]

@MarKov : ok, I fixed it. There was issue in my latest GL_COMPRESSED_XXX code, plus a nasty bug in a texgen function. Warzone works for me now (too slow as-is on the Pandora, with 40% cpu on memcpy, something is still weird here), and I pushed my changes on my repo.
Also, on what platform are you?

 

[MarKov]

Thanks, it's working again.

Two issues that were there before: it's almost completely dark (except for buildings and vehicles) and libGL warnings started spewing again.
I'm trying this on a Beaglebone Black.

 

[ptitSeb]

Thanks, it's working again.

Two issues that were there before: it's almost completely dark (except for buildings and vehicles) and libGL warnings started spewing again.
I'm trying this on a Beaglebone Black.

It's not dark for me. Picture is correct. What are the warning you have (I dont need the glXGetProcAdress not found ones).

 

[MarKov]

No, sorry - it was the old glshim. The new one is displaying completely fine but I managed to get a crash a short while later.

 

[ptitSeb]

No, sorry - it was the old glshim. The new one is displaying completely fine but I managed to get a crash a short while later.

If you can get a backtrace of the crash, that would help.

 

[MarKov]

This is some craaazy stuff! No idea why I managed to see it run correctly once or twice but it keeps crashing ever since. I'm attaching a trace.

 

[ptitSeb]

Mmmm, it's still a crash somewhere in texgen. Can you compile glshim with "-g" so I can have more debug info, and do a backtrace again?

 

[MarKov]

No prob; is there a cmake switch for that or sth?

 

[ptitSeb]

No prob; is there a cmake switch for that or sth?

I use ccmake, the curse frontend to cmake. Then use 't' to go to advanced, and search the CFLAGS to add -g. then use "c" to re-configure and "g" to generated makefiles and exit. There must be some command line options also, using -DXXX probably...