Procedural terrain engine.

User contributed sources that have become inactive, deprecated, or generally unusable. But ... we don't really want to throw them away either.
Post Reply
shadow008
Posts: 86
Joined: Nov 26, 2013 2:43

Procedural terrain engine.

Post by shadow008 »

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

Now that that's over:

https://dl.dropboxusercontent.com/u/531 ... errain.zip

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!

Controls:
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.

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

Re: Procedural terrain engine.

Post by rolliebollocks »

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!
D.J.Peters
Posts: 8586
Joined: May 28, 2005 3:28
Contact:

Re: Procedural terrain engine.

Post by D.J.Peters »

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 "misc.bi" and #include "Misc.bi" isn't the same.
The vertex shader does not compile here (OpenGL 3.1) where is your OpenGL 3.x profile init code ?

Joshy
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Procedural terrain engine.

Post by fxm »

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.
shadow008
Posts: 86
Joined: Nov 26, 2013 2:43

Re: Procedural terrain engine.

Post by shadow008 »

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 "OpenGLExtensions.bi", which was ripped straight from your glScreen.bi 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 heightmapcontroller.bi 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]
    next
next

Delete(thing)
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.
Merick
Posts: 1038
Joined: May 28, 2007 1:52

Re: Procedural terrain engine.

Post by Merick »

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
pestery
Posts: 493
Joined: Jun 16, 2007 2:00
Location: Australia

Re: Procedural terrain engine.

Post by pestery »

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 Shaders.inc 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\HeightMapChunkBuilder.bi(307): assertion failed at INITVAO: HM.VBO(0) =0".

Code: Select all

' Changes to Shaders.inc
' compile vertex shader
If VS Then
   glCompileShader(hVertex)
   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
      DeAllocate(pInfo)
      Sleep 2000:End
   EndIf
EndIf

' compile frag shader
If FS Then
   glCompileShader(hFragment)
   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
      DeAllocate(pInfo)
      Sleep 2000:End
   EndIf
EndIf

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);
}
Post Reply