Which programming language did you choose and why?

[Stormcrowfleet]

Thanks for everyone that chimed in to answer my question. Rincewind for the record I'm not doing this for video game development. I'm doing this to get a job yes, but not in vidya. I'm trying to get a steady job. To make story short, I was in the military for 10 years and studied up to Doctorate in history on the side. Now, there is no job in history as we all know, so I'm aiming at something decent. I did HTML back in the day and all my friends are programmer, so I decided to try out to become a programmer (either web or app, don't know yet). So I enrolled in an official program.

For now we will be learning Java, C#, C++, SQL, CSS/HTML. On my own I'm doing other tutorial and online courses (MOOC or whatever). Then, from what I understand, I'll specialize in whatever my job will be when I get one.

Just trying to learn for now and not think about all of this.

 

[CaffeineConquistador]

A PhD done while in the military? Shit, you obviously have the drive. You sure there’s nothing you can do with that?

 

[Stormcrowfleet]

A PhD done while in the military? Shit, you obviously have the drive. You sure there’s nothing you can do with that?

It's less cool than it sounds. I ended up transfering to what we have here in Canada "part time military", i.e. the reserve. Therefore I alternated between 4-5 months of full time where I studied less and did more military stuff, and my studies. As for the PhD, it's not done yet. But even with it, there isn't much to do here in Canada.

 

[Rincewind]

For now we will be learning Java, C#, C++, SQL, CSS/HTML.

Yep, if getting a job is the goal, these are solid choices. I'd probably remove C#, it's kind of redundant if you're learning Java, you can always pick up C# easily later if you have Java knowledge. If employability is your main goal, I'd put JavaScript on your list.

Little bit of C++ doesn't hurt, but most likely you'll never use it, unless you're doing game dev or high-performance computing. So I'd still drop it or just learn some C.

Once you got the basics down, SICP is still highly recommended for the sheer mind expansion it will trigger in you

Good luck

 

[Stormcrowfleet]

For now we will be learning Java, C#, C++, SQL, CSS/HTML.

Yep, if getting a job is the goal, these are solid choices. I'd probably remove C#, it's kind of redundant if you're learning Java, you can always pick up C# easily later if you have Java knowledge. If employability is your main goal, I'd put JavaScript on your list.

Little bit of C++ doesn't hurt, but most likely you'll never use it, unless you're doing game dev or high-performance computing. So I'd still drop it or just learn some C.

Once you got the basics down, SICP is still highly recommended for the sheer mind expansion it will trigger in you

Good luck

Not really my choice for language ! It's an official program so I'm going with it. I'm already putting some JavaScript on the side with Python. I took note of SICP and others !

 

[Chris Koźmik]

C++ with "Cyber Dreams Engine" (my own custom made engine, SDL+OpenGL+a lot of nice features popular engines do not have) plus some LUA (for scripting).

Made 3 commercial games using this setup.

 

[Tramboi]

Nice, I hate OpenGL (and the supporting drivers) with a passion but it was mandatory for portability before Vk.
This said switch to Vk in the future and it will make your Switch (for instance) ports much easier
Can you elaborate on your "nice features" ? I'm always curious about custom engines !

 

[Chris Koźmik]

Nice, I hate OpenGL (and the supporting drivers) with a passion but it was mandatory for portability before Vk.
This said switch to Vk in the future and it will make your Switch (for instance) ports much easier
Can you elaborate on your "nice features" ? I'm always curious about custom engines !

It's ported to Switch already
As for nice features, well, mostly stuff to make my life easier. Since I make 2D (or 2D-like with a bit of 3D) turn-based games and no engine on the market caters to those (it's all aimed at 3D FPS with few exceptions maybe). For example I have an extensive tooltips support, on they fly image loading (unfeasible for games with tons of gfx assets, so no one except me uses such system), advanced text system (with adjusting, shadows, etc), cute simple GUI system, primitive ZX-Spectrum like screen coordinate sytsem (with 0,0 at the top-left of the screen), pixel perfect display as a default mode, auto screen resizing, built in-game dev panel, localization support, online achievements system, etc.

Basically, no one makes those in their engines because they all focus on "number of polygons", "performance" and "graphical excellence". No one cares about stuff like text manpilation or 2D GUI (which in reality takes like 50% of development time, or more, if you make the kind of games I make), all they care about is if the explosions will look cool or how efficient the enviroment destruction physics is (what would I need those in the first place for my retro turn-based games? :D).

 

[Tramboi]

Yes I saw this but now the Switch supports Vulkan on top of the proprietary API so you can factor lots of code in your engine.

 

[vlzvl]

It seems to me Vulkan is an overkill if you only want to make 2D games or simple 3D ones.
The sheer complexity involved in Vulkan code and/or converting to it from say OpenGL, is not worth the time & extra frames that it offers.
Vulkan is only for sheer performance on AAA games yay-polygons on latest hardware.

 

[Tramboi]

That's quite right except if you care about porting to consoles. You'll get Vulkan support where you won't have OpenGl support.

 

[Rincewind]

That's quite right except if you care about porting to consoles.

I'm wondering if we'll see OpenGL->Vulkan translation layers coming out in the future for people who really don't need all the flexibility that Vulkan offers.

Having said that, would you still recommend learning OpenGL to someone in 2020 who's not interested in console or AAA game development at all?
My guess is that even if we'll have OpenGL wrappers in the future, OpenGL is a dead end, isn't it? So it will always lag behind in terms of supported features, and if you just happen to badly need just one of those features, you'll need to target Vulkan anyway.

 

[Tramboi]

TBH I've been expecting them as free software for a while and it seems I was wrong !

OpenGL won't go anywhere because it's a standard (albeit a bit shitty ) and lots of proprietary software use it and won't migrate for decades.
I think we'll keep seeing proprietary extensions and standard evolutions in the future.
It's probably a good choice if you only want to only do Linux, Win, Mac.
Vulkan might be more verbose and complicated but it will pay off in the future, IMO.

 

[Bad Sector]

I'm wondering if we'll see OpenGL->Vulkan translation layers coming out in the future for people who really don't need all the flexibility that Vulkan offers.

There is a sort of indirect way :-P. GLOVE implements OpenGL ES (not regular OpenGL) on Vulkan. Then there is Regal which implements regular OpenGL (up to 4.4) on OpenGL ES.

Having said that, would you still recommend learning OpenGL to someone in 2020 who's not interested in console or AAA game development at all?
My guess is that even if we'll have OpenGL wrappers in the future, OpenGL is a dead end, isn't it? So it will always lag behind in terms of supported features, and if you just happen to badly need just one of those features, you'll need to target Vulkan anyway.

Personally i'd recommend it, yes. OpenGL is much easier to work with than Vulkan (especially if you ignore those saying to avoid pre-OpenGL 3.0 stuff, the vast majority of them just parrot whatever they have heard without thinking much why what they parrot was said) and chances are if you aren't going for modern AAA style visuals you wont hit any performance bottleneck.

But more importantly, the graphics API isn't really that important - it is the algorithms that matter most and by far and you can transfer that between graphics APIs easily. Unless you are working on a minimalistic renderer, chances are the code that works with the graphics API will be only a very small part of the renderer's code (and, fwiw, the renderer itself will be a small part of a game engine anyway). So you can use OpenGL and if your renderer needs better CPU performance (if you are GPU bound Vulkan wont help you, the primary reason to use Vulkan is because the driver is too slow for your calls) you can switch. Chances are by that time you'll also have a much better understanding of graphics in general so it'll be easier to learn Vulkan than if you started from zero.

 

[Chris Koźmik]

I'm wondering if we'll see OpenGL->Vulkan translation layers coming out in the future for people who really don't need all the flexibility that Vulkan offers.

Having said that, would you still recommend learning OpenGL to someone in 2020 who's not interested in console or AAA game development at all?
My guess is that even if we'll have OpenGL wrappers in the future, OpenGL is a dead end, isn't it? So it will always lag behind in terms of supported features, and if you just happen to badly need just one of those features, you'll need to target Vulkan anyway.

There already is an OpenGL > Vulcan emulator/wrapper or some sort IIRC. Never used it myself.

I would say learning the outdated OpenGL (like 1.3 :D) is a good way to grasp how 3D works. Actually, in Legends of Amberland I used OpenGL 2.1.
One advantage of OpenGL is that it strictly supports outdated APIs, so it you wrote OpenGL code 20 years ago, it will still work :D And then, you could focus on improving the gameplay instead on rewriting your engine over and over again.
Of course OpenGL has many drawback, no denying here, and having Vulcan support would be a neat thing, but then if you compare it to the effort needed to do the most basic stuff in Vulcan...

 

[Tramboi]

The problems with OpenGl I encoutered :
* it is a vast state machine with a lots of implicit state so some things are surprising (clear and scissor is a classic issue for beginners)
* you need to manage extensions and versions to do anything meaningful, you'll probably have surprises during QA because you mixed 3.0 and 4.0 stuff
* this magic (even on trivial apps) on certain drivers mean you'll have suprises with stalls in unexpected places of the pipeline (flushes) which can be a pain to debug
* you have big discrepancies between AMD, nVidia and Intel

This said, the fourth point is probably less of an issue when you're doing OpenGL 1.x code

 

[Joined on the 4th of July]

For me OpenGL became much less painful when I figured I could use something like https://renderdoc.org/ for debugging.

 

[Hirato]

This said, the fourth point is probably less of an issue when you're doing OpenGL 1.x code

It's actually at its worst if you use pre-2.0 stuff.

To this day, AMD's official drivers cannot draw lines using 1.x paths without leaking a shittonne of memory.
And if you're using ASM shaders (1.5), the effects they produce are often wrong, buggy, or really slow, on anything other than nvidia.

Just save yourself the pain and stick to a 3.0+ Core profile.

 

[vlzvl]

There already is an OpenGL > Vulcan emulator/wrapper or some sort IIRC. Never used it myself.

I would say learning the outdated OpenGL (like 1.3 :D) is a good way to grasp how 3D works. Actually, in Legends of Amberland I used OpenGL 2.1.
One advantage of OpenGL is that it strictly supports outdated APIs, so it you wrote OpenGL code 20 years ago, it will still work :D And then, you could focus on improving the gameplay instead on rewriting your engine over and over again.
Of course OpenGL has many drawback, no denying here, and having Vulcan support would be a neat thing, but then if you compare it to the effort needed to do the most basic stuff in Vulcan...

Well, i wouldn't recommend someone to learn OpenGL 1.3 due to absence of GLSL, which it came in OpenGL 2.0 as GLSL 1.1 which version i still use as well.
Vulkan is still new, just recently Vulkan went 1.2. It is obviously a thing for the future but to understand its complexity, keep in mind that Khronos also offers V-EZ, which is an easier wrapper around Vulkan because well, it's batshit complex. Memory checks all the time & tons of undefined behaviour.

 

[Bad Sector]

Well, i wouldn't recommend someone to learn OpenGL 1.3 due to absence of GLSL, which it came in OpenGL 2.0 as GLSL 1.1 which version i still use as well.

GLSL is useful but when you're learning i think it is better to have things on screen as fast as possible and learn things in a step-by-step fashion, so personally i'd suggest learning how to put some very basic models on screen first - something like making a planetary system with planets rotating around a "sun" and some of them having some moons and then having a light and a texture. This will teach both general graphics concepts like how matrices can be used and combined (without needing to deep dive into how they actually work at that point) and some OpenGL stuff that will be used later (creating objects - in this case texture objects - and deleting them, loading data into them, binding them, etc).

Then once there is an understanding with that, one can move to writing a shader to replace the fixed function lighting with their own, without also having to struggle with resources, objects, etc. But still using GLSL 1.2 (or less) so that they have access to the fixed function state (so adding support for shaders will be a minor drop-in work).

Then as a next step after that, they can start replacing piece by piece the functionality that OpenGL 1.x/2.x provides, starting with the matrix stack - replacing the glPushMatrix/glPopMatrix that they used to make the planetary system with their own matrices using glLoadMatrix (so their existing code, including GLSL shaders, still work) and having their own matrix stack.

Then move on to replace glLoadMatrix with glUniformMatrix but still on GLSL 1.2. After that they can start getting rid of the pre-2.x stuff, move to core and use more recent GLSL versions.

I think this is a better and much easier way to learn OpenGL because you have working results soon and you only focus on one thing at each step instead of having to learn everything in one go.

Though i think that after you reach OpenGL 3.x there isn't much of a point of going to the 4.x stuff sincethey were largely about doing the same stuff as before except faster. At that point it might be a better idea to switch to Vulkan since i think that if you need the 4.x stuff, Vulkan can actually be simpler (even if more verbose).

To this day, AMD's official drivers cannot draw lines using 1.x paths without leaking a shittonne of memory.

Do you have any example of this? All of my tools (and i think Blender 2.79 too - which i'm using myself - though i'm not 100% sure) use lines with the glBegin/glEnd stuff all the time and i do not remember ever having any memory issues (i'm using AMD). Line drawing is much slower than on Nvidia hardware though, but that is another issue.

 

[Rincewind]

All good points guys about OpenGL vs Vulkan. Then thing is, I am familiar with the old 1.x fixed pipeline and a little bit with the 3.x+ stuff (GLSL etc.) so it seems like for me learning more about OpenGL is the way to go. Not that I'm doing much with 3D coding nowadays, I was just curious about the general opinion. Right now I'm just using NanoVG in a desktop app I'm currently developing, that's the closest I'm getting to OpenGL nowadays

I see a parallel with the high versus low-level language discussion we had earlier. E.g. Tramboi's points seem very valid if you're an engine developer and need total control over performance at whatever cost. Then you'd just pick Vulkan and rest assured that you can always explicitly tell the hardware what to do. But then for people who don't need that level of control, it's easier to just work with a higher-level abstraction (OpenGL), which comes with some performance loss.

Then again, I don't think I'll ever write a game, so for editors and desktop apps OpenGL seems to be perfectly sufficient (like the Blender example Bad Sector mention, a really awesome app).

Although... what has always been botherinig me with OpenGL desktop apps is the 1 frame mouse pointer lag when vsync is enabled. Not sure if Vulkan would help with that, though.

 

[J1M]

I am using Godot. It's an open source engine with a python-like scripting language, but you can also use C# for scripts. I selected Godot through a process of elimination.

a) Epic removed UnrealScript in Unreal 4, replacing it with a visual scripting tool called Blueprints. I cannot fathom being productive with such a tool, and I didn't want to script in C++.
b) Unity allows you to script in C#, but in my experience it is more of a tool aimed at creating prototypes than commercial products. I also find the idea of paying a subscription to use a piece of software abhorrent.
c) Godot appeared to have more of a 2D focus than other engines, which is something I wanted. But it didn't have C# scripting until version 3. You still have to translate a lot of tutorials from Godot script, but it is simple to do if you know C#'s naming conventions. And guess what? When you use a real language with a real IDE like Visual Studio, IntelliSense makes it easy to learn new parts of the API.

