speed

[marclurr]

Small nitpick. Bytecode is normally the term used for the binary form of compiled languages that are interpreted by a virtual machine, like java or python (though you don't usually compile it yourself, you can though). Exes are usually (always?) actual binary machine code, which is specific to the architecture it was compiled for (e.g. x86, x86_64 or arm64 and many others). Similar to machine code, a given bytecode is specific to the VM it's intended for. So in essence they're very similar but the terms are usually not interchangeable.

[RNavega]

Thanks a lot for the correction marclurr.

I should follow my own advice hehe:

Screenshot_20240616.jpg (95.8 KiB) Viewed 2576 times

[zorg]

Better advice would be to not use chatbots for answers to questions period, unless you want to just entertain yourself.

[1Minus2P1Stringer2]

Thank you but i do want to make the 3d game from 'scratch'(haha get it?). It has been my mission in life to make a 3d engine and make it the best (in my oppinion). And then use it to make a game. (im making a sorta roblox like thing). I like how simple scratch is. It's more orginized for me then python or c. But it tends to go slow when displaying images pixel by pixel, as most non assembly languages do. Espcially since turbowarp while fast, still has its limits. So i tried to find a simmilar language, which ive found as forth and lua. I went with lua cause it go speedy! But, The whole format confuses me so. I wish everything was more orginized like Console.print() or something. but its not. So I get very confused on what something, does. Thats where im stuck at. Also thanks for the bytecode and buffer explanation. Also, turbowarp is very very very very very very very very very horribile queality in rendering. Im opposed to using depth buffers already existing because they confuse me so.

[1Minus2P1Stringer2]

Ive now decided against turbowarp. Doesnt have enough control over the computer. But now im lost. I love turbowarps format. THe scratch block code format is great, for me. Now, i gotta figure out, "forth, lua, or my own language" Im really really avoidant of making my own language, but i may have to.

[dusoft]

OK, when you decide on using LOVE (with Lua), get back to us.

[UnixRoot]

Im really really avoidant of making my own language, but i may have to.

And how do you imagine writing your own programming language? It's much more difficult than reading the Love2D documentation or understanding the concept of a depth buffer.

Just read the Love2D documentation. The logic of programming is actually always the same, regardless of whether you use tools like Scratch or Construct or a real language.

I had no clue of LUA or any other languages when I started using Love2D. I just read the documentation and tried things out, or tried to port existing code to Love2D to understand how everything works.

Try simple things first and don't start with a 3D engine.

[RNavega]

You want to make a 3D engine?
In order to do that, you need to know what makes a good 3D engine. The only way to investigate that is by trying someone else's engine and taking notes of the things you like and dislike about it.

So to expand on what UnixRoot said above with "Try simple things first", I want to give you a challenge:
1) Download Groverburger's G3D engine for LÖVE: https://github.com/groverburger/g3d
2) Run one example, tweak the parameters and things a bit to get a feel for it.
3) After that, using that same engine, start a new project to implement a Pong 3D game. The game looks like this and is very simple:

images.jpg (69.88 KiB) Viewed 2336 times

It's just two boxes for paddles (yours and the CPU's), one sphere as the ball and 4 boxes forming the corridor that's the playing field.
After you finish this challenge then you can confidently begin working on your own 3D engine.

[UnixRoot]

Nice idea. He could later also write a software renderer to learn how a 3D engine works.

Write an Obj parser, the file format is human readable and pretty easy to understand and to parse. Write a vec3 and a mat4 lib to transform your vertices. This way you learn about the math behind all the 3D transformations needed.

Write a framebuffer and a depth buffer with the help of imageData and byteData objects and FFI pointers to the data. Write a backface culling, a occlusion culling and a frustum culling function.

Write a triangle rasterizer that can fill your polygons. Add perspective correct texture mapping. Try to handle all the edge cases.

I did the same thing some weeks ago, and it's completely possible in Love2D. Even with good performance. I'm not a big fan of 3rd party libs. I try to learn from them but always code my own stuff to get better.

[1Minus2P1Stringer2]

Im really really avoidant of making my own language, but i may have to.

And how do you imagine writing your own programming language? It's much more difficult than reading the Love2D documentation or understanding the concept of a depth buffer.

Just read the Love2D documentation. The logic of programming is actually always the same, regardless of whether you use tools like Scratch or Construct or a real language.

I had no clue of LUA or any other languages when I started using Love2D. I just read the documentation and tried things out, or tried to port existing code to Love2D to understand how everything works.

Try simple things first and don't start with a 3D engine.

One, No, Because its not like it would be hard to figure out, I just want to because it feels unatural, "The logic of programming is actually always the same, regardless of whether you use tools like Scratch or Construct or a real language. " Also if that was true, There wouldnt be such things like functional and stack based programing. Also a 3d engine IS simple. At least to me.