What would you use to make a game engine ? Is SDL 2 & C++ a good choice or is there a better one ?

Man I feel like a retard trying to use with with C++
I managed to get a really basic thing running but couldn't include more than the base sdl2 header

I guess this is what I get for using windows

Why in the world would you write your own engine?

godot, because as a one man team i know im not going to make the next zelda.

This. Or OpenGL. If you use DirectX you're a fucking retard or you get paid by Microsoft.

If you're asking this question you're not up to the task.

qt+vulkan is comfy senpai

Have you ever tried to use this? I have been tasked with optimizing mobile on UE4 using Vulkan and the implementation is still immature.

I'm going to tell you this now, don't write a game engine unless you're going to get a PHD in computer graphics. its the most pointless thing you can do, 1 godot is free, 2 you're not going to make anything better, 3 if you want to make a game just make a game.

you're not going to listen, that's fine.

If you are planning on writing a game engine from scratch, I want you to do a quick skill assessment.

>do you know algebra like the back of your hand
>do you know trigonometry like the back of your hand
>do you know linear algebra like the back of your hand
>have you taken calc1/2/3
>have you taken data structures class
>have you taken a algorithms class

if you answer no to any of the above, you're not ready yet.

Here are questions which any second year computer graphics student can answer
>implement a sphere ray intersection function
>implement a binary tree

never did any of the above? well you need to start at the basics

Attached: dusty_phone.gif (266x139, 5K)

I'm using it now

Jai and Vulkan.

>Jai
So in 2025?

I've written the game engine I currently use and this is a fucking retarded post full of stupid advice

For what?

I've been using sdl2 and c for like 4 years now and sdl2 is pretty good but if you don't care about performance as much use sfml
opengl and such are a pain in the ass and sdl2 handles the bs for you

Attached: signal-2019-06--VideoToMp4.webm (640x360, 2.45M)

How many releases do you have under yoir belt, my dear nodev?

I've worked on 5 released games, 3 of my own

He's releasing it this year.

Believe you.
I don't believe your games are very feature packed though, for example, does your game engine have a built in collision detection which can handle thousands of entities on screen at a time?

Not making an argument of feature lacking games not being able to sell, I'm making the argument that if you don't have the mathematical background you're not going to build an engine which can hold a candle to even free free engines like godot

>for example, does your game engine have a built in collision detection which can handle thousands of entities on screen at a time?
lol of course it does, even if my games were simple, that's a feature every game engine needs to have
Making a game engine is a difficult task, but it has little to do with math

I'll post a few more videos I've taken in a little while

Learn OpenGL or Vulkan, use with C or C++
You can use SDL for managing hardware but don't touch the built in rendering tools it has. They're fine for a simple game but absolutely not a full engine.

I'm a computer science student and nothing that you just talked about is difficult. And none of it is PHD level. And I'm pretty sure you don't need most of it for a game engine.

>all these faggots recommending vulkan

unless opengl can't handle whatever it is you're rendering do yourself a favor and avoid vulkan

fuck off nigger vulkan is kawaii

vulkan is for brainlet hobbyists who pick up tech because it's new and not because it's useful
and real game companies looking for gains of course, but you aren't that

It's nice you could do that yourself, but right now I wouldn't build an entire engine on Vulkan. It'd be a nightmare

I find it legitimately easier from an API coherence standpoint than opengl ever was.
init is a bitch, no argument, but once you've got your utility methods setup everything is so obvious

C++
imgui
opengl 4.5+
once you master opengl you can try vulkan
if you want to make an engine you have to think about how to store textures, shaders, sounds, player data, how to generate a binary, etc it's too much work for one person.
Build multiple games/dynamic scenes first then you can start thinking about building an engine.

>little to do with math

I disagree, apart from knowing trig inside out you also need to understand the properties of vector calculus, for example try writing a ray intersection algorithm without knowing the properties of the dot product

I learnt what a dot product is in high school
any intersection algorithm can be googled, or you can just use a collision library because why write the same thing out twice

Too bad, they are required for initializing any kind of video acceleration context.
youtube.com/watch?v=vgAqKB9o1M8&list=PL369E0FEDFEE75B47&index=16

>because why write the same thing out twice
so you agree that he should just use godot instead of writing an engine? thanks you sir :)

a collision library isn't the same thing as a game engine
a collision library is math, it's not open to interpretation, there's little point in doing it yourself
a game engine is a work of software architecture, no two are the same

