Learning about how games work, do i have this backwards?
#1 Members - Reputation: 113
Posted 12 March 2012 - 07:58 AM
So after that long winded post, how much abstraction is good in learning about how to develop a game and its systems? Or is it best to use the highest level tool you have because one could argue," why not use assembly", and even lower level stuff. I like Java a lot and I am not a big fan of manual memory management, but is this ok if I want to learn more about how games work using java and LWJGL?
Thanks
#2 Members - Reputation: 2369
Posted 12 March 2012 - 08:27 AM
how much abstraction is good in learning about how to develop a game and its systems
Depends on abstraction. OGl/LWJGL/etc. are just APIs. The abstraction they provide is the graphics pipeline, something which has been defined formally in every intro computer graphics class. Another topic is linear algebra.
Java is not relevant here either, it's just another language and if using OGL it does it the same way. They are just convenience implementation which may cut down on some boilerplate code.
Unity and MonkeyEngine provide different abstractions again, including scene and asset management, the usual simulation logic and perhaps a few more things.
First learn linear algebra, there are plenty of courses since it's typically intro level. Next look into rendering pipeline, it's often more advanced (perhaps 3xx type course), but concepts are universal across just about all APIs. Only thing related to implementation is the pre-/post-shader approach (DX9 vs. DX10+).I dont know why 2d coordinates start in the top left corner, nor how 3d graphics seem to work.
Because it's not only not an abstraction, but also not very practical or useful. Assembly is just means of encoding a concept for given hardware. It does nothing to help understand computer graphics better.why not use assembly
#3 Members - Reputation: 113
Posted 12 March 2012 - 08:43 AM
#4 Members - Reputation: 2369
Posted 12 March 2012 - 09:02 AM
That is why I thought that if one argues to go lower level you could eventually hit assembly and eventually hit a why bother.
In many ways, shaders are a form of GPU assembly. So are SIMD instructions which are common in graphics algorithms since they are a good fit. But learning those will not teach the concepts behind graphics.
Main high-level concepts are:
- fixed/variable time step simulation
- linear algebra, forms the basis for representing 2D/3D spaces
- graphics pipeline, somewhat hardware-specific, since hardware evolved around proven concepts
Technologies:
- toolchain - vague, but perhaps important to make as transparent as possible, the *real* value of engines
- platform - Flash vs. native vs. sandbox vs. ... It defines the constraints and trade-offs
- language and APIs - defined by platform. While in general there are few restrictions, some are good fit, others are not. On Windows, Java + DX is a very poor fit, even though it's technically doable.
The only stuff that really matters:
- Fun and getting other people to like what you build. Nobody will ask how it was built.
#6 Members - Reputation: 2369
Posted 12 March 2012 - 09:58 AM
Yes.Little off the subject but what did programmers do before there was Directx or any other Graphics API? Did they make there own? Was game programming in DOS before there was Windows much more difficult then it is today?
In the 90s era, before Voodoo launch, you had either ModeX or similar common video modes or later VESA. There was a list of memory addresses and interrupts (mov ax, 13h; int 10;). Then you simply wrote to screen buffer. If you wanted to draw a line you implemented Bresenham's algorithm. Same for circle. And polygon fill. Or just wrote to memory directly. There were libraries (Pascal had BGL), which were fairly high level and user friendly, but slow. And slow back then mean that filling a circle could take 5 seconds compared to 120fps that was possible using tweaked assembly.
Before that, Hercules graphics or such was really basic. You would look up which chip does the logic, add a ram chip, solder everything and that was it. A "graphics card". It would be just part of memory you wrote to and read from, like the rest of code. GPUs still work in mostly the same way, but those parts were hand assembled from off-the-shelf components and they worked.
On home computers, it was similar. Graphics were mostly non-existant, but certain chips could be forced to do graphical stuff. If they supported sprites, you'd use that. Then there were hacks, such as redefining the look of fonts so that characters would form graphics. There were no standards, you read through the chip specs.
Interestingly, there were some types of graphics which were absurdly trivial compared to today. Parallax scrolling is one such effect, it was just a single shift with no abstraction in between, making it effectively free. Today one would likely need to move a texture around through entire driver architecture or use a shader which is again an incredibly complex framework with compiler in between.
There were tons of books on tweaks and hacks and obscure algorithms that made things possible at all. These tweaks are still largely present today deep in drivers or hardware, but exposing the to end user simply isn't viable let alone useful. Most were just techniques which were a good fit for hardware.
But considering I can do canvas.drawTo(...) today and have hardware accelerated graphics running instantly in any browser, old times are best left forgotten.
I'd even argue that using DX/OGL today is a bit low level. One is much better off using stuff that gives you entire character with skinning and animation or pathfinding code or such.
Knowing the APIs is still useful if doing phone or similar development, it allows much more direct and lightweight approach. But it's increasingly hard to justify development effort in commercial setting given given how much middleware is available.
#7 Members - Reputation: 448
Posted 13 March 2012 - 06:23 PM
It just depends on what you want to learn and accomplish. If making games is your goal, there's no reason not to keep using Unity or whatever other engine you want to learn. If you want to learn more about how graphics works under the hood, then OpenGL or Direct3D is probably what you want to study. And if that's your goal you'll want to get into the linear algebra stuff sooner rather than later.So after that long winded post, how much abstraction is good in learning about how to develop a game and its systems? Or is it best to use the highest level tool you have because one could argue," why not use assembly", and even lower level stuff. I like Java a lot and I am not a big fan of manual memory management, but is this ok if I want to learn more about how games work using java and LWJGL?
Thanks
#8 Members - Reputation: 1257
Posted 14 March 2012 - 03:05 AM






