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