>It'd be a nightmare
Better get ready for the nightmare because vulkan is here to stay meanwhile everything else will be deprecated.
>dx12 is literally vulkan with different name
>vulkan is the new android standard
>apple metal will be based on vulkan because there is no alternative and apple does not create new things
>opencl-next works great with vulkan
>vulkan works great with vr (openxr compatibility)
>vulkan work group at nvidia is working on AI layer for vulkan
>vulkan working model matches current and the next ones (i)gpus generations
>vulkan and cuda work great together
>scientists use opengl most of the time so the next logical step is vulkan
>ray-casting/pathing/tracing support

I agree that vulkan is harder to learn and most schools/companies don't have yet their own vulkan higher-level layer.
Computer graphic is one of these fields where you can't benefit from high-level abstractions, you simply can't build powerful enough program without manipulating byte buffers and memory.

stupid tech memer

t.webdev

please tell me more about VR and raytracing

std::map i am done my friend.

Easy to find a first job that pays well with a master's degree
You work in r&d labs
Exactly like AI.
You'd have to be an absolute retard to chose web instead of this in 2019

what the fuck are you talking about?

C, like for everything else

Common Lisp.

I can recommend Raylib. It's not as well known but it's a lot more streamlined than SDL and a lot easier to understand.
For example the render pipeline in SDL is needlessly complicated, you have your window a renderer attached to it and a rendertexture attached to that. You have a ton of displaymodes that you have to fiddle with when loading PNGs. Also SDL2 doesn't support PNGs, you need SDL_img2 for that.
In fact SDL basically doesn't do anything except pop up a window. All functionality has then been split out into a bunch of sub-libraries some of which like sound have a dubious maintained status.
It also has better primitives drawing, supports shaders and even has basic collision detection.
SDL does have some of the nicest input handling I've seen though, way ahead of raylib. Supports different keyboard layouts, you can get the keyname from the keycode e.t.c.
Still would recommend raylib.
Don't get me started on SFLM.

Attached: raylib_256x256.png (256x256, 4K)

Using currently SFML and it's easy to understand, what's wrong with it?

SDL2 is great but very low level.
if its 2d I would recommend SFML, if you want 3d consider ogre if its still alive or urho 3d.

or use gotot or a commercial engine, but I have the feeling you're looking for something that is more code-based and low level.

Nope.

Judging from the API reference it looks like a simple library that tries to do too much, tricking you into thinking you can use it for an entire 3D video game when it's probably woefully underequipped to do so
at least SFML/SDL don't pretend to do anything they don't

>Is SDL 2 & C++ a good choice or is there a better one ?
MonoGame with C# is pretty great and works for most type of games. (however if you want 3d it will require a lot of work).

>dx12 is literally vulkan with different name
>apple metal will be based on vulkan because there is no alternative and apple does not create new things
Stop posting.

to follow this up, I looked again and its 3D capabilities are a complete joke, there's more functions for VR than there are for animation and collision combined, there's literally 4 functions for animation, that's a joke

I just hate OOP and SFML doubles down on OOP since it's C++ and therefore everything has to be OOP even when it makes no sense.
Like if I have to draw a hundred rectangles one frame in SDL or Raylib or any sensible library I have a function basically called DrawAFuckingRectangle() that takes some coordinates and size and you just call that a hundred times.
But in SFML you HAVE to create a rectangle object and then call the draw() method on it.
So if I want a hundred rectangles I either have to create a hundred rectangle objects which is horrible for performance, or create a single rectangle object every frame and change it's coordinate and size members a hundred times which is retarded.
Though I don't use it for a 3D game it does have some pretty slick demos that makes it seem like it could do something basic. I do know however that SDL can't be used for 3D games.

Also forgot to mention that it has a pretty nice GUI lib that's supported by the creator. Good luck finding a SDL gui that isn't awful.

>I do know however that SDL can't be used for 3D games
of course it can

For 2D stuff, SDL2 and C++ are excellent choices.

Nope you would have to use OpenGL and if you start using that you can't mix SDL draw calls.
SDL has 0 functions for animation.

You can use a vertex array, slap everything in it and just draw it once

I'm no expert but the wiki says Trine uses SDL, that's a 3D game
The thing is low-level libs leave animation up to you, Raylib provides you with a model/animation system which is extremely fucking sparse that doesn't do anything useful
the former is better

By using Rust of course

Honestly OP dont.
If you are making a NES/GBC style game I have an engine you can have for free. Its written in C with raylib. It handles input and raster effects and sprites.

If you want a roguelike use bearlib, tcod.

If you want anything else just use an engine.

