I sorta got it into my head that I want to make a 3D game engine.
Now there are some great tutorials on youtube out there and I sorta figured I want to make it in JS, or at least playable in the browser.
https://jsfiddle.net/b0hjovrn/48/
Now I think I just want to make it very bare bones, for "retro" looking shit, maybe a simple 3D model maker or something.
Tried some webassembly (Typescript), but it just was cancer out the ass and pain getting things working between plain JS on a websight and the webass (TS and wasm are new to me so a steep hill to climb), so no I think I'll just stick to plain js.
Thank you for your patience.
Also: Does someone know what causes the "fizz" on these models?
https://www.youtube.com/watch?v=hq_-HvVlfec
I really really like that look.
>>1
I think this advice is still sound: https://geometrian.com/programming/tutorials/write-games-not-engines/
>>2
My guess is that it is some kind of raytracing where certain pixels are skipped, probably for performance reasons. Blender does something similar when previewing raytraced images.
There's some fair points to it but at the same a lot of it is overgeneralizing. Writing an engine is bad because the person writing it will try to solve every available problem in the field... Sure some (specially inexperienced ones) obviously might do that but the smarter ones will of course realize that this approach would take to much time just write the solutions they see as valuable to their vision.
I wonder how the author expects their readers to structure their supposedly superior non-engine games. Spaghetti code full of hardcoded paths and magic variables. Hopefully not. Well structured low level game code will lead (at least the most of the time) to pretty much what an engine would look like. Clean, reusable primitives.
What the author also doesn't seem to realize is that while writing an engine you don't have to actually write everything. A lot of times you'll have some library that does exactly what you want and only needs a little wrapper to match your formatting/structuring/concept standards. This way you can gain a ton of functionality really quick and from the final users perspective it's pretty much indistinguishable that there was "cheating" involved. This also allows for cherrypicking topics one actually enjoys spending time on.
Well structured low level game code will lead (at least the most of the time) to pretty much what an engine would look like. Clean, reusable primitives.
That's the point. By actually writing games and sharing code between them, you will naturally end up with an engine that is proven to work. But if you set out to write an engine just for the sake of it, you are almost guaranteed to end up with some random collection of things that are barely useable.
>>2 >>3
That's definitely error diffusion and not ray tracing. The OS only supports a very low color pallet (the author believed either himself or his code to be a prophet and the low color pallet was a commandment from God, thus error diffusion.)
Writing your own 3d engine is pretty trivially easy if you can draw the primitives you want in the plane.
Just transform all the coordinates according to a projection matrix (itself transformed by the camera position) then if you're drawing polygons do hidden surface removal (either by z sorting or a z buffer) this isn't necessary if you just want line drawings (the easiest to do from scratch.)
Make sure you know your Linear Algebra, CG is kind of a bitch without it.
>>8
What about physics?
>>8
"... Make sure you know your Linear Algebra, CG is kind of a bitch without it."
This. So much.
>>9
Physics is not terribly complicated if you don't need anything fancy. IIRC quake 3's physics used to be something like what? 1000 - 2000 lines of C code? For anything fancy i'd strongly recommend >>5 though unless your in love with math.
ok i got a rotating cube with colored sides
now how do i make a elite like dog fighting ai?
>>11
If the cube is just sitting in one place and rotating, you don't really need AI, you can just hardcode where to shoot.
>>11
So you probably want some ray tracing to see if you hit the target, that's the biggest issue you'll run into.
Just use a hitsphere and look up the ray-sphere intersection formula.
(OP)
So my thoughts are, enemies have velocity and max turn rate, and always try to turn into some vector that shoots out my ships ass, or at least trying to turn towards me that would be even simpler
>>14
Maybe post your code?