How feasible is it to make an OpenGL game without using any libraries?

How feasible is it to make an OpenGL game without using any libraries?
How feasible is it to make a Vulkan game?

Other urls found in this thread:

vulkan-tutorial.com/code/hello_triangle.cpp
handmadehero.org
opengl.org/documentation/
twitter.com/SFWRedditGifs

opengl IS a library

if you don't know OpenGL, Vulkan is a hilarious waste of time

i want me some cat girl puss

>that pic

I thought he was gonna suck some dick :(

Why would you even want that?
OpenGL is awful. Awful to use, awful performance wise.

That's not a catgirl, that's a disgusting furry.

>How feasible is it to make an OpenGL game without using any libraries?
You are retarded if you do this.
>How feasible is it to make a Vulkan game?
You are retarded so this is impossible too.

You'll need OpenGL, which is a library.
You'll also probably want GLEW and maybe GLFW
I've done a few small games and it wasn't that hard.
I'd recommend staying with OpenGL 1 if you're just doing really basic 2d games. OpenGL 2+ is a pain in the ass to work with.
You'll also need an audio streaming library.

>OpenGL is awful. Awful to use, awful performance wise.
What alternatives are there to OpenGL? Nothing else has anything close to the platform support that it has.
I do agree that OpenGL 2+ is awful, but OpenGL 1 is really comfy to use for simple shit. It's nothing compared to vulkan though; it takes hours to draw a fucking triangle in vulkan.
The performance of OpenGL is fine if you aren't doing thousands of draw calls.

>How feasible is it to make an OpenGL game without using any libraries?
Well that's a non-starter because OpenGL is a graphics library.
I guess you mean without using any additional libraries?
It isn't fun but it's doable. There are several OpenGL tutorials that you can follow , but there are some limitations

A) Your program will be shit and unoptimized
B) It will lack features because you're too lazy to program them in
C) It's hell to debug/build in because you have to recompile everything every single time

>Vulkan
Stop right there criminal scum.

Here's the code for a hello world in Vulkan.
It's so long I can't even paste the code here.
Meanwhile the same shit can be done in OpenGL in like 2 dozen lines.
vulkan-tutorial.com/code/hello_triangle.cpp

>A) Your program will be shit and unoptimized
It'll probably be worse on a real game engine because you'll just end up with a fuckton of unnecessary shaders being run on the image. I've seen enough 2d unity games that struggle to run at 60fps on my GTX480.
>B) It will lack features because you're too lazy to program them in
You can make this argument about just about anything.
A game made by someone who has to ask this question is going to be shit anyway. At best, it's going to be a learning experience.
>C) It's hell to debug/build in because you have to recompile everything every single time
I've built several OpenGL based games and they take maybe 10 seconds at most to compile on a system from 2011. You rarely have to recompile the entire program anyway.

>Meanwhile the same shit can be done in OpenGL in like 2 dozen lines.
Only if you're using OpenGL 1 and GLFW (or something similar).
The code required to open a window and initialize OpenGL is going to require a lot of lines of code. I vaguely remember doing that on Windows once and it was at least 50 lines to create a window and a message queue, then initialize OpenGL. With GLFW you can do that in 4 lines, but that violates the no libraries thing.
For OpenGL 2+, after it's initialized you need to set up a VAO and some VBOs, then compile your vertex and fragment shaders. That's going to be a few hundred lines at least.

Still better than Vulkan though.

For what purpose? OpenGL is a library itself. What do you mean user?

>It'll probably be worse on a real game engine because you'll just end up with a fuckton of unnecessary shaders being run on the image.
Well who's fault is that? The game engine or the developer? Any developer worth their salt will not run too many shaders. Plus, many game engines, such as Unreal, will actually attempt to optimize your shaders during compilation. This is an extra feature you'd have to implement yourself and is not available as a library call.

