It takes by far the longest time up in the rendering pipeline, but it’s ok visually if the ocean updates at a lower rate than the rest of the game.
So the generator performed at 9ms or so so my frametime was around 10 ms. But now that I don’t depend on that being finished any more i can run with 1 ms. Meanwhile the ocean updates at 100 Hz, so it’s basically not noticeable that it updates slower.
So what i do is
…
if(task.IsCompleted)
copyProcessedVerticesToVertexBuffer() //This must be thread safe, so the thread can not run!
startTheNewProcessing()
)
So startTheNewProcessing starts a Task on another thread in that example? Since you want the copy operation to happen on the main thread you can’t really have it be automatic. I don’t think there’s a better way to do it than what you do now.
In general it’s easy to load content async, but you want to watch out with threads using the graphicsdevice at the same time. I know there are a lot of locks on the d3ddevice in the GraphicsDevice.DirectX code, so it might be safe to do there, but I’m not sure if synchronization is 100% right. For OpenGL MonoGame currently only lets you create one context (this was different before the switch to SDL). I think some people used a second context to load resources on a seperate thread.
This was like my home rolled gui in xna its kinda hard to see its a old video.
To be honest after all this time it’s not too much better it still looks and feels worse then ever to me. Its just something i stink at really bad gui stuff.
The one really cool thing in that video is the underlying class that holds the map i actually squashed 10 layers of data into each int. using a compressed contiguous bit array class I made before bitarray was a thing in c#. It actually runs right out of the bit array. which could be huge like almost 2 gigs on some of the maps i made.
Interesting, so the data on the map correlates with game functionality right? such as can build something here and this is ocean for a ship type thing?
ya see all the bit data on the bottom left that’s actually expanded just to see it. that’s per tile but the bits are all packed right next to each other as if they are mini data types. So like if i had only 12 possible different sprites for a layer of a single hex thats 1 + 2 + 4 + 8 4 bits which can handle 0 to 15 so it could do nibbles as types 2 bit types 10 20 whatever or even bools as actual 1 bit bools and it would pack them all right next to each other across a entire byte array.
So like it would be really compressed without even zipping it. In fact zipping it all really didn’t do much. I could dig the old class up if you want to see it i don’t think ive used it for anything in years its like pure bit wise math bitshifts and or’s ands ect…
Unfortunately I lost my entire website last year from spammers injecting spam scripts into it.
I have used this same code in MonoGame without any issues. Loading content in a different thread is quite slow on OpenGL platforms due to the requirement to synchronize everything with the main thread. On DirectX it should work fine. I wrote that based on my work in XNA on Windows Phone 7, which was built on DirectX 11, and it was used in released games. XNA on PC was built on DirectX 9 which didn’t work with this method unfortunately.
Speaking of loading asynchronously, loading nearly a 2 gigabyte file while filling up the gpu’s texture memory oooo. The sum total benifit to a lot of hard work a bar that fills across the screen as you load everything slower then you would have.
Just get a picture up there that says loading.
I did it in a winforms app as well that did a lot of image processing just to do it.
That bar is really cool though.
,
,
,
,
,
,
