In this post, I'd like to take a step back from personal projects and happenings and discuss a point of view that was raised in dialogue during a class:
Student: "Which is better: Learning a graphics API or learning how to use a graphics engine?"
Professor: "Well, what are you trying to do?"
Student: "I'm a game programmer! I want to make games with cool graphics!"
Those were words spoken and raised an interesting question which made me think about this from a game development standpoint: which is better to learn?
Well, after digging around, I came up with quite a few different answers, so here's my take on the issue and the pros and cons of the two approaches.
When we talk about graphics APIs, we assume we're talking about something like DirectX or OpenGL, at least in the games world, or whatever platform specific graphics API we're using.
What we gain from knowledge of an API is usually allot of nice information on how the graphics pipeline is handled for that specific type of system. This allows us to not only know the process of what happens when we attempt to place, light/shade, and display the objects in our scene, but it also allows to know how to perform lower level, specific calls to enhance or alter that pipeline, which allows us in many ways, a high level of customization and flexibility with our graphics.
What we often lose here though is the bigger picture. With doing low level shading designs and protocols, tweaking the OpenGL state machine for specific functionality, or making DirectX properly flush our vertices to the graphics card, we often do not gain a clear perspective of the needs for content management, scene control and organization, or gain the high level flexibility of being able to make scenes on the fly without having to specify low level constructs, prefering to develop our own methods or ignore previous methods for obtaining niche performance goals or what we consider cool graphics effects.
When we talk about graphics engines, which are often mislabeled game engines, we are usually talking about the rendering engines behind things such as the Unreal Engine (not the engine itself, but the rendering part of it), Open Scene Graph, the Irrlicht Scene Engine, and similar products.
What these offer is usually a higher level of abstraction away from the tiny lighting functions and placement functions, and give us access to many fundamental function and entities for placing and creating graphical scenes. With this comes content management, allot of extra math done behind the scenes for culling and clipping we don't have to implement, and much higher ease of use.
Here though, we lose allot of the customization and performance upgrades we can have by directly interacting with the API. Like it or not, most of these graphics engines eventually play with DirectX or OpenGL to accomplish their goals. As such, the process in which everything happens behind the scenes is often concealed from us with these engines. Because of this, when we attempt to make personal customizations for fancy or advanced graphics, we often are forced down to the API level, and usually have to conform to the order and organization specified by the engine, unless we want to get errors.
Hence, my opinion on this matter is this. For someone that wants to just make a game, without the need or want to make lots of special graphics customizations or the gut to live with what the engine offers you, then going with an engine is a much easier and faster way to get your game running. However, if you want to learn the ins and outs of how the graphics pipeline works to streamline the graphics performance and be able to eventually create more advanced graphics effects, learning an API (or multiple) is a much better approach. Personally, I choose a little of both, liking to delve really deep into the specifics of an API to pull out good performance or awesome effects, while developing those skills to fit into an engine like construct.
No comments:
Post a Comment