next »

[NilGAYman]

Hello
Im a new game developer and Ive been looking for ways to create my own game engine, cause yes. And ive been wondering if OpenGL is a good api and also how do I use it/download it. Thank you!


ps.
Im a new member so when I was creating my account I received an email from a @flashbang.biz email account to activate my accont, is this an official tigsource email?

[ThemsAllTook]

Welcome!

I'd say OpenGL is a pretty good choice. Recently, there have been some APIs that aim to supersede it (Vulkan on non-Apple platforms, Metal in the Apple world), but I don't think OpenGL will be going away any time soon. learnopengl.com is a fantastic learning resource that goes over everything you should need to know.

ps.
Im a new member so when I was creating my account I received an email from a @flashbang.biz email account to activate my accont, is this an official tigsource email?

Now this is interesting. TIGSource is physically hosted by Matthew Wegner, who used to run Flashbang Studios, which seems now to redirect to flashbang.biz, which seems to be something unrelated... I'm guessing at some point the domain name was purchased and set up to redirect. The back-end administration and hosting of this site is a complicated situation, so it looks like this was something that slipped through the cracks.

[NilGAYman]

So am I good? Cause I checked the link I was sent and it was "forums.tigsource.com" (sorry im just really paranoid)

[ThemsAllTook]

Seems like it. You're able to post, so your account must have been activated successfully. flashbang.biz itself won't have any knowledge about the e-mail being sent or your interaction with it, as long as you don't send a reply for some reason; it sounds like it's just a matter of the From: header being set to a domain that no longer exists as it did.

[NilGAYman]

is openg.org the official website of opengl?

[NilGAYman]

opengl.org I mean

[mtorc1]

is openg.org the official website of opengl?

No, the OpenGL standard is maintained by the Khronos Group https://www.khronos.org/

[michaelplzno]

Hi @NilGAYman

I recommend using an engine instead of working directly with OpenGL. Something like Unity gives you a lot of extra stuff, asset loading, culling trees, fonts/UI, and other game engine stuff that you would have to write yourself if you just work directly with OpenGL.

Just a thought.

[Andersk]

I agree 100%. Unless you REALLY REALLY want to do a lot of things from scratch (which hey I can respect that) then I would suggest going with a game engine to do a lot of the workload for you since you're a new programmer. There's no shame in using an engine!

[J-Snake]

My main concern with Opengl was performance consistency (more so with "Modern Opengl" than with legacy Opengl) a few years back. Unless you make extensive use of batching (submitting a lot of render-information to the gpu in a single draw-call), you might experience ocassional stuttering even in a 2D game with moderate rendering demands. That might already happen with only 400 sprites on an average laptop (but when you batch them then up to 100.000 might be displayed without hitching). While the overall performance maintains a set framerate even with a heavy load to render, the problem is all about the occasional stutters. For CAD programs it is perfectly acceptable, but less so for games.

It all depends on the driver implementation of Opengl, and it is possible that the situation has improved now. I haven't checked yet.

But if you want to make a sprite based game that only relies on blending operations, then the SDL2-renderer will probably suffice. In that case you can just conveniently use SDL2 for everything without touching Opengl/Direct3D/Vulkan/Mantle...(as SDL2 wraps the usage of those render APIs). In its recent iterations it also makes use of batching without you even noticing it. Of course it will not compete in the render performance department, but you can roughly expect around 30.000 stutter-free sprites on an average laptop. Should be enough for most sprite based games. Also note that when your sprites are rather large, you won't pump them out in those huge quantities anyway as the render performance will mainly depend on the fill-rate of your gpu, not so much on the render API you are using.