On Sun, Jul 20, 2008 at 12:23 PM, <address@hidden> 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:address@hidden
ICQ: 59461927