the ancient stuttering problem

[chuck_starchaser]

Asynchronous file i/o under .NET:
http://msdn2.microsoft.com/en-us/library/kztecsys.aspx

Isn't there some cross-platform "afiolib" somewhere?

[safemode]

src/gfx/vsimage.cpp line 105
CheckFormat()

We need to give this function the ability to recognize dds as valid: Done

Line 108

Insert a case for dds. :Done


line 109, create a function ReadDDS to pass the dds data to GL. :Not done



That's all there is to loading a texture (i also made a fix so that .dds files are recognized as valid in python) I'm not sure if that's all there is to playing with it. The read function does a lot of playing around with all sorts of image characteristics. I'm not sure we need to do any of that with dds files.

It'd be really cool if someone could write the readDDS function in vsimage.cpp so we can start working with dds files and compressed textures.

[safemode]

Of course the gimp dds plugin (which i'm using to create the dds files) has all the code apparently necessary to read and write dds files. I just am not familiar enough with the graphics aspects to know what's needed for Vs and what's not.

in addition to the gimp plugin, i found this for java...which can probably be ported over to C++ without much effort for those who are familiar with the vs graphics code

http://www.chriscohnen.de/cg/tutorials/ ... torial.htm

[ace123]

Seems like a better way would be to do what the audio library does.

Basically, it creates a helper thread on initialization. Then, whenever it wants to load a new file, it asks the thread to get a file.

Then, synchronously with the Vegastrike main_loop, the Music function will check if the file is finished loading, then copy it over, reset the musicLoader thread, and play it with openAL.

The similar thing can be done with textures:
Read/Parse the file asynchronously, then copy it back and give it to OpenGL.

Now, the problem would be that the texture would show up as white/undefined while the texture reference has not yet been defined.

This method would be much cleaner than asynchronous file I/O. And what do you gain from using OS-specific functionality like that? You still have to parse the texture in the main thread.

The asynchronous loader could possibly be extended for meshes (though this would be best implemented starting with the OGRE port because of the amount of work.)

Python and other stuff would be much harder to do asynchronously. The nice thing about reading and parsing file formats is that it is independent from running Engine code until you get to the raw data.

[safemode]

OK, but that doesn't negate the need for dds.

If we thread texture loading we still need something to execute in the mean time to make the thread save any time. We have to hand over GL to the thread i thought to get it to work, which wouldn't that cause GL to block ?

I'd really like to get dds reader/writer in vs and having it able to use dds files to render textures first. Then work on threading/async io on file input/output. It may turn out that it's unnecessary.

[chuck_starchaser]

Ace, that's a great idea.

Now, the problem would be that the texture would show up as white/undefined while the texture reference has not yet been defined.

Unless the same thread uploads textures AND mesthes.

The asynchronous loader could possibly be extended for meshes (though this would be best implemented starting with the OGRE port because of the amount of work.)

No amount of work at all, the way I look at it: Just a matter of separating out the unit creation parts of the code that deal with open_gl, put them into a routine, then, instead of calling it, going,

Code: Select all

    using boost;
    thread thrd( &final_gl_stuff( args ) );
    thrd.join(); 

@safemode: I'll look into that java thing tonight after work. (I shouldn't go to work really; I'm sick as a dog...)
EDIT:
This question may be the product of a fevered brain, but... Why do we need to "read" dds, again? Isn't there a gl function already that reads dds? I'd be very surprised if there isn't...
EDIT2:
http://oss.sgi.com/projects/ogl-sample/ ... ession.txt
EDIT3:
http://tgtl.sourceforge.net/

[safemode]

I'm not saying we need to process it, but we need to add those GL functions inline with how we load other textures so that we know they're loaded ... just like we know the others are loaded. I'm thinking a passthrough function that doesnt really do anything to the contents of the file, just loads it in our texture cache memory and offloads it onto GL functions. We cant just bypass everything for dds and go directly to GL. API's must be enforced and perhaps improved, especially in areas like this where many inputs become the same output for use in game.

[chuck_starchaser]

Sure; what I was saying is that the gl functions for loading dds already exist. They are part of that "texture compression ARB" thing. I can try and find the specific function for you, but I'm feeling really bad: feverish, splitting headache, my eyes feel like they are about to explode. Went to get aspirin and Neo Citran an hour ago, and forgot to take them... I'll see how it goes, but I might jump back into bed.

EDIT:
What we might need code for is to write dds, if we want the engine to automatically create dds version of textures in other formats.
When we read a bfxm file, the engine could check, for any textures named in it, whether a .dds version exists. If it doesn't, it could load the texture in its expicit format and write a dds version for future use.

[safemode]

http://www.codesampler.com/source/ogl_d ... loader.zip

Has a very good example of the code needed to load a dds file and such things.

[chuck_starchaser]

Good. I'll take a look at it tomorrow.

[safemode]

I'm currently in the process of writing/porting (from the gimp plugin) the code to load dds files into vegastrike directly from the filesystem.

The goal of the initial code will be to uncompress a compressed dds file and load it as if it were loading a jpg or png file into vegastrike. 80% done.

Once that milestone is completed, we will provide a means to bypass that decompression and go directly into loading the texture to openGL.

Once that milestone is reached, we will create a method to write DDS files and create a means to allow the user to decide to cache generated DDS files to disk for future use given a quality setting that they're using.



The wildcards with DDS compression and it's use on filesystem is in the release installation package. Do we provide any dds files on filesystem? Do we simply allow a configuration directive to allow the user to generate the dds files if they wish? Do we provide dds files and jpg for the same texture ? etc etc. That is all to be worked out later.


Any other suggestions for reducing stutter time ? Perhaps any real python fixes ? The c++ aspect seems to be pretty fast. Is python just injecting way too many units into the system on load than it needs to? Could we figure out a better way to load the units in the background and have them come into view after we jump into a system or through the jumpgate after us? Could we create an animation of the process of jumping into a system to hide the system loading times? Some of these questions regard system loading only issues, some both individual loading some not.

I'd really like to hear what anyone who knows about the scheduling system has to say about the idea that the scheduling is getting botched up and that's why we see spurts of pauses throughout gameplay. That sounds awfully suspicious and would be prime for fixing without altering gameplay in a negative manner.

[chuck_starchaser]

The goal of the initial code will be to uncompress a compressed dds file and load it as if it were loading a jpg or png file into vegastrike. 80% done.

Okay, you're probably 100% done by now. I was going to say that, from your link, it would seem to me this function:
DDS_IMAGE_DATA* loadDDSTextureFile( const char *filename );
does that.

Once that milestone is completed, we will provide a means to bypass that decompression and go directly into loading the texture to openGL.

I think this function does that:
void loadCompressedTexture( void );

Any other suggestions for reducing stutter time ? Perhaps any real python fixes ? The c++ aspect seems to be pretty fast. Is python just injecting way too many units into the system on load than it needs to? Could we figure out a better way to load the units in the background and have them come into view after we jump into a system or through the jumpgate after us? Could we create an animation of the process of jumping into a system to hide the system loading times? Some of these questions regard system loading only issues, some both individual loading some not.

I think Python being a lot slower than compiled code, should be used only in small snippets that only execute once per frame or occasionally. Finding out what functions in python are called often, and turning them into compiled code would be one way to go. Chances are the AI is a prime culprit.

I'd really like to hear what anyone who knows about the scheduling system has to say about the idea that the scheduling is getting botched up and that's why we see spurts of pauses throughout gameplay. That sounds awfully suspicious and would be prime for fixing without altering gameplay in a negative manner.

Sorry I have no opinion on this; I don't even know what the "scheduler" is or does (it schedules, obviously, but what I don't know).
In fact, I never quite got my head around the main loop in the vs engine, hard as I tried to find where the code was.

