ASSEMBLER POWER! Why you should consider 386Power for game devenlopement. ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ CHAPTER ONE: Some misleading objections to the use of assembly language ------------------------------------------------------------------------------ 1) C/C++ is as fast as assembly and it is easier to code Right! C is NEARLY as fast as assembly if you use C as an "improved assembly" (read: if you heavily use pointer tricks and you code thinking carefully at what the compiler will do with your code) BUT ... if you have a "critical" loop that gets executed 90% of the time your program runs, the little speed difference between C and assembly becomes a 5..10 frames per second difference. C is not easier to code than assembly, it is easier to learn and easier to port to another operating system (BUT ONLY IF YOU START CODING WITH BOTH EYES LOOKING AT EASY PORTING) ... that is, only if you code with an eye to the future. Is not the language that makes a good program! I started programming in Pascal on an old Data General mini at the I.T.I.S. (sort of italian high school oriented to industrial applications) then i learned Z80 assembly, 68000 assembly, C then 8086 assembly, a little of Lisp and Prolog (very little) and at last 386 assembly. I see assembly as a "spartan" high level language and apply to it the same techniques (with an eye to code optimization). I never had problems. I just thinked a lot and planned a lot what to do before start coding. I never really needed a debugger, my brain was enough to simulate the program run and seek&destroy bugs. The key for this ,is coding in modular way and if something fails restart from a previous "all system go" situation and start activating new code a piece at a time. Antique aproach you say? Heck! This works for rocket scientists, it works for programming too! It is the method, not the tool what really counts. Now comes the interesting thing, if you code in assembly you will know what is the exact code your cpu executes, excluding chip bugs and assembler bugs you know exactly what happens. If you use C ,the actual code (and compiler quirks) changes if you just switch a compiler option, the same can happen with an assembler but it is less frequent. Yeah! There are some terror stories about bugs that only a debugger can discover ... But usually these bugs are produced by badly designed code. Planning and analisis takes 50% of code production, coding takes another 10% and profiling takes the other 40% if you coded correctly, debugging&testing will take another 100% ( expect spend twice the time you planned) BUT IF YOU CODED THE WRONG WAY d&t will take 10000% and you will be dead and this does not depend on the language you coded. ------------------------------------------------------------------------------ 2) C is portable and assembly is not. Sort of... if you "mark" self modifying code and self-compiling code (so you will be able to quickly locate it for update) assembly becomes as portable as an high level language (you just need a code translator, and this is an easy thing to do) IF YOU USE 386 ASSEMBLY you will never have to worry about porting. 386 assembly is sort of "industry standard", supported by real cpus (from Intel,Amd,Cyrix,Nexgen,IBM ... even from the PowerPC 615 CPUs!!!) or by processor emulators running on powerful risc machines. What's more I CAN produce a cross assembler to port 386 assembly code to another instruction set (Heck! Last year i made a C to C++ translator assembly translation is a lot easier) (you just need to "translate" a finite state machine), if everything goes RISC i can produce a translator. IS THE ENVIRONMENT WHAT MATTERS, that's why i introduced the XGE device drivers. With the correct drivers a 386powered program can run even on and X-window workstation. ------------------------------------------------------------------------------ 3) You need an high level language to write big programs. Don't think in term of "writing a big program", a game is mostly made of images,sounds and FINITE STATE MACHINES describing "game agents" and "game objects". The actual program code is very little. Instead of making lots of subroutines, make "generic" finite state machines emulators, and then add the state evolution and output tables needed to describe the various things. As weird as it seems finite state machines looks all the same so a f.s.m "engine" can be quickly coded in assembly. With 386P+XGE you already have the foundation code, add some drivers for your video/sound card and what's missing is just the specific code to implement the finite state machines and some special effects. N.B. Don't ask me about "the other code needed to make a game engine" the rest is very specific, it depends on what you want to do and how you want to implement it ( not to mention it is what makes the difference between a fair game and a terrific-ultra-cool game). ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ CHAPTER TWO: How to correctly use assembly 1) Plan a lot The more time you spend planning what to do and how to do it the less you will spend debugging,profiling and testing. Also plan HOW to test is everything goes right and HOW to test if something goes wrong, this speeds up debugging a lot. This applies to every real world activity, but on things like programming this is the key to get the job done. 2) Use "deep thinking" optimizations only where you need maximum speed in all the other parts use compact and easy to read code. Stick lots of comments where the code gets tricky. When you will reach the "all time optimizing mentality" you will easily optimize the code as you type it and optimized code will look easy to read (to you), but this takes some time, don't run too fast. 3) Don't made lots of similar routines, made one that's generic enough and if you wan to keep parameter passing simple, make multiple "interface" routines (to reduce the code needed to stuff parameters into registers or stack). Use "different" routines only whe absolutely needed. 4) Use assembly to MAKE bricks, NOT as a brick. Then use the bricks to build the program. Make things modular, but plan ahead how to subdivide things. One of the reasons i delayed the distribution of 386P 2.00 was that i had not a clear vision about how to make the sound system modular. (Gee! I hope i got it right!) 5) Try to keep "clean" your code, use nasty tricks only where absolutely necessary. 6) Know when it's time to break the rules and when it's not (only experience will tell you how). ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ CHAPTER THREE: The dos-extender advantage The big advantage of using a dos-extender is that you program can run on anything from a plain ms-dos system to a RISC machine with a 386 emulator AND can always run faster than a plain 16bit ms-dos or Windows program. Some people think that the 32bit advantage is just more memory and 32bit access, wrong! There is also 32bit addressing! Accessing memory thru a single 4Gbyte segment you can almost forget of segment registers (almost!!!), you code quality improves a lot (no more fucking segments to swap around) AND the extra 32bit addressing modes can boost your program if you know how to use 'em. My 32bit code ROARS,it is TWO TO EIGHT TIMES FASTER than equivalent 16bit code. Of course there are situation when the difference is nearly zero (accessing things byte-by-byte) or 16bit real-mode code is faster (when doing things that cause protection checkings), but you can limit 'em to the minimum. If you deal with graphics and sound you will see and hear the 32bit difference!