Page 2 of 2
Posted: Sun Jan 25, 2009 5:40 pm
by Svengali
Ahruman wrote: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.
Posted: Sun Jan 25, 2009 5:52 pm
by 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.)
Posted: Sun Jan 25, 2009 5:52 pm
by Thargoid
Svengali wrote:Most of these ships were made long before shader-support was available, but this has changed.
Not for everyone it hasn't... 
Posted: Sun Jan 25, 2009 6:08 pm
by Svengali
Ahruman wrote: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.
Thargoid wrote: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 .-)
Posted: Sun Jan 25, 2009 6:16 pm
by 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 
Posted: Sun Jan 25, 2009 7:44 pm
by Lestradae
Ahruman wrote: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
Posted: Sun Jan 25, 2009 8:56 pm
by _ds_
Svengali wrote:Ahruman wrote: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…
Svengali wrote: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];
}
}
Re: OXPShipRegulator
Posted: Wed Sep 21, 2022 12:48 am
by Cholmondely
I think that
this belongs here:
Svengali wrote: ↑Sat May 11, 2013 8:50 pm
spara wrote: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.