Yeah, I was going to mention the amount of time it took too. I was running the test late in the afternoon and had quite a few other programs running, also the computer came with McCrappy Anti-Virus installed so I'm sure that might be slowing it down a bit. :-) Next time I reboot I'll try and run the program and see if it runs any faster.
-This is prone to crashing. I'm doing something wrong with memory, I'll fix it soon.
-There's a variable called PARTIAL_LOAD_VARIABLE in terrainmanager.inc, lower that if it's lagging horribly.
-Occasional beeps when more than one section is reset at a time (I'll explain a bit later), these usually lead to a crash. I'm not sure why it beeps... Seriously, why a beep? Why not just fall over quietly like any other program?...
-There is no level of detail, and the larger the terrain size, the more polygons you're gonna be rendering (64*64*2 triangles per section). The LoD shouldn't be too difficult to add on.
-So, as you may notice immediately, the lighting looks horrible. Sorry about that. Also, notable artifacts that look like banding when viewed from a distance.
Alright! After some time of fiddling with what works, what doesn't, what looks good, what's not worth bothering with, I've finally gotten a framework for some kind of engine that generates terrain as far as your computer can support it.
I know, I know, it's been done before (But not in B4GL )
Jumping right in: Each section is loaded in real time by only going through parts of the generation iteration at a time (the PARTIAL_LOAD_VARIABLE thing), rather than all at once which would just stutter all over the place. I'll try and make this dynamic in real time based on some fixed FPS value (So the generation properly matches hardware).
The terrain is generated starting with the chunks closest to the camera and loaded out. So, if you're not going too fast, there should always be terrain under the camera (unless you're running this on a toaster). The terrain is kept in an array (which you can easily change the size of btw).
When the camera enters a new section, the cells in the array are pushed back by one and the "new" cells are re-loaded. The code has a somewhat better description. But, when this happens multiple times successively, the program crashes, probably due to trying to delete empty memory. Or perhaps trying to access memory that doesn't exist. That will probably need to be fixed before going on. But this allows for seemingly "infinite" terrain.
There's a lot of variables throughout the code that can be changed (most of them as const's) that may or may not change/break the code. Most notable are the ones in "InitPerlinNoise()" and GLOBAL_SEED.
If you want to just see what's happening overall, comment out "UpdateTerrainManager(Terrain, vec2(Cam.Pos(0),Cam.Pos(2)))" in the main file (line 98), and maybe bump up the MAX_VIEW_DISTANCE variable.
Any feedback is appreciated. Especially those concerning shaders not compiling or "wow, this is like watching a slide show", etc.
~Happy Coding ;D
Last Edit: Nov 17, 2013 23:25:58 GMT -5 by shadow008
Warning: boredom may result in armed robbery, kidnapping, reckless endangerment of others, aggravated assault of a police officer, felony fleeing apprehension, and damage to property.
We should take bikini bottom, and push it somewhere else! <(O.O<) <(O.O)> (>O.O)>
' ok so I'm lazy... compression and more info can be found here http://www.fileformat.info/format/bmp/egff.htm#MICBMP-DMYID.2
Holy crud, where was this site a few years ago when I was trying to make my picture editor in Basic4GL. And here I was going about things like an insane person and had basic4GL load different bmp's and tga's and print all the byte values so I could note the differences and such until I actually figured out how to load them somewhat properly....
Moral of the story, documentation makes life simpler, but reinventing the wheel makes it a whole lot more interesting - or something like that anyways