Jump to content
  • Advertisement
Sign in to follow this  
Nicholas Kong

Why is low level programming used to create great games?

This topic is 1781 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Why deal with binary and assembly to create great games? What is the result the programmer get out of performing low level programming on the games?

Share this post


Link to post
Share on other sites
Advertisement

Handcrafted assembly was used to create games for older systems such as the NES and SNES. It was necessary to write the code in assembly since the processors of those systems were slow. By writing the assembly code by hand, the programmers could make efficient use of every last bit of processing power through various methods and tricks. As previously mentioned, this is no longer needed to create games since processors have gotten faster and compilers have gotten better at optimizing high level code when translating it to machine language.

Edited by Ludus

Share this post


Link to post
Share on other sites

Assembly isn't really used for programming games anymore other than to debug some really tricky bugs.  Modern compilers can optomise better than hand coded assembly.  Also the assembly that was optimal 10 years ago may not be optimal on a newer processor.  Even for stuff like SSE it is more common to use intrinsics.

Share this post


Link to post
Share on other sites

To complete the previous answers most of the time you don't need to write assembly (and likely never), but like any other domain that need high performance, you DO need to know how most of it works to perform some optimization.

Edited by Titan.

Share this post


Link to post
Share on other sites

last time i has to go to the metal was about 1993, assembly code for a real time blitter that did blit, mirror, zoom, and rotate simultaneously.  As i recall, this was with Watcom C++, and the target PC was a 386, or was it a 486? it was one routine, about 1 and a half screens of code. the phreaker on the team wrote it in about a week. i spent another week tuning it for max performance. 

Edited by Norman Barrows

Share this post


Link to post
Share on other sites

Well, I should just add that for this discussion I think that C++/C would be considered a lower level language as well, considering that most AAA games/engines are written with it.  The reason for this is that you get the control and speed, and moreso the lower you go, with Assembly being the ultimate in control and speed, though as stated above that has changed with the modernization of compilers.

 

That doesn't mean development speed is faster.  A game can usually get created much faster in something like UDK/Unity/Shiva/GameMaker than by programming it in low level languages.  But, this assumes that one of those programs/frameworks has the requirements you need for your game, and you know how to use them.  For most indie games, that is the case, but for AAA studios, they want/need lower level access to things that most indies just don't need.  For example, Unity's scripting as pretty fast, relatively speaking, but it won't be as fast as well coded C++.  It will beat badly coded anything though :)  Some AAA games really need that speed, for example because they would like to release for as low-grade of hardware as possible, while not loosing any gameplay(which in general many AAA games still suck at).

 

In reality, for us indies, the best solution is something like Unity or GameMaker most of the time.  We don't usually need to lower level speed of C++, rather we need lower development times.  Our games aren't going to beat out AAA games in sales, so to survive, we need to make more and more fun games, without spending too long on the art assets required for AAA engines.  And then, the creators of Unity and GameMaker are both smart enough to include ways to use external code created outside of the software.  The interfaces sometimes are limited, like GameMaker being limited to char* strings and doubles when sending/receiving from DLLS, but from that you can do almost anything, and the same applies to Unity's plugin thingy.  So in this end, us indies get the best of both fast development and access to lower level languages.

Share this post


Link to post
Share on other sites

Being able to read assembly is a valuable skill to have when debugging any kind of system-level software.

Quite a few times I've seen someone exclaiming "Argh, why is my [insert complex C++ code] crashing here", when a veteran swoops in with a hexadecimal memory and assembly code viewer, tracing through the code to point out a now-obvious point of failure....

 

Not sure what you mean with "binary". Binary file formats (i.e. not text / human-readable file formats) are used for efficiency. I can parse a binary model file in a several microseconds, compared to several milliseconds (or seconds) for an XML file tongue.png

 

 

Also, all of these details -- low-level stuff -- belongs in the inner workings of game engines.

 

Actual games are often not written in a low-level language, because they don't have to be. Games are often written in "productivity" languages, like Lua or Python or C#, to lessen the required time/budget required to build them.

 

Only the really performance critical parts (i.e. the engine) are worth spending an excessive amount of time working on. Lower level programming is more verbose and explicit, which lets you ensure that things are occurring in a very precise way (often for performance), but the flip-side is that this requires more time, and more experienced staff.

 

When you're calculating 10,000 animated transform matrices (an engine task) then that becomes very computationally expensive -- it takes quite a bit of CPU time, which means it has an impact on the FPS counter. This means that you start to care about clock cycles, branch mispredictions and L1 cache behaviour, which are issues that low-level languages allow you to address.

 

When you're deciding which animation a dozen characters should choose next (a game task) -- this doesn't take a lot of CPU time -- then you don't care about micro-optimizing all those low-level details to gain back an extra nanosecond of time, so you're better off using whatever language makes it easiest to solve the problem in an elegant way.

by binary I mean base two numbers: 0 and 1

Share this post


Link to post
Share on other sites

Well, I should just add that for this discussion I think that C++/C would be considered a lower level language as well, considering that most AAA games/engines are written with it.  The reason for this is that you get the control and speed, and moreso the lower you go, with Assembly being the ultimate in control and speed, though as stated above that has changed with the modernization of compilers.

 

That doesn't mean development speed is faster.  A game can usually get created much faster in something like UDK/Unity/Shiva/GameMaker than by programming it in low level languages.  But, this assumes that one of those programs/frameworks has the requirements you need for your game, and you know how to use them.  For most indie games, that is the case, but for AAA studios, they want/need lower level access to things that most indies just don't need.  For example, Unity's scripting as pretty fast, relatively speaking, but it won't be as fast as well coded C++.  It will beat badly coded anything though smile.png  Some AAA games really need that speed, for example because they would like to release for as low-grade of hardware as possible, while not loosing any gameplay(which in general many AAA games still suck at).

 

In reality, for us indies, the best solution is something like Unity or GameMaker most of the time.  We don't usually need to lower level speed of C++, rather we need lower development times.  Our games aren't going to beat out AAA games in sales, so to survive, we need to make more and more fun games, without spending too long on the art assets required for AAA engines.  And then, the creators of Unity and GameMaker are both smart enough to include ways to use external code created outside of the software.  The interfaces sometimes are limited, like GameMaker being limited to char* strings and doubles when sending/receiving from DLLS, but from that you can do almost anything, and the same applies to Unity's plugin thingy.  So in this end, us indies get the best of both fast development and access to lower level languages.

what does badly coded mean? is it determined by coding syle or not optimized code?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!