• Advertisement
Sign in to follow this  

Assembly coding with DirectX

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

Hi everybody: I'm new to GameDev.net and this is my very first forum post. I'm a computer engineering student and my ultimate purpose in life is to become a great game developer and to create my own video game company. However, my university does not focus on certain API's or languages. Rather, the learning program is centered around the major components of the computer sciences, regardless of the plattform or market niche. That's why we are forced to learn the nooks and crannies of the different API's and languages on our own, though based on the strong conceptual and architectural foundations taught to us in the classrooms. So, I've enforced myself into learning various languages and API's in order to broaden my action scope. This way, I've learned languages such as VBScript, SQL, Java, javascript and so on. I've also researched in API's such as J2SE, J2ME and a bit of Win32. Right now, I'm starting research on the DirectX API, and I've realized that it's crafted in C++. This lengthy introduction leads to my primary question: Seeing as how C++ is compiled to native code and therefore can be used in conjuction with Assembly-coded routines, I was wondering if this could be possible with applications using DirectX. Maybe the question should be put the other way around: Could I use DirectX in appications programmed in Assembly code? I know that programming in Assembly is rather stupid these days, but it will always be true that the Assembly code is much more powerful than any high-level language, and therefore allows the developer to wield an immense programming power and more often than not, more efficient coding, both in terms of time and resources usage. I know it's a bit long (and maybe pointless) question, but I hope someone could help me in this one, so I can begin experimenting with Assembly routines (especially in MMX and Core ISA's) to program powerful and resource-cheap graphic engines and interactive applicatios with DirectX. Thanks in advance! Tsuki wo miru tabi omoidase!

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Fighterguard
I'm new to GameDev.net and this is my very first forum post.

Welcome!

Quote:
I'm a computer engineering student and my ultimate purpose in life is to become a great game developer and to create my own video game company. However, my university does not focus on certain API's or languages. Rather, the learning program is centered around the major components of the computer sciences, regardless of the plattform or market niche. That's why we are forced to learn the nooks and crannies of the different API's and languages on our own, though based on the strong conceptual and architectural foundations taught to us in the classrooms.

And that's how it should be in my opinion. API's and languages come and go, and should be easily to get familiar with. The underlying basics are something you wouldn't easily pick up by yourself, yet are extremely important when designing and implementing software.
Quote:
Seeing as how C++ is compiled to native code and therefore can be used in conjuction with Assembly-coded routines, I was wondering if this could be possible with applications using DirectX. Maybe the question should be put the other way around: Could I use DirectX in appications programmed in Assembly code?

Possible: yes. Sane: no.
Quote:
I know that programming in Assembly is rather stupid these days, but it will always be true that the Assembly code is much more powerful than any high-level language, and therefore allows the developer to wield an immense programming power and more often than not, more efficient coding, both in terms of time and resources usage.

It's not true. Focusing on individual instructions will not give you better performance, especially regarding the complexity in today's applications (including games). Proper performance starts with a well designed system and for instance in the case of Direct3D, with a good understanding of how the GPU works. And when it comes to development, I couldn't possibly imagine how a game completely written in an assembly language would be lead to more efficient use of time.

Share this post


Link to post
Share on other sites
Thanks for your reply!

I'm not intended to code a game ENTIRELY using Assembly code (that would be nuts). Rather, I'd use Assembly in certain, very specific spots, to take advantage of certain instructions that are not accounted for by high-level compilers. CISC CPU's (e.g. Pentium and Core2 CPU's) are devised with a huge instruction set. Many of those instructions are, as far as I know, never used by high-level compilers or API's. That's why I would like to make use of such instructions that (for a good reason, I bet) are included in the ISA.

However, if anyone can assure that, by means of DirectX, I can harness the full potential of my CPU and GPU, then using Assembly would be fairly pointless.

I hope this further clarifies my point, and thanks again for your reply.

Share this post


