I want to make 3D engine on C++

Godot is pretty shitty unfortunately. Slow, clunky, and hard to use.

>hard to use
Are you dumb? It's not hard unless you don't understand OOP. In which case you shouldn't even attempt to make games.

Go get paid to shill somewhere else please, real people are talking here.

If you have never done anything 3D or engine related, you certainly aren't gonna write the engine right away, but starting 2D is not gonna be very beneficial if your ultimate goal is 3D.
You are gonna write a bunch of trash whilst getting familiar with whatever framework you choose ( OpenGL, DX11/12, Metal, Vulkan ). I would suggest OpenGL or DX11 if you are starting though.

Also note that if you simply need an engine, writing one from scratch is absolutely .rarted
Only good reason to write one is to learn, or if you really, but really hate working with higher level tech.
I myself am making a game with OpenGL and C++ not because I think Unity or Unreal are bad, but because I don't enjoy working with them. And even if it turns out like shit, I will have learned a lot more.

this is such a meme. a lot of indie games are made from scratch.

why reasons?

I hope you know linear algebra like the back of your hand

Also this

because video games are approximations and scientific results need accuracy

>I hope you know linear algebra like the back of your hand
You can make a 3D engine by copy and pasting matrix, quaternion and vector functions without knowing how they work
it's best to look at an open source to see how they do things

Haha kys retard

>I want to make an engine

no

yes

youtube.com/channel/UC-yuWVUplUJZvieEligKBkA

this guy have a lot of videos that might help you to start with game engine, top tier learning material

>I need to download visual studio crap to develop using openGL in windows
Well damn, stupid headers

Ignore this shill. Godot is a very shitty example for a game engine.

Look a urho3d. It is actually designed really well.

engine dev is a scam user trust me

you will never compete with 200 full time engine devs working at unity or unreal, dont bother - it will take weeks just to implement a simple feature you might use once or twice

invest in learning how to use unreal, you could do anything on it without spending months agonizing of stupid engine details where 90% of the technical problems come from doing mathematical magic that someone solved before you in 1994

but what do i know, im not a successful game developer or anything :^)

>engine dev is a scam user trust me
Ignore this faggot. In the real world, when you're learning new things, someone has already done it. On the real world, employers care more about your ability to learn than what you already know. Creating an engine demonstrates this flexibility.
>but what do i know, im not a successful game developer or anything :^)
You're clearly not a successful anything.

yeah, start with 2d first. you can always add another d later

I've actually done this, almost done after about three years at it. My first recommendation is "don't": there seem to be very good 3D engines out there already.

