assembly language...the best tool for game programming?

While reading some of the tricks andre lamothe suggests that we keep in mind when developing games it seemed like assembly language would be the ideal tool for developing games. For instance he suggests that c++ should be used sparingly I guess because of the performace loss of using a lot of objects with multiple inheritance etc. He also seems to be fond of using global variables instead of passing parameters on the stack. Assembly language would be useful in this case because function parameters can be passed through registers. Another trick he mentioned was using the left and right shift operators to do multiplication and division. It seems like he likes to use C as an assembly language of sorts and I guess thats why C is sometimes called a mid level or high level assembly language. I understand the usefulness of a high level assembly language when a program is being written with portablility in mind but if a game is being written for windows only or for one specific platform wouldn't it just be better to use assembly instead of trying to emulate it with a high level language.
And in addition to this I think that having the instruction set of a particular processor at your disposal allows the programmer to be more expressive in the implementation of algorithms leading to sometimes a better implementation whether better means shorter or faster or both. A lot of people question whether or not assembly is a suitable development tool today but i think game programming may just be one area where it's a perfect fit. What do you guys think?

I think you don't have much experience programming in assembly. Trying to code and entire game in pure assembly would be.... unimaginable. It's too many lines of code, and too complex a process.

In modern game programming, the game is coded in a high level language such as C. However, they still revert to embedding assembly right into the code for situations where it is necessary to be fast and efficient as possible (graphic pipelines, hardware interaction, etc).

Pure assembly may be too much but I think masm or HLA or any other "high level assembler" would be nice for game programming because especially with HLA the language it allows you to code as low or as high as you would like to. :) You can use high or low level features where appropriate.

i dont think you understand, maybe you should read some assembler src code

Quote:

---

high level assembly language

---

No such monster except for HLA which I don't use.

Assembly can be used for extremely fast copy operations - basically bitblt's from one surface to another. Multi-texturing can be done this way, and using MMX, can also be alpha blended as well if, and only if there are no hardware resources available to do this. Often times the resources are quite limited so this happens more than you think.

But coding an entire DirectX or OpenGL game in assembly, well....................let's just say you and I wouldn't be playing any games developed in this century on our systems.

Quote:

---

Originally Posted by silk.odyssey

For instance he suggests that c++ should be used sparingly I guess because of the performace loss of using a lot of objects with multiple inheritance etc.

---

Neglible 99% of the time. The advantages more than outweigh that.

I agree with what Sang-Drax said.

LaMothe is correct in saying that there is a performance loss with the mentioned C++ functionality (and it is definitely not negligible if you are trying to implement some 'real' 3D graphics stuff, such as an elegant shader system).

However, why do you 'pay' for anything? You pay for stuff because you can get something out of it. Subsequently, you 'pay' for elegance and ease of implementation with a cost of a slight speed hit.

The best example for C++ is using std::vectors instead of writing your own linked list...people use them all of the time because they're so easy if you just want to dynamically add objects to an array, and then access them later (although they have other problems).

The usage of basic assembler code in your program leads to alot of code readability/reusabilty problems. Basically, if you want to learn assembler, I totally support you, because it is a great way to understand the higher languages. However, if you want to use assembler in a game, use SSE/2 extensions for stuff where you need the extra speed of the faster instructions, but dont like how the compiler uses them(compilers as of yet from what I have seen still dont like to properly write assembler for SSE instructions), but dont use them for the entire game.

P.S. I am not sure about my last clause, since IIRC it took people only around 2 years to code 1 mil+ assembler line games and I think that with the advent of full scale APIs for graphics/audio , 1 mil might be the most necessary today for most games.

Quote:

---

Originally Posted by vNvNation

I agree with what Sang-Drax said.

---

i agree too, although his numbers are a little off.... it's more like 99.99% of the time.

hi,

there's a game being written 100% in asm. Hostile Encounter is called.

Its a RTS game(a la starcraft) made using TASM.

www.hostileencounter.com

jmgk

well if you are going to make a game in complete asm, it's all about subroutines, subroutines, subroutines....use them freely...or else you would die...

I dont see how this is possible since TASM operates in real mode and can only use EMM386.EXE to access 32MB or XMS via int2Fh in pure DOS only.

TASM is also not compatible with DJGPP or RHIDE (they claim it is but I've never had any success). TASM32 runs in 32-bit mode but TASM does not support newer opcodes for MMX/SSE(1/2) etc AFAIK.

I could write a game in TASM but there is no point. The speed gained would be quite marginal compared to the structure lost. Anyone on this board can attest to the fact that I'm an avid x86 assembly language crusader so I'm not against assembly and I use it a lot in places where it might be needed

Most code bogs down in about 10% of the entire program and yet most people try to optimize the the 90% that's not the bottleneck.

Optimizing 90% of your code but leaving the 10% bottleneck will still result in slow code be it in:

• assembly (x86 rocks!!)
• C++ (bring it on!!!)
• Java (omg i hope not)
• Visual Basic (I just puked on myself)
• BASIC (sorry can't insult my first love and first language ever)
• COBOL (CO what?)
• FORTRAN (fortunately no one has tried)
• PHP (isn't that some kind of drug??)
• Python (I don't even have to say it do I?).

I included some of the scripting languages simply because there are some here who are under the false assumption that a real-time game can be programmed using them. Here's your sign.

:D

I could, however, see a game being programmed in C/C++ with core engine routines in NASM.....but on its best day it would still be 10 times slower than Direct3D or OpenGL.

Hardware acceleration is here to stay. Live by it or die by it. Your choice.

Just go learn DirectX or OpenGL....it makes life a lot easier.

>I included some of the scripting languages simply because there are some here who are under the false assumption that a real-time game can be programmed using them. Here's your sign.

I KNEW IT!!
people didnt believe me!

Quote:

---

I could, however, see a game being programmed in C/C++ with core engine routines in NASM.....but on its best day it would still be 10 times slower than Direct3D or OpenGL.

Hardware acceleration is here to stay. Live by it or die by it. Your choice.

---

how do you feel about matrical and quaternion operations, which are infamous for being very slow when sent to the FPU instead of SSE(1/2) registers(I have seen code that is 10x-25x as fast as C equivalent from a few people over at www.gamedev.net)? Because unless I forgot a white paper, I didnt realize GPU's were being used for those kinds of math?

Quote:

---

Originally Posted by Bubba

I dont see how this is possible since TASM operates in real mode and can only use EMM386.EXE to access 32MB or XMS via int2Fh in pure DOS only.

TASM is also not compatible with DJGPP or RHIDE (they claim it is but I've never had any success). TASM32 runs in 32-bit mode but TASM does not support newer opcodes for MMX/SSE(1/2) etc AFAIK.

I could write a game in TASM but there is no point. The speed gained would be quite marginal compared to the structure lost. Anyone on this board can attest to the fact that I'm an avid x86 assembly language crusader so I'm not against assembly and I use it a lot in places where it might be needed

Most code bogs down in about 10% of the entire program and yet most people try to optimize the the 90% that's not the bottleneck.

Optimizing 90% of your code but leaving the 10% bottleneck will still result in slow code be it in:

• assembly (x86 rocks!!)
• C++ (bring it on!!!)
• Java (omg i hope not)
• Visual Basic (I just puked on myself)
• BASIC (sorry can't insult my first love and first language ever)
• COBOL (CO what?)
• FORTRAN (fortunately no one has tried)
• PHP (isn't that some kind of drug??)
• Python (I don't even have to say it do I?).

I included some of the scripting languages simply because there are some here who are under the false assumption that a real-time game can be programmed using them. Here's your sign.

:D

---

Sigh, bubba I really wish you hadn't said that.

Because, and mainly for the reason, that you can code a real time game in scripting langauges. JavaScript is a scrippting language, and it is QUITE possible to do real time games with it. It wont be doom, but it will be a game, in real time. This is especially true when you consider browser plugins that interact with javascript. Such as wild tangent (www.wildtangent.com). Wild tangent is a 3d graphic api for browsers. It can be used in java, javascript, vb script, and c++.

Any ways the point is, your conception is wrong here. If if I absolutely must, I will program a game in pure javascript (with out wild tangent or any other plugin) to prove the point. But you will owe me something.. Perhaps a very verbose humbling apolagy.

shot down...

Yeah I installed the so-called Wild Tangent piece o crap and all it did was send my computer off on some tangent.

I wouldn't program a game in Java if it was the last language left on earth. It's too slow.

If they can speed it up then perhaps but until then there is no way.

I'm interested in three main things when it comes to programming.

Speed.
Power.
Tech.

That's it. With DirectX and/or OpenGL you get all of em. Assembly has the most power to offer but it is not easy to create a large program with it because it is so unstructued. Amounts to having a billion jmps everywhere. C/C++ with some asm thrown in is where the speed, the power, and the technology is. Games have always pushed the envelope of computers and they always will simply because they must not only be real-time but they must provide real-time interactivity. Which means that you can't expect someone to sit there while your slow ass code executes some O(n^2) algo and expect them to be satisfied. I've never seen any Java games on the net, compiled or otherwise, that I was impressed with. Even on DSL and even having the exe right on my machine the code still ran terrible. No go for me.

So if you want to program a game in a scripting language...feel free but I think your game will be missing quite a bit.

Judging from some recent books I've read and a very good physics one, the same one that Shadow read and recommended to me, there is no way you will ever get all the calculations and graphics to work in a pure scripting language. I'll probably be creating my own scripting language for AI and use scripts for DirectMusic, effect files, vertex/pixel shaders, etc., in my 'game' so scripts have their use but I'd never use them as my core language.

I mean....I'm sitting here wondering how I'm going to get all this physics stuff to work in C/C++ with an acceptable frame rate...much less any other known slower languages.
I'm going to have to compromise and omit some stuff or approximate some stuff just to get it to work and still retain its interactive element. I'm shooting for 30 FPS bare bones which is crap. I'd like to maintain 60 FPS or better so that the engine never dips below the 30 FPS mark.

And when I say 'game' I'm not talking about tic tac toe, or any of the puzzle games you can play on MSN. I'm talking about real-time in your face high tech who's your daddy games. The rest of gamedom does not interest me. Which is fine because if everyone were like me we'd never have Scrabble or Tic Tac Toe on a computer. I'm just not interested in that type of stuff.

So you said it. It won't be DOOM and I'll add that in a scripting language...it can't be DOOM. Because of that....I've no interest.

It seems to me rather than try to use the wrong tool for a job you would want to use the right one to get the best results. Essentially all languages are tools. Trying to design something beyond the capability of a language or even beyond what it was intended for in the first place...to me is a waste of time. Perhaps I'm mistaken though.

Sure I can create a game in pure assembly and maybe I'd be super cool for doing it but it would end right about there. No one could add to it, plugins would be nightmare, I'd have to re-assemble to change anything, etc., etc.

I just don't understand why people try to do these things. Use the right language for the job at hand....period. It's really as simple as that.

There is nothing special about languages but there is something special about using them the right way.

Quote:

---

how do you feel about matrical and quaternion operations, which are infamous for being very slow when sent to the FPU instead of SSE(1/2) registers(I have seen code that is 10x-25x as fast as C equivalent from a few people over at www.gamedev.net)? Because unless I forgot a white paper, I didnt realize GPU's were being used for those kinds of math?

---

Yes this is true. Which is what I meant by core functions. However, based on what I've seen in Direct3D it appears that the HAL is taking care of this for you. Since I never send the vertexes to be transformed...rather I simply set the transform matrix and then DrawPrimtive I think that the HAL is taking care of this. After this step then the transformed vertex data is sent to the GPU. But I'm not sure I could code a faster transformation pipeline than has already been provided. I've programmed several transformation pipelines, but D3D seems to be doing the job just fine so it would be arrogant of me to assume I could program a faster one....but later perhaps when it does not suit me and when I move to pixel shaders and such I probably will do this. I'm not sure how OpenGL transforms the vertices...probably through a similar method. I've never seen any info to point to matrices and quats being sent to the GPU....but perhaps someday we will be able to do this which would be nice. Perhaps OpenGL and D3D are already using SSE (if avail) internally....which would make sense.

This is what I meant by it being 10 times slower. Sorry for being vague. Also if you are not using the hardware to render then you are missing out on an awful lot of speed there. The hardware can do more effects, blending, etc. and faster than anything I've seen in asm. And this makes sense since hardware is supposed to be faster than software.

I think you misunderstood me a bit and I think we are basically saying the same thing.

How fast or efficient a game written with a scripting language is not the focus of my statement. You made an invalid statement. That it was impossible to make a real time game in a script language.

Fact:
You can.

Web games have a purpose, they are "web" games. They arn't doom4 or quake 28. Get over it. Recognize them for what the are--a medium to provide entertainment through a limmited communication barrier (the internet). Quite frankly, and to be brupt, I've played wild tangent games -- ones programmed with scripting languages, java, and c++. And all of them have been more content, better graphics, and gameplay then you or I have demonstrated on this forum. Even with DirectX, OpenGL and other efficient, fast, powerful api's at our direct use.

I think you should keep that humbling truth in mind when considering the usefulness of scripting languages.


cheers.

Their usefulness is not in games.

Man...go buy a game mag or something. I can't believe I'm hearing this. We are talking about two totally different genre's here. I'm not blasting your genre and I'm not elevating the one I'm interested in.

But don't make statements like real-time games can be programmed in scripting languages. What I consider real time and what you consider real-time might be 2 different things. For real-time let's go with 30 FPS renders - not bit blts, not sprites, etc., etc. True 3D, 3D sound, etc, etc. That can only be done with a language like C/C++ and an API like OpenGL or D3D. Even a game in Allegro is going to be slower simply because it does not have access to the hardware. These companies have worked years and years to bring us this cool stuff and I've watched it evolve from the old Rendition Verite 1000 to the newest Nvidia card. With all this cool stuff at our disposal I cannot fathom why someone would use something else. Right now it's a game programmer's paradise. More RAM, more speed, more hardware functions, more...everything...and its only going to get better.

The games you are talking about do not need total control of the system but the one's I'm talking about do. 2 totally different concepts. And nowhere did I say that I have programmed anything close to what has already been released nor could I with just me at the helm. But I don't need a title under my belt to know when a game is just too slow for my tastes or a language for that matter.

Chill out.

It's obvious you didn't really spend any time trying out wild tangent. Else you would know that most of the games use REAL*** 3d and REAL*** 3d sound. It's part of the api, I know, I've used it. FPS is limmited to user machine. And if you are running sub 30 fps on those games, really you should look at your system cause there is something wrong with it. I play the Men in black game, black hawk game, and several others and post 30 fps. They are really fun.

I'm only attacking you because of your whacked out definition of real time. Real time (as far as gaming goes) has always been about the nature of game play, not system performance. Your ackward use of the word real time to perpetuate the false idea that games can't be made in a scripting language is what is so frustrating. I would have no problem if you clearly stated what you obviously mean in a way that doesn't result in a false conception in the ability of scripting languages.

What you mean to say is that scripting languages are by nature (due to their implimentations) are less efficient then the high level (or low level) programming languages they are based on.

The fact still remains however, they can be used to program games, applications and be used for other software uses so long as you can impliment functionality that isn't impeded by the run time performance. Which is very possible.

Quote:

---

What you mean to say is that scripting languages are by nature (due to their implimentations) are less efficient then the high level (or low level) programming languages they are based on.

---

Yes, I think that sums it up well. Now why couldn't I have said that?

I agree. It's really no big deal. As for silk.odyssey's original question... As everyone has said, the best way to write games is to use OpenGL/DirectX. Those libraries themselves, if you look through them, are mostly assembly optimizations to thinkgs like hardware access, speed tweaks, etc. Assembly is the best to use, just in its proper place.

Quote:

---

I agree. It's really no big deal. As for silk.odyssey's original question... As everyone has said, the best way to write games is to use OpenGL/DirectX. Those libraries themselves, if you look through them, are mostly assembly optimizations to thinkgs like hardware access, speed tweaks, etc. Assembly is the best to use, just in its proper place.

---

well, quick question, is the core of D3D HAL written in assembler? Because basically what we are looking at here if it is is the following:

1) D3D HAL written in assembler, programmer uses C function calls to abstract the assembler subroutines

2) Programmer writes all core functions to use if available SSE optimizations . . . in assembler. Programmer then abstracts those subroutines to be incorperated in C.

To Original Poster:
Notice a pattern here? Basically, what Bubba has been saying, and me attempting to say, is that you can view programming as a multiple tier skyscraper. You begin with assembly, programming all of your necessary core routines so you have a solid foundation, so that when you code runs slow you dont have to go through all of your Matrical operation functions to try to find the bottlepoint, because the bottlepoint is in one of your higher level functions(such as 3D Model loading, BSP rendering,etc.). You then progress to C/++ with everything else, because there is no real reason to program a BSP renderer in pure assembly (with D3D calls), because it really isnt floating point arithmetic intensive.

NOTE: sorry if the beginning of my words to you OP sound like I am saying that you aren't recognizing something, I tend to come off condescending when I am trying to make things clear for the benifit of the person in the case the person doesnt know it.

It seems to me that a lot of people are pre-judging DX and OpenGL without ever having used either one. I for one do not know how DX or OpenGL get the job done exactly but I do know what every 3D API has to do to transform vertexes. I understand the mathematics and I could code them myself but why?

I'm sure as Ev has stated that the devleopers of DX and GL both took assembly into consideration when they coded the APIs. The API probably does check for SSE SSE2 support and if its available I'm sure it uses it.

What DX and GL allow all of us to do is....focus on the game, not on the nitty gritty. When you need more speed and have verified this via profiling, testing, etc., then you might be able to get more speed with hand-tuned assembly.

Ev and I are huge assembly advocates but we also realize that it is completely, or at least very nearly, unstructured and turns into a large mess rather fast. Use assembly where it is needed, but keep in mind that if the hardware supports the function no amount of assembly produced by the best asm programmer on the planet will ever be faster than the hardware. Essentially the hardware is the hard coded asm function.

For more info I refer you to the AOA book and the chapter on architecture and circuit design.

As for Scripting Games go. There is one called runescape at http://www.runescape.com That is pretty advanced. It is a mmorpg that is written in pure javascript. I am pretty sure. Sure it is no Doom3 but I think it stresses the fact anything can be written in whatever you like. Just choose what you have researched to have the benefits that matter most and the costs that don't really matter to you.

Its written in JAVA. not javascript.

Quote:

---

Those libraries themselves, if you look through them, are mostly assembly optimizations to thinkgs like hardware access, speed tweaks, etc. Assembly is the best to use, just in its proper place.

---

How, exactly, do you 'look' through them when the implementations are hidden in dlls?

I tend to agree with what goten said, because you can use a scripting language to make games. You can even do decent real 3D.

Is Visual Basic a scripting langauge? I mean, it *is* interpreted at runtime (but it can also be compiled to an exe), which is the basic definition of a scripting language. I've seen some nice 3D rendering projects done in OpenGL and written with Visual Basic.

edit

back to the whole assembly issue. I've got a few questions.

1) How many people on these boards can really effectively use assembly in their projects?

2) How do you know that your assembly instructions are faster than what you would've written otherwise?

3) Are you adding assembly to your projects before or after you are done? As a rule, the best idea for projects is to code first (like, get stuff to WORK), and then optimize later (meaning putting assembly code in your project a week into it is essentially sabotaging your later efforts, unless you comment like a demon).

Quote:

---

Originally Posted by vNvNation

back to the whole assembly issue. I've got a few questions.

1) How many people on these boards can really effectively use assembly in their projects?

---

For the x68 motorolla processor, I can.
For anything greater, x86 etc. LOL no. But it's only cuase I haven't takin any steps to learn the instruction set or the registers.

Quote:

---

2) How do you know that your assembly instructions are faster than what you would've written otherwise?

---

Usualy you can use timing methods to find out. But as a general common sense rule - compilers create fat juicy binary. It has been inflated to allow for general use. 9 times out of 10, hand written assembly code (specifically for a task) will be faster then a high level language code (for general all purposes).

Quote:

---

3) Are you adding assembly to your projects before or after you are done? As a rule, the best idea for projects is to code first (like, get stuff to WORK), and then optimize later (meaning putting assembly code in your project a week into it is essentially sabotaging your later efforts, unless you comment like a demon).

