Jongware

Of course the second xor ax,ax in the original code was not necessary at all :D Well, it probably came out as such out of the compiler. Wasn't Dune II written using Borland C?

How about this: mov ax, 0xFFFF push ax push si inc ax as "inc ax" is only a single byte opcode.

Nah -- back when Dune II was new it was my favourite game! I spend hours on disassembling it, first with DOS based utilities, then with one of the first free IDAs. You've come a long way since then ... I was mainly checking out how the graphics worked, and wrote sort of a self-running demo with a day/night cycle -- quads riding around with headlights, stuff like that. I'm fairly sure I still have a commented disassembly somewhere on my PC; if I can find it, I'll try to confirm what I wrote above, as it was totally from memory.

(Warning: All from memory!) The programmers used a shortcut there. Rather than checking each single pixel for the to-be-remapped colors, they used (IIRC) XLAT to translate from the pixel value into an array of color values to use. So if the original values for a row of pixels is (just some random values) 00 01 90 91 50 51 after an XLAT into the Harkonnen color array, they would translated into 00 01 90 91 50 51 (because the Harkonnen color array doesn't change colors -- the default unit colors are Harkonnen), and for the Atreides, they'd get translated into 00 01 A0 A1 50 51 because in the position '90 91 92 .. etc.' in Atreides' palette, it contains the values 'A0 A1 A2 ..' etc. Assembly Refresher: XLAT uses AL as input and returns the value in DS:[bX+AL] into AL again. So all you have to do, as a programmer, is point DS:BX to the color translation array.

Slick! Designed by a Star Trek:TNG afici.. erm, fan, no doubt!

Just checking: you are aware this is an old game, running in palettized 320x200 mode? The "glow" color may just be using one single color index, with some timer rotating the R, G, or B (or a combination) values of that index up and down. Perhaps it works like this: the RGB color of the index you found is copied to a buffer, and that gets read to draw a rectangle in the 'glow' color index (rather than directly in the color index of the lookup), and after that it's just that one index that gets updated. If you are able to make color indexed screenshots of various score screens, you might find that the differently coloured bars are, in fact, using the same index. It's what I would do, leaving the other 255 colors (a preciously low number) unchanged, to draw the rest of the screen with.

What machine did you develop it on? If everything compiles correctly, you might have endian problems. I see a getU32LE function (/macro?), did you consistently write your code like this? Though I couldn't spot an error with a few cursory glances into the files where I know 'what it probably should do' -- very good written, AFAICT. Such stuff ought to run right away :-( Any specific parts?

[OT] Well, that's the reason I have poor Dr. Yueh as my avatar -- recently switched over to Mac! Okay, Dune 2 on the Mac in 5 easy steps. 1. Download DOSBox For Mac OSX from its home site. 2. Find a Dune 2 package. Lots of them, but ... the one I got has been zipped as a self-extracting archive on a Windows system. It does not work in DOSBox ... 3. Other than on Windows, you cannot fool the system by renaming "dune2.exe" to "dune2.zip". So find a good archiver. I got p7zip from http://web.me.com/krmathis/. The package will contain a 'binary' called "7za". Copy this into your home account root folder -- simply open any Finder window and keep on going "up" until it shows your hard disk. Open this, then open "Users", and there you will find your home folder. 4. In that same home account folder, create a folder DUNE2 and copy the to-be-unpacked file into it. 5. Start Terminal! It will open in your current home folder. 6. Type "ls" -- it should display a list of your current folders, as well as the 7za executable. Type "cd DUNE2" to change to the folder you just created (and containing the packed dune). 7. To unpack, enter "../7za x Dune2.exe" -- this will call the unpacker from one folder up (remember? That's where you put it?), extracting the file "Dune2.exe". Watch out as Unix (and thus the Mac OSX terminal) is cAsE sEnSiTiVe. When done correctly, you'll see the file names scroll by as they are unpacked, and you can also see them with the "ls" command. Close the terminal. 8. (Eh. I did say "in 10 easy steps, didn't I?) Start DOSBox. Yippee (once) -- a DOS screen! 9. Enter "mount c ~" -- that's right, nothing else needed as path name. Enter "c:" to go to this mounted 'drive' -- your virtual hard disk. Enter "cd dune2" to go to the game directory. And, wait for it .... 10. Enter "dune2" to start the game! Yippee!

Prolly falling under "better late than never": a tag simply always starts at the next even offset. If the size of the previous block was odd, a zero byte is inserted. (Thinking: recently had to find this out myself again -- where are the file specs when you think you don't need them anymore?)

That's correct. The weapon damage is shifted right twice, dividing by 4 (bitwise; 0b001101 -- 13 goes to 0b0011 -- 3). Then this new value is subtracted from the original value: weaponDamage -= (weaponDamage >> 2) resulting in a damage value of 0.75 times the original. Well, that and some rounding down.