Notices


Reply
Thread Tools
Posts: 838 | Thanked: 3,384 times | Joined on Mar 2009
#51
Originally Posted by Estel View Post
As for 3th method, could You please write exact parameter? AFAIK lincity-ng is run through .sh wrapper. Should command be passed to wrapper, to executable itself, or the latter via wrapper insides?
Game is not started via wrapper, but menu-entry is pointing to the binary file /opt/lincity/games/lincity-ng. When started from terminal it will print which renderer it is using, e.g. OpenGL Mode 800x480.

This will start it in gles-mode:
Code:
/opt/lincity/games/lincity-ng -g
Config file should remember renderer settings. If not, it is bug, and I will try to catch it.
 

The Following 2 Users Say Thank You to AapoRantalainen For This Useful Post:
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#52
Even if I've OpenGLES set in config file, upon starting from terminal, it says about using SDL. It seems, that OpenGL isn't used in any case.

/Estel

// Edit

Haven't tried method with running -g parameter from terminal, only GUI settings and config file editing. Will try 3th tomorrow (today, but after sleep, so it's tomorrow )

// Edit

I've checked running it with command line argument /opt/lincity/games/lincity-ng -g and terminal still says "SDL Mode" upon running. So, currently, none of 3 methods works + setting via GUI reverts back to SDL upon game restart + editing /home/user/.lincity-ng/userconfig.xml to use OpenGLES is also reverted back to "no" after game start&close.

Seems, that OpenGLES is disabled totally as in previous versions. Maybe some code merge hickup occured?
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 

The Following 2 Users Say Thank You to Estel For This Useful Post:
Posts: 838 | Thanked: 3,384 times | Joined on Mar 2009
#53
Originally Posted by Estel View Post
Seems, that OpenGLES is disabled totally as in previous versions. Maybe some code merge hickup occured?
This might be the case, I will fix it on end of the week.
 

The Following User Says Thank You to AapoRantalainen For This Useful Post:
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#54
I hope that You don't get it as complaining or demanding? I'm just trying my best to provide valuable feedback.

Maybe it's unnecessary disclaimer, but lately, many people on TMO started to react little exaggeratedly, to posts that are not sugar-coated enough. Maybe it's just moon phase or something

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 

The Following User Says Thank You to Estel For This Useful Post:
Posts: 804 | Thanked: 1,598 times | Joined on Feb 2010 @ Gdynia, Poland
#55
Originally Posted by Estel View Post
Seems, that OpenGLES is disabled totally as in previous versions. Maybe some code merge hickup occured?
I think it's because Aapo doesn't like me Don't expect much speed gain now, as I said before, there are too many textures atm...

Originally Posted by javispedro View Post
And then compressing that texture (called a texture atlas btw) with PVRTC.

However, the worst offenders for PVR performance is alpha testing/blending, which I bet you cannot turn off easily, so performance will always be abysmal.
Thanks for the tip, I will try that. I'll see what I can do to speed things up, now even with GLES it's slow as hell...

Originally Posted by AapoRantalainen View Post
I have no ideas would it be faster. Are you thinking starting time (as images are loaded on start) or something else?
Drawing time - the less separate textures, the less time it takes to draw single frame. (easy trick - combine few small texture files into one big, speed gain should be noticeable)
 

The Following 3 Users Say Thank You to misiak For This Useful Post:
Posts: 838 | Thanked: 3,384 times | Joined on Mar 2009
#56
I appreciate every bug report.
I appreciate GLES-port.

I have big problems with GLES on autobuilder, and seems I can't solve it by myself.

Currently in extras-devel there are version -maemo11. When started from terminal it says: version 2.0-maemo11 without GLES, which means GLES-support is not compiled in.

inside scratchbox:
Code:
apt-get source lincity-ng
fakeroot dpkg-buildpackage
scp lincity-ng root@192.168.1.111:/opt/lincity/games/
And that version will say: version 2.0-maemo11 with GLES

So there are some difference between my environment and autobuilder, which I can't track down.

Log is here:
https://garage.maemo.org/builder/fre...ild.log.OK.txt
 

The Following 4 Users Say Thank You to AapoRantalainen For This Useful Post:
Posts: 2,076 | Thanked: 3,268 times | Joined on Feb 2011
#57
The page http://maemo.org/packages/source/vie.../2.0-2maemo11/ looks somewhat different than other gles projects (for example: http://maemo.org/packages/source/vie...arty/0.5.91-2/ - libgles1-sgx-img-dev is fine here; http://maemo.org/packages/source/vie...ehegles/1.4.1/ - libsdlgles here fine; there were some other with red, but no bold+incompatible msg)

