Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Nightly Builds => Topic started by: The E on September 26, 2009, 09:03:15 am
-
Here's the nightly build for revision 5610: http://www.mediafire.com/?zwhhdyh4fxn
Revision: 5610
Author: portej05
Date: 13:22:26, Samstag, 26. September 2009
Message:
Fix for error introduced in Antipodes 3 which caused animations not to repeat
----
Modified : /trunk/fs2_open/code/graphics/generic.cpp
Revision: 5608
Author: portej05
Date: 07:52:17, Samstag, 26. September 2009
Message:
Antipodes 3 from Flaming_Sword
----
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Modified : /trunk/fs2_open/code/ship/ship.cpp
Modified : /trunk/fs2_open/code/graphics/generic.cpp
Modified : /trunk/fs2_open/code/asteroid/asteroid.cpp
Modified : /trunk/fs2_open/code/bmpman/bm_internal.h
Modified : /trunk/fs2_open/code/bmpman/bmpman.cpp
Modified : /trunk/fs2_open/code/bmpman/bmpman.h
Modified : /trunk/fs2_open/code/cfile/cfile.cpp
Modified : /trunk/fs2_open/code/fireball/fireballs.cpp
Modified : /trunk/fs2_open/code/fred2/shiptexturesdlg.cpp
Modified : /trunk/fs2_open/code/freespace2/freespace.cpp
Modified : /trunk/fs2_open/code/graphics/2d.cpp
Modified : /trunk/fs2_open/code/graphics/generic.h
Modified : /trunk/fs2_open/code/menuui/mainhallmenu.cpp
Modified : /trunk/fs2_open/code/menuui/techmenu.cpp
Modified : /trunk/fs2_open/code/missionui/missionbrief.cpp
Modified : /trunk/fs2_open/code/missionui/missioncmdbrief.cpp
Modified : /trunk/fs2_open/code/missionui/missioncmdbrief.h
Modified : /trunk/fs2_open/code/missionui/missionshipchoice.cpp
Modified : /trunk/fs2_open/code/missionui/missionshipchoice.h
Modified : /trunk/fs2_open/code/missionui/missionweaponchoice.cpp
Modified : /trunk/fs2_open/code/model/modelinterp.cpp
Modified : /trunk/fs2_open/code/network/multi_pxo.cpp
Modified : /trunk/fs2_open/code/network/multiui.cpp
Modified : /trunk/fs2_open/code/parse/lua.cpp
Modified : /trunk/fs2_open/code/particle/particle.cpp
Modified : /trunk/fs2_open/code/ship/shield.cpp
Modified : /trunk/fs2_open/code/ship/shipfx.cpp
Modified : /trunk/fs2_open/code/starfield/starfield.cpp
Modified : /trunk/fs2_open/code/weapon/flak.cpp
Modified : /trunk/fs2_open/code/weapon/muzzleflash.cpp
Modified : /trunk/fs2_open/code/weapon/shockwave.cpp
Modified : /trunk/fs2_open/code/weapon/weapons.cpp
Note that this build will take slightly longer to load mainhalls and other .anis used in the interface.
-
No SSE builds?
Nevermind I see it's in the 7-zip file
-
What's this about taking longer to load interface .ani files?
Is it enough to worry about?
-
Flaming_Sword has changed the ani loading code, which means that if you load interface screens with lots of anis (like the retail mainhall or the tech room) you will experience a few seconds of the game going unresponsive.
-
Heheh, it says "Date: 13:22:26, Samstag, 26. September 2009"... what language is that? German?
-
Yeah. Not quite sure how that got there, though. I usually keep my comp set to english....
-
It might be worthwhile to notice that users of FRED will still want to use versions prior to 5606, due to a waypoint bug caused by fixing WMC's warp-code..
I'll be posting a private build soon that does not include the changes to waypoint system, while still allowing Sync "Lost" to proceed as intended. It will contain all the other latest updates as an interim solution until FRED get's fixed.
-
It might be worthwhile to notice that users of FRED will still want to use versions prior to 5606, due to a waypoint bug caused by fixing WMC's warp-code..
I'll be posting a private build soon that does not include the changes to waypoint system, while still allowing Sync "Lost" to proceed as intended. It will contain all the other latest updates as an interim solution until FRED get's fixed.
Follow-up to say that this was fixed yesterday. The 5613 builds will work.
-
I really, really don't like the new ANI loading code.
It breaks all immersion, and on occasion makes it feel like the game has hung.
For example, Weapon selection ANIs don't start playing until *after* the 'swoosh' sound has played.
- What was the reason for the change?
-
a) To make the ani loading generic across all the UI functions that use anis, and b) allow EFFs to be played as well as anis.
-
So why did that make it so much slower?
Where's the new inefficiency coming from?
-
The old code was able to stream anis, as I understand it. The new code loads all anis into memory at once, which increases loading times.
-
Well I have to say I'm not a big fan of the new method either.
-
EFFs ought to be streamable too... that must be why the TBP effects are so slow, if they were pre-loaded!
I'm going to join in and say that whether animations are ANI or EFF, they must be streamable.
-
Give me an idea about how to do it for EFF and I'll get onto it. :P
Also, there are fixes for other issues with this commit yet to be committed to trunk... :nervous:
-
A thought then (blind as I've not looked at the code):
Open the EFF file, process and close.
Spawn a thread that does the following:
- Create a number of file handles to open the data, either the number of frames or a sensible maximum number (eg 10). (This does not limit the number of frames)
- Open these files
- Start to load the frames into memory.
- As soon as the first frame is in memory, close its file and reassign the file handle to the next unassigned frame (eg 11), start to load that.
- If the last frame already has a handle, delete the completed handles as they're not needed anymore.
- The thread dies once all frames are loaded.
The loading thread has to inform the caller when it's sufficiently far ahead for it to start playing based on framerate and speed of loading each frame.
Once the loader gets sufficiently far ahead you can start playing the effect.
For effects that are fully loaded into memory, obviously that doesn't matter.
- It might be faster to have the loader thread only access one file at a time, depends on the setup time for file handles.
-
An early attempt at streaming EFF while writing the current code ended in spectacular failure. It did the same thing as what happens now, except not all at once (and made the mainhall lag like hell while it was loading animations during playing).
I've had a look at how the current ANI code did the streaming. Horrible does not even begin to describe it. At least now I've got a direction I can work towards which is known to work, more or less.
-
Tomo: be advised that the FreeSpace code is almost entirely single-threaded. :)
-
Don't interface anis need keyframes though, which is not supported currently by the EFF format? Or would EFF be easy enough to say that every frame is a keyframe since they're independent images?
-
Effs do support keyframes now.
-
EFF was never intended to be used on the interface, hence it wasn't designed to handle streaming. Although it could be coded to stream it would be so horribly inefficient that it would hardly be worth the trouble. I worked on the EFF format with Lightspeed solely for use with in-game effects. So really, getting EFF working on the interface is something that it was specifically designed NOT to do.
The idea was always to create a new container format which could replace ANI on the interface. The new format would easily support everything that ANI does, but better. And it would be able to function equally well for effects as well as UI elements. This new format was never fully completed, but did have a basic working implementation when I started the Xt builds. The main missing piece was an app like AniBuilder which could be used to actually combine all of the animation frames into the container. However, the code got put in the back-burner, and unfortunately, it ended up getting lost along the way.
-
EFF was never intended to be used on the interface, hence it wasn't designed to handle streaming. Although it could be coded to stream it would be so horribly inefficient that it would hardly be worth the trouble. I worked on the EFF format with Lightspeed solely for use with in-game effects. So really, getting EFF working on the interface is something that it was specifically designed NOT to do.
Agreed. Saw it firsthand. :nervous:
-
Tomo: be advised that the FreeSpace code is almost entirely single-threaded. :)
Awk!!
Fair enough... not really a way to do it then!
As to a 'new' container format - wouldn't it make more sense to go out into the world and find an existing, open format to use?
Preferably one that already has (free) editors and viewers.
Maybe Animated PNG?
That's natively supported by Firefox, so it's easy to test. They do seem quite large though, so maybe not such a great format.
-
I already have something in mind for a possible container format, based on what I've seen in a previous job.
The general idea:
http://en.wikipedia.org/wiki/Type-length-value
There are things you can do with it that aren't obvious from the wikipedia entry, especially when used as a container format.
Anyone else got an open format (or method) in mind?
-
As to a 'new' container format - wouldn't it make more sense to go out into the world and find an existing, open format to use?
Preferably one that already has (free) editors and viewers.
The idea of a new format is so that we wouldn't be limited to a single content format/type. We wanted the flexibility to use (un)compressed DDS or JPG at the very least. That way it would be possible to use 8-bit/16-bit DDS for the interface if you didn't need a huge color count, but still needed the palette flexibility that ANI does not provide.
You could then use JPG if file size was very important (for huge frame-count animations) on certain interface animations. Streaming JPG would be pretty efficient since you can use the same decoder stream and just keep feeding it new data to process. This would work well for large interface animations, such as on the mainhall. And since JPG has no real size requirements it could be used anywhere that an alpha channel wasn't needed.
And you would have the option of DDS if you wanted a streaming effect or comm animation, something that you might need an alpha channel for, or something that you could use a DXT format with (if the dimensions allowed for it). Using uncompressed DDS was an issue as far as filesize went, but that is why compressed VPs were on the todo list as well, to negate the size issue. DDS is highly compressible with BZ2, even the DXT formats. Decompression overhead is an issue for streaming in that case, but some rudimentary read-ahead support could be added to help reduce that.
-
So why invent a new container?
There are so many container formats out there that it seems crazy to re-invent the wheel yet again.
Surely it is far more useful to pick a reasonably good, pre-existing container and use that.
I have noticed a tendency in almost all open-source projects to invent new formats 'just for the sake of it'.
Heck, OGG would work, and we already use that for audio.
- OGG is indeed 'just a series of boxes', and it's already specified that it should work with video as well as audio, and maintains very good separation between codec and container.
-
Managed to get ANIs to stream, now to figure out the rendering and the fixing up therof...
EDIT: About to post patch/builds for testing.