[jackS]

I'd really like to hear what anyone who knows about the scheduling system has to say about the idea that the scheduling is getting botched up and that's why we see spurts of pauses throughout gameplay. That sounds awfully suspicious and would be prime for fixing without altering gameplay in a negative manner.

I'd put ship-simulation binning down under the category of fairly unlikely as primary cause. Having examined traces of length ~ few-thousand physics frames under a few different selected stress-test levels (how many 1000s of ships, friendly vs. combat, etc), I'd say the randomized scheduling algorithm performed well within expectations.

Common offenders for overrunning desirable time in a given frame tended to be AI routines. Anything involving disk loading (i.e. uncached textures/models) clearly can cause very noticeable stalls (being on the order of time of human perception just for the disk part). The occasional interspersed frame from lo-fi-simulating a neighboring system can lead to some additional unevenness, but I'd have to see some more data on that to have anything concrete to conclude about it.

[safemode]

just wanted to make a little update on the dds reading. That last 20% is a real pain. I may just be hitting upon a problem with gl contexts. I use hardware routines to decompess the texture i loaded (temp for debugging purposes) and it's segfaulting either after or in executing that function. I need to do more testing to see if perhaps i'm running into a problem because the texture I'm testing with is a unit texture which is cubic i believe. The loading and all that is good though. Just hitting a little wall on the decompression. The texture images are 1024x1024, so maybe that has something to do with it too. Not sure yet.

