The Oolite Extended Project - Fork, no oxp

[metri]

Where you have been before, you just copy paste what I have already done.

[metri]

Which OXP is oobay in "originally" - I'll see if I can narrow it down that way...

There is no originally for the oobay station - it'll make its first appearance in OSE - I only know this because I modified the originally texture for L because he was having problems with his graphics package and, as the creator of Oobay (for YAH), I had a nice big 2048x1024 image to play with!

Oobay is not problematic, but blue cargo nodes are, there are multiple definitions of them even they all look the same.

[metri]

Maybe I missed it somewhere but OSE depends on Target Autolock and Target Reticle.

Those have now been combined into one I believe... but I don't have them installed either way. They're not mentioned anywhere in this thread as far as I can remember. What depends on it do you think?

I tracked it, it is same issue like with cloak indicator and that points to (I belive) oolite bug.
Custom hud for ships do not inherit default values from hud.plist: workaround is to edit every hud and add reticle and cloak indicator hud support.

Edit: Reticle target sensitive is problem with OSE javascript code and it is not related to hud in any way.

[Cows]

Um, well, just a question:

Is the Navy Constitution from the Testpilots download supposed to shoot upwards instead of forwards?

[JensAyton]

Textures use very little memory, most of memory is lost on models.

I believe you are mistaken.

A model takes up just under 100 KiB of memory in 1.72.2 (less in 1.73), and generally less video memory.

A single 1024 × 1024 colour texture takes up 4 MiB, and there are three copies of it (two under Mac OS X), one in video memory and the others in normal memory.

[metri]

Textures use very little memory, most of memory is lost on models.

I believe you are mistaken.

A model takes up just under 100KiB of memory in 1.72.2 (less in 1.73), and generally less video memory.

A single 1024 *1024 colour texture takes up 4MiB, and there are three copies of it (two under MacOSX), one in video memory and the others in normal memory.

Are all available textures loaded in memory at same time?
Using max-texture-size=512 use less memory for big textures. You mean there are three copies of single texture loaded in oolite memory on UNIX?

[JensAyton]

Are all available textures loaded in memory at same time?

No. Textures are unloaded if there are unused ones and more than fifty are in memory. They can also be unloaded from the graphics card and re-uploaded by the OpenGL subsystem (which is what one of those copies are for), which of course causes a performance hit.

Models are not cached or shared, so the 100 KiB is per active entity (or subentity). On the other hand, the raw data form of all models is kept in memory. This form is generally much smaller than 100 KiB (and smaller than the .dat files).

Using max-texture-size=512 use less memory for big textures.

Specifically, 1 MiB.

You mean there are three copies of single texture loaded in oolite memory on UNIX?

One in graphics memory, two in normal memory – one is Oolite’s copy, which is used only when the graphics system is reset (i.e., when resizing the window or switching between windowed and full-screen mode), and the other belongs to the OpenGL implementation, and is used if the copy in graphics memory has been unloaded.

In Mac OS X, the GL_APPLE_client_storage extension is used to avoid this redundancy.

[zevans]

Where you have been before, you just copy paste what I have already done.

I don't know HOW I missed your list before, sorry!

Anyway, I've done a bit more testing with some heavy logging turned on and some other looking around and made two discoveries.

1. Lestradae has already logged a bug on Berlios about apparently excessive memory usage of models with flashers, and I am wondering if that is some of the problem with OSE versus trunk-only.

2. Memory usage is pretty proportional to ships spawning and disappearing as a whole, and the textures I think are working well. Which means the problems I saw correlated with oobay are down to two things:

A. oobay is a lot of objects in a tight space and therefore cause a lot of cache thrashing when they come into view - hence the disk thrashing. The rest of the time about 1.6GB VM footprint is as bad as it ever gets and the 700 I can keep in RAM is JUST about enough to allow smooth play. For instance a big ol' Navy battle causes a somewhat lighter cache frenzy when I get close to it.

B. The AI scripts seem to use a good chunk of memory, and again, as soon as you get close to oobay it loads lots of instances of the script. What worries me is that I would expect the majority of that allocation to be copy on write, if not read-only, and it shouldn't translate into real paging, so I wonder if there's some allocation tweaking to be done.

Fundamentally OSE has a lot more world scripts, another one to do with missiles that I saw an awful lot, and generally puts the object count to almost twice per system, so it's always gonna increase memory pressure. But I do think the Flashers bug is genuine and fixing that might make the whole problem go away (at least until we double the number of objects again. )

[metri]

1. Lestradae has already logged a bug on Berlios about apparently excessive memory usage of models with flashers, and I am wondering if that is some of the problem with OSE versus trunk-only.

Yeah, removing all those pesky flashers from Constitution makes it apperas immediately in shipyard.
Not even counting how many flashers in OSE exist, probably more that 10% of shipdata.plist

[Lestradae]

Hi guys, thanks for all the feedback, I will take it into account for the next OSE test version.

It will probably already be V0.65 and include things like big player ship special docking and the buying and selling of stations (!) but sadly, my notebook died yesterday and this will cost the development of this meta-oxp a lot of time.

The data could be saved, but don't know how long it takes until I have a working system to script, test & play on again

Good n8

L

[DaddyHoggy]

Eek! Sorry to hear about the notebook. Fingers crossed you're up and running again soon.

[Lestradae]

Thanks, DH!

I too hope that my notebook will be up & running again soon - tomorrow I'm going to take it to the bring-in shop and see what they tell me

[DaddyHoggy]

Thanks, DH!

I too hope that my notebook will be up & running again soon - tomorrow I'm going to take it to the bring-in shop and see what they tell me

If they tut loudly and shake their heads - it will be expensive...

[Lestradae]

Well, there is a silver lining now: My laptop died three days before its garanty would have ended ...

[zevans]

Good news! But now we KNOW this is a parallel Universe, because that never happens