[Droid803]

Why can't we get bmpman to be "smarter" and treat EFFs + their associated frames as if they were a single file, you know, so it only counts once.
That's just also increasing the limit without actually increasing the limit, but hey.

Also, wasn't there that discussion of coming up with an entirely new format altogether, due to the lack of existing formats which are up to specifications? TBH I'd just suggest something like MKV but for EFFs, which is just a file which basically contains all the others...with no compression changes etc. Just so it's cleaner >.>

[Valathil]

My opinion of new file formats is "WHY THE ****" we have complete control of bmpman and handling of files if we want to change it we can why do we need to make a new file format i just dont get it.

[mjn.mixael]

That's why we "landed" on .mng because it already has a standard lib.

[chief1983]

Also, keep in mind that streaming anis is not the _cause_ of the stuttering, because at one point in the past, they never had this problem.

[Valathil]

Ok i did a little code combing and the biggest problem in my opinion is that the opengl textures and bmpman are so tightly bound by the bmpman handles that getting the animation frames to a texture requires a bmpman handle so i cant load in the animation then kill the bmpman entries because i could possibly lose the textures in the meantime if something overwrites it.

[Spoon]

I wish I had intelligent thoughts to contribute to this but all I can muster is "BMPman limit bad, eat soup with a Spoon."
At least EFF talking heads works

[Valathil]

I need someone with the head.ani stuttering run this and tell me if the stuttering is there again http://www.mediafire.com/download.php?brauo5zdul46olp

[niffiwan]

I need someone with the head.ani stuttering run this and tell me if the stuttering is there again http://www.mediafire.com/download.php?brauo5zdul46olp

If you can send me a patch, I'll test it tonight.

[Valathil]

http://www.mediafire.com/?009rycrda0dxctb patch

[Rodo]

I need someone with the head.ani stuttering run this and tell me if the stuttering is there again http://www.mediafire.com/download.php?brauo5zdul46olp

I can confirm without a doubt, the stuttering is back in that build.

[Valathil]

And with that ladies and gentlemen we now know why the stuttering occurs. It's not the reading of the frames or the streaming its the constant deletion of the old frames from the opengl context. Thats the only difference that is between my two builds. The first loads every ani frame individually but doesnt delete old frames from the opengl context it just leaves them in there forever. The new build deletes them after the frame has played. Very interesting but finally gives me the data to conclusively decide what to do. First write code to allow updating an existing texture with new image data (much faster than deleting and recreating) then convert ani stream code to use that and then create a eff preparser for the generic ani framework to allow streaming of eff files which also will use the texture updates to only use 1 bmpman slot.

[Fury]

and then create a eff preparser for the generic ani framework to allow streaming of eff files which also will use the texture updates to only use 1 bmpman slot.

So, you say that in the future bmpman handles eff animations in one slot, instead of using a slot for each frame? This includes textures and effects, not just interface?

If yes. We love you.

Hell, we love you regardless.

[mjn.mixael]

Indeed. That would be much win.

[Swifty]

No, this will just be for head ANIs and EFFs. The reason why we can do this with those is because we know that only one instance of a frame for those assets will be rendering at a given time. We can't do this for effects and textures as multiple instances can be rendered at a given time. A good example of this is having a bunch of explosions on screen in different frames of animation.

[niffiwan]

I need someone with the head.ani stuttering run this and tell me if the stuttering is there again http://www.mediafire.com/download.php?brauo5zdul46olp

I can confirm without a doubt, the stuttering is back in that build.

Errr... not on my system.  I've double & triple checked now and I get stuttering with trunk, but no stuttering with either of Valathil's patches.    (although, from Rodo's reports in mantis I suspect that the stuttering was always much milder on my system than his... could that explain the difference?  Also - does the OGL texture deletion explain why I get stutter in full-screen, but not windowed?  And the lack of stutter when I run in non-native monitor res?  Damnit - I want to understand this! )

Regardless of that, the OGL update vs delete texture plan sounds awesome 

(ps - retail head ani's are black/white rather than black/hud-colour in the generic_anim_stream build, but maybe that's deliberate?)

[Valathil]

No, this will just be for head ANIs and EFFs. The reason why we can do this with those is because we know that only one instance of a frame for those assets will be rendering at a given time. We can't do this for effects and textures as multiple instances can be rendered at a given time. A good example of this is having a bunch of explosions on screen in different frames of animation.

And mainhalls dont forget mainhalls they get the 1 frame thing also

Errr... not on my system.  I've double & triple checked now and I get stuttering with trunk, but no stuttering with either of Valathil's patches.    (although, from Rodo's reports in mantis I suspect that the stuttering was always much milder on my system than his... could that explain the difference?  Also - does the OGL texture deletion explain why I get stutter in full-screen, but not windowed?  And the lack of stutter when I run in non-native monitor res?  Damnit - I want to understand this! )

Regardless of that, the OGL update vs delete texture plan sounds awesome 

(ps - retail head ani's are black/white rather than black/hud-colour in the generic_anim_stream build, but maybe that's deliberate?)

well we dont get the stuttering either AND in trunk it seems to be a very specific thing where the order of opengl calls and the configuration of the system  must be taken into account. I'm fairly sure that it's not a code thing and has to do with the driver and the Texture deletion as said is the only thing different. The black/white thing is because i set the override flag in mod.tbl to test colr eff its just a test that slipped through in the patch but thanks for reminding me to turn it off again.

[chief1983]

Is there any way to tell if this behavior was added in the original go_faster code or was too much rewritten to tell for sure if this was not happening before?

[The E]

Well, it seems to me that this issue came to be due to changes in go_faster that exposed this behaviour, rather than  bugs in that patch. That, and maybe some change in driver behaviour.

As such, I don't think that trying to pin the blame on one commit or another is a useful thing to do, as long as we know how to fix it.

[chief1983]

I'm not saying it's blame, it's just that, I wonder if this particular loading behavior was the same before, and other changes exposed it, or if that patchset actually changed the loading behavior. 

[Valathil]

Ok one more for the stuttering guys: https://www.dropbox.com/s/ov43lk7q08fg7qh/fs2_open_3_6_13r_INF_SSE2.zip

there are two exes in there first try the texture_streaming one if that has no stuttering use the control trunk build and that SHOULD have stuttering again. If those conditions happen then were safe and have fixed it