Re: [Pingus-Devel] Memory consumption in pingus 0.7.2
On Wed, Jul 30, 2008 at 11:19 PM, [EMAIL PROTECTED] wrote: 1. After level1 is completed OK, I can not go to level2, when I click on it, game says 'locked'. What could be wrong ? I butchered a lot of code in the last weeks, some things like save system, cutscenes and config file handling got a bit broken in the process. Will be fixed in the coming weeks. 2. I wanted to make a clean build and executed scons -c. After that executing scons configure complain s that libboost_signals nor found and there is following log in config.log: scons: Configure: Checking for C++ library boost_signals... scons: Configure: .sconf_temp/conftest_0.cpp is up to date. scons: Configure: The original builder output was: ... What could be wrong ? Hm, maybe something with the scons state data got screwed up, try to delete .sconsign.dblite files floating around in Pingus directory. -- WWW: http://pingus.seul.org/~grumbel/ Blog: http://grumbel.blogspot.com/ JabberID: xmpp:[EMAIL PROTECTED] ICQ: 59461927 ___ Pingus-Devel mailing list Pingus-Devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/pingus-devel
Re: [Pingus-Devel] Memory consumption in pingus 0.7.2
On Sun, Jul 20, 2008 at 12:23 PM, [EMAIL PROTECTED] wrote: == I've got the latest version. src/ut8_iterator.hpp did not wanted to comiple beciuse of stdint.h include was missing. Ok, added that. Unfortunately, svn version does not react on -g options. I changed def resultions back to 640*480 in globaps.hpp and pingus_main. Fixed that. Current version runs but kernel is out of memory on the first level already. So it this respect it's worse than prev version. There was a big leak left, I closed that one, try again. == my system doe snot have any GPU. Only framebuffer. Does this means that level map is kept twice anyway? If yes, please let me know where to look for the second copy. In ground_map.cpp the MapTile class, Sprite sprite is the video surface, while Surface surface is the one in software. However Sprite is optimized for the Display and in a different color format then Surface, so you can't just blit on it with the current blitter, which assume 32bit RGBA for most part. A workable approach might be to get rid of all the Surfaces after the Sprites have been created, thus freeing the memory. And then when the Surface is modified, copy it back from video-memory/format to software and only then keep it for the rest of the level. That way only tiles that are modified are kept in memory twice, which are much less then the whole level. A function that converts a Sprite back into a Surface also would fit well enough into the current API. And is it possible to make the map smaller? Only with a level editor. I have thought about adding a (levelsize-small) tag to the level format, to define a minimum required levelsize for the levels, but not sure if that is worth the effort, since the levels are already sparsely allocated (except the collision map), so a bigger level isn't really all that much bigger in memory, since its mostly empty space. What is --tile-size game parameter? is it possible to reduce memory consumption with it ? Ireied --tile-size 24 and it did not help... The level is split up into tiles, tilesize gives you that size. Larger tilesizes means more memory is spend, smaller ones mean less, since the tiles fit closer to the level. However when it gets to small the tile overhead gets to big and memory usage increases again. I don't think you can safe much memory with it. The current default value however is basically randomly selected, not benchmarked, so there might be a better size, however the saving will be tiny. * the whole screenstack is kept in memory, so the menu background and such are kept in memory even when not visible == I do not think it's too much and I feel optimizing this will be a lot of pain. Probably it's easier to conventrate on double map storage cleanup... It shouldn't be to hard to do and gives you 6MB free space. -- WWW: http://pingus.seul.org/~grumbel/ Blog: http://grumbel.blogspot.com/ JabberID: xmpp:[EMAIL PROTECTED] ICQ: 59461927 ___ Pingus-Devel mailing list Pingus-Devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/pingus-devel
Re: [Pingus-Devel] Memory consumption in pingus 0.7.2
Hi Ingo, Thank you for the fast reply. My comments are in the text - Original Message - From: Ingo Ruhnke [EMAIL PROTECTED] To: [EMAIL PROTECTED]; pingus-devel@nongnu.org Sent: Sunday, July 20, 2008 2:06 AM Subject: Re: [Pingus-Devel] Memory consumption in pingus 0.7.2 On Sun, Jul 20, 2008 at 1:21 AM, [EMAIL PROTECTED] wrote: Maybe there is a bug in memry manager or something that does not free sdl surfaces after they are used? There were a handful of memory leaks that have been closed in the meantime. So I suggest you try the latest SVN version to see if that performs better. == I've got the latest version. src/ut8_iterator.hpp did not wanted to comiple beciuse of stdint.h include was missing. I've corrected that. Should I send you my file version? Unfortunately, svn version does not react on -g options. I changed def resultions back to 640*480 in globaps.hpp and pingus_main. Current version runs but kernel is out of memory on the first level already. So it this respect it's worse than prev version. I think it's because of high res level map. Is it possible to make the level map smaller? I tried to use level data from 0.7.2 but game complains on some files missing... It would of course also be possible to reduce the memory usage of Pingus further, there certainly is still quite a bit of room left. Some things that come to mind: * resource system got ripped out in the ClanLib-SDL switch and isn't back yet, so some surfaces are keep in memory twice even so they are identical (I'll fix that in the next days/weeks) * collision map is keep in memory as one piece instead of as sparse tiles, so we waste a bit of space (colmap consumes ~2MB for a 1920x1200 level) * graphical level map is hold in memory twice (once in software and once on the GPU) and hold as 32bit RGBA, this could certainly be optimized for some systems, i.e. use 16bit or 24bit RGB + Colorkey, share the GPU and software surfaces, since they are identical on some platforms or don't keep them in software at all (levelmap takes around 10MB for a 1920x1200 level) == my system doe snot have any GPU. Only framebuffer. Does this means that level map is kept twice anyway? If yes, please let me know where to look for the second copy. I think if I free those 10 extra mb all will be fine and problems will be gone And is it possible to make the map smaller? My screen is 480x272x16pp and I run the game in 640*480 and scale the output to match the screen. What is --tile-size game parameter? is it possible to reduce memory consumption with it ? Ireied --tile-size 24 and it did not help... * the whole screenstack is kept in memory, so the menu background and such are kept in memory even when not visible == I do not think it's too much and I feel optimizing this will be a lot of pain. Probably it's easier to conventrate on double map storage cleanup... -- WWW: http://pingus.seul.org/~grumbel/ Blog: http://grumbel.blogspot.com/ JabberID: xmpp:[EMAIL PROTECTED] ICQ: 59461927 ___ Pingus-Devel mailing list Pingus-Devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/pingus-devel
Re: [Pingus-Devel] Memory consumption in pingus 0.7.2
On Sun, Jul 20, 2008 at 1:21 AM, [EMAIL PROTECTED] wrote: Maybe there is a bug in memry manager or something that does not free sdl surfaces after they are used? There were a handful of memory leaks that have been closed in the meantime. So I suggest you try the latest SVN version to see if that performs better. It would of course also be possible to reduce the memory usage of Pingus further, there certainly is still quite a bit of room left. Some things that come to mind: * resource system got ripped out in the ClanLib-SDL switch and isn't back yet, so some surfaces are keep in memory twice even so they are identical (I'll fix that in the next days/weeks) * collision map is keep in memory as one piece instead of as sparse tiles, so we waste a bit of space (colmap consumes ~2MB for a 1920x1200 level) * graphical level map is hold in memory twice (once in software and once on the GPU) and hold as 32bit RGBA, this could certainly be optimized for some systems, i.e. use 16bit or 24bit RGB + Colorkey, share the GPU and software surfaces, since they are identical on some platforms or don't keep them in software at all (levelmap takes around 10MB for a 1920x1200 level) * the whole screenstack is kept in memory, so the menu background and such are kept in memory even when not visible -- WWW: http://pingus.seul.org/~grumbel/ Blog: http://grumbel.blogspot.com/ JabberID: xmpp:[EMAIL PROTECTED] ICQ: 59461927 ___ Pingus-Devel mailing list Pingus-Devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/pingus-devel
