I decided to get back to work on my (extremely long running development, "duke nukem forever" style :lol: ) jungle game, after 7 months gap. As is always the nature of returning to something after a long gap, I found myself trying to remember how the thing worked (this normally takes a while to get back into the codebase). With fresh eyes I realised that the codebase had accumulated a lot of mess from the various major changes, and decided it was time for a rewrite, using the old code as a reference. I should be able to just copy paste some bits in, like the sound, scripting and text etc.
I have mixed feelings about rewrites. While refactoring things is often a great idea, there are schools of thought that rewrites can be bad because you neglect all the testing and bug fixing that has gone into the original. But there are lots of benefits when you want to make major changes. :)
The main major change I wanted to make (aside from simplifying how the codebase worked) was to go back to a scrolling engine. Let me explain, when I first began, I used a scrolling totally 2d engine.
Then for various reasons I decided to go 3d, and it seemed easier to limit the map to a certain size (say 2048x2048) so everything could be pre-rendered on level load.
This worked, but I became dissatisfied because the resolutions of mobile devices (I'm targetting android, perhaps iOS) was higher than I had originally envisaged, and the maps weren't big enough for high res devices. Once I started raising the map sizes, the memory use because prohibitive for small phones (storing pre rendered colour, depth buffer, shadow buffer etc). :o
So I wanted to have a go at going back to a scrolling engine, but this time with the 3d 45 degree view I had moved to.
Anyway here is some indication of how far I've got. The main rewriting of the actual game code was fun, because it was nice and simple and I had a much clearer idea of what I wanted it to do than when I wrote the first versions. The scrolling graphics engine I knew would be the biggest hurdle.
With scrolling techniques, the idea is essentially to draw the borders of the map as you move onto them, rather than drawing the whole screen window on each frame. While modern PCs are pretty powerful, mobile phones don't always have heaps of horsepower and I like to minimize the CPU where possible to save on battery use. :D
My terrain is as before split into 128x128 tiles, at a 45 degree view angle (this view angle is fairly easy to change, but it seems a good standard). My first thoughts were to render the terrain directly into the scroll 'window' texture with texturing applied. However this resulted in all kinds of aliasing nastiness, so it was clear for best results I would need to have not 1, but 2 scrolling systems, 1 for the terrain texture, and 1 for the terrain + models.
I'd ideally like to get rid of the billboarded trees, but I haven't managed to get 3d tree models to look as good as yet, so they may well return, perhaps with a depth (and even a normal map?) channel. Of course that will limit the viewing perspective, but so does using a scrolling engine. Although I may have a separate indoor perspective for the planned 'nude mud wrestling' scenes.
Progress so far
So far I've just been working on the terrain texture scrolling, the terrain itself (with no elevation as yet) is just drawn in full, that will be the next stage.
Here you can see it in action. Aside from not having done the initial filling, it seems to be working bug free. It is a little bit fiddley to calculate the amount of border tiles to use to avoid 'flipping' happening on the game screen, but it seems to be working now.
Here I have reduced the scroll window size so you can see the flipping / redraw happening as you move through the map:
I might try and get it to redraw sub sections of the tiles to avoid spikes in CPU (a call to glViewport may be all that is required). Next I'll see if I can get the terrain itself rendering with a scrolling system. That is all so far! I'll try and do updates as I add back in the features. :)