TheChernoProject's MineFront, in ComputerCraft. 3D Graphics.

Background Info
I remember I watched a tutorial, on how to make a Java 3D game some years ago. The guy who made the tutorial was called TheChernoProject, and he had a 50 episode series, which was going when I watched it. It featured how to make 3d games in Java from scratch, without the use of external libraries (for example OpenGL, DirectX etc.). It all was based on the concept that the programmer has to calculate all pixels by himself. I remember I watched that tutorial, but then I haven't touched that code/project for years. That was back in 2012

How I got the idea
Now I was playing around with ComputerCraft (I'm not new to ComputerCraft nor am I new to Coding). I thought, Hey, I've never seen someone make 3d stuff in ComputerCraft. I thought I'll give it a try. So I made this:
http://www.youtube.com/watch?v=PobArz09CQ0

Features and how it works
It features a fully working D-Pad, where you can move forward and backward, you can rotate left and right, and ofcourse you will move in the way you're facing, not just in 2 set directions. It also features walls, with a premade level. And lastly, the walls have collision. The D-Pad's signals gets transferred to a computer behind the monitor, which then translate it into position and rotation, and which also draws everything on the monitor.

But hey? where is the source?
Here it is: http://pastebin.com/2KYTxaU2

Wow that's pretty neat, it's nice how you've got the textures, it makes it look even cooler! It's a shame it's rather slow though, are you using a buffer or anything that might speed it up?

Actually, just noticed too, you don't have your code posted; you'll need to upload it to Pastebin or something else otherwise your topic will be locked.

if you remove the s from https in the link and use the full link then the forum will embed the video for you

also, the mods don't like shortened links

Moved to Media.

oeed, on 14 December 2015 - 11:20 PM said:

It's a shame it's rather slow though, are you using a buffer or anything that might speed it up?

A note on this, normally a display buffer would slow things down (while in turn reducing flicker); in ComputerCraft, changing part of a line updates the whole line. Meaning if you render every point in a row individually you're wasting a whole lot of time - you're better off figuring out what every point in the row should look like and then blitting the lot in one go.

I rather suspect that's already what GamersForOne is doing, and that the main bottleneck is in the 3D transforms.

I just woke up. And thanks for the replies. I did update so it embed the video, and I also uploaded the sourcecode

I did want it to go faster, but however afaik it all gets calculated within a programming language (lua) which is interpreted with another programming language (Java) which also runs the game. I don't know if this might cause it to get slower. It may also get more slow as it actually have to calculate each pixel every time it renders the world. So first it starts at one corner and then goes to next pixel in X direction, then the next. And when it reaches the far right side, it goes back to the first X pixel, and continues on a new line (Y direction). Just to make the "drawing" more smooth, I do first render it all into a buffer, which at the end, gets the pixels rendered to the user all at once, when they are all calculated. As you can see in the source, some of calculations has +1 and -1 at the end (mostly at the end). It's because many of the calculations the program does has to (I think) have a system where the computer starts counting at 0, unlike in Lua where it all starts at 1 (I don't know why they made it that way).


For those who are interested. this is the original tutorial series for Java (same code which I ported to Lua/CC). It is also the same code that Notch used for his Ludum Dare #21 game Prelude of the Chambered. In my version though I had to make some changes/adjustments. For example the textures I made is hardcoded into the source of the lua program so that I don't have to load them from external fills, though it does still work because it's still an array (table) with pixels (colors) which makes it a texture.

Lyqyd, on 15 December 2015 - 12:50 AM said:

Moved to Media.

Yeah, I understood that this was proably the wrong section, but I really wanted to get this up before I went to bed, so I left it for the mods/admins to move it, sorry for wasting your time :P/>

GamersForOne, on 15 December 2015 - 08:16 AM said:

I did want it to go faster, but however afaik it all gets calculated within a programming language (lua) which is interpreted with another programming language (Java) which also runs the game. I don't know if this might cause it to get slower.

It does slow things down a bit, but there are quite a few optimisations you could be making in there. Getting rid of many of those function calls, for example ("function draw() floor() end" being the most blatantly redundant, but calling term.setTextScale() and term.setCursorPos() over and over when you don't need to isn't helping either). Most of your transforming code looks pretty solid to me, though; I certainly can't see many improvements I could make at a glance.

But the rendering system is what stands out to me - when I was talking about blitting before, I was referring to term.blit(), with which you can quite literally output entire rows at once. If you'd like to try them, implementing these changes would switch your renderer over to it:

Line ~28:

  local pixels = {}
  for i = 1, h do pixels[i] = {} end

Line ~34:

  local c0 = "0"  -- black
  local c1 = "7"  -- gray
  local c2 = "8"  -- lightGray
  local c3 = "f"  -- white

Line ~49:

  local c10 = "3"  -- lightBlue
  local c11 = "9"  -- cyan

Line ~138:

      pixels[y+1][x+1] = col

Line ~293:

        pixels[y+1][x+1] = wallTexture[bit.band(xTexture, 7) + bit.band(yTexture, 7) * 8 + 1]

Line ~313:

local blankLine = string.rep(" ",w)
function finalPlot()
  for y=1,h do
    term.setCursorPos(1,y)
    term.blit(blankLine,blankLine, table.concat(pixels[y]))
  end
end

This is amazing. A lot of projects are cool on the forums but this is litterally amazing. +1

And thanks for the youtuber, I will use him for my 3D game/rendering engine project.

Thanks for the replies. I did not expect it to be this awesome replies.

But now to the point of this reply. I did try to add/fix some things in my "game". Though there was a problem, which wasn't that huge, but if I don't do anything about it, it will become huge. It's the structure/layout of the code, I noticed I did not put the code in a structured order, and when I'm implemented stuff by just adding the code/functions somewhere in the mess. So I'm currently working on a recode, and the main focus is to make it OOP, DRY and having a good Structure. I will be using the following structure:

• Constants at the top
• Following that comes a small part where if someone changes the constant value to something which is out of bounds of the rules, this part fixes that
• Following next, is the classes. Because I want to make the new version OOP, so I will use classes. And I know that there's nothing called classes in Lua. I know I have to use tables for this and some tricks to work around it.
• Following that is the part where the core stuff, like peripherals wrap, getting needed variables/values, setting up core objects (from the defined classes), setting up the monitor, setting up the buffer/buffer handler etc.
• Following that is where the code start, or I should say, it's where the game actually begins, and where to main loop will be

I hope that this will work better than the last version, atleast for me, the coder. The end user will see mostly no difference except maybe some performance/feature improvements.

Creator, on 15 December 2015 - 12:40 PM said:

This is amazing. A lot of projects are cool on the forums but this is litterally amazing. +1

Thanks.

Creator, on 15 December 2015 - 12:40 PM said:

And thanks for the youtuber, I will use him for my 3D game/rendering engine project.

No problem man. Though one problem is you can't really look up and down. Just left and right. I know you can tweak it in a way, which Notch did for his Minecraft 4k game (Java game below 4kb file size). Though the decompiled version isn't that easy to understand because it's VERY Obfuscated. I guess if you wanna stay at making it from scratch without external libraries, this is still the way to go. But if you have the chance, I'll recommend watching 3D Tutorials for OpenGL (LWJGL in Java) or something similar. This version is quite laggy itself, even on the Java version, I mean you don't get like a constant 60 fps (atleast I didn't). Another thing about the youtuber, his mic/sound can get annoying after awhile too. And just so you know, and he haven't even posted the source code for the game either.