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

Active Topics

[ANNOUNCE] MeeShop - new app store (10)
to Applications by aspergerguy - 1 day, 9 hrs ago
HTTP-401 Sfos-Builder when using /etc/ssu credentials (0)
to SailfishOS by insanelysexy - 2 days, 15 hrs ago
Longtime users: What device(s) are you using today? (54)
to General by ryu1 - 4 days, 21 hrs ago
more...

Page 5 of 9

Thread Tools

szopin	2012-04-21 , 11:16
Posts: 2,076 \| Thanked: 3,268 times \| Joined on Feb 2011	#41

Originally Posted by misiak

Sure, I'll take a look at it during this weekend, but I can't promise I'll make it work. If there is desktop OpenGL rendering engine, I will try to port it to OpenGL ES 1.1 (it's easier for me, I hate writing shaders, etc.)

Will be very grateful, my 1h+ commute to work would turn into 1h+ of pure gaming awesomeness (hell, I might miss a bus stop or two)

Originally Posted by misiak

5. Change this function calls to soething OpenGL ES compatible - but testing is still done on desktop PC, as it is much easier and faster to debug than compiling everything in scratchbox and uploading to my phone...

Does not compute, all my 'work' is done on device during abovementioned commute (with 4.6 gcc/++ thanks to Aapo). Still believe it is easier/faster to have the resulting binary ready to run once it compiles (sure for rewrites of large parts of the code desktop is nice I guess)

Quote & Reply |

The Following User Says Thank You to szopin For This Useful Post:
Estel

misiak	2012-04-21 , 11:46
Posts: 805 \| Thanked: 1,605 times \| Joined on Feb 2010 @ Gdynia, Poland	#42

Originally Posted by szopin

Does not compute, all my 'work' is done on device during abovementioned commute (with 4.6 gcc/++ thanks to Aapo). Still believe it is easier/faster to have the resulting binary ready to run once it compiles (sure for rewrites of large parts of the code desktop is nice I guess)

LOL@your post count

I just prefer to make changes on my powerful desktop PC and check resulting binary anyway (if you take now the sources of lincity-ng for maemo - either Aapo's clean sdl version or my versinon and change only SDL_gles related stuff to SDL_opengl - it will compile and run fine on 64bit ubuntu virtual machine), for me it just speeds up development... in the final steps (when i'm compiling in scratchbox), i'm also checking every compilation on device, like in this case. I was trying to implement frame limit in opengl, but it looks like it is coded somewhere anyway (out of PainterSDL/PainterGL/PainterGLES classes), so it only made rendering more laggy look. But putting SDL_Delay(100) after each call to SDL_GLES_SwapBuffers() made my cpu usage go down to 25%

)

Quote & Reply |

The Following User Says Thank You to misiak For This Useful Post:
Estel

AapoRantalainen	2012-04-21 , 13:04
Posts: 839 \| Thanked: 3,386 times \| Joined on Mar 2009	#43

Originally Posted by misiak

