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 Wed, Jul 30, 2008 at 5:19 PM, <[EMAIL PROTECTED]> wrote:
> I've just got latest version from svn.
> Large memory leak seem to be solved, I can pass 1st level now. Some memory
> seem to be returned to the system after level is completed. But I still have
> following problems:
> 1. After level1 is completed OK, I can not go to level2, when I click on it,
> game says 'locked'. What could be wrong ?
> 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:
> |.sconf_temp/conftest_0.cpp <-
> | |
> | |
> | |#include "boost/signals.hpp"
> | |
> | |int
> | |main() {
> | |
> | |return 0;
> | |}
> | |
> |
> ccache /usr/local/cross/gcc-3.3.4_glibc-2.3.2/bin/arm-linux-gcc -o
> .sconf_temp/conftest_0.o -c -mcpu=arm920 -O2 -ffunction-sections
> -fdata-sections -Darm -DCPU=arm
> -I/home/serg/devel/Libraries/Pingus-devel/../../Arch/arm/include
> -I/home/serg/devel/Libraries/Pingus-devel/../../Arch/arm/../../TT
> -I/home/serg/devel/Libraries/Pingus-devel/../../Arch/arm/../../TTMP -I.
> -Isrc .sconf_temp/conftest_0.cpp
> arm-linux-gcc: .sconf_temp/conftest_0.cpp: No such file or directory
> arm-linux-gcc: no input files
>
> I checked .sconf_temp and there is no conftest_0.cpp. For some reason it is
> not created. I swear I have boost, it was compiling today ok and configure
> was OK week ago...
> What could be wrong ?
Maybe the scons database (.sconsign.dblite) got inconsistent with the
contents of .sconf_temp/. It won't hurt to try deleting the whole
.sconf_temp/ directory.
--
Michael Ploujnikov
http://plouj.com/
___
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
I've just got latest version from svn.
Large memory leak seem to be solved, I can pass 1st level now. Some memory
seem to be returned to the system after level is completed. But I still have
following problems:
1. After level1 is completed OK, I can not go to level2, when I click on it,
game says 'locked'. What could be wrong ?
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:
|.sconf_temp/conftest_0.cpp <-
| |
| |
| |#include "boost/signals.hpp"
| |
| |int
| |main() {
| |
| |return 0;
| |}
| |
|
ccache /usr/local/cross/gcc-3.3.4_glibc-2.3.2/bin/arm-linux-gcc -o
.sconf_temp/conftest_0.o -c -mcpu=arm920 -O2 -ffunction-sections -fdata-sections
-Darm -DCPU=arm -I/home/serg/devel/Libraries/Pingus-devel/../../Arch/arm/include
-I/home/serg/devel/Libraries/Pingus-devel/../../Arch/arm/../../TT -I/home/serg/devel/Libraries/Pingus-devel/../../Arch/arm/../../TTMP
-I. -Isrc .sconf_temp/conftest_0.cpp
arm-linux-gcc: .sconf_temp/conftest_0.cpp: No such file or directory
arm-linux-gcc: no input files
I checked .sconf_temp and there is no conftest_0.cpp. For some reason it is
not created. I swear I have boost, it was compiling today ok and configure
was OK week ago...
What could be wrong ?
Sincerely,
Serg
- Original Message -
From: "Ingo Ruhnke" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>;
Sent: Monday, July 21, 2008 7:40 PM
Subject: 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 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
my comments in text - Original Message - From: "Ingo Ruhnke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; Sent: Monday, July 21, 2008 7:40 PM Subject: 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 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. ==> confirmed 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. ==> Seems to be better but for some reason current version newer gets further level 1 "learning to dig". I pass that level, games success but the mountain is not "open". and when I press on any other levels than 1, it says 'locked' While running the level, there are artifacts on screen above pingos that dig. Yesterday all was OK I still think that level map is not unloaded after level is finished. At the beginning of level 1 there is about 26mb of free mem. Info screen eats about 2MB (definately should be out of memory when user presses OK). Level start at about 18mb free and ends at about 7mb. After I press OK on success screen, I see the "mountain" picture again but only 9mb are free. It seems that only info screen is freed but not the level and probably not first story screen. In total after level 1 complection, about 17MB are lost. When I press o "leave' button, only 10mb are free. 'levelsets' in main menu it uses around 2mb and seems to give all memory back 'show story' button on 'moutain' screen also takes around 2mb but gives all back ==> 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
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 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]>; 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 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
[Pingus-Devel] Memory consumption in pingus 0.7.2
Hi all, I'm trying to port Pingus to an embeded arm system (tomtom navigation system). And amazingly enough, it works. But... My system has no swap configured and it has 64mb of ram. Pingus seem to use memory quite extensively and I see in memory log that after every complete level amount of free memory is declining very rapidly. So I have kernel oops on the middle of 3rd level... My question is: Is it possible to reduce the memory usage? Maybe there is a bug in memry manager or something that does not free sdl surfaces after they are used? Sincerely, Serg___ Pingus-Devel mailing list Pingus-Devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/pingus-devel