---

I prefer to code first, and improve later. At times it becomes important to tackle bottlenecks immediatly though--especially in situations where further code will be revolved around whats already done.

The only way to make any code faster is to use better algorithms. If you take code written in any language, and write out the corresponding assembly commands line by line, the programs will be the EXACT same.

The only time when one should resort to assembly is when the language you are using will not allow you to use a specific algorithm, and assembly will.

Quote:

---

Originally Posted by silk.odyssey

Assembly language would be useful in this case because function parameters can be passed through registers.

---

I think Delphi/Pascal functions pass their first 2 parameters through registers.

Quote:

---

Originally Posted by silk.odyssey

Another trick he mentioned was using the left and right shift operators to do multiplication and division.

---

I'm fairly sure GCC does this implicitly if possible. No need use it in your code. It performs a lot of other optimizations like using the faster leal asm instruction for additions/multiplications if possible.

Quote:

---

Originally Posted by silk.odyssey

but if a game is being written for windows only or for one specific platform wouldn't it just be better to use assembly instead of trying to emulate it with a high level language.

---

No. The development cost/time would be enormous. You would also need programmers that are better at optimizing asm code than an optimizing compiler is. That excludes 99% of all coders from your project. It's easy to optimize short passages of assembler code, but a whole program? Even trying to do so might seriously impair your mental health :)