My second recommendation is if you want to do something specific (say you want to make a 3D game with a seamless real-scale multi-planetary world and none of the engines will do that out of the box) take a bunch of pieces and assemble them into an engine with your application specific logic in the middle. For example take Bullet for the physics, libcinder for the graphics, Chromium Embedded Framework for the UI, QUIC for the networking, something like that (I haven't used all of those so I can't vouch for them, there's also a library called Toy which is the basic components of a 3D engine already built for you to connect up however you choose).

Other than that, just pick either OpenGL or Vulkan (Vulkan being trickier and much more verbose but giving you more control and theoretically greater speed) and start writing a renderer. Just do it quick and dirty the first couple times, I think I threw out two render engines before I finally built a "good" one and that's not counting the significant restructuring I had to do for picture-in-picture support and similar.

OpenTK

I use my own engine for my games and I think unless you know how an engine works and what it does in the first place it would be a waste of time for you to try and you wouldn't create anything useful or productive

>Vulkan being trickier and much more verbose
WHAT
Good thing nobody accepted it as a standard then

It's easier to build an engine for one specific indie game than it is to build one generic engine for everybody's game.

Yes but if you are learning you should avoid black boxes.
If you aren't learning use a fucking engine.

I've written 3 separate ones in completely different styles.

Don't bother and learn unity.

>you wouldn't create anything useful or productive
Read my post again

>Yes but if you are learning you should avoid black boxes.
there's always going to black boxes even when you're making your own engine
you're not gonna understand what the OS is doing for one
and copy pasting functions isn't exactly a black box, you can still see the code, you just don't need to know the math behind it

There are better ways to learn than creating a 3D engine as a beginner. The task is too big (assuming you mean a useful 3D engine and not a toy)

>There are better ways to learn than creating a 3D engine as a beginner
>beginner
Where did OP say he was new to programing?

To clarify by "trickier" I mean "more difficult to get right". There's less of the "oodles of invisible state machine parts of which have been deprecated years ago but which tutorials will still tell you to use" that plagues OpenGL. But in exchange you have to have a very good understanding of what the calls are actually doing and how to structure an application or you're going to produce slow garbage (and spend forever refactoring when you realize it needed to be done a different way). For an extreme example: If you want to support multi-GPU in your application you need to support initializing several graphics devices when first starting up your application, then your application needs to intelligently divide up the work between the two cards so that they're both doing as much useful work as they can without having to wait for one or the other, etc.

I'm assuming he is, I think you need to have actually worked with some 3D engines first before you consider writing your own

I don't think OP actually implied he wanted to make an engine for everyone, just that he wants to learn how for his own personal use and learning.

>Potentially new to game engines == definitely new to programing

Attached: 1516003050252.png (250x202, 8K)

>it isn't a black box, its just a white box with a black tarp of mathematical ignorance thrown over it!

If you are posting on this board you are probably somewhat new to programming, that's just a statistical truth

You can look at it and see what it does you just don't need to know why

>Projecting this hard

Attached: 1519467272833.jpg (399x385, 29K)

If you're upset that I assumed you were a new programmer you need only correct me, you don't need to get passive aggressive about it

Yeah, I'm reading some documentation and it's not that bad.
Shame it's object oriented though.

OpenGL isn't object orientated, that's the problem everyone has with it, you control it by manipulating a huge amount of global state

>passive aggressive

Attached: 1485604408299.jpg (798x770, 195K)

posting cancer frogs because you got triggered is passive aggressive

I'm talking about Vulkan.
Global state is more straight forward.

I suppose it gives you more control but 99% of the time you're gonna wrap those states in objects anyway so it's more of a pain in the ass than anything else

I don't think "has objects" is what most people mean when they complain about "object oriented". If Vulkan qualifies as "object oriented" then most C libraries are as well, like SDL or Opus or libarchive.

Well of course I don't want to write my own windowing for every platform if I'm just making a hobbyist engine, but not understanding linear algebra is going to hinder your ability to write complex shaders.
Yes you certainly can use other peoples tools like GLM and I would recommend it, but your lack of deep understanding will limit you.
I did write my own library for math, but that's because I am lazy and don't wan't to spend time learning GLM, but that also hinders me in different ways. Would overall recommend learning both library and maths.

OPENTK

It allows you to use a functional style if you wish though.
>" then most C libraries are as well, like SDL or Opus or libarchive
Aren't they? Well I only know for sure about SDL, it seems object oriented

I hate you faggots. I don't care if he's shill, but at least expand on your fucking claims. If it's shitty, explain how it's shitty. If urho3d is good, explain why

Saying "it's shitty" is not criticism.

Leave pajeet alone... he know the shit in the street with the great successfulness.

not that guy but I can explain why Godot is shitty
it falls for the "one architecture to rule them all" design anti-pattern by making everything a scene node

what game are you making? i habe a free year between compsci years, amd want to do a project and maybe earn some money.

In the sense that they have "objects", meaning structs representing literally anything more complex than a vec3 and functions that operate on those objects, yeah they're object oriented. But there's hardly any other way of doing it really. You can return an integer identifying the SDL_Surface that exists somewhere internally within SDL instead of giving it directly to the user but that's just pretending there isn't an object.

What people mean when they complain about things being "object oriented" is inheritance, polymorphism, composition, encapsulation and all that business that comes with fully featured object systems found in Java and C# (for example, also in C++ but it's a lot more awkward there). That stuff has it's place (composition is very good for creating classes in game code for example) but other times it's like trying to cram a square peg into a round hole, you often see this in game engines where everything has ended up inheriting from one "Entity" class for the sake of object oriented design and now the skybox and ambient lighting is controlled by an entity that must be spawned into the world with a physical position and rotation, even if that physical position and rotation have no meaning whatsoever for that particular entity.

>passive aggressive

Attached: (you).jpg (600x518, 48K)

Thank you for the first legit piece of criticism.

this better be bait

I have released games with my own engine and I dont know how a quaternion works or what an imaginary number is

I do scientific simulations for work from scratch. Don’t build a general purpose engine, make purpose built simulations.

>I dont know how a quaternion works
>I dont know what an imaginary number is

Attached: 1540731500565.png (1217x1015, 708K)

I started working on it very recently, so it's still very vague, but it will be a system oriented puzzle game in a 3D automaton like environment.
You shouldn't take it very seriously though, because the main reason for it is to keep me busy during high school and I'm still learning as far as 'proper software' development goes.

I see.
My problem is the:
>functions that operate on those objects
Often the functions could be used in general but are restricted to arbitrary objects.
But I'm being a bit extreme I admit, what you just described is much, much worse

>Often the functions could be used in general but are restricted to arbitrary objects.
thats because you're interfacing with an abstract gpu which doesnt offer you much freedom

shilling this youtuber who messes with the sm64 engine. mostly helps with getting an idea of how you might implement stuff.
btw this is two diff links
youtube.com/user/pannenkoek2012
youtube.com/user/pannenkeok2012

And you think the Vulkan objects are justified as well?

>Often the functions could be used in general but are restricted to arbitrary objects.
Only in C++ really. We don't have function overloading at all in C, so your options are:
Drop support for C and have a C++ only API.
A bunch of functions named Lib_TransformTexture, Lib_TransformSurface, Lib_TransformWindow, etc. like we have currently (even global state machine party OpenGL takes this approach, with glUniformfv, glUniform3f etc.).
One function called Lib_Transform that takes a void pointer and you have to guarantee the first four bytes of it are an integer identifying what type to cast this pointer to internally (or any similar dirty implementation of runtime dynamic types).
Various absolutely vile preprocessor nonsense such as writing a template function with it if the structs are guaranteed to be semantically identical (for example they all have members x, y, w, h even if the layout of those may change).
Using C11's template macro is also an option I believe.

Of these options have a bunch of differently named functions is easily the best option. It incurs no runtime overhead, doesn't require storing a largely useless type identifier and doesn't involve undebuggable witchcraft with the preprocessor or dependence on incredibly recent C11 features.

I don't know what you're getting at
an abstraction can't exist without some way of distingushing things from one another
You can't just allocate memory and say "this is a framebuffer" because the internal representation may vary depending on the platform

You are right, I was thinking of c++.
And I agree multiple functions is the best option, it even makes reading the code easier.
Are the abstractions needlessly limited in a futile attempt of forcing the programmer to make good code?
Like all the other languages and APIs that have been doing this recently.

>Are the abstractions needlessly limited in a futile attempt of forcing the programmer to make good code?
They're needfully limited because they have to be able to communicate with specialized hardware that does different things on different platforms
OpenGL is a pain in the ass to work with but you have to consider what it's doing, you're basically communicating with another computer at as high a speed as possible, and it's an abstract computer that could be any GPU

lol yeah I understand, dealing with multiple architectures is a pain and it's a miracle that it works at all.
I was asking if the Vulkan API introduces any of these "safety" roadblocks that OpenGL doesn't have

afaik Vulkan offers you even more control than OpenGL

I need to read on it then, thanks user.

I suggest you stick with OpenGL because it has better docs
You don't need more control

I don't but I'm worried that it will be deprecated

Vulkan hasnt caught on
everyone is still using OpenGL
it won't be depreciated for a very long time considering how much software runs on it

urho looks comfy, thanks user
urho3d.github.io/samples/13_Ragdolls.html

>at a stage in learning graphics api and engine design where i need to really start supporting external data
>runtime arbitrary serialization is a massive security flaw and also requires some shit dynamic lang
>compile time arbetrary serialization requires C++'s metaprogramming to not be shit and metaclasses aren't coming until 2023 at least
fuck this fucking shit FUCK i don't want to have to write that much fucking boilerplate fuck

build system that supports expanded metaprogramming like qt's meta-object compiler but compile time FUCKING WHEN

>>runtime arbitrary serialization is a massive security flaw and also requires some shit dynamic lang
you're a fucking idiot

if you don't use some shit dynamic lang it doesn't solve the fucking problem of a fuckload of boilerplate
lua as a whole is nice and its metaprogramming is great but I'd still rather not embed lua at this level

I really shouldn't have to explain why runtime arbitrary (de)serialization is a massive security flaw, every non-static language from .NET to Java to ruby has had CVEs issued because of it

this, do not make game engines, make games.

geometrian.com/programming/tutorials/write-games-not-engines/

>I really shouldn't have to explain why runtime arbitrary (de)serialization is a massive security flaw
You should because it's not
You don't give the contents of a file free reign to do whatever it wants to your program

maliciously crafted files can give something free reign
java had to completely remove deserialization because they weren't able to figure out how to sanitize input

>maliciously crafted files can give something free reign
er no not unless you let them
you dont give it the freedom to create whatever object it wants or call function it wants
it's like your arguing that something every single program does somehow isnt possible

>you dont give it the freedom to create whatever object it wants or call function it wants
Arbitrary (de)serialization is literally the freedom to do just that, you dumbass. You understand the meaning of the word arbitrary, right?
>it's like your arguing that something every single program does somehow isnt possible
The interpreters for languages that do not compile to machine code literally do that by nature, and that's why remote code execution relating to serialization has effected literally every single one.

You give it the freedom to arbitrarily do things within constraints. Like it's allowed to instantiate classes that extend this class. Under no circumstances should external input be able to do anything to your program. That's just dumb

>That's just dumb
welcome to interpreted languages and why i only want it to be done at compile time with strictly enforced typing provided by metafunctions
>bleepingcomputer.com/news/security/severe-deserialization-issues-also-affect-net-not-just-java/
>infoworld.com/article/3275924/java/oracle-plans-to-dump-risky-java-serialization.html
>portswigger.net/daily-swig/ruby-taken-off-the-rails-by-deserialization-exploit
interpreted functional langs are probably completely immune from the problem but pure functional languages are just toys for mathematicians until a lamda calculus machine becomes a thing

it has nothing to do with interpreted vs compile time. You are in complete control of what file input does or doesn't do to your program. You are spouting gibberish

okay it seems you're missing the fucking point

Non-arbitrary serialization, which is what you're talking about, requires a fuckload of boilerplate. You have to define every single datatype and how it saves and how it loads, and a fucking game engine needs a fuckload of datatypes.
Now because there are only a few fundamental datatypes, and only a few containers they could go in, you could, in theory use metaprogramming to provide the serialization primitives, and generate serialization functions for each class by compile time iteration over class members.
However C++ metaprogramming does not, at this point, support compile time iteration over class members. That apparently comes with the metaclass proposal.

It's not a binary question of completely free arbitrary deserialization vs doing it all by hand
You have the power to control what can and can't be done with it
Well I'm assuming you do, I don't use C++ but it's the most powerful programming language so I'm really going to be surprised if you can't do a bit of basic reflection with it

>I don't use C++ but it's the most powerful programming language so I'm really going to be surprised if you can't do a bit of basic reflection with it
hahahaha
no wonder you don't know
C++ has really really fucking shit reflection system that also has a shitload of implementation defined behavior

people keep trying to get around it
for example, the Qt graphical toolkit/libraries, designed their own meta-object system around a special preprocessor called a meta-object compiler that has to be run on any class that wants Qt's reflection