I should have this done over the course of the week (not a lot of free time) , and a commit to my branch by the weekend for those wanting to test it out.

[chuck_starchaser]

I'd suggest to avoid an esoteric cube map or 3d texture for initial testing. Just take, say, the llama skin, or whatever ship you happen to have, diffuse and specular, nice and square and power of two size, make them into dds's with the gimp dds plugin, and get that to load first. Not sure what you mean by hardware routines. As for decompression, I'm not sure why your plan is to first get decompression to work; it would seem to me that's one function you'll never need. Just getting dds's to load straight to the videocard is what I'd think to come first, like with the void loadCompressedTexture( void ) function. And after that it would be to get compression on the fly to work, rather than de-compression. Or is that for compatibility with gpu's that aren't compressionARB extension capable?

[Halleck]

Note: Don't use the llama texture. It's split into three main submeshes with a seperate diffuse texture for each.

Much easier to use a Dostoevsky.

[safemode]

I am using a star texture. Should be easy. I am decompressing them for debugging purposes only. Right now the api doesnt allow directly loading textures to GL from the disk. I convert to raw image as if it was a jpg being loaded and VS does it's thing none the wiser that it came from a dds file. When that works, we can work out how it will bypass all that.

Right now I am using hardware routines to decompress. This isn't working for some reason. So now i'll have to implement the much more complicated software routines that dont use GL.

Tomorrow or so I'll commit to my branch the dds code as it is now (broken) and see if anyone can spot an obvious oops in the code. It segfaults inside the gl function.

[safemode]

I just want to make this clear. We are going to have a sw decompressor, and a hardware _passthrough_ in the final version. This is because we plan on shipping VS with some files in dds only, so older cards not supporting compressed textures will still be able to load those dds textures. The compressor will only be hardware, because only people able to use hardware compression will want/(be able) to generate a cache of dds files to use in subsequent runs of VS.


The GL routine that is crashing however, is the same one that would be used in the hardware passthrough, so it is still important to determine why, even though we wont be doing _hardware_ decompression of dds files.

[chuck_starchaser]

I doubt the ogl function would be buggy. If it crashes it means the input to it is borked; without seeing the code, I say I'd put a few asserts before it.

[safemode]

yea, i realize it's my fault the gl function is crashing, I just dont know if it's my input, or some initialization or context issue that could be causing it to also crash. Hence why the software decompressor is necessary. :-/.

I'm going to probably commit my changes, despite their being broken in my branch today or tomorrow .

[safemode]

I just committed a beta dds loading routine in my safemode branch and head. It uses hardware decompression to decompress the texture to a raw format that VS uses to re-load the texture further down the pipeline. Eventually we will have a pass-through, but for now this will be used to test the loading routines (especially when i implement the software decompresser)


Currently, what you can do to test it out is use the gimp dds plugin,

1. open a texture file and save it as a dds file under one of the three DXT compression routines. Don't use the ATI ones. Don't save it with mipmaps. I currently dont bother implementing mipmap handling but will eventually.

