I am someone who uses unity 3d and a lot of engines and some very high level frame works a lot. I was thinking to myself recently that I dont know how many of these things work, or in fact why. I dont know why 2d coordinates start in the top left corner, nor how 3d graphics seem to work. I just know that they do. This troubled me and I wanted to learn more. I figured as someone who wanted to specialize in software development It would be good to focus on those topics. I know a lot of java and I decided maybe I should look at LWJGL and try that library. It seems great. A way to use many gl calls in java and learn about more advanced topics. I then was reading that JmonkeyEngine used LWJGL and that it would be a better idea to use that because in the end i would be (at best) recreating that tool. This started to perplex me about how abstraction works with what I type in to how it actually works. I then thought to myself maybe it would be best to use regular OpenGL and SDL instead of LWJGL to learn. This got me thinking that you could infinitely go down the chain of lower level languages and Ideas until you got to binary.

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

how much abstraction is good in learning about how to develop a game and its systems[/quote]

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.

I dont know why 2d coordinates start in the top left corner, nor how 3d graphics seem to work.[/quote]
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+).

why not use assembly[/quote]
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.

Thank you for the advice. I see what you are saying and I thank you for the leads(Linear algebra,into to computer graphics,etc). The reason I brought up assembly was because I took a course on it and it was very painful for me and it was the lowest level things I dealt with. That is why I thought that if one argues to go lower level you could eventually hit assembly and eventually hit a why bother.

That is why I thought that if one argues to go lower level you could eventually hit assembly and eventually hit a why bother.[/quote]

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.

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?

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?

Yes.

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.

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

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.