Archived

This topic is now archived and is closed to further replies.

Assembly in Game Programming

This topic is 5535 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

Hey, I checked through all the recent posts and couldn''t find anything on this topic and the forum search doesn''t work so please don''t flame me if this is a repeat question . Anyway I was wondering if assembly is used much anymore when programming C++ and DirectX? I am wondering weather it is worth continuing learning of Assembly to help build a better graphics engine and whether it is used in the industry? Cheers

Share this post


Link to post
Share on other sites
two words..."Pixel Shaders"

If you arn''t aiming for the cutting edge of 3D game engine development...or are worried about trying to please low end PC owners...then you would be relitivly okay without knowledge of any assembly.

But if you ever want to do console development, or just get the most out of your computer...then some knowledge of assembly basics are highly recommended (every processer is different, which requires different sintax (and assembler)...however the opcodes and such are different, but basic programing logic still applies).

I''d say, stick with it...it can only help

Share this post


Link to post
Share on other sites
learn it, no reason not to. Plus when an employer asks you what you know, assembly ALWAYS looks good. Its the hardest language to learn (besides writing out 1''s and 0''s) so it makes everything else seem easy as pie!

Share this post


Link to post
Share on other sites
I say learn it, I did =) its not heavly used anymore but its something that defanatly helps. it my opinion that compilers today can optimize basic code better than most people (notice basic code & most people =) there are places where assembly code would help improve speed, but the prime reason that I sugest learning assembly is so you know how to optimize code. they''re lots of little tricks & gotcha''s that you learn about when learning assembly that just aren''t talked about in higher level languages (for example using shifts instead of multiplies & divideds when possable, or reorganizing code to take advantage of pipelining, ect)

Share this post


Link to post
Share on other sites
Can anyone recommend a good book on assembly for the PC?

I''d prefer something that would start with the basics, and then preferrably move onto the newer instruction sets like MMX, SSE/3DNow. Something I could use as a good reference.

I''ve already downloaded the Art of Assembly language programming, and a few other tutorials, but wouldn''t mind having a book on the subject.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Mulligan
Its the hardest language to learn (besides writing out 1''s and 0''s) so it makes everything else seem easy as pie!


if you knew how cpu works, youd realize that you are actually writting the 1''s and 0''s when you write assembly.



Share this post


Link to post
Share on other sites
False (the same would apply for any compiler).
Assembly is considered a second level language, while entering 0's and 1's is first level.

I can remember entering straight hexcodes on my C64 with a so called monitor, whilst keeping track of procedure addresses on a paper notepad (yes paper ) It didn't get you anywhere but was fun to do.

Edit: added some melancholy

[edited by - Prototype on October 17, 2002 4:36:04 PM]

Share this post


Link to post
Share on other sites
I myself am not much of an assembly guro but back in my dad''s age (idk..20 yrs ago?) they DID code completly in ones in zeros. I believe he has some code from a pong game he made somewhere... Anyways, can''t speak for myself - can''t find an assembly compiler that''s easy to use :-).

---
Brent Gunning | My Site

Share this post


Link to post
Share on other sites
quote:
Original post by Prototype
False (the same would apply for any compiler).
Assembly is considered a second level language, while entering 0''s and 1''s is first level.

No, the thing is, Assembly converts DIRECTLY into 1''s and 0''s other languages don''t. Assembly really is like writing in 1''s and 0''s but with words and opcodes to make it easier to remember

Share this post


Link to post
Share on other sites
quote:

"Assembly is considered a second level language, while entering 0''s and 1''s is first level." -Prototype

No, the thing is, Assembly converts DIRECTLY into 1''s and 0''s other languages don''t. Assembly really is like writing in 1''s and 0''s but with words and opcodes to make it easier to remember.

Actually assembly *is* a (the) second-level language. Machine (binary) code is the first level, assembly is the second level, and high-level languages are the third level.

That''s because assembly doesn''t convert directly into binary code. What about pseudo-ops? They aren''t included in the machine code; they are simply there to make the code more human-readable.

If you are talking about inline assembly with no op-codes, sure it can be called first level programming, but assembly is generally considered the "second level."

Share this post


Link to post
Share on other sites
And it has variables, data collections, labels and other abstractions which make it a language. It's close to the bone, but still you'll need the assembler to compile your code.
Hex is no machine format and entering "mov eax,24" is quite different from feeding the processor something like "0101011100011101110111".

Edit: this reply was to Hybrid. Considered wasn't the right word maybe, but hey, I'm Dutch

[edited by - Prototype on October 17, 2002 7:55:54 PM]

Share this post


Link to post
Share on other sites
quote:

Actually assembly *is* a (the) second-level language. Machine (binary) code is the first level, assembly is the second level, and high-level languages are the third level.



Actually...machine language (or binary)...is *THE* base language [0]...assembly is the first-generation language [1] developed inorder to make programing easyer...second-generation languages are COBOL and FORTRAN again developed to make programing easyer...third-generation languages are PASCAL, C, and BASIC (developed to make programing easyer, but also to re-inforce 'structured' programing techniuqes)...fourth-generation languages were/are developed to address Object Oriented (OO) programing like JAVA, C++ (remember Turbo C? LOL!)...then their are fifth-generation languages like LISP, FOXPRO, etc..

