Not sure as to where this should belong. Was thinking of posting it in the WIP board, but it’d not really a game:P
I’ve been working on a voxel terrain generation thing for a while - and here is the result.
Thanks for looking:)
CPU: AMD 8320 8 core 3.5ghz (Black edition)
GPU: GTX 650 Ti 2GB GDDR5 (Overclocked to 1024mhz)
Running at a solid, 60 fps. Send me a link without vSync or a limiter if you want me to test it in full frames.
Also, I have a few questions,
Okay, that’s a great deal faster than mine i would imagine, just look at all those big numbers:D
1:Not too sure what immediate mode rendering is
2:Simplex noise. I didn’t implement it - it was based on example code by Stefan Gustavson, and optimised by Peter Eastman.
3:Yes, think a less deep but easier to control dwarf fortress but with RTS controls:P
Its the depreciated glBegins, glEnds and such. The good old fixed function pipeline. More… Modern OpenGL uses shaders to compute matrices, vectors, and pixel colors. If you were getting serious about performance, I would recommend Interleaved VBOs (The vertices are saved into VRAM on your GPU rather than send per-frame in real time), and GLSL theory and implementation. Its a TON faster. Also, look into the ‘Programmable pipeline’. Its really interesting.
Runs smooth on a Phenom II 955 + HD 4670. ~5% CPU usage, not sure about GPU.
@Spacebeans
Ohhhhhhh right yeah this uses interleaved VBOs already:P
@BurntPizza
Great, thanks for testing it:P
I’m glad it runs fine, I spent a lot of time trying to get it faster:P Guess I’ll start building the game then.
Running a solid 60fps for me. (Had to open up Fraps to get a counter)
CPU: Intel i7 3770 4 core 3.9 GHz
GPU: Asus GTX 660 Overclocked to 1084 MHz
Although you should really be measuring delta, without a cap.
What kind of performance techniques are you using? (face culling, greedy meshing, etc…)
I don’t understand the difference between measuring delta and capping it? All I do currently is use Display.sync(60), I’ve no idea what that does under the covers, I just kind of take it for granted:s
Just face culling and greedy meshing currently.
I’ll add an FPS count, sorry, I overlooked that.
Measuring delta is linear, while FPS is not. There was a great post by cas (I believe) a while back explaining the whole thing. There is some math involved that I can’t quite remember correctly.
If you keep a cap on, a lot of people are going to be reporting 60fps. Some of them might have gotten hundreds of fps, while others might barely be holding onto 60. You can just measure the performance on different systems better.
“It’s now 5 FPS faster” means nothing without context:
1000 FPS to 1005 FPS: 1 ms/frame vs. .995 ms/frame, 1.005x faster
1 FPS to 6 FPS: 1000 ms/frame vs. 166.7 ms/frame, 6 times faster.
A somewhat contrived example, but no less important.
I doubt this is intended. :point:
I bet it is something to do with your VBO’s, I have had issues like that in the past.
Mac OSX 10.7.5
GPU, Geforce 7300GT
CPU, 2.16 Intel Core 2 Duo
^asldkserjfsd waht
I’ve no ideaD: I bet it’s something to do with Mac, that’s the only difference I can think of:(
You might want to check the size of your VBO, I seem to remember that if it was oversized, it did random shenanigans like that. Also, do you mind pastebin’ing your VBO code?
CPU: Intel i5 4200U @1.6/2.55Ghz
GPU: GT745m 850mhz (Not sure if memory or core?) or Intel 4500
Solid 60FPS. Both chipsets.
But my VBO code is so messy :'D
Okay, here it is
http://pastebin.java-gaming.org/0c322778a92
I end up negating a lot of positions and adding some weird offsets just to get it to work right.
The 1st function (updateChunk()) culls the faces. It then passes these face to the next function - ‘meshCrossSection’ which is the greedy meshing part. It’s in this function that everything is bound to the VBO.
each chunk is 16x16 blocks, and between 16 and 32 in height depending on the noise.
I added a more accurate FPS counter.
However, I had to very quickly find a way to display text in LWJGL - previously, I’d only done it in 2D. So you all have the privilege of witnessing what could possible be THE MOST ugly display of text in anything ever.
To emphasise my point, you’ll have to move the camera around a bit to find the number. It should be floating in the sky on a giant billboard. Good luck:P
I didn’t see any rendering code, but if you do something like:
glDrawArrays(GL_TRIANGLES, 0, buffer.capacity());
rather than:
glDrawArrays(GL_TRIANGLES, 0, buffer.capacity() / 7);
that could cause it to explode.
Just for curiosity, can you try that first snippet? I’m interested as to what will happen on windows 
Oh, the rendering code is much smaller
http://pastebin.java-gaming.org/c32278a8293
vertexCount, contrary to its name, is the amount of faces there are to render in the buffer.
Why would not dividing it by 7 cause it to explode? 0.0 In case you can’t already tell, I’m a COMPLETE newbie to the whole 3D thing:P
Can’t see anything wrong with that, unless the vertexCount is wrong. I’d still be interested to know what happens if you multiply vertexCount by 6, instead of 4.
Anyways, here’s a minor optimization for you.
public void renderChunk()
{
//remember, the format is
//x1,y1,z1,r1,g1,b1,a1
//Draw the vertexes first -
//Size is 3
//Stride is 28
//Offset is 0
GL11.glEnableClientState(GL11.GL_COLOR_ARRAY);
GL11.glEnableClientState(GL11.GL_VERTEX_ARRAY);
GL15.glBindBuffer(GL15.GL_ARRAY_BUFFER, VBOID);
GL11.glVertexPointer(3,GL11.GL_FLOAT, 28, 0);
GL11.glColorPointer(4,GL11.GL_FLOAT,28,12);
GL11.glDrawArrays(GL11.GL_QUADS, 0, vertexCount*4);
}
Intel Core i5 1.7 GHz
Intel HD Graphics 4000
4GB RAM
Windows 8
Solid 2000 FPS. Really surprised it’s that fast. :o