Quote:

---

Originally Posted by silk.odyssey

A lot of people question whether or not assembly is a suitable development tool today but i think game programming may just be one area where it's a perfect fit.

---

It's nice to optimize important parts of your program with it. Use a profiler, see where the bottleneck is and optimize that part in assembler. However, maintaining assemblercode is not easy. I would use it as little as possible.

>>For the x68 motorolla processor, I can.
For anything greater, x86 etc. LOL no. But it's only cuase I haven't takin any steps to learn the instruction set or the registers.

ive looked into learning but there are different syntax for different implementations. eg. NASM is different to TASM which is different to MASM. So how am i supposed to know what to learn?

That's the reason I havent bothered to learn asm yet :D

Quote:

---

ive looked into learning but there are different syntax for different implementations. eg. NASM is different to TASM which is different to MASM. So how am i supposed to know what to learn?

---

Learn the AT&T syntax because it rules all the others ;)

would most people agree with that? or is that just a personal preference?

personal. some people swear by the Intel syntax but it looks fugly to me.

are the intel, at&t or other versions of asm vendor specific, or will they work on both amd's and intel's because they're both x86 based?

Quote:

---

Originally Posted by dbgt goten

I think you don't have much experience programming in assembly. Trying to code and entire game in pure assembly would be.... unimaginable. It's too many lines of code, and too complex a process.