I also use Excel as part of the data pipeline. Excel has a lot of useful functions for highlighting and transforming data and Microsoft has created a great C# ecosystem for reading and transforming that data into JSON or similar to import into a game engine.

I like being able to use the same language for the whole project and being able to use advanced language features that scripting languages don't have.

 

[Bad Sector]

I see a parallel with the high versus low-level language discussion we had earlier. E.g. Tramboi's points seem very valid if you're an engine developer and need total control over performance at whatever cost. Then you'd just pick Vulkan and rest assured that you can always explicitly tell the hardware what to do. But then for people who don't need that level of control, it's easier to just work with a higher-level abstraction (OpenGL), which comes with some performance loss.

Yeah though with the difference that if your engine and content are at a level where such a difference between graphics APIs matter, your graphics API-specific code will be only a tiny aspect of the engine you'd need to rewrite whereas rewriting your engine in a different language would be a somewhat bigger task :-P.

Although... what has always been botherinig me with OpenGL desktop apps is the 1 frame mouse pointer lag when vsync is enabled. Not sure if Vulkan would help with that, though.

That isn't really OpenGL-specific, you also get it with Direct3D (e.g. try to play Witcher 3 with hardware cursor disabled - which IIRC it is the default option). Or really any app with double buffering that draws its own cursor. The solution is to either turn off vsync, use some adaptive method that turns off vsync when you move the mouse pointer or just use a hardware cursor (in which case the mouse pointer is drawn by the GPU on top of the framebuffer, bypassing any OS-side drawing).

 

