Jump to content

  • Log In with Google      Sign In   
  • Create Account


Learning about how games work, do i have this backwards?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 timetopat   Members   -  Reputation: 129

Like
0Likes
Like

Posted 12 March 2012 - 07:58 AM

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

Sponsor:

#2 Antheus   Members   -  Reputation: 2385

Like
1Likes
Like

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.

I dont know why 2d coordinates start in the top left corner, nor how 3d graphics seem to work.

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

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.

#3 timetopat   Members   -  Reputation: 129

Like
0Likes
Like

Posted 12 March 2012 - 08:43 AM

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.

#4 Antheus   Members   -  Reputation: 2385

Like
0Likes
Like

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.

#5 ILoveJesus   Members   -  Reputation: 166

Like
0Likes
Like

Posted 12 March 2012 - 09:39 AM

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?

#6 Antheus   Members   -  Reputation: 2385

Like
2Likes
Like

Posted 12 March 2012 - 09:58 AM

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.

#7 Suspense   Members   -  Reputation: 449

Like
0Likes
Like

Posted 13 March 2012 - 06:23 PM

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.

#8 LorenzoGatti   Crossbones+   -  Reputation: 2310

Like
0Likes
Like

Posted 14 March 2012 - 03:05 AM

Regarding, specifically, JmonkeyEngine vs LWJGL: what are you drawing? Do you have models, textures, lights and scene graphs in general, for which an engine is suitable, or do you stuff low-level data into nontrivial buffer structures in order to run your custom shaders, for which you don't need any library help besides taking care of OpenGL contexts and other objects? If you need something special, does the graphics engine allow you to make arbitrary OpenGL calls?
Produci, consuma, crepa

#9 darksheikh   Members   -  Reputation: 102

Like
0Likes
Like

Posted 14 March 2012 - 09:03 AM

I'd recommend any starter to start with DirectX. You'll learn all the foundation that way.
Live Television: http://www.hdlivestreams.com
Online Shopping: http://www.shoppynow.com




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS