Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Valathil on August 08, 2012, 01:07:20 pm
-
So i herd u liek .eff Head.ani's?
There you go: http://www.mediafire.com/download.php?cc5l6bh5520nhpt (http://www.mediafire.com/download.php?cc5l6bh5520nhpt)
Few Notes: I changed the head animation system to use generic_anim's instead of the anim_play framework so this could possibly fix the head.ani stuttering please check that.
Also new Mod Table entry "$Override Head.ani color to white:" which surprisingly overrides the head.ani color to white so you can have full color eff animations.
I also patched FRED so you can select *.eff in the browse dialog of the event editor but i cant compile FRED so you have to wait on a kind soul to provide one OR you edit the mission file yourself OR you just name you eff the same as your ani, it takes precedence. With that have fun and please report bugs.
EDIT: I should probably clarify the mod.tbl settings its in #OTHER SETTINGS after "$Default weapon select effect:" so basically for now the last parameter
-
My antivirus is saying that the file is infected with something like..NewHeur_PE.
I'll test this at home when I get back tonight.
-
Your antivirus is confused.
-
YES FINALLY. :D
Much <3's.
-
This is awesome.. Can I just say though, that the mod.tbl should probably be the other way around? White has always been default.. the override should allow color? Maybe? I dunno... does it really matter?
Nao. Valathil, you will be my personal hero if you make an .eff container... >_>
-
My antivirus is saying that the file is infected with something like..NewHeur_PE.
I'll test this at home when I get back tonight.
"NewHeur" as in New Heuristic?
-
EFFing FRED builds:
http://blueplanet.fsmods.net/E/EFFHeads.7z
-
This is awesome.. Can I just say though, that the mod.tbl should probably be the other way around? White has always been default.. the override should allow color? Maybe? I dunno... does it really matter?
Nao. Valathil, you will be my personal hero if you make an .eff container... >_>
You can set the color of the head.ani in your hud settings. So if you have color effs they would get tinted by that user setting therefore override to white.
What the EFF is a .eff container? you mean like compile it into a single file? why the EFF would you wanna do that?
-
For the ease of handling and renaming, presumably.
-
Well, .effs don't stream like .anis do, which as caused a bit of an issue for me with my mainhalls.
EDIT: Ala, this ticket. (http://scp.indiegames.us/mantis/view.php?id=2026)
-
Can we rename that parameter to "Full Color Talking Head" so we can just describe function and not implementation?
And also, since we're no longer relying on the anim_play func to hack in the talking head animation in the gauge for us and using generic_anim_render within the actual Talking Head gauge, could you use setColorGauge() instead of gr_set_color_fast(&HUD_config.clr[HUD_TALKING_HEAD])? I really disliked having to reference HUD_config in the head animation code back then when I was rewriting the entire HUD system. gr_set_color_fast should just be used when we want to set the color context to white for getting full color animations.
-
Well, .effs don't stream like .anis do, which as caused a bit of an issue for me with my mainhalls.
EDIT: Ala, this ticket. (http://scp.indiegames.us/mantis/view.php?id=2026)
This ticket only describes the format not the problems you having. Cause i dont want to overwhelm the thread here with our discussion i suggest you find me on IRC and we can talk.
-
If you want something to test this on, go play Dimensional Eclipse, which has all the headanis as anis as well as effs. Droid kept holding on for the day eff support would come and looks like he got it. :p
-
Concerning hitting the bmpman limit 5 possible solutions:
- Unload the eff everytime the animation finishes (Bad for cases where theres much reuse)
- Write a separate handler with dynamic limits (lots of work)
- Same as 2 but push everything into gl textures and dont keep the data in memory (high vram usage)
- Load every frame individually and unload it everytime the next frame is displayed (isnt this what causes the .ani stuttering?)
- Sort of a hybrid of 2 and 4 and the old bmpman where you load some frames ahead of time render them while loading more and killing old unused ones
DISCUSS!!!
-
Someone talked a while ago something about some kind of texture arrays. That wouldn't cut it?
-
Someone talked a while ago something about some kind of texture arrays. That wouldn't cut it?
that's number 3 or a way to do 3 not a solution by itself
-
5 sounds like a good compromise, but I'm afraid it could be a bit overengineered and difficult to implement. 2 could be the best solution for the end user, but I know such things need a lot of work from the devs and a lot of testing afterwards.
-
5 sounds kind of... ugly. 2 sounds like it'd be the "cleanest" solution but it might have to go through antipodes, which could take a while depending on how much longer this RC phase lasts etc.
That's just my opinion though.
-
I'm just curious, what's wrong with option #1?
-
what about increasing the BMPMAN limit by approx 500 (for example - to allow 10x head ani/EFF per mission @ ~50 frames each ) until 2 (or 3) is completed? Otherwise 1) doesn't sound like too much work - it could be tried to see if unloading/reloading causes issues? (e.g. FSO pauses while the ani/eff is removed from memory)
-
The problem with just raising the bmpman limit is that it's not limiting missions, it's limiting interface (mainhalls to be specific) and so raising it by 500 won't be enough to load all the EFF frames simultaneously. To get around this, I have to use a streaming format which is only ANI at the moment. (Horrid quality)
-
ahh - thanks for that info - I was completely unaware of the mainhall problem :)
-
Few Notes: I changed the head animation system to use generic_anim's instead of the anim_play framework so this could possibly fix the head.ani stuttering please check that.
I think you nailed it.
-
Concerning hitting the bmpman limit 5 possible solutions:
- Unload the eff everytime the animation finishes (Bad for cases where theres much reuse)
- Write a separate handler with dynamic limits (lots of work)
- Same as 2 but push everything into gl textures and dont keep the data in memory (high vram usage)
- Load every frame individually and unload it everytime the next frame is displayed (isnt this what causes the .ani stuttering?)
- Sort of a hybrid of 2 and 4 and the old bmpman where you load some frames ahead of time render them while loading more and killing old unused ones
DISCUSS!!!
Question..
Why is the bmpman limit there? High memory usage? If so, would it be possible to use some sort of high quality compression like h.264 (http://blog.superuser.com/2011/11/07/video-conversion-done-right-codecs-and-software/) and just raise the limits by however much memory is saved? I mean, you would of course increase CPU usage, however, how much CPU could a head animation at ridiculously small resolution take? And, in the mainhall, it's not like the game is running, so if your rig can handle full-screen h.264 video playback, that shouldn't be a problem, right? FWIW, x264 (http://www.videolan.org/developers/x264.html) is a free encoder for h.264.
/me prepares for the possibility of not knowing what he was talking about and being beat with the non-working plasma rifles... :eek:
-
x264 is GPL'd - so we can't include it in FSO (to the best of my knowledge)
As for the BMPMAN limit - read what taylor said (http://www.hard-light.net/forums/index.php?topic=37158.msg758420#msg758420) (many years ago now I admit...)
-
[Captain Obvious] FSO badly needs a streamable container which takes up only one slot regardless of how many frames the container contains. [/Captain Obvious]
Are there really no other readily available container formats with compatible license other than those two obscure PNG derivatives?
-
Few Notes: I changed the head animation system to use generic_anim's instead of the anim_play framework so this could possibly fix the head.ani stuttering please check that.
I think you nailed it.
The stutter is gone for me as well :yes:
-
[Captain Obvious] FSO badly needs a streamable container which takes up only one slot regardless of how many frames the container contains. [/Captain Obvious]
Are there really no other readily available container formats with compatible license other than those two obscure PNG derivatives?
Hmm... http://en.wikipedia.org/wiki/Container_format_(digital)
Matroska (MKV) (not limited to any codec or system, as it can hold virtually anything. It is an open standard and open source container format).
>> http://en.wikipedia.org/wiki/Matroska
CoreCodec owns the copyrights and trademarks for the Matroska specification, but the specifications are open to everybody. The Matroska project is an open standard which is free to use and the technical specifications are available for private and commercial use. The Matroska development team licenses its libraries under the LGPL, with parsing and playback libraries available under BSD licenses.
Is that feasible?
EDIT: Also, Containers for h.264: .mp4, .mkv, .mov.
x264 – H.264/MPEG-4 AVC implementation. x264 is not a codec (encoder/decoder), it is just an encoder (it cannot decode video).
On August 26, 2010 MPEG LA announced that H.264 encoded internet video that is free to end users will never be charged royalties.[10] All other royalties will remain in place such as the royalties for products that decode and encode H.264 video.[11] The license terms are updated in 5-year blocks.[12]
http://en.wikipedia.org/wiki/X264
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
http://en.wikipedia.org/wiki/Open_source_codecs_and_containers
http://en.wikipedia.org/wiki/Matroska
http://en.wikipedia.org/wiki/Digital_container_format
http://blog.superuser.com/2011/11/07/video-conversion-done-right-codecs-and-software/
-
No, jr2, those are not really options available to us.
h264 video would be nice, but AFAIK we'd have to write our own decoder (since libavc and similar are GPL).
mkv would be nice, but without h264, using it makes little to no sense.
The only real options we have (and it would be only slightly worse than mkv/h264) would be to either roll our own mng implementation, or allow ogg video streams as another option for ani replacement.
-
the problem of ogg is lack of transparency.
-
Which is not a problem for head anis, and an art design issue anywhere else.
-
that is a very short sighted assumption. :doubt:
I'll explain when I'm not on my phone.
EDIT: Explanation.
I don't want to be boastful, but you need to consider my credibility here. While you have read and possibly created some of the code as well as having made or added a few anims to FSO, I have worked with FSO's anims to the limits. I've created over 400 anims (.ani and .eff) and, as far as I know, I've made the only fully functioning 3D mainhalls. I know what I'm talking about.
Now, the first thing that comes to mind is that transparency is a retail used feature with anims. It's also a feature I've used extensively. Think CB Anims.. what if I want a logo anim with a seamless background to match the interface? Best way to do it is to render the animated logo on a transparent background (or full green for .ani). I've also used this for ship/weapon select anims so that they are transferable to any interface style and just just FS2 style.
Now, for mainhalls. You can not do 3D mainhalls without transparency and have it look good. You just can't. Retail Bastion uses transparency for the cranes, as do I. I also use transparency to blend all the doors and misc anims onto the background seamlessly.
All in all, transparency is an essential thing to be used for a lot of anims throughout FSO. Calling it an art direction issue is extremely short sighted and, frankly, I'm shocked that you, of all people, would say that.
-
You are, of course, correct, and I didn't mean to belittle your efforts or desires. I also realize, upon rereading my post, that I worded it in an unnecessarily clumsy way.
I am just saying that ogg video as an option would be a good thing to have, not that it was the only, or even best, option.
-
Tbh I don't think that
There is currently a limit of 4,750 bitmaps that can be loaded at one time. THAT LIMIT WILL NOT BE INCREASED AGAIN. The limit was calculated (by myself) based on the code changes to bmpman, the largest texture map using mission available at the time, plus an extra buffer factor for the future. In theory, if the effect and model producers followed certain rules (which almost no one knows at this point), then it would actually be possible to drop that limit to a lower level given the changes to bmpman.
Is a valid reason for me anymore. To me it's sounding like "EVERY PIRATED SONG IS WORTH $800,000 IN LOST PROFIT! This was calculated (by myself) based on statistics, the largest amount of money we've successfully sued for, plus an extra buffer in case we want to sue for more."
It's totally failing to address (or predict) a number of things. Yes, getting rid of tilerape would help, but for every animated glowmap you add, you have to de-tile 3 ships... For every new explosion effect with 50 frames, you need to what, de-tile 5-7 ships? Clearly model producers at this point are the least of the problems - each of my ships uses two, maybe three textures.? Same with Spoon's in WoD, and we can still hit the limit!?
It still hasn't been explained why a bmpman limit exists in the first place. It's certainly not memory because I can shove 4750 textures which are 8192^2 in there and it'll happily accept all of them...until I run out of video memory, crash, and burn. So what's the real reason for this (completely arbitrary) cap of 4750?
-
It still hasn't been explained why a bmpman limit exists in the first place. It's certainly not memory because I can shove 4750 textures which are 8192^2 in there and it'll happily accept all of them...until I run out of video memory, crash, and burn. So what's the real reason for this (completely arbitrary) cap of 4750?
Are you seriously saying that you have several Terabytes of RAM available on your machine?
-
This is irrelevant. Bmpman limits are supposed to prevent something from happening. What is that eactly and would gates to hell open if the limits were simply pulled?
-
It still hasn't been explained why a bmpman limit exists in the first place. It's certainly not memory because I can shove 4750 textures which are 8192^2 in there and it'll happily accept all of them...until I run out of video memory, crash, and burn. So what's the real reason for this (completely arbitrary) cap of 4750?
Are you seriously saying that you have several Terabytes of RAM available on your machine?
No, but I'm saying that since it only cares about texture count and not texture size it's worthless as a memory controller, because you can just as easily run out of memory by shoving massive textures in there.
-
Bmpman with a limit is not an inherently bad thing. The problem here as it relates to EFFs and the interface is that we are using a screwdriver to hammer a nail. Bmpman wasn't built with the idea to store each frame of an animation as a separate handle (which is evidenced by how. anis work). Concurrently, .eff wasn't built to always be a huge set of image files to be loaded.. it is (according to the mantis ticket I linked above) an incomplete-ish feature... but one that works very well in most cases.
-
I've been studying the code and found something interesting. You guys ever seen the "Fast-unloading ...." stuff in the log. It seems that after a Texture is successfully put into OpenGL we dump the image from system memory anyway. Have I missed something? And if not that speaks even more as the limit not being representative of memory limitations. I also want to chime in in respect to loading/streaming. You cant have both the fastness of preloading everything and the low memory requirement of streaming at once I just wanted to say that so we need to decide what we want with the animations. To me it looks like the head.ani problem was because every frame was loaded individually a.k.a. streamed. SO if we want to preload we have basically 3 options. Either increase the bmpman limit, kill all animations after playing and always reload them, or load animations with a system outside bmpman which is basically the same effect as increasing the limit WITHOUT increasing the limit.
Also i just noticed theres a HUD section in the mod.tbl i moved the setting there but i wont release an updated build just for that but keep it in mind for the future
-
Valathil, I'd love to hear your thoughts on these previous discussions (http://www.hard-light.net/forums/index.php?topic=80792.0). One solution to this problem was the implementation of the MNG format. Its a container and, I assume, would work like ANIs in regard to bmpman slots. It allows transparency and compression. The problem is the format is somewhat lacking in available tools.. so yeah, give the threads a once over, I'd love to know your thoughts on it.
-
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 >.>
-
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.
-
That's why we "landed" on .mng because it already has a standard lib.
-
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.
-
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.
-
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 (http://img21.imageshack.us/img21/1134/whattheeff.jpg)
-
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 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.
-
http://www.mediafire.com/?009rycrda0dxctb patch
-
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.
-
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.
-
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.
-
Indeed. That would be much win.
-
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.
-
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. :confused: (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?)
-
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. :confused: (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.
-
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?
-
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.
-
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.
-
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
-
Could you please send a patch my way? Thanks
-
Tested them.
texture_streaming one presents no stuttering at all.
trunk presents the stuttering problem, no doubt about it because it's really noticeable.
I don't even know how was I capable of playing FS2 with this horrible thing all the time.
-
**** Yes.
-
Whoa, let's calm down for a minute. I'm sorry to show up and put a damper on the celebration, but Valathil, this didn't have a code review or even a thread on the internal. The first I heard of it was by seeing the commit log. Considering that EFF streaming is a problem that has stymied numerous coders for quite some time, this is a problem that needs more eyes on any proposed solution.
This part especially makes me skeptical:
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.
There are a lot of ways to interpret a fix that only works in a limited number of situations... one is "a partial fix", and one is "a brittle hack". I don't know enough about the graphics code to tell which category this falls in.
Regarding the container format, MNG is a possibility, but Mjn.Mixael brought to my attention this (http://scp.indiegames.us/mantis/view.php?id=2026) Mantis ticket about a draft for an EFF container format. Has anyone besides Flaming_Sword looked into it?
-
Except that this commit does everything I need it to, short of cross-frame compression. In fact, it even speeds EFF loading up.. by a lot. As in, my Bastion mainhall (which used to take 3+ seconds to load) now loads up in a fraction of the time.
Over the last few hours, I've thrown just about every anim I can at this commit (that Swifty reviewed, according to the IRC log, BTW), and except for a possible issue with 1 frame EFFs, it's all working well as far as I can tell.
EDIT: Oh, and this definitely resolves the bmpman limit issues i've been having. (See: Unashamedly Smashing Through It)
-
There are a lot of ways to interpret a fix that only works in a limited number of situations... one is "a partial fix", and one is "a brittle hack". I don't know enough about the graphics code to tell which category this falls in.
Well, if you know a way to have multiple instances of the same animation open and playing without having to keep all the frames of said animation in memory, please share it with us before calling this thing a partial fix. It's a complete fix for the issue under consideration (to wit, comm anis causing stuttering).
Secondly, I know you don't like this, but Valathil was very open about discussing what he was doing in this patch on IRC. I dare say that the people most qualified to evaluate this fix were listening, and agreeing with the steps taken here.
-
- This isn't some kinda of hairbrained scheme i hacked up in a few hours. I spent about 6 hours researching bmpman and the tcache code before even writing the first line of code
- Multiple people were involved in the discussion of how this would be best handled which include such high profile SCP and community members as The_E, Swifty, MjnMixael and chief1983
- The patch was code reviewed by swifty and the commit was greenlighted by chief1983
- Multiple people confirmed the patch working through various testing. Rodo, niffiwan, Spoon, MjnMixael, The_E and probably others.
- Streaming single frames of explosion or impact animations instead of preloading them is bad. It should be rather obvious why. The question of why they are not done this way now is not a question of "this is only partially done" but a conscious decision in favor of performance.
-
There are a lot of ways to interpret a fix that only works in a limited number of situations... one is "a partial fix", and one is "a brittle hack". I don't know enough about the graphics code to tell which category this falls in.
:wtf: This isn't a hack. Just because I said that we were treating different kinds of resources with different use cases doesn't mean we're making some sort of unrobust and inelegant discriminatory code path. It's simply a matter of intelligently determining how we allocate and stream resources to render. Preloading textures and getting all effect and model resources available for render is good for drawing dynamic scenes because we don't know in advance of when something needs to be drawn to the screen. On the other side, loading and streaming texture data is a better use case for predictable animations since we know exactly when certain a bitmap data frame is needed at a given time and therefore don't need to greedily consume resources we actually don't need.
On the plus side, this also killed the ANI stutter. Turns out it's better to just let OpenGL to handle updating a texture object data by itself rather than explicitly tell it to make a delete. I used the same philosophy when updating particle vertex data using the vertex buffer in my most recent commits.
This doesn't preclude any future effort to get MNG or whatever animation container you want into the game. This in fact opens the door even wider for those prospects. In the end, they're all going to be turned into texture data and will be streamed via this code.
-
I'm going to be less tactful and ask Goober when was the last time you submitted anything for code review? Cause the last time on the internal was in April, and if you're going to tell me that was the last time you committed something that could potentially break something, my response is going to be a rude noise. :p
In that time you've submitted quite a bit of code which I tend to feel you should at least have run past me as the other main FRED/SEXP coder. I doubt I'm the only coder who feels that you've submitted code you should have run past them.
So if you want us to take you seriously about code reviews, I'd like to see you posting them yourself before asking others.
-
For science! Data from PVS-Studio shows this commit does not introduce or change any code in such a way as to lead to additional warnings.
-
Except that this commit does everything I need it to, short of cross-frame compression. In fact, it even speeds EFF loading up.. by a lot. As in, my Bastion mainhall (which used to take 3+ seconds to load) now loads up in a fraction of the time.
I don't doubt that Valathil's changes are a significant improvement on the features in question. What I'm trying to find out is its potential effects on the other parts of the code, and to what extent people were looking out for that sort of thing. The law of unintended consequences is merciless.
Secondly, I know you don't like this, but Valathil was very open about discussing what he was doing in this patch on IRC. I dare say that the people most qualified to evaluate this fix were listening, and agreeing with the steps taken here.
What I don't like is the lack of a permanent record of the discussion or a notification that a discussion even took place. But the fact that a discussion did take place, with multiple participants, and with multiple qualified eyes on the problem, is what I was primarily concerned about.
Consider that anybody who wasn't present at the IRC meeting, or for that matter who didn't happen to see this thread, would have no idea what was discussed, or by whom.
- This isn't some kinda of hairbrained scheme i hacked up in a few hours. I spent about 6 hours researching bmpman and the tcache code before even writing the first line of code
- Multiple people were involved in the discussion of how this would be best handled which include such high profile SCP and community members as The_E, Swifty, MjnMixael and chief1983
- The patch was code reviewed by swifty and the commit was greenlighted by chief1983
- Multiple people confirmed the patch working through various testing. Rodo, niffiwan, Spoon, MjnMixael, The_E and probably others.
These points pretty much address all of my my concerns. :yes:
5. Streaming single frames of explosion or impact animations instead of preloading them is bad. It should be rather obvious why. The question of why they are not done this way now is not a question of "this is only partially done" but a conscious decision in favor of performance.
Yeah, this makes sense. I thought this feature wasn't applicable to effects and textures, though, as Swifty mentioned here (http://www.hard-light.net/forums/index.php?topic=81616.msg1628100#msg1628100)? Even in the case of head anis, it is theoretically possible that a mod designer would use a single-frame head animation. Does the code compensate for this?
:wtf: This isn't a hack. Just because I said that we were treating different kinds of resources with different use cases doesn't mean we're making some sort of unrobust and inelegant discriminatory code path.
Which is why I qualified my statement with a disclaimer. :) I was trying to find out information, not throw out accusations.
I'm going to be less tactful and ask Goober when was the last time you submitted anything for code review? Cause the last time on the internal was in April, and if you're going to tell me that was the last time you committed something that could potentially break something, my response is going to be a rude noise. :p
In that time you've submitted quite a bit of code which I tend to feel you should at least have run past me as the other main FRED/SEXP coder. I doubt I'm the only coder who feels that you've submitted code you should have run past them.
So if you want us to take you seriously about code reviews, I'd like to see you posting them yourself before asking others.
Please don't try to turn this into a personal argument. :rolleyes: Valathil's SVN comment included the phrase "implement eff streaming", which is a feature that had been discussed multiple times in the past, in multiple threads, and had been deemed a fairly tricky problem with no easy solution. I don't demand a code review for every one of Valathil's commits, and I'm not trying to attack him personally. This is about "EFF streaming" as a feature, which is fairly a big deal, and as such warrants a fair bit of attention.
And based on all the responses to my question, it sounds like it got the attention it warranted. So I thank you all for bringing me up to speed. :p
-
You can't use a single-frame head animation unless you only want it to appear for a maximum of 1 second as it appears once it stops and you can't have less than one frame per second.
Suffice to say single-frame head ani/effs will not be a problem. At the very least you need duplicate frames in which case, it shouldn't make a difference from an actual animation.
-
Please don't try to turn this into a personal argument. :rolleyes: Valathil's SVN comment included the phrase "implement eff streaming", which is a feature that had been discussed multiple times in the past, in multiple threads, and had been deemed a fairly tricky problem with no easy solution. I don't demand a code review for every one of Valathil's commits, and I'm not trying to attack him personally. This is about "EFF streaming" as a feature, which is fairly a big deal, and as such warrants a fair bit of attention.
I'm not trying to make this personal. I'm asking you to request code reviews more often since your features frequently are a big deal and yet you commit them very often without any oversight at all. If you're going to make the argument that Valathil's code requires more oversight I'm going to have to point out that a lot of yours does too.
-
Valathil's SVN comment included the phrase "implement eff streaming", which is a feature that had been discussed multiple times in the past, in multiple threads, and had been deemed a fairly tricky problem with no easy solution.
Yeah and I just went out and did it cause thats how I roll.
"Theres no way we gonna get real time ship selection effects not for a few years anyway"
"Shadows in FSOpen are not really possible for now"
"I dont think godrays could be done in the game"
"Distortion thrusters would be nice but we cant do that i think"
-
And while it's not like you got all those right the first time, you do seem to have a way of bending the spoon. But your smugness might not be helping your case :P
-
And while it's not like you got all those right the first time, you do seem to have a way of bending the spoon. But your smugness might not be helping your case :P
Valathil is allowed to be smug and bend me at the same time.
It comes with being a wizard.
-
And while it's not like you got all those right the first time, you do seem to have a way of bending the spoon. But your smugness might not be helping your case :P
Valathil is allowed to be smug and bend me at the same time.
It comes with being a wizard.
There's something oddly wrong about this suggestion....
-
Valathil is allowed to be smug and bend me at the same time.
It comes with being a wizard.
There's something oddly wrong about this suggestion....
It is what it is.
-
For differences, I suggest a rap battle. Although, what's good for the goose is usually also good for the gander, and laws for the goose should apply equally to the gander.
/me looks up around the table of wizards at which he has just spoken, and then scuttles to hide behind the beer keg, realizing that he is only a hobbit.
-
All disagreements will be settled by reasoned argument. If that fails, dance off. :p
-
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
Late to testing...
I can't seem to run those two builds, they're either 64 bit or maybe corrupted.
-
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
Late to testing...
I can't seem to run those two builds, they're either 64 bit or maybe corrupted.
They're incompatible with Windows XP since he compiled with VS 2012
-
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
Late to testing...
I can't seem to run those two builds, they're either 64 bit or maybe corrupted.
They're incompatible with Windows XP since he compiled with VS 2012
...Yep. Definitely behind the curve these days. :beamz:
-
:bump:
As requested by the wizard Valathil, I ran a trunk build (r9223) via MSVC's debugger to try and pin down this animation corruption I've been having.
http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/r9223_Callstack.png (http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/r9223_Callstack.png)
http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/r9223_Unhandled_Except.png (http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/r9223_Unhandled_Except.png)
The debugger breaks right here with the unhandled exception:
gropengltexture.cpp
glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, t->w, t->h, glFormat, texFormat, (texmem)?texmem:data);
-
Oh, great, a bug in Intels' GPU driver. Fan-friggin-tastic.
-
nono driver gets power of 2 texture sizes from texture info which are bigger than the actual texture data -> read outside allocated memory -> crash i need to pad the data when we dont have nonpowerof2 textures avaliable.
-
Who is using non power of 2 textures?
-
Who is using non power of 2 textures?
Head ani's
-
Who is using non power of 2 textures?
Head ani's
And retail mainhall animations, and retail briefing animations...
-
...So, is this the reason why Intel GPUs always cause crashes with FSO or are there other reasons?
-
...So, is this the reason why Intel GPUs always cause crashes with FSO or are there other reasons?
As far as I know, yes, this is the only reason.
-
So all you have to do is patch FSO to pad that data and they'll work?
-
So all you have to do is patch FSO to pad that data and they'll work?
The patch is already in trunk as of 9226. Padding the data was what actually caused the problem in the first place, because apparently Intel didn't go fully by the OpenGL specs for glTexSubImage2D. Whereas the rest of the GPU's would chug away with the padded data, Intel's GPUs would do a read access violation and cause the corruption/nastiness. (or so I've heard from Valathil when he was making the patch)
-
nah it was because the texsubimage call took the texture dimensions of the gl texture slot which was in z's case a power of 2 and therefor larger than the texture data which caused a read into unitialized memory and made the pictures come out wrong. im now just passing the right dimensions now it works fine.
-
So it was a crash in Intel's drivers caused by bad data from FSO?
-
yes cause i assumed non power of 2 textures everywhere cause come on who has stone age gpus like z
-
What GPU ? I thought he had a derptelgrated.
-
yes cause i assumed non power of 2 textures everywhere cause come on who has stone age gpus like z
GL_INTEL_bang_rocks_together is probably one of the best OpenGL extensions in the registry.
-
yes cause i assumed non power of 2 textures everywhere cause come on who has stone age gpus like z
GL_INTEL_bang_rocks_together is probably one of the best OpenGL extensions in the registry.
My Laptop's cheaper than yours and works great so meh :P
-
considering you have tons of acers around that are cheap, and different models have either craptelgrateds or a bit better integrated's, ala ati or nvidia, but they are horribly underpowered compared to even weak-ass desktop cards. i know that a friends laptop with nvidia M520 or whichever, is tons slower than my gf's pc with a measly nv 9600GT anyhow.
-
I'm running an nVidia GT 540M w/1GB vid RAM in my laptop; works just great. Just have to remember to manually set it to use that instead of trying to save power by using the Intelgrated that comes with the i7 (and the i5).