---

rollercoaster tycoon, and most other games where Chris Sawyer is involved.


edit: Chris Sawyer!

Yes.

edit: I mean, yes it will work on all x86 compats as long as you don't use instructions specific to a certain processor, such as a 586 or something.

Quote:

---

Originally Posted by skorman00

The only way to make any code faster is to use better algorithms. If you take code written in any language, and write out the corresponding assembly commands line by line, the programs will be the EXACT same.

The only time when one should resort to assembly is when the language you are using will not allow you to use a specific algorithm, and assembly will.

---

Uhh, name an algorithm that you can't implement with C/C++ ? Because I really don't believe that there are any.

And I mean honestly, if you are doing 3D, which relatively few people are on these boards, if you've got basic spatial partitioning and relatively good culling routines, then you aren't going to need to do tons of optimizations to get basic rasterization to work at a decent framerate.

Just because the people who work on 'bleeding edge' technology games do tons of optimizations, doesn't mean that it's even moderately appropriate for us to do it. Your time is much better spent learning new concepts and implementing them in a robust manner, unless your goal is specifically to learn assembly.

And another thing, WHY do people think it's so totally awesome to learn assembly programming? You aren't able to actually accomplish more with that than C/C++ or other high level or scripting languages, and it's not like assembly is actually really all *that* difficult to learn. The actual instruction sets are EASY to learn. I started doing work with the floating point unit and some basic x86 stuff, and I found myself making macros to do specific repetitive jobs for me, and I found it started looking more and more like C :)


So, the whole speed thing isn't really that big of an issue for our type of work (I would like to see somebody post a project where they were able to squeeze 20% speed by doing the same stuff in hand coded assembly), and x86 and FPU instruction sets aren't that hard to learn (I found it easier than C++), so why the great appeal?

