Shannon V. OKeets
Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
|
March 1, 2010 Status Report for Matrix Games’ MWIF Forum
Accomplishments of February 2010
Project Management
I monitored all the threads in the MWIF World in Flames forum daily.
Hardware and Software
I spent virtually all of February replacing assembler routines with equivalent Pascal routines. This is still a work in progress but it has improved the performance of the Delphi 2010 IDE (Interactive Development Environment) when executing MWIF in debug mode. Happily, I am now able to examine internal values of variables while the program is running. Things aren’t 100% what they had been when I was running Delphi 2007, but they are ~80% now. Once I get the rest of assembler code replaced with pure Pascal, I am hopeful of getting my debugging efficiency back to where it was a couple of months ago.
Why am I removing the assembler code? Well here is a short explanation from Zorachus99:
No wonder you are having trouble with your IDE.
1) Some registers are being quietly deprecated, and a lot of the old ones don't work the same in a 32 vs 64 bit OS.
2) New registers are being added to processors for a variety of reasons
3) Some registers are being re-purposed to do different things.
The short and long as a result:
1) OS (Microsoft) vendors don't want you playing with the CPU directly and go to great lengths to prevent it with emulators (which fail regularly). This is primarily because 16 bit != 32 bit != 64 bit != 128 bit registers.
2) Theoretically you could live off emulators, but it's better to move up a level and abstract routines, not directly handling hardware, rather than try to drive the hardware at maximum speed.
Registers are the storage locations used by the CPU. Indeed, they are a physical part of the CPU. I wrote a couple of games in assembler for the 8086 CPU, which evolved into a family of CPUs known collectively and the X86 CPUs. If you are running Win7, you’ll see that your file directory has two folders for program files: Program Files and Program Files (x86). The latter is for programs written for the older x86 family of CPUs.
I have some direct evidence that the problems I have had with Delphi 2010 relate to the CWIF code that is written in assembler. In technical terms, assembler works with the CPU registers directly, and the CWIF code modified the call stack directly. As Zorachus99 said, the guys who write the operating system code do not want application programmers messing around with those. From a practical point of view, if they don’t want you (the application programmer) to do that, then you shouldn’t, since it is likely that you will not be informed about changes they make in the operating system. If they change something in the operating system that the application program’s assembler code was relying on, well, then the program crashes.
Pascal is a strongly typed language - it has a lot of rules about what can and cannot be done. While you can add ‘St’ to ‘eve’ and get ‘Steve’, or add 3 to 4 and get 7, you cannot add 6 to ‘air units’ and expect to get 6 air units. The compiler checks to see that everything makes sense. If any of the rules it imposes are violated, the compiler displays an error message when the program is compiled, or at least a warning message.
Assembler works with binary strings (e.g., 0111001) and uses them for both variables and procedures. In assembler, variables are untyped - ‘this’. A procedure - “do that” (e.g., sort by unit type, find all bombers) is also a binary string. In assembler you can add 6 to air units and the compiler will not complain. Of course the program will crash in strange ways when it executes that instruction, but there will be no warnings from the compiler about the faulty code.
For those of you who do not understand any of this, let me try a simple analogy. Pascal has rules, like the rules of the road for cars. It stops the programmer from violating the rules of the road, thereby preventing numerous crashes. Assembler, however, has no rules. The cars can drive wherever they like, however they like. With assembler, you can go the wrong direction on one-way streets or exceed the speed limit on S curves. That is fine if the driver/programmer is very careful and it helps if you are the only car on the road.
When we introduce different CPU chips (e.g., dual core and quad core), there can be more than “1 car on the road”. Threading has a similar effect. The operating systems that you are use to running keep several program executing simultaneously and they do that using complex software that works down at the level of the CPU registers. An application written in assembler relies on the CPU registers and call stack being available according to certain rules. If the operating system vender (i.e, Microsoft) or the compiler vendor (Embarcadero) changes those rules, then the program has to be modified to obey the changed behavior.
So, MWIF contained a fair amount of assembler code. The new CPUs and operating systems don’t process that code as the programmer intended/expected. More threatening, Embarcadero has announced that integrating assembler code into Pascal code with be deprecated in future releases of Delphi.
While I was able to replace a lot of the assembler code easily, there were a few places where a one-to-one replacement could not be done. The assembler code more or less took ‘this’ and did ‘that’ to it. Pascal wants all those variables and procedures typed. While the assembler code worked with all variable types and all procedure types, in Pascal separate code fragments are necessary for each variation in the program. There were ~1730 references to one assembler procedure in MWIF. Each of those single line references requires 8-10 lines of new code. Over the course of February I have gotten that count down to 590, while also cleaning up all the other miscellaneous bit of assembler code. I should be able to purge MWIF of the last traces of assembler in the next week. Note that once all the assembler is gone, I will have added ~14,000 lines of new code to the program.
Beta Testing
Right now the beta testers are running into fatal crashes caused by Theme Engine 9.10. But I am assuming that software library is innocent until after I get all the assembler code removed. If it still causes trouble once the assembler code is gone, I’ll look into rewriting some (as little as possible) of the Theme Engine source code - i.e., I’ll debug it for MWIF.
I released versions 4.00.06 and 4.00.07 of MWIF to the beta testers in February. The primary goal of these versions was to let the beta testers see if I screwed up anything that use to work before my hundreds of edits replacing assembler calls.
Saved Games
Nothing new.
Map and Units
Nothing new other than some more naval unit writeups from Rob/Warspite.
Scenarios and Optional Rules
Nothing new.
MWIF Game Engine and CWIF Conversion
Assembler code replaced with Pascal code.
Player Interface
Nothing new.
Internet - NetPlay
Nothing new.
PBEM
Nothing new.
Artificial Intelligence (AI)
Nothing new.
Player’s Manual
Nothing new.
Tutorials, Training Videos, and Context Sensitive Help
Nothing new.
Historical Video, Music, and Sound Effects
Nothing new.
Marketing
Nothing new.
Communications
Nothing new.
_____________________________
Steve
Perfection is an elusive goal.
|
Printable Version
RE: When? - 
. The one area I thought ADG took a backward step with was when they changed to the latest maps....those mountains..horrible 
. MWIF maps on the other hand are the business. 
. 
RE: When? - 
Well you're partially right. At least Steve gives us enough to maintain body weight. When I heard that TOAW's long-awaited patch was going to deny larger scenarios even minimally functional naval unit attributes(when it ever shows up -MWiF may get here first) I switched avatars. To me all other work on that game is tantamount to rearranging deck chairs on the Titanic.
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread