Active Topics
-
[ANNOUNCE] MeeShop - new app store (10)
to Applications by aspergerguy - 1 day, 19 hrs ago -
HTTP-401 Sfos-Builder when using /etc/ssu credentials (0)
to SailfishOS by insanelysexy - 3 days, 1 hr ago -
Longtime users: What device(s) are you using today? (54)
to General by ryu1 - 5 days, 7 hrs ago - more...
 |
|
2012-05-04
, 05:27
|
|
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?
/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!
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: | ||
|
|
2012-05-04
, 19:04
|
|
Posts: 839 |
Thanked: 3,386 times |
Joined on Mar 2009
|
#53
|
Originally Posted by Estel
This might be the case, I will fix it on end of the week.
Seems, that OpenGLES is disabled totally as in previous versions. Maybe some code merge hickup occured?
| The Following User Says Thank You to AapoRantalainen For This Useful Post: | ||
|
|
2012-05-04
, 20:32
|
|
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
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!
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: | ||
|
|
2012-05-06
, 18:02
|
|
Posts: 805 |
Thanked: 1,605 times |
Joined on Feb 2010
@ Gdynia, Poland
|
#55
|
Originally Posted by Estel
I think it's because Aapo doesn't like me
Seems, that OpenGLES is disabled totally as in previous versions. Maybe some code merge hickup occured?
Don't expect much speed gain now, as I said before, there are too many textures atm...
Originally Posted by javispedro
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...
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.
Originally Posted by AapoRantalainen
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)
I have no ideas would it be faster. Are you thinking starting time (as images are loaded on start) or something else?
| The Following 3 Users Say Thank You to misiak For This Useful Post: | ||
|
|
2012-05-09
, 12:07
|
|
Posts: 839 |
Thanked: 3,386 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:
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
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/
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
|
|
2012-05-09
, 19:29
|
|
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
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: | ||
|
|
2012-05-09
, 19:43
|
|
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...
[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: | ||
|
|
2012-05-09
, 19:49
|
|
Posts: 805 |
Thanked: 1,605 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
instead of "yes" in the end... However, it states further
, so gles libs are included... Then it compiles GLES code:
, but again, in the end displays warning:
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.
Code:
checking for OpenGLES and SDL-GLES libraries... -lGLES_CM
Code:
GL_LIBS ?= "-lGLES_CM -lSDL_gles -L/usr/lib -lSDL" ;
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
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).
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: | ||
|
|
2012-05-10
, 07:53
|
|
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:
As in: doesn't find something on my device, still builds, finds something in autobuilder and result differs?
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.
This will start it in gles-mode: