Procedural terrain engine.

User projects written in or related to FreeBASIC.
Posts: 11
Joined: Nov 26, 2013 2:43

Procedural terrain engine.

Postby shadow008 » Apr 29, 2014 0:33

Hey everyone, first post. Let's be friends. Ok? Awesome, thanks.

Now that that's over: ...

So I've been working on this for a while now as a nice little project. As the name implies, it's just a procedural terrain engine. I had originally started this project in Basic4GL back in the day, but ported it to FB for it's speed.

Features are really limited at the moment, though is far from the first stable build.

But I can guarantee you there will people who can not run this.

It requires about 300MB free ram AND at least a 512MB GFX card with opengl 3.0 support just to run. And Windows OS (though I see no reason a linux compile wouldn't be possible)

Windows task manager has also informed me that there is a minor memory leak. (Nothing to worry about on your end, unless you're using XP). It also sometimes crashes on closeout.

So test play with it as you see fit. There are bugs, yes, but there's also awesome potential!

Standard WASD + Mouse movement
'Shift' for "running speed" (This should give you an idea of the scope of the terrain)
'Space' for actually visible movement speeds (220 times standard speed to be exact)
'P' resets the terrain. Useful sometimes.
'ESC' to exit.
Left mouse sets wireframe mode.
Right mouse sets primitive directional lighting.

Tell me what you think. I can go into details about things, just drop a question.

And please, don't look at the source code directly: Use thick glasses to mask the horrible coding practices.

Posts: 2655
Joined: Aug 28, 2008 10:54
Location: new york

Re: Procedural terrain engine.

Postby rolliebollocks » Apr 29, 2014 16:47

Trippy. I would get rid of the console log, it slows down your program quite a bit. But I tested it on a4 quad core which I use to program on solely because it is crappy and it worked ok. Looks good!
Posts: 8116
Joined: May 28, 2005 3:28

Re: Procedural terrain engine.

Postby D.J.Peters » Apr 29, 2014 23:32

Hello shadow,
don't use "END" in your main code.
If you call the end command some destructors are never called.
Linux filesystem is case sensitive so #include "" and #include "" isn't the same.
The vertex shader does not compile here (OpenGL 3.1) where is your OpenGL 3.x profile init code ?

Posts: 9800
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Procedural terrain engine.

Postby fxm » Apr 30, 2014 10:58

When instruction 'End' (or 'System') is executed, the remaining opened scopes are not closed (at least the main scope).
Thus, the destructors of the static objects in the unclosed scopes will not be called.
Posts: 11
Joined: Nov 26, 2013 2:43

Re: Procedural terrain engine.

Postby shadow008 » Apr 30, 2014 22:00

rollie: Concerning the console log, I didn't notice any lag on this end, but I can see why it could cause some.

D.J.Peters: I just assumed that because it's a Basic dialect, you throw END at the "end" and everything works out fine... That's logical, right? (lol) As for the linux file system part, I've never even tried to compile this on linux, or anything outside windows 7 for that matter, but case sensitive things aren't much of a problem. And the OpenGL init code is simply the glScreen() init followed by the OpenGL function wrangling in "", which was ripped straight from your code : )

But if the problem is the vertex shader not compiling, that's an issue with graphics card compatibility. I've only ever compiled/ran this code on AMD cards (and intel integrated), so are you perhaps using an Nvidia card? Specifically, which file is it saying isn't compiling? I just noticed it says "vertex shader error" regardless of whether it's the vertex or fragment shader, so I'll go fix that. I can throw a few bare-bone test shaders your way and see if they compile. I mean, I have heard that Nvidia is a lot more picky about shader syntax so that might be a bit tricky.

Also, I don't think I even have properly written destructors for... well... anything but the class (are they called classes in FB?).

And on a quick note, does the Delete() function delete all members of a pointer? By that I mean, if I have something like:

Code: Select all

dim thing as integer ptr ptr
for i = 0 to count
    thing = New integer ptr[5]
    for j = 0 to 5
         thing[i] = new integer[10]


Would that go through and delete all allocated memory? Or do I have to do this the C style way? Because I had something like this in my code, and it didn't seem to be a problem, but it could have been the reason for crashing on shutdown.
Posts: 1038
Joined: May 28, 2007 1:52

Re: Procedural terrain engine.

Postby Merick » Apr 30, 2014 22:46

You need to use delete on every element that you used new on - and in reverse order with nested arrays like your example. Additionally, there are two versions of the function: delete and delete[]

delete by itself is for freeing a single element ptr, delete[] is for freeing a ptr array.

For example:

dim as integer ptr A = new integer
delete A

dim as integer ptr B = new integer[10]
delete[] B
Posts: 493
Joined: Jun 16, 2007 2:00
Location: Australia

Re: Procedural terrain engine.

Postby pestery » May 01, 2014 4:16

Look good, all be it a little... trippy... as rolliebollocks said. Although it didn't run for me at first. I found a couple bugs in 3 files that I had to fix before it would run. The changes I made are listed below. I may have fixed the error checking in the file for you.

Also, it seemed to either exit suddenly after moving a little, or crash, not sure which. There was an assert failure which said "InfiniteTerrain\ assertion failed at INITVAO: HM.VBO(0) =0".

Code: Select all

' Changes to
' compile vertex shader
If VS Then
   glGetShaderiv(hVertex, GL_COMPILE_STATUS, @status)
   If status=GL_FALSE Then
      glGetShaderiv(hVertex, GL_INFO_LOG_LENGTH, @status)
      pInfo = Callocate(status + 1)
      glGetShaderInfoLog(hVertex, status, 0, pInfo)
      dprint("Shader " & VertexPath)
      dprint("compile error: vertex shader")
      dprint("Shader error: " & *pInfo) ' Changed from pInfo to *pInfo
      Sleep 2000:End

' compile frag shader
If FS Then
   glGetShaderiv(hFragment, GL_COMPILE_STATUS, @status2)
   If status2=GL_FALSE Then
      glGetShaderiv(hFragment, GL_INFO_LOG_LENGTH, @status2)
      pInfo = Callocate(status2 + 1) ' Changed status to status2
      glGetShaderInfoLog(hFragment, status2, 0, pInfo) ' Changed status to status2
      dprint("Shader " & FragmentPath)
      dprint("compile error: fragment shader") ' Changed vertex to fragment
      dprint("Shader error: " & *pInfo) ' Changed from pInfo to *pInfo
      Sleep 2000:End

Code: Select all

// Changes to DiffuseVert.txt
void main()
   out_color = in_color;
   vec3 position = in_position; // Added this line

   if(in_offset.y > 0.0){
      if(abs(in_position.x - in_offset.x) < 3328 &&
         abs(in_position.z - in_offset.z) < 3328){
         position.y -= 500; // Changed in_position to position

   gl_Position = projMatrix * viewMatrix * vec4(position, 1.0); // Changed in_position to position

Code: Select all

// Changes to DirectionalLightFrag.txt
void main()
   float diffuse = max(0.0, dot(normalize(out_color), -normalize(vec3(-1,-1,.25)))); // Changed this line
   //fragColor = vec4(out_color * vec3(1,1,.8) * (.25+diffuse),1);
   fragColor = vec4(vec3(1,1,.8) * (.25+diffuse),1);

Return to “Projects”

Who is online

Users browsing this forum: No registered users and 4 guests