OXPShipRegulator

[Svengali]

Hmm. Flashers shouldn’t be using much memory. Interesting…

A single FLASHER (or a few of them) is absolutely no problem and while testing I saw that it's using ~300KB. That's not really much. But >250 of them is another thing :-)

I'm not so sure if we can get similiar effects for all of these ships, because a FLASHER is a 3-dimensional object, so the result would be different. But it would help a lot to reduce the amount of used declarations.

[JensAyton]

Hmm. A flasher should be taking about 5 KiB. I just noticed that 1280 bytes of that is completely unused (and most of the rest is for fields only used by exhaust entities). ParticleEntity really needs to be refactored…

However, 300 KiB per particle sounds like the texture isn’t being shared. (The texture is 256 KiB.) That would indicate a rather fundamental problem in texture caching. I’ll definitely look into that soon. (Gotta finish this whitelisting stuff first.)

[Thargoid]

Most of these ships were made long before shader-support was available, but this has changed.

Not for everyone it hasn't...

[Svengali]

However, 300 KiB per particle sounds like the texture isn’t being shared. (The texture is 256 KiB.) That would indicate a rather fundamental problem in texture caching. I’ll definitely look into that soon. (Gotta finish this whitelisting stuff first.)

Thanks Ahruman.

Not for everyone it hasn't...

Yes, you're right. We still have users without shader-support, but probably this will change some day too .-)

[Thargoid]

I can but hope, or failing that my employer sees sense and gives me admin rights so I can drag the graphics drivers on my company laptop out of the dark ages...

OK, I'll just go back to hoping

[Lestradae]

However, 300 KiB per particle sounds like the texture isn’t being shared. (The texture is 256 KiB.) That would indicate a rather fundamental problem in texture caching. I’ll definitely look into that soon.

Thanks for that, Ahruman

Hey! Via OSE, a bug was found. Due to is extremeness in some ways it might not be such a bad thing to find other things out via that?

Cheers & relieved a bit that the cause or the memory problem issue of OSE is probably found now

L

[_ds_]

However, 300 KiB per particle sounds like the texture isn’t being shared. (The texture is 256 KiB.) That would indicate a rather fundamental problem in texture caching. I’ll definitely look into that soon. (Gotta finish this whitelisting stuff first.)

Would be good. I might even have a poke around there myself (get my head around some more Objectionable C ). I did wonder about that a bit when fiddling with my compression patch. I got some noticeable slowdown whenever something exploded…

We still have users without shader-support, but probably this will change some day too .-)

Me, for one. (X300, xf86-video-ati 6.10.0, mesa 7.3-rc3. The hw's capable; the driver isn't – at least, not yet…?)

And something odd which I noticed on another computer to which I sometimes have access: running Vasti, I see no shaders support, but booting from a convenient Debian live CD, I see shaders support. (i965, recent oolite build on Vasti and a local snapshot build on Linux.)

(Edit) Looks like it was flare256.png being loaded a lot and discarded quickly. Might be worth locking that one in memory, perhaps?

Code: Select all

diff --git a/src/Core/Entities/ParticleEntity.m b/src/Core/Entities/ParticleEntity.m
--- a/src/Core/Entities/ParticleEntity.m
+++ b/src/Core/Entities/ParticleEntity.m
@@ -691,9 +691,10 @@ FAIL:
 {
 	if (name != nil)
 	{
-		const uint32_t options = kOOTextureNeverCompress;
-		[texture autorelease];
-		texture = [[OOTexture textureWithName:name inFolder:@"Textures" options:options] retain];
+//		const uint32_t options = kOOTextureNeverCompress;
+		OOTexture *oldtexture = texture;
+		texture = [[OOTexture textureWithName:name inFolder:@"Textures" /*options:options*/] retain];
+		[oldtexture release];
 	}
 }
 

[Cholmondely]

I think that this belongs here:

Thanks guys for setting me straight.

Oumpf, sorry. This wasn't the intention.

btw: I've made the same 'mistake' a whole while ago with the OXPShipRegulator. A dead-end as well

Search for "OXPShipRegulator" to find other posts relevant to this.