There is however, in Extras testing, a version which supports more formats ( http://maemo.org/packages/package_in...5+0m5+ogg+mp3/ ), and it didn't uninstall any metapackages or anything on my phone with CSSU stable (someone reported it uninstalls maemo-fremantle-pr or however is this metapackage named) - is it just case of phones with Nokia's PR's?

CSSU users doesn't need to worry maemo-fremantle-pr, it is already uninstalled (without dramatic side-effects). There are one difference between 1.2.6-5+0m5+ogg+mp3 and 1.2.6-5+0m5+ogg+mp3-2: first one is using 'broken' libmikmod (it is for playing s3m/mod -audio). Broken means it makes zero length file to the directory where binary is, which means that directory must be user-writeable (which is not good, but can be handled if needed).

I do not know what is currently wrong with dependencies of lincity, I will check it before next release.

Originally Posted by misiak

You changed default rendering engine to SDL anyway? Ok, the OpenGL can be turned on by using "-g" command line option anyway - I hope you didn't change that

I added option to the settings (gui) to toggle between SDL and GLES. Command line "-g" is also working, and ~/.lincity-gn/userconfig.xml

I chose SDL to default, because it is more tested (at least by me).

Originally Posted by misiak

Android Lincity required quite heavy rewrite I guess, as it's different language and must use different libraries...

Android can use c/c++, only start-wrapper must be java. And it must compile every library statically: check this https://github.com/kobr4/Lincity4dro...master/jni/src looks familiar?

Quote & Reply |

The Following 3 Users Say Thank You to AapoRantalainen For This Useful Post:
Estel, misiak, szopin

misiak	2012-04-21 , 13:16
Posts: 805 \| Thanked: 1,605 times \| Joined on Feb 2010 @ Gdynia, Poland	#44

Originally Posted by AapoRantalainen

CSSU users doesn't need to worry maemo-fremantle-pr, it is already uninstalled (without dramatic side-effects). There are one difference between 1.2.6-5+0m5+ogg+mp3 and 1.2.6-5+0m5+ogg+mp3-2: first one is using 'broken' libmikmod (it is for playing s3m/mod -audio). Broken means it makes zero length file to the directory where binary is, which means that directory must be user-writeable (which is not good, but can be handled if needed).

good to know about that bug, there is also version with "-2" in the end in extras-devel http://maemo.org/packages/package_in...0m5+ogg+mp3-2/ strangely, in extras-testing there is the same version but only for i386, not for armel

Originally Posted by AapoRantalainen

I do not know what is currently wrong with dependencies of lincity, I will check it before next release.

Could you try adding "1:" in front of sdl mixer's version as i suggested in one of my previous posts?

Originally Posted by AapoRantalainen

I chose SDL to default, because it is more tested (at least by me).

Ok, fair enought, you are the maintainer, i understand that.

Originally Posted by AapoRantalainen

Android can use c/c++, only start-wrapper must be java. And it must compile every library statically: check this https://github.com/kobr4/Lincity4dro...master/jni/src looks familiar?

I know, I'm also Android developer, I thought maybe they have redesigned the interface and code to be more Android-friendly and Dalvik(-not-to-use-"java"-word)-integrated, but now I see they didn't. I feel awfully stupid that I've rewritten OpenGL code to OpenGL ES instead of using code from their repo

Last edited by misiak; 2012-04-21 at 13:19.

Quote & Reply |

The Following 2 Users Say Thank You to misiak For This Useful Post:
Estel, szopin

	Estel	2012-05-02 , 17:35
	Posts: 5,028 \| Thanked: 8,613 times \| Joined on Mar 2011	#45

AapoRantalainen, when we can expect OpenGLES version hitting repositories? @ 900 mhz, CPU still have much spare power (even when playing background music), so it shouldn't involve any slowdowns when processed on DSP, still providing *BIG* battery savings gain.

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

Quote & Reply |

The Following User Says Thank You to Estel For This Useful Post:
AapoRantalainen

AapoRantalainen	2012-05-03 , 06:31
Posts: 839 \| Thanked: 3,386 times \| Joined on Mar 2009	#46

Lincity-ng-2.0-2maemo8, changes since last version:
* GLES(1) support by Bartosz Miskiewicz
- http://developer.berlios.de/bugs/?fu...&group_id=2929
* Icon for 'back' on load/save-menus
- http://developer.berlios.de/bugs/?fu...&group_id=2929
* Windowed version possible (not crashing, but not playable)
* Space=QueryTool
* Fasten startup time. Not loading resume game automatically
- http://developer.berlios.de/bugs/?fu...&group_id=2929
* Change "Start with empty board" to look more button (not text)
- http://developer.berlios.de/bugs/?fu...&group_id=2929
* Fasten setup_land()
- http://developer.berlios.de/bugs/?fu...&group_id=2929
* Scrollbars fixed (use up/down-buttons)
- http://developer.berlios.de/bugs/?fu...&group_id=2929
* Reorder layout of NewGame-menu
* Scaled background images manually
* Bigger buttons on help-menu
* Drop non-used datafiles (progressbar/progresswheel)

SDL is default, you can enable GLES with a) options, b) commandline parameter, or c) via configure file. I'm interested in to hear some reproducible statistics about CPU/mem/battery when GLES is used.