Quote:

---

(I would like to see somebody post a project where they were able to squeeze 20% speed by doing the same stuff in hand coded assembly),

---

go ask CharlesB on Gamedev.net who is programming a MathLibrary whose entire core is assembler SSE/2 optimized.

regular assembler is not where you get the huge benifits, as integer based math is fairly simple for the processor to do(however, multiplication/division is still a pain), but SSE optimizations for Floating point math can give you 1000%-2500% gains in speed, with an average gain I have seen of atleast 200%.

However, as Bubba ,others, and I have said, most of the speed problems people have are simply because they used too many loops to load a 3DS model, or are simply beginner programmers.

Quote:

---

Just because the people who work on 'bleeding edge' technology games do tons of optimizations, doesn't mean that it's even moderately appropriate for us to do it.

---

I thought that programmers were supposed to accept challenges to better themselves and put themselves higher in the ranks of the computer world . . . I guess I was wrong. By learning optimizations and how they work, it can give us a better understanding of our current code so that we will realize where things can be optimized for a huge gain(such as in Matrical/Quaternion operations), and where they are better left alone.

ive been looking at masm32 which seems pretty cool but i dont think learning that would be helpful with inline asm in my c programs.
i have no idea whether its worth learning asm or not and if so which assembler is worth learning for.

Quote:

---

The only way to make any code faster is to use better algorithms.

---

While I understand the concept this statement is not true in all cases.

Quote:

---

go ask CharlesB on Gamedev.net who is programming a MathLibrary whose entire core is assembler SSE/2 optimized.

---

I've chatted with him quite a bit before, and he hasn't posted a project with optimizations, and then the same project without optimizations, so that we could compare the two. I doubt very many people on gamedev.net will have a lot of use for his horsepower mathlib. He does know a lot about the whole optimizations thing, and his time would be better spent working on a large programming project for a company (which, maybe he is, I don't really know).

Quote:

---

I thought that programmers were supposed to accept challenges to better themselves and put themselves higher in the ranks of the computer world . . . I guess I was wrong.

---

It is, and you can learn a lot about how the computer works, but this type of optimization takes quite a bit more work than you realize. If you are a newbie, and you are spending all this time trying to optimize your code, then it seems it would have been better to just go and implement something else.

Quote:

---

It is, and you can learn a lot about how the computer works, but this type of optimization takes quite a bit more work than you realize. If you are a newbie, and you are spending all this time trying to optimize your code, then it seems it would have been better to just go and implement something else.

---

I do agree that optimization is not for the faint of heart, as I have been reading through several optimization guides and most of it is such that you could spend a couple of years learning all the little tricks and proper way to do things, which often change between generations of chips. I am just saying that if there is a newbie who can't find a project that s/he wants to desperately work on, but is willing to spend alot of time on something, that they should learn the optimization as it can be very useful in increasing speed so that when you use some things that are slow in of themselves(such as dynamic loading of levels, which I still havent been able to see as an effective way of doing a game. I am personally inclined to load each "level" in one swoop, as both Dungeon Siege and Morrowind really made me get angry when you would be fighting something then accidently hop a "level" border and then you would be dead when the thing loaded up.)

but I will agree with you that 99% of the programmers here and elsewhere really have no want/need for assembly as 10-20 FPS is not a problem if you can run your game at 100+ fps already. IMHO, however, the real reason I am interested in mastering assembly is for patching/manipulating already compiled code such as in the case of abandonware, where there are some really cool games, but the developers let them slide and never released patches.

Quote:

---

Originally Posted by vNvNation

Uhh, name an algorithm that you can't implement with C/C++ ? Because I really don't believe that there are any.

---

I'm glad you asked that question!

Most people here are throwing around the notion that most assembly in games is used for intensive 3D graphics. This has some truth, but they don't say why. The reason why is because there are many math calculations that can be done quicker in assembly than using an high level language (HLL from here on out). Reason being, is that any HLL will just use the processor op codes.

Does anyone here know what the cycle count are for most of them? These numbers are off the top of my head, but for the Pentium 4, addition, subtraction and multiplication are around 5, which isn't going to get faster for the most part. Division is around 40, and square root calcs are hanging at about 56. These number are on integers, and as vBladeRunnervE said, floating point numbers are uglier. Sometimes you can get away with using some of your own bit operations in an HLL to lower these counts. However, one can use use bit rotations that are allowed in asm in order to get really quick calculations. Bit rotation cannot be done quickly without using asm commands.

If you're working on a console system, you need to work under harsh memory constraints. To help out, it's best to make your own memory manager to handle the stack and the heap. If you do this purely in an HLL, you get pretty good results. When you go down to the asm level and manipulate the registers directly, things get even better.

Those are just a few examples to think about, there are many other situations which are dependant on specific situations.

Quote:

---

Originally Posted by EvBladeRunnervE

I thought that programmers were supposed to accept challenges to better themselves and put themselves higher in the ranks of the computer world

---

They should, and some do. Those that do and work in the game industry will probably stay there for quite some time, instead of the 4-5 years that an average programmer stays. But that doesn't mean that they should be asm masters. I think that in order to fully understand what any code is doing, one should understand asm, even if it's at a conceptual level. It takes a LONG time to get to the point where one can use asm to it's fullest.

Quote:

---

Originally Posted by Bubba

Quote:

The only way to make any code faster is to use better algorithms.



While I understand the concept this statement is not true in all cases.

---

This concept is true for all cases unless you're testing different processors. Some processors are just plain faster, and some may work better with certain algorithms just because the curcuitry is built differently. However, that curcuitry is a giant algorithm on its lonesome.

Quote:

---

Reason being, is that any HLL will just use the processor op codes.

---

So does assembler. Pardon me but what are you talking about?? How do you suggest we execute programs without opcodes??? What do you think a compiled program is???

All assembler, all C/C++, all of any language uses opcodes/instructions -> they are synonymous. The opcode is the hexadecimal equivalent of the instruction or vice versa. The instruction is the English equivalent of the hexadecimal opcode. The hexadecimal opcode is the base 16 version of the binary opcode.

Quote:

---

These numbers are off the top of my head, but for the Pentium 4, addition, subtraction and multiplication are around 5, which isn't going to get faster for the most part.

---

False.
And how do you know how long each instruction takes?? Intel stopped releasing and publishing clock timing information for opcodes after the 486 manuals. Timing is not constant in all cases and cannot be relied upon - hence they offer performance timers to the programmer so that they can clock the code.
No timing information is given for these opcodes in the IA32 or IA64 manuals.

Quote:

---

These number are on integers, and as vBladeRunnervE said, floating point numbers are uglier.

---

False. Actually on newer FPUs floating point operations are faster than integer ops. Perhaps your statement was true in years past but it is no longer so. There are floating point operations that actually run faster than their floating point counterparts due to the gains in technology in FPUs and the on-chip implentation of floating point math. Profile it.

Quote:

---

Sometimes you can get away with using some of your own bit operations in an HLL to lower these counts. However, one can use use bit rotations that are allowed in asm in order to get really quick calculations. Bit rotation cannot be done quickly without using asm commands.

---

False. You cannot bit shift any floating point data type. Bit shifting is not supported in floating point registers and should not be relied upon. Floating point is represented in such a way that certain numbers simply cannot be represented accurately in floating point. In other words there is no binary equivalent for the exact value. For more information consult the IA32 manual - specifically concerning numerical applications and the formula for converting binary to floating point.

fld [floatingpointvalue]
shr ?????

Since SHR and SHL both operate on integral registers there is no way to bit shift the local real that lies in ST(0). Bit shifting is not defined for floating point and never wil be.

Also in C this:

unsigned int X2=x>>1;

is the same as:
mov eax,[x]
shr eax,1

No difference at all. The compiler will automatically see the integral data type and use a bit shift if possible in assembly. If it cannot then it will check to see if it can use multiple bit shifts added together. If not...then it will do a DIV. For instance value*320 can be done as a sequence of bit shifts like this (value<<6)+(value<<8). Since bit rotations are allowed both by C/C++ and in assembly language I have no idea what you are talking about.

C was designed to be able to do anything and everything you could do in assembler yet gain the benefits of being a structured language and thereby reducing development time and increasing productivity - at least one of the reasons it was designed. But the statement that C does not allow bit shifts is an extremely uninformed one. The days of gaining 30 to 40 FPS simply by using integer data types are gone my friends. The bottleneck today is getting the vertex data to the GPU. What you want is a burst of data sent once to the GPU per frame. Very limited numbers of DrawPrimitive calls in D3D, complex meshes that contain nearly all of the geometric data for the level, etc. Cut down on state changes and state block changes - such as:

Code:

---

//Render all alphablended surfaces
Device->SetRenderState(D3DRS_ALPHABLENDENABLE,true);
.....render all alpha blend objects
 
//Device->SetRenderState(D3DRS_ALPHABLENDENABLE,false);

---

D3D offers a state block mechanism in which blocks of states can be created, instantiated, and destroyed. This allows a very compact method of changing the render states. They also offer effect files which will cut down on render states. Also the pixel/shader assembler language has been replaced by HLSL or high level shader language and OpenGL has an equivalent high level language for this as well.
Saying that assembly is always faster than C would be like saying vertex/pixel shaders written in pure opcodes will always be faster than those in HLSL - simply not true.

There are places where hand tuned assembly will yield better results than C/C++ but unless you have:

• Profiled the code and located the bottleneck
• Tried different algos and code structures as well as code logic
• Ensured there are no memory leaks or hidden bugs(pointers, exceptions, etc) causing frame rate and/or execution slow downs
• Have enabled all the optimizations in the compiler
• Have ensured you are building with no compiler run-time error checking

For optimization methods and tricks I would recommend reading several books over at amazon.com. There are lots of them.

Then you have no business coding the algo in asm. Assembly is not always the answer. It is, again, a tool that can be used and abused. All of the ideas you have suggested concerning optimizations are not what needs to be optimized on modern day systems. These are not the bottleneck and hence a perfect illustration of why people should not just rely on assembler for optimization.

For more information consult Randall Hyde's books, IA32 and IA64 Itanium manuals, x86 AMD manuals, MMX manual (Intel corportation), SSE/SSE2 manuals (compiled into volume 3/4, instruction set reference of Intel's IA32 and IA64 tech refs).

Before you begin to discuss pros/cons between two languages it might be a good idea to research them prior to making statements about either of them.

And since I know Ev he would never say that you cannot do bit shifts in C or suggest that a floating point divide/multiply could be done by a bit shift and I'm sure he realizes that floating point on todays FPUs is slamming fast.

Finally:

Quote:

---

This concept is true for all cases unless you're testing different processors. Some processors are just plain faster, and some may work better with certain algorithms just because the curcuitry is built differently. However, that
curcuitry is a giant algorithm on its lonesome.

---

False. Instruction execution depends a lot upon the context/state of the processor before the instructions are executed. The timings are not identical in every case which is probably why Intel no longer leaves a column for each opcode's cycle count. It is probably undefined w/o known register states.

Quote:

---

Originally Posted by skorman00

I'm glad you asked that question!
The reason why is because there are many math calculations that can be done quicker in assembly than using an high level language (HLL from here on out).

---

Quote:

---

Originally Posted by skorman00

The only time when one should resort to assembly is when the language you are using will not allow you to use a specific algorithm, and assembly will.

---

You were talking about algorithms that *can't be implemented in C/C++*, now you are saying they can be implemented in C/C++, just that they might be slower. Congrats on being inconsistent.

edit

Quote:

---

There are floating point operations that actually run faster than their floating point counterparts due to the gains in technology in FPUs and the on-chip implentation of floating point math. Profile it.

---

???
Okay...

I still stick to the stance that nobody on these forums is really getting all that much out of assembly :)

Quote:

---

Originally Posted by vNvNation

You were talking about algorithms that *can't be implemented in C/C++*, now you are saying they can be implemented in C/C++, just that they might be slower. Congrats on being inconsistent.

edit


???
Okay...

I still stick to the stance that nobody on these forums is really getting all that much out of assembly :)

---

I get quite a bit out of it. When I'm coding for handhelds running on an x68 dragonball processor. Assembly is the only way to go on those bad boys.

Assembly reared its ugly useful head when palm pilots were introduced to the market. But now that technology is making the damn things more powerful, and more memory etc. Other languages are supported on the damn things. Like java for instance.

I'm expecting laptop watches real soon--I'm talkin about word processing capable LCD display watches. I'm thinking it will be a bit of a trend. I wouldn't be surprised if the first series will all be programmed with good ol assembly.

Quote:

---

There are floating point operations that actually run faster than their floating point counterparts due to the gains in technology in FPUs and the on-chip implentation of floating point math. Profile it.
???
Okay...

---

I agree. Made a lot of sense eh?

:D

Was supposed to say that there are floating point operations that actually run faster than or as fast as their integer counterparts.

Sorry for the typo.

:D

::bonk::

You know how much RAM would be taken up loading Vvardenfell all at once? I hope that's not what you're saying. No matter what, you'd have to stop and load somewhere. I mean, unless you want HDD operations going on while you are playing your game. I just hope you have a supercomputer for that.

My knowledge of cycle counts on operations is quite outdated, so thank you for pointing that out Bubba. I thought that those numbers were for the Pentium 4, which I was way off. It was for the 486 dx!
I also did not mean to suggest that floating point numbers can be easily handled with bit shifting and such. I apologize to anyone who thought that.

Quote:

---

Originally Posted by Bubba

The compiler will automatically see the integral data type and use a bit shift if possible

---

If you have a good compiler yeah, but I never trust my compiler to do things like that for me. Every now and then, I unroll small for loops just to be safe. But that's just me.

Quote:

---

Originally Posted by vNvNation

You were talking about algorithms that *can't be implemented in C/C++*, now you are saying they can be implemented in C/C++, just that they might be slower

---

I did not say that they can be implimented, I said that C/C++ can do things that will have the same effect, but with a different algorithm.

Quote:

---

Originally Posted by Bubba

How do you suggest we execute programs without opcodes??? What do you think a compiled program is???

---

Well of course you would still use opcodes. But like I said, some of them, the square root in particular, can be avoided. C++ will just say "call that sqrt opcode!" I have seen some algorithms that calculated the square root pretty quickly over on the GD boards, and they used bit rotation. I admit, this situation is very specific, but it's still a burden on some projects.

I'll agree with everybody saying that the gain from using assembly is pretty much NULL now, unless you're working with handhelds, or trying to do things that are "revolutionary". Nobody commented on my example of a memory manager when developing on a console, I would be interested to here all of your opinions on that (do not take that as a "ha ha, I'm right," it's more of "perhaps I am wrong? what do these guys think")

Let me throw this question out there:
Does anybody here think it's pointless to know assembly?

I for one don't, as I stated earlier.