I assume youāre applying this same region logic to entity updatesā¦ updating everything in the current region every cycle, then queuing things in neighbouring regions according to some priority so they can still go about their business, but not hog all the processor time as things scale?
Thatād be about all I could suggest.
Iāve played around with stuff like this when I was developing a QuadTree. Itās fun to have an infinite world Nice work!
If its CPU related performance yourāe trying to gain, then selective updating can gain you quite a bit, meaning that you only updated things if you know that they have changed. Easy to overlook in your attempt to just get things going.
QuadTreeās are also really nice for things like these.
GPU wise you could looks at mip maps of just having low and hi res images and selecting between them as you zoom in and out, may save you some bandwidth, great for low bandwidth GPUs.
Something a little more crazy would be to render a chunk to RenderTarget2D and only then call that to render that chunk as a texture during your spriteBatch.Draw(āstuffā);. It will probably only be feasible for parts that donāt change like the actual terrain. Or if itās smart, it only updates the region RenderTarget2D if something in that region changed or moved.
This can gain you CPU and GPU time as you waste less time telling the GPU what to do, obviously depends on implementation and exact scenario.
Do you also have tips on improving encoding data to a disk?
Thatās the main problem I think. I encode the data to a binary file and each region of 16 x 16 tiles is 3kB at the moment. Not a problem, but thereās a small freeze when loading in many new regions (15+) on a big resolutions and a small scale.
Maybe using multithreading and placing the region loading on a separate thread?
Multi-threading would help with the freeze upās as slow encoding should not hamper the game itself. Loads of pitfalls in multi-threading and Iām the wrong person to ask for help with that madness.
Not sure how you are encoding to your binary file? But Iām assuming your writing to it every few seconds as the world moves? Some times itās a game of RAM vs HDD. If you can build up a bit more data in some kind of String Builder before writing to HDD you may reduce the read write thrashing. And yes, Iām assuming you are writing but also possible reading from that same file āat the same timeā, or at least shortly after in some cases. But less writing or less chunky writing(encoding). Remember the read/write head can only do one thing at a time, and an SSD is faster but simulates the same thing as far as I know.
I will probably keep the current state of the generator, and improve further upon it in the future. It works decent I think. The project that will be using it, isnāt going to render that much tiles at the same moment.
At this moment Iām encoding each region that goes off the screen individually to a different file. I load that data when the camera moves back to the same region.
Oh, I see.
Thatās a ton of little filesā¦ 3kb you said? Each with their own name and file header etc.
If you can work out any way to write more regions in to a single file, or have larger regions per file that could gain you loads of speed. RAM > HDD any day of the week even if the HDD works overtime and weekends. Unless your developing for mobile or computers from the 90ās ram should not be a problem for a few 1000 low data size objects especially not if you use TextureIDās.
Other than your probably right, some times you just have to come back to something when its an actual problem for your program
It was not the encoding that was the problem, it was the generation code for a region.
The infinite world runs very smooth without a generator. I will improve the region generation in the future.
Yeah itās the simplest method at the moment. I like how it came out!
Also added some color codes, for example: T;re;bst will write āTestā with a black āTā, red āeā and blue āstā.
If you were drawing signed-distance field text you could use a 1d LUT texture to do the same thing (gradient ramp basically), though itāll be even more bubbly than what youāve got. What youāre doing is probably faster though (bare-bones shader), and it works.
While reading up on optimizations, I came across a few things that may be of interest to you or others reading this question:
Jagged Arrays, Iām assuming that you store your train data in 2D arrays or something.
Also look in to using Structs instead of Class for data objects when appropriate, it can gain you quite a bit of speed, even more so when the iteration list is very large. It is important to understand when to use them as they can hurt performance if used incorrectly.
Thanks for your reply @egodamonra! Iāll definitely look into structs.
Just one quick question: How would using a jagged array improve performance over a 2D array in this situation?