I am still a noob in lua, so I won't be able to help you a lot with the actual coding. But for the algorithm, I can give you this algorithm based on what I used in my 2D minecraft clone:
- Set a height variable to what you want for the average height of the level
loop accros each collum:
   - generate a random number and use that to determine if the ground level should get higher or lower (for example, a random number between 0 and 4: 0: decrease height variable, 4: increase height variable, other values: do nothing.) You might want to decrease the chance of moving up when above the average height, and decrease the chance of gowing down when under the average height to make the world height fluctuate around the average height. You can make the chance of changing the height depend on a biome variable as well.
   - fill the collum from 0 to a random number of blocks between the ground height of that collum. (set the bounds of that random to something that looks right)
  If the height for that collum is above the water height: (the water height depends on what type of map you want. Higher than the average height will give you islands, lower than the average height will give you lakes.)
     - fill the collum from above the last stone block to 1 block under the world height with dirt. Place a block of grass at the top
  else:
     - fill the collum from above the last stone block to the world height with dirt. Randomly replace the top block with sand or clay if desired.
     - fill the collum from the last dirt/sand/clay block up to the water height with water.
  endif
end loop

tree placing loop: (repeat a random number of times. More means more trees, less means less trees)
   - Choose a random collum.
   - Get the location and type of the topmost block
  If the topmost block is grass:
     - place the blocks that form the tree at the location you got from the previous step
  endif
end loop

ore generation loop:
   - shoose a random location (it's reccomended to use a logaritmic scale for the y-coordinate to make ores more common at the bottom of the world)
   - try to replace some stone blocks on and around that location by a vain of random ore (more valuable ores being less common)
end loop

It's very basic, but you should be able to make it more complex and make it generate more beautifull worlds.

I like the graphics, but if you are only gonna use 1 shade of gray for the entire tileset, wouldn't it be better to make it black or add more details with different shades of gray?

Will you change later that you won't be able to fly?

But yeah, it is looking pretty cool, great job!

I think you misunderstood. I haven't worked on this project for a while, but I've gotten a few requests from poeple wanting to see the source code of this project. And because the download link is 'hidden' somewere in this thread, I decided to make it a bit easier to find.

I'm sorry, but this project won't be updated soon. I'm now focussing on my java game. Maybe after that, I'll see what I can do to revive this project.

Hi,

As you may or may not know, I'm working on a java online RPG. I am currently working very hard on it to get it ready for beta (I have a deadline, but I'm not sure if I'll make it, so I'm not going to tell it yet). The graphics of the 3D models are all reasonable for a beta version, but I have always been using very simple graphics (=coloured circles) for the item sprites. I have done a few attempts at drawing item sprites, but they looked awfull.

If anyone wants to give it a try, I'll write the specifications:
 - Theme: The graphics of the game itself are meant to look reasonably realistic, but the theme of the menus (and thus the inventory) is more simple (it contains large areas of rougly the same colour), so I think that for the item sprites, a simple or cartoonish theme would look best, but an other theme will probably look good as well as long as all items have the same theme (Note that items that appear in the 3D space (like wieldable items) wil have a seperate model, so the item sprite is only displayed in the inventory.
 - Size: Preferably 32*32. If you can't do 32*32, please use at least 20*20. The image has to be square. Make sure that the item is still recougnizable at a 20*20 resolution.
 - Background: The background must be transparent.
 - format: png

Some items you can try:
 - An iron axe
 - A box (just a plain, cardboard box)
 - A stick (branch of a tree)
 - A pile of leaves
 - A log

If you still have questions, feel free to ask them. And of course, if you make sprites, I'll put your name in the credits.

Even then it would take more time. If he handles the drawing in a simular way as I do, some constants are calculated for each wall/triangle. For the rest it just relies on simple additions. Drawing a textured wall requires approximately three times the calculation time for the calculation at the start, and the additions that need to be done take almost three times the calculation time as well. Actually drawing a pixel takes approximately four times time on a textured wall than on a solid wall.
Creating a textured wall by positionning 64 tiny walls (an 8x8 texture has 64 pixels. For a 16x16 texture, you'll need 256 walls) in a rectangle means that the calculations of the constants for each wall has to be done 64 times. And as those calculations are quite slow, this would cause a huge slowdown (21.33 times slower than a texture).
Then, the calculations at the start of each scanline (a getPixel call and some additions) has to be done 8 times more (or 16 times more if you want 16x16) than on a regular wall (which makes this part 2.67 times slower than drawing a textured wall.
But acually drawing a pixel will take the same amount as a regular wall (because in this part, it actually is a regular wall) (so this part is four times faster than a textured wall)
When you add all of that up, it will be a lot slower, mainly because the slowest part has to be done 21.33 times more than when you use a texture.

Yeah of course. Clipping are mainely for indoor scene, as well as portals.

A very very very very    super good new :

TEXTURES WORKS !!!! 

but it's slllllllloooooooowwwwwwwwwwwwwwwww 

Awesome!

BTW is the texture drawing done in axe? If so, you might want to consider converting it to assembly. Axe is a good and fast language, but for stuff like per-pixel drawing, assembly usually gets faster results.

Quote from: ben_g on July 02, 2013, 01:54:35 pm

This seems to be able to do what my 3D engine kept failing at, and at a thrutely great speed.

I am not agree with that. You have texture, and they give me a very hard time !

Well, my 3D engine failed missarably at clipping in indoor scenes. But I didn't do any 3D clipping when only one point is behind the camera.

Anyway, if you want help with textures, I can always see if I can modify my texture drawing code to make it compatible with axe.