2. Once you save the dds file, rename it to the original filename you used so that VS bothers looking for it. The texture should be loaded just as if it was any other file format.


You will definitely not see much if any improvement or slowdown from using dds files with this routine.

This routine uses hardware GL functions to decompress the texture, i'm not sure if gl will fallback on software on it's own (i doubt it) so if you dont have hardware that supports hardware texture compression, dont bother playing with dds files, especially not until i get software routines setup.


I've tested this routine with dds files created with the gimp plugin only. I've only really tested it with RGB source textures and saving it without mipmaps. It will work just fine on unit textures, planet textures etc etc. Just open, save as dds, select one of the three routines and no mipmaps and you should be golden.


Next is the passthrough code. Once that is working, I will start on the software decompresser. At that point, we can start replacing textures on the filesystem with dds files.

The next step after that is deciding how to determine which textures will be shipped as dds files, how to cache dds files so that compression of those textures not shipped as dds doesn't occur each time they're loaded (user options etc) ...all that fun stuff.

[safemode]

Passthrough code is hitting a small road block. Can't seem to get the texture to load in and operate correctly. I probably have to add a variable to VSImage to indicate it's already compressed, litle boolean job and set the values as if it was uncompressed for the attributes in vsImage. Then see if that does it.

The other idea as to why it's not working could be mipmaps. I currently dont do anything with mipmaps in dds files, and the gl_texture code wants to generate mipmaps using the buffer data. I dont think the gl mipmap generating function can handle doing that from compressed textures.

So either I'm missing some code somewhere that's messing up the buffer so that by the time i call the function to load the texture it's not correct, or my lack of mipmaps is causing it to not get drawn correctly.

[chuck_starchaser]

Congratulations!
Pure speculation here, but there's a chance dds files are meant to have mipmaps in them, if only from the point of view that, otherwise, the driver would have to decompress them, generate the mipmaps, and then recompress the mipmaps. Makes no sense, politically, I'd say. So probably there is no facilities built into the driver to generate mipmaps for dds, so you have to supply them. /Pure speculation.

[safemode]

in order to get vsimage to transmit the information about mipmaps, I had to create a new variable in vsImage that aux_texture's Texture class could use to send to gl_texture for GFXTransferTexture ..

So, in order to send that variable without rewriting the function in gl_texture (and thus breaking the api and having to edit all calls) I utilized the unecessary argument, maxdimension. Since we know that the dds file HAS to be within GL's max dimension for a texture (since it already processed it) I'm using that argument to pass the number of mipmaps.

So, now we can read in mipmaps and send them to gl_texture.

And guess what peoples. We can now load dds files (when they are created with mipmaps) directly to GL. WOOT!

I'll be making a commit to my local branch. NOT SVN HEAD, that supports this. Currently, I dont support endianess so it will only work on x86, and i dont support people trying to use dds files but can't use them in hardware.

When i get endianess in, I'll commit to svn head. When i get the software decoding of compressed dds files in, we will be ready to convert over images to dds files in our releases.


For now, using the gimp dds plugin. All you need to do is open a texture (2D types ..which is most/if not all of them) and save it as a dds file using one of the 3 compression types and check the box for generating mipmaps.
Once the file is saved, move that file to the name of the original file you opened. So if you opened llama_body.jpg and saved the file as llama_body.dds, you will mv llama_body.dds llama_body.jpg

That's it. All you need is hardware compression support and an x86 box to test this code out in my branch.

Just make sure if you're developing on the data4.x dir in svn, you dont commit changes to those image files

[safemode]

OH, another important note. I'm not sure of where to put the code in gl_init so that it's all nice and happy with apple and intel. So i just put them outside of the ifdef's for now.

I also noted on line 190 of the un-modified gl_init.cpp has a bug, or it looks awfully like a bug.

#ifdef __APPLE__
#ifndef __APPLE__


that second conditional will never be true.

Anyways, i'm waiting for input from some of the higher ups as to where that code should go prior to syncing to svn head.