maemo.org - Talk - [Announce] Lincity-ng (city building simulator) on extras-devel

maemo.org - Talk (https://talk.maemo.org/index.php)

- Games (https://talk.maemo.org/forumdisplay.php?f=12)

- - [Announce] Lincity-ng (city building simulator) on extras-devel (https://talk.maemo.org/showthread.php?t=83647)

Re: [Announce] Lincity-ng (city building simulator) on extras-devel

Quote:

Originally Posted by Estel (Post 1201507)

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.

Re: [Announce] Lincity-ng (city building simulator) on extras-devel

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 :p)

// 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?

Re: [Announce] Lincity-ng (city building simulator) on extras-devel

Quote:

Originally Posted by Estel (Post 1201681)

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.

Re: [Announce] Lincity-ng (city building simulator) on extras-devel

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

Re: [Announce] Lincity-ng (city building simulator) on extras-devel

Quote:

Originally Posted by Estel (Post 1201681)

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...

Quote:

Originally Posted by javispedro (Post 1201372)

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...

Quote:

Originally Posted by AapoRantalainen (Post 1201479)

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)

Re: [Announce] Lincity-ng (city building simulator) on extras-devel

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

Re: [Announce] Lincity-ng (city building simulator) on extras-devel

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

Re: [Announce] Lincity-ng (city building simulator) on extras-devel

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...

Re: [Announce] Lincity-ng (city building simulator) on extras-devel

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.

Re: [Announce] Lincity-ng (city building simulator) on extras-devel

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?