svn 11411 high memory usage

[mduf]

svn 11411 use much more merory then the last version I built (it was around 11280, slightly after purge zero ship moved to C++)

my spec are:

ubuntu 6.10
athlon 600MHz
384 MB ram
1.2 GB swap
Gefore4 FX 440

With the last version, after I had load my saved game I had ~800 MB free memory (swap + ram). After few hours and many jumps it was still well above 600 MB of free memory.

With 11411, after I had load my saved game I had less than 500 MB of free swap and less than 100MB of ram. After I flew from Cephid 17 to Benards and back to cephid 17 (4 jumps) I had ~100MB of free memory. I saw it go down very fast, it took around 20 min.

I think free memory go down when it load a new song (but I'm not sure)

[hellcatv]

singe temporarily take new memory
but the big change is that png files are no longer compressed...
the idea is that if an artist goes through the trouble to upload a png instead of a DXT5 texture then that artist must want full quality

but right now png is the only way to get transparency--so until safem0de is done making things into DXT5 you'll see big mem usage

[pheldens]

I think free memory go down when it load a new song (but I'm not sure)

Yeah I think I see that here too, but not consistently, may be the textures that often load around the same time as song changes.

1GB ram without swap atleast crashes the game (at any ram setting with vssetup), I had to create a 1Gb swap file , this solves the aloc bugs.

mduf, try finding some used parts on a scrap market, you can build really nice computers for little money nowadays of used parts.
having alot of ram is lovely ;p When not directly used, it caches every application you loaded before, for quick restart times.

[safemode]

i run vs without swap (swap isn't even compiled into my kernel) and I'm ok. I'm going to do a massive conversion of textures tomorrow now that i've fixed gui compressed textures. I still need to find out why the atmosphere texture is funky, but that can wait a day.

Hopefully by tomorrow night you should see VS use the same or less memory than it used to prior to making png's uncompressed.

And it should load _much_ faster.



Should make sourceforge's servers really happy.

[ace123]

The music system should free all used memory. But maybe OpenAL is inefficient about the memory, or there is a bug in the AUD library.

As to swap, I highly recommend having some. If you ever end up running out of memory for some reason (compiling while playing VS), at least in my experience, it will cause the machine to completely freeze, seeking like crazy... because the disk cache disappears.

[safemode]

I wasn't suggesting to go w/o swap like me, just that it can be done w/o crashing VS. In any case, VS memory issues should be fixed by tonight.

[safemode]

gonna have to wait one more day (thursday evening) ...crap came up and i couldn't get to VS early enough to convert a decent amount of textures. I'm going to let it convert overnight while i sleep for the 4 hours a day i do sleep and i'll review the new files tomorrow/later today after work.

Right now we dont compress png because png is going to be the format authors use to designate something that _must_ be of the highest quality all the time. As of right now, i'm treating all current png's as not that. Any png's that must remain uncompressed, will either have to be pointed out prior to tomorrow evening, or later on when it's discovered, reverted.

There are 1400+ textures being converted to dds, I'm not going to be able to review every single one individually and test it for functionality in the game. That's why we have svn and people who use the svn prior to release. After the commit i suggest everyone update and start testing and telling me right away of any textures that are just _wrong_ in the game. The release is fast approaching and this overhaul of the textures has to get done before it.

I'm already aware of the broken textures in /texture that i committed a few days ago, i'll be fixing those tomorrow.

Commits will be done in batches, probably on a directory to directory basis. This will probably take a couple hours since sourceforge is extremely slow lately and several hundred MB's are likely to be transferred (I dont think svn does inline compression for some reason). It's really too bad we can't distribute the bandwidth requirement a bit. Kinda like torrenting svn. Though i guess that's what you would call git.

Anyways, i'm tired.

for those eager to get in on some mass texture changes, the stupid little script i'm using is here http://signal-lost.homeip.net/files/vega/contex.sh

I would really suggest not commiting any textures to data4.x until after tomorrow however.

[Miramor]

Hey, no problem. You might want to be getting more sleep though.