I use it only when hacking games, when making my own, I don't use it at all.

Quote:Original post by eedok
I use it only when hacking games, when making my own, I don't use it at all.

I would place that in a debugging category, since youre probably disassembling and editing in hex.

Never have, never will.

Quote:Original post by Vampyre_Dark
Never have, never will.

Why not? Is intentionally crippling yourself as a programmer just amusing?

Quote:Original post by VanillaSnake21
Thanks for the replies, so basically everyone is saying that assembly is almost dead in games, except for debuggin purposes. I think that overall, the language is becoming extinct as a main production language, the only places it seems to be usefull is in boot-sectors for OSs and console games. I still plan on learning it though, for me it seems so much easier than high-level langauges, mainly because i now know about everything that the computer does and how it does it. I don't know why schools don't teach this as a first and primary langauge. When students know that processesor takes a certain amount of commands, and these command are represented with 1s and 0s, so when a prossessor sees 1001 coming at it knows it needs to ADD the next two varibales, I think that explains it so much better than the way high level langs are teaching us.

Yup in the pre directx days it was still used quite a bit as you can see if you pick up one of Andre Lamothe's first game programming books where he used it to program a sound driver for a game as one example. Also look up Mike Abrash.
Also ,the master programmer Peter Norton of norton utilites fame, wrote the first disk doctor,etc in assembly and if you want to see how he did it pick up his old book where he teaches you assembly. That's how I learned and all his code still works except for the direct disk access code. You also need to use a 16bit linker since it's 16bit assembly code.
But like everyone I've moved on to higher languages as Peter Norton did for later versions of Norton Utilities and everyone else that wants to be more productive.
Only use it now for debugging like everyone else and when using custom console game machines that doesn't even come with basic c compiler so I'm forced to use it.

Quote:Original post by Promit

Quote:Original post by Vampyre_Dark
Never have, never will.

Why not? Is intentionally crippling yourself as a programmer just amusing?

? [lol] I certainly don't view it as intentionally crippling myself. Is a guitar player who doesn't want to play the bagpipes too limiting himself musically?

Everyone was offering their own take, and I was offering my own. Never have / Never will comes from me being a hobbyist who writes small games for fun, and learning asm to get some speed boosts in certain functions has 0 appeal to me.

Everyone wants and gets something different out of programming. I keep my designs small and simple, so worrying about frame rate or other little effiency concerns never really comes into play. I don't push the limits of anything, or require huge amount of resources, so my stuff always runs fast enough, that I don't have to go hunting around and obbssessing over optimizations. (Not to say that I don't go back and rewrite some of my ugly placeholder code I sometimes quickly write, but no need to resort to ASM...)

I'm more concerned with the look, feel, and functionality of my projects, rather than if I write the fastest / most efficient possible functions for every little part of it. I'm sure ASM could speed up some of my stuff, but that's not my goal. I get several hundred FPS on all my stuff on my ancient rig, more than enough for me.

On the PC, PS3 and Xbox 360 optimizing by writing inline assembly directly is rarely a good idea. Using intrinsics is generally better because it gives the compiler a lot more freedom to optimize effectively - using inline assembly prevents the compiler from performing a lot of useful optimizations. The only reason to write assembly on those platforms is if for some reason you can't get the compiler to generate the code exactly the way you want, it's really a last resort.

As others have said though, knowing enough assembly on your target platform(s) to be able to follow what's going on in the debugger is very useful and a working knowledge of assembly is generally useful to help you write efficient code in C++.

In the game code I've seen, assembly was used in a few key places on the PS2 and to a lesser extent the Xbox and popped up occasionally on the PC (often to access particular instructions like rdtsc directly rather than as an optimization) but is very rarely used on the 360, PS3 or newer PC code. Intrinsics are generally used now where assembly might have been used in the past.

Thanks for the replies, I'm currently studying Java in my school, and I came upon a topic of stacks, before I used to think it's only used for memory management but a chapter in the book explains thats it's used in parsing and compiler development. For example to transform the infix to postfix. They gave some example code in Java, which came out to be a couple of hundred of lines long, which is pretty short for a high-language app. But then I realized how easily this could be done in assembly where I don't have to declare any classes, don't have to extend/implement anything, but simply say push this on stack, pop this off, move the ebx to a new position, rertieve the variable 8 bytes from ebx etc. Working with stacks seems almost native to assembly, is that something it could be used for? Thanks

Quote:Original post by VanillaSnake21
Working with stacks seems almost native to assembly, is that something it could be used for?

Not really. While there are a couple of clever stack tricks floating around (many of which will corrode your soul), you have to understand that the stack is there for a good reason and is constantly doing its job - it isn't just a convenient general-purpose data structure for the programmer. If you need a stack to store some user data, make a stack, 'cause the thread's stack won't help you.

As well as keeping track of function calls, the stack is responsible for structured exception handling (SEH). Throwing into the mix temporary storage around linear code, we have a very overworked data structure. Assembly programmers who have tried to rely on the stack for anything other than its well-defined and strictly policed purposes (mainly those involving ESP, EBP and FS:[0]) have lived to regret it. Some didn't even live*.

If you want to use the stack for something clean and appropriate, such as recursion, then you're free to do so in whatever procedural language you choose. From another perspective, if you find yourself needing assembly language to work your magic, then you're almost certainly breaking the rules and will most likely pay the consequences.

Admiral

* I think I made that bit up.