Games

[entry1wound]

I figured I'd get a general opinion of others here for my own project; I'm wondering if I'm just being absolutely retarded about this or if it's actually feasible.

I would absolutely LOVE to write a game in pure x86-64 assembly.  I've written a basic engine in C++ using DirectX, but I'd love to be able to handle all aspects of it directly from assembly.  One idea I had was to use the generated assembly from the project listing, clean it up, and then modularize it where appropriate.

Do you guys think this would be feasible?  Assume I like torturing myself with low-level shenanigans.

*EDIT*

Part of the reason why I want to do it in assembly is because I'm supporting both DirectX 9.0c, and DX10 (due to DX10 ridding of the fixed function pipeline), and the most optimized form I can get it in is hand written assembly.  My goal is to establish a lower bound of 120 FPS, even on midrange cards (nvidia 7xxx series).  That, and I have direct access to the vector registers (SSE 3), and I can fine tune thread synchronization with MONITOR and MWAIT (provided the processor has it, CPUID stub is the first part of the program).

So far, I have a simplistic terrain engine written to cover maps that would be outside (it's a third person shooter with some added goodies), and a dynamic system to include maps that would run inside (simple model view).  Gimbal lock is all sorted out, and the engine is starting to take a unique shape.  If any of you here have played the game GunZ, it's similar to that (if you haven't youtube it and you'll et a feel for what I'm talking about).  It's turning about to be a really fun project, but I need some added control in order to achieve my performance goals, hence my question.  Would it be feasible to continue the project in only assembly language?

So now that I've at least provided a sane basis, I feel better about asking the question lol.   :lol

[baltoro]

...absolutely retarded,...

...It's a good question,...actually,...
I was reviewing an older book that was written about writing games,...and apparently, in the days before DirectX and Windows NT 4, ALL games were written in assembly,...because it was the fastest code they could write. So, it could be done,...but,...games are so fiendishly complex nowadays, I think you'd have a hell of a time debugging it. I think the more appropriate question would be: are you insane enough to write the whole shebang in assembly ???
Modern compilers, like Visual Studio, just make it all just TOO easy and convenient (and, they catch alot of your initial errors, too).
...Which is probably why most new games are written in C++.
I have written a couple of DirectX programs in a mix of C++ and assembly (doing COM in assembly, while possible, is alot of work),...and, I think it's great for a variety of approaches,...it gives you enormous control,...and, it's perfect for trying stuff out that you know would be cumbersome (or, ambiguous) in just C++. For instance, when you call a standard Windows API (or, C runtime functions),...you never really know what subroutines it's calling,...

:eek ...Oh,...and, by the way,...I'm the reigning King of absolutely retarded,... :eek

[Twister]

Game programmers back in 80s and 90s were literally cram-packing as much code and graphics onto their 20 kB ROMs. The only choice was assembly due to its small size, and the game systems ran at a few Mhz so speed was critical.


A game engine is feasible in pure assembly language.

[jj2007]

Unless you are the king of coders, consider to stay with 32-bit, as 64-bit assembly is still very messy.
Have a look at the 64-bit subforum, and search for macros, calling convention, Jwasm.

[donkey]

Unless you are the king of coders, consider to stay with 32-bit, as 64-bit assembly is still very messy.
Have a look at the 64-bit subforum, and search for macros, calling convention, Jwasm.

I disagree Jochen,

It depends on the tools you're using. I am exclusively writing 64 bit apps now, the only 32 bit stuff I'm working on is a few unfinished projects. From the GoAsm perspective it is virtually identical to 32 bit coding and for the most part source level compatible with both if you follow a couple of simple rules. The macros in macros.h are being ported to automatic switching between 32/64 bit for example the CoInvoke macro which auto-switches make coding nightmares like COM in 64 bit source compatible with its 32 bit counterpart.

I agree that from a MASM standpoint 64 bit is crippled and not worth the headaches for now but that will change as coders like entry1wound keep working with it. Warning people to keep away from it does nothing to advance the available coding base and macro library for it. I have taken cursory look at JWasm and it looks to be easy enough to make the change over, all in all a very good package for 64 bit coding.

For the game engine, you should check out Homer's excellent game engine tutorial at asmcommunity.net

[jj2007]

Edgar,

You are probably right. I just thought he should really know what he is up to (and he seems to be a very skilful C coder indeed).

[Vortex]

Hi entry1wound,

Bogdan's RTS game Hostile Encounter is coded with asm. Here is the link :

http://oby.ro/rts/index.html

It is written in FULL 32bit Win32ASM for great speed and effects

Game demo runs under Microsoft Windows 95,98,Me,Windows 2000 and Windows XP

[BogdanOntanu]

I have just installed and tested it and it also works on Windows 7 x64 ;)

[entry1wound]

These are awesome replies (not to bump or anything).

I would call myself sufficiently experienced, so I know what I'd be getting into.  64 bit processors were actually my target, seeming as how it would be prudent to write a game for newer processors (and most these days are 64-bit).  Donkey, I definitely agree with you...there are some kick ass tools that allow you to use macros and such to create bit-width-agnostic code, too.  I'd evaluate those before I start.

Thanks for the support guys ^.^, thoroughly appreciated.

[donkey]

Hi entry1wound,

I would start by looking at JWasm, though I can't vouch for it myself since I only tried it to see if some libraries I wrote would be MASM64 compatible (they aren't but I'm working on it) it has the signature MASM macro system which is very powerful. You might also want to take a look at FASM, it also has a powerful macro language. GoAsm (the assembler I use) allows easy switching between 32 and 64 bit however the macro language is limited at best though most of the common macros in MASM are intrinsic to GoAsm such as inline strings, Unicode support, better structure member isolation etc.. Also GoAsm does not require import libraries and my headers allow you to switch between 32 and 64 bit easily as the structures and types are automatically adjusted for differences in data width between the two (I believe that JWasm includes do this as well). For now at least I would suggest you stay away from MASM as it was severely crippled in the 64 bit port with a lack of the high level directives and there are no plans to fix it.

[hutch--]

entry1wound,

To address your original question, if your C/C++ code is well written and the concept is well designed you may not see any gain for the vast majority of code by manually coding it in assembler. Where you may see gains if the code is well written is in speed critical areas that you would find with a profiler or similar. If you use a C/C++ compiler with a compatible object module format then writing dedicated modules in assembler is a viable option that is compatible with your C/C++ code.

The choice of which assembler you use is of course your own but if the future interests you, then picking one that will still be around has some mileage. There are a number of good tools available but ML64 is produced by the OS vendor and it does the job they need it for but its main advantage is it will be there as long as Microsoft will be there as they need it themselves.

[entry1wound]

Hutch,

That's a very logical argument.  ML64 is going to be around if 64 bit windows is around...So I'm at least guaranteed compatibility.  I've done some 64-bit apps (trivial in comparison) with MASM and I've had no trouble...I'm guessing the faults lie in the reliability of large structures/multiple modules?

As for the already written C++ modules, that is EXACTLY what I want to accomplish.  The high level structure of the game is outlined in C++; an example would be just a straight game loop:

AI()
Physics()
Draw()

etc.  Basically, the C++ is just my flowchart...the meat and potatoes of the processing done in each function would be done in assembly.

Donkey,

I was wondering how GoAsm would turn out as I haven't tried it, but since you seem to have had success with it often I don't see why the hell not ^.^

Thanks guys,
entry1wound

[donkey]

Hi entry1wound,

I use GoAsm for stand alone applications mainly, I haven't tried integrating its output into my C projects but there should not be too much of an issue. When I (rarely) need to have asm and C mixed in a C project I tend to use inline assembly as it usually just short snippets that are easier to write in asm than in C, at least they are for me. As I said the macro support in GoAsm is very limited and since you will likely need extensive macros from the sound of your project it is iffy as to whether it will meet your needs. Give it a try though, it is a very nice package.