GMS 2 My CS professor reversed engineered my game to run faster using assembly

So I spent some time with one of my computer science professors at my college, to learn more about programming in assembly langauge for the intel chip series that has the preceding i in their model names. Well, I made a simple asteroid shooting program based on Shaun Spaldings youtube short video series called " Your first game ",

See :

and gave the program to my professor to show me the problems of programming in assembly language with intel CPUs such as his custom built computer that has a i9 for his windows 10 system. I am using a i7 with my windows 7 Pro to make my games with. He says " Im going to prove you that programming in assembly language is a headache, showing the differences between the legacy instruction set that intel CPUs have to have for backwards compatibility and the special chip set instructions just for the i9 which will not work on another intel CPU other than a i9".

He takes my game copies it to his computer system , then using a program that is like MASM, he reversed engineered my game from its machine language into assembly language. Now in assembly language he was able to find the exact location, where to add specific chip instructions, that access the core layers in his computers CPU. What happened is that he was able to make my game run faster by having the memory that used by game to be shared with the individual core layers in his i9. I dont know how to explain it - like my professor does. In fact he told me that each core can be instructed to manage a different address section of the stack and heap to get those variable values.

So my professor runs my game again on his computer, and it still fast. So he says to me " Why is that when I first ran your original asteroid game it runs slower, than my modified version? The answer is the legacy instruction set which is what game maker studio uses compile code into. That's why windows PC programs are portable to most other systems. Here's the problem with the new version of the asteroid game - It will only run on a windows 10 system that has a i9." I took the copy of the asteroid game that was modified, to try and run on my Windows 7 pro that has i7 - and it crashed the machine, that night.

I go back to my professor the next time I am at college, and I told him what happened. And he said , " That's part of the reason why windows programs are portable with other machines that have windows - because compilers that are made today do not use special instruction set of intel CPUs to produce stand alone executables. Those special instruction sets that are added to the instruction set ( which are separate from the legacy instruction set - which is not obvious unless you have studied the differences ) by the engineers at intel, those are for specific applications that are seldom used. They have no portability at all except to the same CPU model design. There even series different chip sets of series of the same i9 which are not compatible. When you go to your systems folder in Windows, and look at your CPU name,( in my case i7 ) there is a set of numbers after a dash '-' ( usually 4 numbers sometimes) that represent the chip set series ", as my professor continued . " You need to read up on the sandy-bridge architecture used by intel, and purchase a updated book on assembly programming by Kip R. Irvine, again ", he said to me and showing me the book.

( I hate buying college text books because I am forced to buy the one the school using which is too
expensive ! )

Therefore a program written in x86 that use legacy asm. code for a pentium 2 can be ported to a machine
that has a i7 like my computer has, or has a i9 like my professor has, because they have the same legacy asm instruction set. This does not mean a program, such as one written in C source code, that is compiled is portable.

This is the text book that the school is using :


This is what I know about assembly programming :

Assembly programming is never used for building giant programs, now days, its used for optimizing parts of a program, drivers for hardware, and software embedded hardware. My professor has a Xerox photocopier connected to one of his older computers by some invention he came up with, to allow him to use the photocopier as a scanner to send pictures back to his computer, but the software he designed to let him do that , had to have a driver written in assembly.

What I have learned :

I have to be worried about what I program in intel assembly because I have to be aware of the differences between these two different types of instruction sets.

" Tell your friends on that forum, dont bother learning asm. for AMD CPUs - they are not compatible as you think they are with intel CPUs. instruction sets ". - he told me to say that to all of you here at this forum.

That's what I learned about my game and the problems of machine language when it was reversed engineered with assembly.

Now would any of you would like to learn x86 asm for reverse engineering your games ? Note , I do not mean overclocking your CPU.


I love assembly. Although yes, it is extremely tedious for doing large projects such as games with.

I re-wrote part of the DirectX Math in assembly library to see how it compared with Microsoft's implementation. It was compatible down to a 386 CPU and destroys Microsoft's version by up to a 600% performance boost in some functions. The worst performing function is only 150% faster, but that is for a computationally inexpensive function and there wasn't much room to move on that one.

