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

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.

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.

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.

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.

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).

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.

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).

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.