I've been looking into fractal terrain generation lately, as I'm currently working on a Minecraft clone and want to have a good randomized, realistic terrain. Well, I ended up porting an old C++ Perlin Noise routine into GLBasic, then adding a GUI wrapper to control its output.
At the moment, it only draws and exports 2D representations of terrains, but I will soon add in 3D viewing/exporting.
(http://www.sblectric.com/img/tgen01.png)
(http://www.sblectric.com/img/tgen02.png)
New 1.2 release on 7/29!
Download it here: http://sblectric.com/downloads/TerrainGen-v1.2.zip (http://sblectric.com/downloads/TerrainGen-v1.2.zip)
C++ and GLBasic code included for the actual algorithm.
Looking great!
If you're interested, here's a thread discussing voxel style graphics, and algorithms to only add exposed quad faces of a random voxel grouping. Later perlin noise (simple implementation) is added to make it appear more Minecraft like.
http://www.glbasic.com/forum/index.php?topic=9499.0 (http://www.glbasic.com/forum/index.php?topic=9499.0)
Seems to work fast enough for small worlds (128x128). Some more optimization would be needed for larger worlds maybe. It does implement a chunking system, by breaking the world into predetermined size chunks (8x8x8 for example). This concept speeds up the calculation, plus updating a voxel is much quicker.
Keep us posted on your progress, looks promising. :good:
Nice and interesting program, thanks for the code always it's good learning C++ for GLbasic , thanks.
Very nice!
Looking forward to 3D version
Great stuff and just what I was looking for my flat 3D environment and catchup on a bit of inlining. :enc:
It's working really great on my Minecraft clone. Looks good so far! Here's a video of its current status (terrain, physics (still buggy), block placement, walking, etc.)
https://drive.google.com/file/d/0B2Ez6zqWxZAZVWpyMjRKZEhtZWM/edit?usp=sharing (https://drive.google.com/file/d/0B2Ez6zqWxZAZVWpyMjRKZEhtZWM/edit?usp=sharing)
Hey! =D You know I (https://www.youtube.com/watch?v=9Xw9Bn1eK5I) like that. How about some more distance views? :whistle:
Here's a good one:
(http://www.sblectric.com/minecraft/ripoffcraft/largeviewdistance.png)
Nice =D =D =D
I agree, very nice!
Are you telling me this is running at 936 FPS?
What size world is this? 256x64x256?
What's next? Add/destroy a block? Water? Can't wait.
It's more like 500-800 now that I added placement, and I achieve this by grouping all the blocks in a chunk into a single object, so instead of ~300 draw calls per chunk like I was getting before, it's now only 1 per chunk.
Here's a video:
Yep, world size is 16x16 chunks, or 256x256x256.
You code this in GLBasic?
Impressive...!
Did you use VBO or Immediate Mode?
Indeed, really neat. :good:
:nw: :nw: :nw: guapísimo, How many polys you can move?¿, really this it's very good, and the Editor, I love the simple UI....
Super!!!
I guess technically it's VBO mode, as I'm loading all of the chunks' vertices and data into memory at startup/chunk update. As for the amount of polygons, it renders two per block face (pretty standard, I don't have poly grouping or anything fancy), and only renders the block faces it calculates to be visible (colliding with an air block).
nice, me wonders if you can stress test the amount...would also be lovely to see explosions ;/
In the OG Minecraft, the lag increase with view distance settings. This main concern discussed earlier, and me also wonders, is about rendering chunks in the far distance and whether they need to be delay drawn or down-rendered like how lower res texture maps are uses for objects far away.
Seems to be running quite smoothly even with 16-chunk render distance atm. Of course, I haven't added in all the goodies like mobs and crafting/cooking/brewing/etc.
Can you make a techdemo to try it out?
would love to try that tech demo too! :good:
I will when I fix the physics and add a bit of threading to chunk updates, as they freeze the game for a quarter-second maybe each time you place a block.
Quote from: SBlectric on 2014-Jul-19
I will when I fix the physics and add a bit of threading to chunk updates, as they freeze the game for a quarter-second maybe each time you place a block.
Hmm. That problem would also extend to other things that change blocks like water, lava and explosions I guess. Hope you find a nice solution!
thanks!
Its looking very nice!
Sounds a bit like youre using native GLBasic X_OBJ... commands to create youre chunks? If you do so, X_OBJ... is a bit to slow to use it at runtime, you may consider using native OpenGL instead. That would be way faster, but you could not use GLBasics shadow system.
GLBasic use OpenGL 1.1 right?
There is no VBO ( comes with OpenGL 1.5, imho ) to speed this thing up( you have still a nice FPS-Count !)...
Maybe you have to look into Gernots threading post here:
http://www.glbasic.com/forum/index.php?topic=3642.0
Although I like to keep it pure GLBasic, this has really become a back-end engine issue again. So let's consider detailing switching techniques! To calculate, store and render less faces for distance chuck objects, where a chuck group of blocks are reduces to one block because seen at from afar. A general example, and would apply a normal game, by switching to lower res meshes and textures. :S
I think I'm going to wait until I have a bunch more features before I optimize the graphics to use VBO. Though it would help chunk updates and loading times a bit. As of right now I'm getting a solid 800FPS with just native stuff. 8)
Are the explosions and massive block destructions in yet? ;)
Quote from: Schranz0r on 2014-Jul-20GLBasic use OpenGL 1.1 right?
There is no VBO ( comes with OpenGL 1.5, imho ) to speed this thing up( you have still a nice FPS-Count !)...
No this is not correct, on mobile GLES you need to decide if you want to use 1.1 or 2.0 and GLBasic has locked us at 1.1. But on desktop OpenGL you can always use all versions that are supported by the hardware/drivers. Its just that 1.1 OpenGL commands are easier to load/use than higher version ones (thats general on windows, no GLBasic special) and Gernots wrapper gives us only the 1.1 function - but if you need other ones, you can simply load them by yourself. So you should be able to use VBO, but ive not tested this yet.
BTW I dont think you would need to use VBOs - simple glDrawArrays is way faster than X_OBJ...+X_DRAWOBJ - and its really easy to do this.
ah ok, thx for the Info!
But VBO's are much faster then immediate mode....
::) I tried to create a project with the library files but have errors. I am using the forum headerpack but still get compile errors. SBlectric, could you kindly make a project with the included header files! Is there updated headers I should be using? :whistle:
I actually came up with a fix for that already. Just replace the inline code after the global declarations with this:
INLINE
typedef int time_t;
ENDINLINE
IMPORT "C" int time(void* timer);
IMPORT "C" void srand(unsigned int seed);
IMPORT "C" int rand();
I'll update the code on my website to include this new stuff soon. However, I still can't seem to get it working on Android, as it crashes on open.
I updated the download link to v1.2, released today.
New in v1.2:
- changed library dependencies
- Save as binary file (could be useful as a raw import)
Binary file format:
*.bin or any file extension
File Header: TGBIN followed by newline
Header packet: TGH followed by width UWORD and height UWORD
File packet: TGF followed by newline, then the raw IEEE data stream of each pixel
Note that the IEEE data "pixels" range from 0.0 (lowest) to 1.0 (highest).
Download link: http://sblectric.com/downloads/TerrainGen-v1.2.zip (http://sblectric.com/downloads/TerrainGen-v1.2.zip)
Oh great that works and thank-you. If I change the palette to flat blue,green,red on the water, land and mountain then it's easy to directly import as a png. Perfect! =D The palette option should be in the application. ;)
preview()
FUNCTION preview:
LOCAL num, file$, map[], img%[], cl AS TG_MAPCOLORS
DIM map[256][256]
DIM img%[256][256]
file$ = PLATFORMINFO$("DOCUMENTS") + "/test.png"
TerrainGen(map[], img%[], cl, 256, 256, 0.65, 2.0, 16, file$, 0)
num = GENSPRITE()
LOADSPRITE file$, num
CLEARSCREEN
DRAWSPRITE num, 0, 0
SHOWSCREEN
MOUSEWAIT
ENDFUNCTION