The biggest project I have done (which isn't huge) is to setup a DirectX 11 renderer and draw a model with 3D lighting in assembly. Although an awesome feat, that was probably 6000 lines of hand typed ASM. And ASM is not very forgiving, get one command wrong and your program often exits without any warning whatsoever.

Still very fun though.

Fun fact. A couple of my extensions that I used to sell on the Marketplace were written in assembly.

Now would any of you would like to learn x86 asm for reverse engineering your games?
Hell no. :D

Although it is amazing to have a look at now and then. When you think you have the tightest code possible and you look at how the compiler beats you. You then pick up little tricks to make your code tighter.

For example;

To store '0' in the EAX register. Logically it would be this, right?

mov eax, 0
Can't get any faster and tighter than that, right?

xor eax, eax
Does the same thing, but both way faster computationally and uses less bytes of RAM.

Oh, an hat's off to your Professor. Sounds like he is extremely knowledgeable if he can open up a random application and optimise it like that. He sounds like a cool guy too.
Last edited:
My professor makes learning asm look easy, the problem is that it isnt, once you start reading Irvine's books. I dont think I will be able to take my professors class this term, because I am on the waiting list already , #30. :(


Dunno, I have never found it to be hard. Each command is very basic in what it does.

GML has way more commands than assembly does. Thousands more.

I'd be surprised if I use more than 10 different opcodes (commands) on average when I code in assembly. Maybe even less.


nobody important
GMC Elder
Assembler is pretty simple once you get going, however optimising isn't. In "the olden days", when games were "just" transitioning to C, you would normally write a function in C, then it would easily speed up by about 2/3rds, sometimes more when rewritten in ASM.

But those days are long gone. modern compilers are "extremely" efficient and highly optimal. Multiple pipes, out of order execution, branch prediction, different cache levels and cache lines makes hand tuned ASM only suitable for very small functions really now.

The one place you can usually still outstrip a good compiler is when using SIMD, as compilers just can't do this properly yet. So vector or Matix maths are a good thing to do in ASM if you have a tight loop doing a lot of these calculations.

As to beating GameMaker...well, that's hardly a shock. The VM is a virtual machine written in C, and not "super" efficient, it's evolved for a long time and is in need of a rewrite - something that's pretty high on YoYo's list. So beating that is easy. And while YYC is technically C/C++, it's still jumping through hoops to do many simple operations, so again... beating this with ASM probably isn't that hard.

However... with machines being so fast, you have to weigh your time verses speed. Does a game - or even a function NEED to be that fast? Sure, lets say you speed up a game 100 times - which, on an Asteroids game compared to the VM, is probably possible - it did used to run on VERY old hardware after all. But it will take MONTHS and MONTHS to do this - if not longer. In GameMaker, you can so this in days - or weeks, and the machines or even phones they run on, as so massively powerful compared to the older machines, does it really matter?

You need to look at the 80/20 rule (might be even higher now).... 20% of your code being run 80% of the time. In the past, this was rendering. So write the rasterisers in ASM, and you were usually golden. Now... this isn't as clear cut as they all use GPUs, so you're looking at game code, meaning you have to profile and optimise, but I can guarantee that you can simply rewrite your high level code better, and still have it run faster.

In general... ASM is a great, fun thing to do, but not really required for modern machines. That being said, they CAN help you debug nasty bugs more easily if you do at least understand the basics. If you wanted to do that, ignore Intel and big PCs, go back to retro machines, the C64, ZX Spectrum and learn 6502 or Z80. You'll see an immediate effect on speed ups, you'll still be able to write pretty much the same games but in pure ASM, and I guarantee you'll learn more using them than trying to speed up some Intel code.

There's a huge retro community so anything you produce can actually be released on these machines, not to mention seeing your stuff run on an old machine is always a thrill. There's also loads of tutorials and help to learn these older ASMs, not to mention the tools and emulators make it much easier.

If you don't get into the class, do it yourself. That's how all the old school coders started, the machines are monumentally simpler, and easier to get into that big PCs, and once you understand and can write ASM in these, moving to other CPUs is very simple

Just my $0.02 :)


nobody important
GMC Elder
Uhoh we set Mike off again... :p
It's a shame the VM bytecode isn't visible in GMS2's debugger like it is in GMS1. I learnt a lot by looking at that.
Sorry.... time for my pill again....

wouldn't really do much good, it's the VM that's slower anyway. If you need something much faster, write a C++ DLL....


Oh for sure, for optimisation purposes it's of marginal benefit. But for the sheer learning experience of "what does bytecode look like in a VM" it's been invaluable.