(Packaging) Game and data are not separated (yet) because datafiles are also changing from version to version (so both will be downloaded anyway).

Quote & Reply |

The Following 7 Users Say Thank You to AapoRantalainen For This Useful Post:
dgls82, Estel, HolgerN, ivgalvez, javispedro, Joseph9560, szopin

misiak	2012-05-03 , 14:52
Posts: 805 \| Thanked: 1,605 times \| Joined on Feb 2010 @ Gdynia, Poland	#47

Originally Posted by AapoRantalainen

SDL is default, you can enable GLES with a) options, b) commandline parameter, or c) via configure file. I'm interested in to hear some reproducible statistics about CPU/mem/battery when GLES is used.

(Packaging) Game and data are not separated (yet) because datafiles are also changing from version to version (so both will be downloaded anyway).

I think that changing from bazillions of textures to 1 big texture containing all images will speed thinks up, I will test it in a few days. Could you write something more about datafiles changes since last version?

edit: background music finally works

Last edited by misiak; 2012-05-03 at 15:14. Reason: tested

Quote & Reply |

The Following 2 Users Say Thank You to misiak For This Useful Post:
Estel, szopin

	javispedro	2012-05-03 , 15:32
	Posts: 2,355 \| Thanked: 5,249 times \| Joined on Jan 2009 @ Barcelona	#48

Originally Posted by misiak

I think that changing from bazillions of textures to 1 big texture containing all images will speed thinks up, I will test it in a few days.

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.

Last edited by javispedro; 2012-05-03 at 15:46.

Quote & Reply |

The Following 3 Users Say Thank You to javispedro For This Useful Post:
Estel, misiak, szopin

AapoRantalainen	2012-05-03 , 18:24
Posts: 839 \| Thanked: 3,386 times \| Joined on Mar 2009	#49

Originally Posted by misiak

Could you write something more about datafiles changes since last version?

*Changed: I made new background images, not only scaled, but reoriented some elements:
https://gitorious.org/lincity-n900/l...6c626eb4f9059d

*Added: Gles/SDL icons for options
https://gitorious.org/lincity-n900/l...19a30cfb529cb1
(data/images/mainmenu/settings/gles_renderer.png)

*Removed: Not install files images/mainmenu/progresswheel* (and progressbar*). They are not used.
https://gitorious.org/lincity-n900/l...8580932b3d4dd2

Originally Posted by misiak

I think that changing from bazillions of textures to 1 big texture containing all images will speed thinks up, I will test it in a few days.

I have no ideas would it be faster. Are you thinking starting time (as images are loaded on start) or something else?

Quote & Reply |

The Following 2 Users Say Thank You to AapoRantalainen For This Useful Post:
Estel, szopin

	Estel	2012-05-03 , 19:07
	Posts: 5,028 \| Thanked: 8,613 times \| Joined on Mar 2011	#50

Are You sure, that OpenGLES renderer is working at all, in current version? Trying to enable it via GUI options or config file (/home/user/lincity-ng/userconfig.xml), I see *exacty* same CPU usage/battery consumption as with SDL. Game speed is also unaffected (not worse or better in any way). Same goes for memory consumption. Isn't it too much for a coincidence?

Also, if I enable GLES render via GUI, game indeed "restart", yet, upon closing and opening again manually, it's still in SDL mode. If I edit mentioned config file (/home/user/.lincity-ng/userconfig.xml), changing approriate option to "yes", after running game and entering menu, GUI still states that SDL is used.

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?

/Estel

// Edit

I don't remember, how it looked in older releases, but it's also quite memory hog - it uses roughly 80-100 REAL memory, and almost 200 virtual one at all. It's probably justified, so I point it out just for the records.