Qdfps

[Luuk van Venrooij]

It should compile on linux using freepascal. I dont have any intentions so far to make the levels destructible.

[WILL]

No video post? ...or more screenies

[Luuk van Venrooij]

There is a demo attached a few posts back

[SilverWarior]

I just fideled around a bit with your demo and I belive I found a bug or posibly just a unintendedt glitch. Damn I'm good in bughunting maybe I should try to find a job in this area
Anywhay the bug happens if you move the camera beneath the level and then move upwards. Ass soon as you get to the botom layer you are teleported above that layer or if there are more layers on the top one (glich in colision detection). This doesn't happen when you try to do similar with cealing.
Also if when placing block you get camera boxed into a small place and then place final block which is placed on the position for camera to be inside the block camera might sometimes glitch between two block and sorta jump up and down. It fixes itself when you try to move.
So you might wanna check your colision detection algorithm again to see why this things are happening and prevent user from placing the block which would be placed on the position where the camera is and therfore cuase forcefull camera move to another position.

[Luuk van Venrooij]

I just fideled around a bit with your demo and I belive I found a bug or posibly just a unintendedt glitch. Damn I'm good in bughunting maybe I should try to find a job in this area
Anywhay the bug happens if you move the camera beneath the level and then move upwards. Ass soon as you get to the botom layer you are teleported above that layer or if there are more layers on the top one (glich in colision detection). This doesn't happen when you try to do similar with cealing.
Also if when placing block you get camera boxed into a small place and then place final block which is placed on the position for camera to be inside the block camera might sometimes glitch between two block and sorta jump up and down. It fixes itself when you try to move.
So you might wanna check your colision detection algorithm again to see why this things are happening and prevent user from placing the block which would be placed on the position where the camera is and therfore cuase forcefull camera move to another position.

Thanx! I will look into them

[Luuk van Venrooij]

Again a little update

- Optimized the rendering of the cubes. Cubes in a node are now grouped by texture instead of setting the texture for each cube side rendered Didn't really much on Ati and Nvidia cards but my on-board Intel card performance want up by 200%
- Fixed the 2 collision bugs that SilverWarior pointed out.

I started to look in to how I`m going to do the lighting on the cube geometry. I types of lighting I want are 1 directional and point lights with different colors. My first try is going to by per vertex lighting since the density of geometry is pretty high. Also this should be pretty simple to implement and fast enough to update in real time while editing. Another option may by light mapping. Implementing shouldn't be that hard since the checks to calculate the color per vertex are basically the same for as for the lightmaps. Also the layout of the light maps in the textures is pretty easy since all surfaces are rectangles However the code will be more complex and real-time updating might be an issue depending on the resolution of the lightmaps.

I`m also going to extend the texture mode. I want to be able to rotate textures per surface of the cube so I can align them properly in some situations. I`m talking about rotations of 90 degrees so I`m thinking of some sort of look-up table for this.

Anyway here`s the updated demo:

[phibermon]

Minecraft uses ambient occlusion and due to the oct-tree based cube world, there's some compromise optimizations you can do to achieve ambient occlusion.

(calculating per cube face as apposed to disc-based simulation of ambient occlusion (http://http.developer.nvidia.com/GPU...chapter14.html). SSAO is also a good approach however it's probably not as fast as per face, oct-tree bounded AO and obviousy ray-traced style occlusion is not an option for current hardware)

I found an excellent source of information when I was adding Voxel regions to my engine (I shall avoid the temptation to elaborate) and I provide for your reading pleasure : http://codeflow.org/entries/2010/dec...s-in-opengl-4/

Whilst it's geared towards GL4, I don't remember seeing anything that couldn't be achieved on Pixel Shader 3.0 hardware.

Oh and brilliant work by the way! you must write tight, consistent code to be able to achieve a stable system in such a short amount of time. I do myself a disfavor by refining my designs, If it works then it works! if only I could take that advice then perhaps I'd have a user-base by now

[Luuk van Venrooij]

He guys,

So a little update on this little project. I have been working on and off on this project for the last month again. Most of these time I have spend rewriting and refining system but also added some new features.

- Optimized map memory usage. Map system now uses pointers so cube records are now only allocated when needed.
- Optimized cube rendering. Cubes are now grouped by texture, fixed some hidden surface removal bugs.
- New scripting language. Supports functions with parameters now and parsing is more robust.
- Switched from SDL1 to SDL2 because in future I want to use OpenGL 4.x for rendering.
- Switched from color picking for selection to raycasting method. OpenGL 4 doesn`t support this so removed it.
- Texture based font rendering. Used glBitmap before and OpenGL 4 doesn`t support this so removed it. Also text is scalable now.
- New TGA texture loader and texture management system.
- New map improved map format. Used roughly 1/10 of the space used before.
- Directional lighting with shadow casting. Its per vertex lighting but still looks pretty good because of the high poly count.

Next things I will be working on is refinement of the lighting system. It still has some problems and I have some ideas to improve that. Not sure if I will look into point and spot lights already to. I also want to make the editing a bit easier. Instead of placing one block at a time I want to be able to select and manipulate selections of multiple blocks. Other things I want to work on is physics and collision.

Anyway like always there are some screens and the latest binaries included in this post and a little video showing the latest test level with lighting!



Cheers!