>So if I want a hundred rectangles I either have to create a hundred rectangle objects which is horrible for performance
use your own allocator if you think it's bad for performance (it's not, you'll be iterating over your own data structures anyway to draw them)

Always use GLFW

Unity/Unreal like a normal human and not some tryhard Jow Forumstard

Don't know if that would make it better. I admit it was some years since I used SFML. It's not a bad library though if you like C++ and OOP. It just happens that I don't
I don't know what Trine is but if it's 3D it can't use SDL to draw anything. I can use it to open a window, handle input and sound but all drawing would have to be reimplemented in OpenGL.
But the point is that I already have my own data structures that I can iterate over. But now I would have to create an object every time I want to make a draw call. How can that not affect performance?

The point is you aren't making calls, you're maintaining objects and the calls are done by the library
although I agree you want to make calls yourself if you're doing low level programming

I guess my example is a bit idiosyncratic but but I don't want to have to maintain any object because the number of "rectangles" that I draw varies from frame to frame. Could be 50 one frame and 500 the next. So having a fixed amount of objects doesn't make sense for me, I store everything in a giant array. I admit this is not a standard use case though.

What's /g opinion on Allegro?

While listening to his video where he talks about how the LoC have increased over the years all I could hear was "I'm old and tired, why is everything so complicated now? Bring back BASIC and linear programs. What's optimization, multitasking, or modularity?"

It sounds like you're afraid of simple A-level maths m8. I agree you need to know lots about maths to make a game engine but not the way you think. It's more about optimizations and making things run smoothly by having a good engine design, most of the math is understanding efficient algorithms and how to get the most out of your hardware.

And before you ask no I'm not a game dev but I've written several (failed) engines in my free time. The common factor in their failure has always been the lack of planning and poor optimization.

for 3d engine dev you need a SHITTON of math

People who use sfml sdl glew are disgusting.

Attached: game_dev.png (1585x917, 66K)

>c++
lmao

it just needs linear algebra. Also what programing doesnt need math ? are u a webdev or something?

SFML is better.

>link to msdn
>for winapi
um sweaty...

Just use bare OpenGL or Direct3D.

Remarks
If hdc references a window, calling the SetPixelFormat function also changes the pixel format of the window. Setting the pixel format of a window more than once can lead to significant complications for the Window Manager and for multithread applications, so it is not allowed. An application can only set the pixel format of a window one time. Once a window's pixel format is set, it cannot be changed.

sure, Tell me you remember this kind of pitfalls?

Frameworks and libraries are one thing, but using full-lifecycle third party software is like herding cats. Learning its quirks takes about 10 times the amount of effort as just writing one myself. They're only good for huge projects because you need to standardize the codebase.

For smaller indie projects they're a crutch used by people who can only code by using google.

I remember a Webdev was asking on Jow Forums how to order object in a circle

sure for game engine you need a lot of math but u are not gonna proof a new Theorem. most of the stuff is ez and you can look it up somewhere.

i use 3 lines of eigen do you really think i should write my ownd solver for sparse linear systems?

Many people learn to write code. only a few can read code; so sad!!!

sdl2 uses gpu faggot.

>i use 3 lines of eigen do you really think i should write my ownd solver for sparse linear systems?
Do you really not know the difference between a library and a fully-integrated and bounded production framework?

Using Eigan is like using OpenGL.
Using a pre-made game engine is like using Matlab.

Absolutely based. I'm personally thinking about trying Direct3D

>SetPixelFormat
does not exist in my windows

2d game dev requires significantly less math.

>t. zero drive to learn or be original

Yes.
>inb4 reverse engineer your bideo driver

This. Unless you're really sure, I'd recommend using an existing engine.

SDL is okay for 2D games
not great, but okay

What if I told you that the original roller coaster tycoon was almost entirely written by one man (only sourced work was some sprites and audio) in x86 assembly without any third party libraries?

Would your pea brain head explode?

Attached: RollerCoaster-Tycoon-Classic-background_495fc81621674fd179ecabb23b7dda87-xl.jpg (1440x765, 514K)

To continue, everything you mentioned is standard undergad curriculum. Everyone with a bachelor's should have done some basic ray tracing with blin phong, some rasterization, triangle mesh stuff, etc. That is not PhD level work.

A basic game engine is a fun task even if you never finish your game. Go for it, op.

i just google the solution you fool. why would i do it my self if theres alibrary that already does it, you fucking mongoloid programers think that we rewrite every month a fucking spacial wheel? are you out of yor mind? aint botthering wit this bulshit suck dick faggot