[Rincewind]

That isn't really OpenGL-specific, you also get it with Direct3D (e.g. try to play Witcher 3 with hardware cursor disabled - which IIRC it is the default option). Or really any app with double buffering that draws its own cursor. The solution is to either turn off vsync, use some adaptive method that turns off vsync when you move the mouse pointer or just use a hardware cursor (in which case the mouse pointer is drawn by the GPU on top of the framebuffer, bypassing any OS-side drawing).

Yep, I came to more or less the same conclusion that it's inevitable. However, the OS itself uses the same graphics hardware somehow to achieve superior mouse cursor behaviour at the OS level. I'm talking about the scenario when you drag something with the mouse on the screen; when dragging OS windows (or even something in an old win32 GDI app), the "thing" you're dragging follows the mouse cursor instantaneously, while in your OpenGL app there's always some lag. Sure, disabling vsync approximates the same level of responsiveness, but at the cost of wasting processing power. So I thought maybe there's a way to achieve the same OS level responsiveness in a Vulkan app somehow. Or maybe it's also possible using some OS-specific OpenGL extensions, haven't really looked into it.

 

[Rincewind]

or just use a hardware cursor (in which case the mouse pointer is drawn by the GPU on top of the framebuffer, bypassing any OS-side drawing).

Yeah, so for the record, I'm using the hardware cursor in my windowed-app, plus vsync with double buffering.