I mean this part saying incompatible when hovering over it:
libgles1-sgx-img-dev ([arm armel]), libsdl-gles1.2-dev ([arm armel])


Maybe compare their source/build instructions? If not that problem with jam(+gles?) maybe?
Building lincity on-device from 11v atm, will report how it goes
 

The Following 3 Users Say Thank You to szopin For This Useful Post:
Posts: 2,076 | Thanked: 3,268 times | Joined on Feb 2011
#58
Finally finished compiling:

[3|user@Nokia-N900|~/dev/lincity]./lincity-ng
Starting lincity-ng (version 2.0-maemo11 with GLES)...
Couldn't add '/usr/local/share/lincity-ng' to physfs searchpath: File not found
[/home/user/.lincity-ng] is in the search path.
[/home/user/dev/lincity//data] is in the search path.
[/home/user/.lincity-ng] is the write directory.
Language is "en_GB".
fast = 9
SDL Mode 800x480
ERROR of degree -1:Error. Can't find LINCITY_HOME

With GLES it is indeed. Forgot to mention: works, music and all...
 

The Following 3 Users Say Thank You to szopin For This Useful Post:
Posts: 804 | Thanked: 1,598 times | Joined on Feb 2010 @ Gdynia, Poland
#59
I think it is my fault, because patching jam config file was pain in the *** for me, you can even see in output log
Code:
checking for OpenGLES and SDL-GLES libraries... -lGLES_CM
instead of "yes" in the end... However, it states further
Code:
GL_LIBS ?= "-lGLES_CM -lSDL_gles  -L/usr/lib -lSDL" ;
, so gles libs are included... Then it compiles GLES code:
Code:
MkDir1 ./build/arm-unknown-linux-gnueabi/optimize/src/gui/PainterGLES 
C++ ./build/arm-unknown-linux-gnueabi/optimize/src/gui/PainterGLES/TextureManagerGLES.o 
C++ ./build/arm-unknown-linux-gnueabi/optimize/src/gui/PainterGLES/TextureGLES.o 
C++ ./build/arm-unknown-linux-gnueabi/optimize/src/gui/PainterGLES/PainterGLES.o 
MkDir1 ./build/arm-unknown-linux-gnueabi/optimize/src/gui/PainterSDL 
C++ ./build/arm-unknown-linux-gnueabi/optimize/src/gui/PainterSDL/TextureSDL.o 
C++ ./build/arm-unknown-linux-gnueabi/optimize/src/gui/PainterSDL/TextureManagerSDL.o 
C++ ./build/arm-unknown-linux-gnueabi/optimize/src/gui/PainterSDL/PainterSDL.o
, but again, in the end displays warning:
Code:
dpkg-shlibdeps: warning: dependency on libGLES_CM.so could be avoided if "debian/lincity-ng/opt/lincity/games/lincity-ng" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on libSDL_gles-1.2.so.0 could be avoided if "debian/lincity-ng/opt/lincity/games/lincity-ng" were not uselessly linked against it (they use none of its symbols).
Really strange... If you feel like modifying jam config, you may try to add "-lEGL" to GL_FLAGS (I won't have time untill weekend to provide a proper patch, just search for a place where I add -lSDL_gles and add it there, if you have more time during this week), now I see http://wiki.maemo.org/User:Javispedro/SDL-GLES lists it for GLESv1... But it's strange that it compiles with opengl es on your local computer and does not in autobuilder... edit: and compiles for szopin locally

edit2: are you guys using bash locally? it shouldn't make a difference when using "configure", but afaik autobuilder may use ash instead of bush, maybe it interprets something in other way than our computers do... or it's outdated versions of software are being stupid, who knows I still bet it's my poor jam skills' fault.

Last edited by misiak; 2012-05-09 at 19:54.
 

The Following 3 Users Say Thank You to misiak For This Useful Post:
Posts: 2,076 | Thanked: 3,268 times | Joined on Feb 2011
#60
Yup, bash here.

Been reading jam manfile and this part maybe is causing different build:
Code:
The scanning for header file inclusions is not exact, but it is at least dynamic, so there is no need to run something like makedepend(GNU) to create a static dependency file. The scanning mechanism errs on the side of inclusion (i.e., it is more likely to return filenames that are not actually used by the compiler than to miss include files) because it can't tell if #include lines are inside #ifdefs or other conditional logic. In Jambase, HdrRule applies the NOCARE rule to each header file found during scanning so that if the file isn't present yet doesn't cause the compilation to fail, jam won't care.
As in: doesn't find something on my device, still builds, finds something in autobuilder and result differs?
 

The Following 2 Users Say Thank You to szopin For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 22:32.