Speaking of optimization, there are a LOT of non-trivial shit you'd have to redo if you wanted to add things like particle systems. The naive approach won't even run at anything past 1 fps, and the unity/unreal engines have super optimized particle systems and UI systems that took several PhDs several years to get running. That's just 1 system.

>You can make this argument about just about anything.
No. Because if the engine you're using has everything you're just not using it, who cares. Going back to particle systems any Unity dev can just shit up something and have it run better than any approach you do from scratch (unless you happen to be a grad student)

>I've built several OpenGL based games and they take maybe 10 seconds at most to compile on a system from 2011.
10 seconds every time you want to see a change is a lot of dev time. Even 1 second is a lot of dev time. Unity/Unreal have WYSIWYG views which mean you never have to assume anything, you can see it run as you develop it.

>10 seconds is a lot of dev time
I was working on Endless Sky which took 2 minutes to recompile, and the only time the compilation time became a real issue was when I wanted to find out what worked well instead of program something that had to work in a specific way.

This.

This especially.

Opengl is not a library. It's an API

Eh semantics, really.

No it isn't.

What is the A that the P is I'ing with? Oh, right, the Graphics Library. How can something be "just an API"? They just call it that because the underlying implementation can vary depending on devise while the calls remain the same, but no matter what you're dealing with an OpenGL library.

Very feasible.
You might find this interesting.
handmadehero.org

OpenGL is a specification. Retard.

If you understand OpenGL it's really not that hard. And if you want to do anything remotely unique about your rendering methods (not just your assets) you're probably going to need to know OpenGL. Not that there's anything wrong with just using cookie cutter rendering methods with good assets, just saying that getting the graphics pipeline working using OpenGL is really not that much code so it's really not that much of a massive undertaking compared to the rest of the game. It's just a lot to learn especially for someone without Linear Algebra in their background.

Don't bother with Vulcan as an independent developer, though. That's not its use case.

Not that guy, you're weird. You seem to understand what opengl is. You even distinguish it as an API but then you turn around and call it a library despite having explained its an API.
The point of it being an API and you writing opengl oriented code is that you're targeting the API, not the 'library' or driver+api.

This is a moronically pedantic argument in the least possible productive sense.

The point is that if you're using OpenGL you're using a library. An OpenGL library. One of many, but a library all the same.

Pedantic? You're arguing about the nature of opengl. Of course we have to be pedantic. We can't just throw words out the window.
You could have multiple api to the same underlying library. You could have multiple libraries fitting the same api.
If we ignore this distinction why even have the word api?

To me it seems you said something that wasn't well thought out and you just want to be right. You're not though. Opengl is an API.
You can ask any reputable source and they should provide you with this answer. Consider Wikipedia for instance.

You'll need some libraries user, but nothing too heavyweight - GLEW for extension handling, SDL2 for window management and input handling for keyboards/gamepads/mice, SDL_audio for sound, and one or two others, but if you stick to those you can build cross-platform stuff pretty easily and roll your own game engine that works on Linux, OSX and windows with just a recompile.

You don't understand what openGL is. No, it's not a library. There are libraries that implement the openGL API (and spec). These exist driver-side and exist to, in lay term, map the API to GPU functionality. That's not what openGL is though. openGL is an API and a specification detailing the functionality and a very high-level implementation (not concrete) of the API, i.e. calling x should do thing1. There are graphics libraries that use openGL to accomplish specific graphics tasks yes, but those aren't openGL either. OpenGL is an API and specification.

you are fucking retarded

what does opengl stand for again you retard?

From Khronos's site.

>OpenGL is the industry's most widely used, supported and best documented 2D/3D graphics API making it inexpensive & easy to obtain information on implementing OpenGL in hardware and software.
>2D/3D GRAPHICS API
>GRAPHICS API
>API
opengl.org/documentation/

You can even read their specification document and see that it's not a library. Next you'll tell me that direct3D is a direct to hardware 3D library.

DirectX gets coverted to OpenGL

>Open Graphics Library
>Not a library
top kek