glshim

[lunixbochs]

I've been building FreeOrion for my Raspberry Pi 2 and it's been slow. I think I need to build all of boost still.

 

[ptitSeb]

I'm still compiling it...

I'd never have guessed...


Is it even possible without huge amounts of swap and a whole day to spare? Those 15.04 ubuntu binaries are not usable on pandora I take it?

It's possible, with swap and a whole day indeed. Ubuntu wil be hardfloat, so not compatible with Pandora.

I have seen a lot a python also, so I'm a bit concerned about performance too.

 

[petevine]

It's possible, with swap and a whole day indeed. Ubuntu wil be hardfloat, so not compatible with Pandora.

I have seen a lot a python also, so I'm a bit concerned about performance too.

Unless you've already used up yours I'd recommend a free trial of google compute engine which you could use to set up a fast cross-compiler available for 2 months.

EDIT:

Congratulations guys, either version of your graces' glshim can handle Naev perfectly!

http://forum.odroid.com/viewtopic.php?f=91&t=16201

 

[ptitSeb]

It's possible, with swap and a whole day indeed. Ubuntu wil be hardfloat, so not compatible with Pandora.

I have seen a lot a python also, so I'm a bit concerned about performance too.

Unless you've already used up yours I'd recommend a free trial of google compute engine which you could use to set up a fast cross-compiler available for 2 months.

I have made my fork of glshim more multiplatform friendly. It should now compile and run "out-of-the-box" on the ODroid with "cmake . -DODROID=1"

If you can test and repport.

 

[ptitSeb]

EDIT:

Congratulations guys, either version of your graces' glshim can handle Naev perfectly!

http://forum.odroid.com/viewtopic.php?f=91&t=16201

Yeah. Look here for my port: http://repo.openpandora.org/?page=all&search=ptitSeb&s=newmany use glshim.


Or lunibochs: http://repo.openpandora.org/?page=all&search=lunixbochs&s=new

 

[petevine]

I have made my fork of glshim more multiplatform friendly. It should now compile and run "out-of-the-box" on the ODroid with "cmake . -DODROID=1"

If you can test and repport.

Yes, it builds and works fine.

BTW, C1 is rather low-end - should the same functions be disabled on other odroids, including the new XU4?

Yeah. Look here for my port: http://repo.openpandora.org/?page=all&search=ptitSeb&s=newmany use glshim.

Or lunibochs: http://repo.openpandora.org/?page=all&search=lunixbochs&s=new

Thanks; I'm mainly interested in FOSS projects - could a filter be added along the lines "no additional data packs required"?

 

[petevine]

Which reminds me I've also tested ToME 1.3.1:

http://forum.odroid.com/viewtopic.php?f=91&t=16039

The issues mentioned in your repo wiki are gone (or not applicable on Odroid) but all's not sweet. I've managed to find a serious glitch visible in the attached screenshot (all 2d elements are gone). I'm attaching the save in case you wanted to have a look at what the level's supposed to look like on x86 (should go into .t-engine/4.0/tome/save).

 

testsave.zip

 

[ptitSeb]

I have made my fork of glshim more multiplatform friendly. It should now compile and run "out-of-the-box" on the ODroid with "cmake . -DODROID=1"

If you can test and repport.

Sure, any test case suggestions? I'll edit this part later to let you know.

BTW, C1 is rather low-end - should the same functions be disabled on other odroids, including the new XU4?

It is temporary, until I code a proper way to detect GLES capability at load time.

Yeah. Look here for my port: http://repo.openpandora.org/?page=all&search=ptitSeb&s=newmany use glshim.

Or lunibochs: http://repo.openpandora.org/?page=all&search=lunixbochs&s=new

Thanks; I'm mainly interested in FOSS projects - could a filter be added along the lines "no additional data packs required"?

I don't think so.

Which reminds me I've also tested ToME 1.3.1:

http://forum.odroid.com/viewtopic.php?f=91&t=16039

The issues mentioned in your repo wiki are gone (or not applicable on Odroid) but all's not sweet. I've managed to find a serious glitch visible in the attached screenshot (all 2d elements are gone). I'm attaching the save in case you wanted to have a look at what the level's supposed to look like on x86 (should go into .t-engine/4.0/tome/save).

View attachment 12167 

testsave.zip

I am not the owner of this port, and I must confess I never tried this game, so I don't know. I'll try to make a compile to work on glitch you found.

 

[petevine]

 

Thanks; I'm mainly interested in FOSS projects - could a filter be added along the lines "no additional data packs required"?

I don't think so.

Hopefully we didn't have a misunderstanding - I was referring to the search engine you linked to (it already has a commercial games filter) and not glshim itself!

 

[ptitSeb]

 

Thanks; I'm mainly interested in FOSS projects - could a filter be added along the lines "no additional data packs required"?

I don't think so.

Hopefully we didn't have a misunderstanding - I was referring to the search engine you linked to (it already has a commercial games filter) and not glshim itself!

Yes, me too. The "additional data" flags doesn't exist to my knowledge (there is nothing like that in the PXML file that you create when creating a PND and that is then used by the repo).

 

[ptitSeb]

So, I finally got FreeOrion to run on the Pandora.
This one is a beast to compile! Really.
I succeed to barely compile natively, but memory issue and compiling time is huge (4Go swap, and sometime it get killed, and days to compile).

So, I reluctantly built a Cross-compile environment, higly experimental, using codeblocks.pnd as base for all arm libs and a Linux Mint x64 VM.. After hours of messing, compiling and patching binutils & GCC, I finaly got something. Once transfered to the Pandora, it works! Yeepi.

Now, The game seems a bit slow (it needs lot of memory and CPU power it seems), and there seems to be missing thing using glshim as reported. I have now to try fix that.

 

 

[ptitSeb]

 

[petevine]

You mean (judging by that last screenshot) all problems are gone? The research screen as well?

Well done, I think I might donate!

 

[ptitSeb]

You mean (judging by that last screenshot) all problems are gone? The research screen as well?

Well done, I think I might donate!

Yes, I think I have fixed all the rendering issue. I pushed my changes to the github repo, so it's ready to try.

(You can donate to the Pyra development pool)

 

[lunixbochs]

Judging by that UI, this might be perfect for TinyGLES.

 

[ptitSeb]

Judging by that UI, this might be perfect for TinyGLES.

Yeah, mostly 2D bliting, with just heavy use of Stencil & VBOs.

 

[petevine]

Judging by that UI, this might be perfect for TinyGLES.

It will be interesting to see how it stacks up against the poorly performing Mali driver.
 

Yes, I think I have fixed all the rendering issue. I pushed my changes to the github repo, so it's ready to try.

(You can donate to the Pyra development pool)

As for FO it's become perfectly playable indeed. One easily remedied performance issue is related to the game itself and SD write performance (triggered by frequent uncompressed autosaves).

Now, the glshim itself has experienced a regression, noticable in foobillardplus (see attachments, after and before)


BTW, the forum link on your github homepage is broken (recent changes here?)


 

 

[ptitSeb]

FoobillardPlus was running? Last time I tried it was not working well for me (worse than the broken screenshot). I'm surprised, the regression came with just my last commit for FO?

 

[petevine]

FoobillardPlus was running? Last time I tried it was not working well for me (worse than the broken screenshot). I'm surprised, the regression came with just my last commit for FO?

On my Odroid C1? Yes and yes.

EDIT:
Oh, the broken link was meant to lead here...

 

[ptitSeb]

Ok, that was a bad copy/paste... It should be fixed now. (and indeed, it's working on my side too  )