Link to post
Share on other sites
Quote:
Original post by Fighterguard
Rather, I'd use Assembly in certain, very specific spots, to take advantage of certain instructions that are not accounted for by high-level compilers. CISC CPU's (e.g. Pentium and Core2 CPU's) are devised with a huge instruction set. Many of those instructions are, as far as I know, never used by high-level compilers or API's.

When Intel, AMD or any other CPU designer creates a new iteration of a CPU they have to make engineering decisions - how much silicon is available, how much cache, and so on. One of these decisions is based around optimising the way instructions are processed. Ideally, you want the instructions that are commonly used to execute really fast at the expense of the less frequently used instructions. Companies do not guess these parameters - they analyse the millions of instructions dispatched to the CPU in a modern operating system. Most modern software is written in high level languages so there will be a subset of instructions that will show a peak in the instruction frequency analysis and these will be the instructions the chip designers will aggresively optimise.
The point here is that the type of instructions the compilers don't use are generally much slower in relation to common instruction when compared to previous CPU designs. For example, the XLAT instruction used to be a helpful instruction on the 8086 but is no a dreadful instruction to use because the architecure of the CPU is not geared towards this kind of instruction.
Quote:

That's why I would like to make use of such instructions that (for a good reason, I bet) are included in the ISA.

They are included for backward compatibility. As I said above, there are many instructions that were implemented efficiently on the 8086 which are really slow on a Pentium.

Skizz

Share this post


Link to post
Share on other sites
Quote:
Original post by Fighterguard
Rather, I'd use Assembly in certain, very specific spots, to take advantage of certain instructions that are not accounted for by high-level compilers. CISC CPU's (e.g. Pentium and Core2 CPU's) are devised with a huge instruction set. Many of those instructions are, as far as I know, never used by high-level compilers or API's. That's why I would like to make use of such instructions that (for a good reason, I bet) are included in the ISA.

Good reason? What on earth makes you believe that?
Good reason is the last thing you'll find in a x86 CPU.
And while it is cluttered with dozens of old unused instructions, they're unused for a reason. They're slower than the alternatives. They're still supported for backwards compatible, but if you read AMD's or Intel's optimization manuals, they'll list a bunch of instructions that you just should never use. They work, but they're not fast.

(The obvious exception here is SIMD instructions, SSE and its derivatives, which most compilers can't handle)

Quote:

However, if anyone can assure that, by means of DirectX, I can harness the full potential of my CPU and GPU, then using Assembly would be fairly pointless.

You can't. The question is whether you can harness *more* of its potential than you could in assembly.
There are two sides to this question. First, not using assembly would actually allow you to be reasonably productive, which would mean you'd use your hardware's potential a lot better. And second, compilers aren't perfect, but they do a fairly good job at a pretty complicated task. You have to *really* understand the CPU's you're targetting, and be *really* good at ASM to compete. But if you can do that, then yes, you can often produce better code than the compiler.

So basically, don't bother. Write in a high level language like sane people do. And then, if and when you run into performance issues, you can start looking at whether to convert the hotspots to assembly.

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
So basically, don't bother. Write in a high level language like sane people do. And then, if and when you run into performance issues, you can start looking at whether to convert the hotspots to assembly.


Thanks a lot! This is exactly the sort of answer I was expecting to recieve. It's true that many things have changed since the times of the 8086, when it was almost necessary to write in ASM. These day's compilers do a pretty good job at exploiting the most important (and powerful) instructions, but, since Core is a fairly new architecture, maybe the current compilers and API's have not yet exploited its full potential. That's why I wondered if I could use Assembly in tandem with high-level, DirectX based routines. But I think I won't bother myself for now and settle for traditional C++ "like sane people" as you say.

Share this post


Link to post
Share on other sites
Quote:
However, if anyone can assure that, by means of DirectX, I can harness the full potential of my CPU and GPU, then using Assembly would be fairly pointless.


I don't have any resources handy, but you might want to look at graphics pipeline as it applies to GPU accelerated hardware, and the abstractions of it through DX.

You may find that the large performance difference between accelerated and CPU-based rendering comes solely from algorithmic and hardware optimization - not low level assembly hacks.

Especially when it comes to complex rendering, you can get 5,10 even more -fold increase in throughput by rearanging the data sent to GPU, rather than optimizing something locally.

GPU is where performance comes from. SIMD is what can be used to prepare the data you're sending. Shaders can be used to manipulate the pipeline directly. The glue that binds all of these (what you're talking about) might as well be javascript - it has negligible impact. Even in cases where it might matter - it'll be the last place where performance is to be gained.

Perhaps a much bigger problem to address are memory allocations and management, but once again, algorithmic optimizations will give more benefits.

Quote:
since Core is a fairly new architecture, maybe the current compilers and API's have not yet exploited its full potential. That's why I wondered if I could use Assembly in tandem with high-level


Multi-core processors allow for concurrency. Once again, nothing to do with assembly. You'll be almost certainly stuck with whatever your OS provides you with for this.

Share this post


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

  • Advertisement