If a program is compiled (through compiler or assembler...linked, etc.) it is translated into machine code (obviously) and is at that point a first-level language...if it needs to be interpreted at run time (JAVA, good old Quake-C, VB, etc...) then it is a second-level language.

Assembly is usefull to learn because every language still has to use the processer for anything to be acomplished...there are no special opcodes on the processor that OO programing uses...ANYTHING that can be done in any other language, can be done in assembler. and if you can learn assembler, then most other languages are a piece of cake

quote:

Hex is no machine format and entering "mov eax,24" is quite different from feeding the processor something like "0101011100011101110111".



"mov eax,24" is not Hexadecimal notation (or simply Hex)...

In the dawn of computer programing, thier were 'punchcards'...a machine would read the holes on the cards as "1"s and non-hole areasa as "0"s...course this was before computers universaly used moniters (instead they used printers)...when moniters (terminals on main-frame systems) became common place...programming could be done by entering 1's and 0's...but by the time moniters were able to show whole letters and generaly mimic the output the printers could do...codeing in 1's and 0's became obsolite as Hex editers could be used instead...

Hexadecimal notation is nothing more then converting 4 bits into a 16-base numerical system (0 through F...a byte is then represented by two Hex characters 00-FF, course I suspect anyone who is somewhat interested in assembler already knows this)...you very much CAN program in "machine language" (or "binary") by useing a Hex editor (which is how most people do it)...

Assembly doesn't exactly translate into machine language...

ADD AX, BX
ADD AX, 6

will translate differently because it makes a difference in that one statement adds one register to another...while the other statement adds a set value to a register...which, of course, makes a big difference to the processor





[edited by - MSW on October 17, 2002 10:00:18 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster

quote:
Assembly doesn''t exactly translate into machine language...


dont be so sure.

yes assembly is a level just above entering 1''s and 0''s.

but 90% of what an assembler does is just replace your
"mov reg0, reg1" instruction with that particular cpus
bit stream format for that particular op code.

so if a 32 bit cpu has the following format for a
move instruction..
8 bits of opcode
8 bits of padding
8 bits of destination address
8 bits of source address

and if ..
the mov op code = 0x0a
reg0 address = 0x00
reg1 address = 0x01

so, the machine langauge for your "mov reg0, reg1" in hex would be..

0x0a000001

so in a way writting assembly _is_ like writting the 1''s and 0''s,
except in a more readable format..

Share this post


Link to post
Share on other sites
For all practical purposes, assembly language _is_ machine language.

Assembly language is simply a textual representation of machine instructions. There is a 1:1 mapping.

You can sit down with a processor reference and start coding in assembly for just about any given processor.

Moving down to the actual 1s and 0s does absolutely nothing for you. It doesn''t even really give you more control over things. Assembly language is nothing more than a convenient way to work with processor instructions. You can reorder them and directly understand how the processor will execute your code.

Things like labels aren''t as abstract as you think and assemblers themselves differ greatly from compilers for "true" high level languages. Labels are nothing more than unresolved addresses. It''s much more convenient to work with labels and identifiers that can be calculated all at once rather than having to change them each time you insert a new instruction. The assembler and linker take care of this tedious work for you.

You can argue that it''s a higher level language than actual machine code, but don''t make it sound like it''s an entirely different language -- it''s the same thing, just easier to represent (and with extra assembler-provided features like macros, etc.)


---
Bart

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The only case when you would actually need to code instructions in machine language, instead of assembly, would be when there is a bug in your assembler or there''s some new instruction(s) that aren''t supported in the assembler you''re using.

Sure, using assembly is a very good way to optimize your applications, you can be 100% certain, that the code you write is the most efficent for the processor.
If I would have the time, I would code a game entirely in asm... well, actually I''m writing an OS from the scratch with NASM

-Ring0

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
The only case when you would actually need to code instructions in machine language, instead of assembly, would be when there is a bug in your assembler or there''s some new instruction(s) that aren''t supported in the assembler you''re using.



Right. If you''re writing your own assembler or something that has to generate code on the fly, you''ll have to deal with machine language. Any assembly language programmer can simply pick up a processor reference manual and figure out how to write the machine code.

quote:

If I would have the time, I would code a game entirely in asm... well, actually I''m writing an OS from the scratch with NASM



Cool! Writing system-level code is a great way to learn about how things really work (if you haven''t already done so.) I remember doing similar projects.

There''s 1 piece of advice that I''d like to give regarding OS projects: Try to use C.

By this I mean figure out how to set up a compiler (gcc) to allow you to compile your OS and cross-compile programs for it. I haven''t tried doing a real OS, but I''d imagine that attempting to do it mostly in C would force me to think out more of the basic design ahead of time. I''d have to figure out exactly what needs to be written in assembly and what can be left to C, and then how to set up my compiler to produce system code the way I want it to be layed out.

Just a thought. The most important things are to learn and have fun, of course

---
Bart

Share this post


Link to post
Share on other sites