I'm in the game now. Monster AI has been ported, objects, moreobjects, and inventory all are in and compile. I managed to clear out about 10 functions from the MissingFunctions collection. Unforunately, the main display seems to be suffering from an off-by-one error in a couple of spots (map looks off-by-one and some of the buildings are the wrong characters).
....
Updates delayed due to me catching the Starcraft2 Beta sickness (what a fantastic sickness to have...) and being in Hawaii. Finished converting object.c. Still blocked from the game loop due to not implementing moving Spheres of Annihilation. I need to fix a few more compile errors. This file got much simpler since I'm not using a linked list but a C# generic list now. I did enjoy finding the snippet above though. The smarter you are, the less likely the sphere is to change directions.
Ignoring the fact that everything shares a global namespace, I've managed to hit the most highly coupled parts of the source. To be fair, some portions of a game are all but impossible to make any other way (i.e. AI has to understand all the game data, so even if you try to abstract the information for the AI, something has to convert it into that form which leads to high coupling).
In Larn, lookforobject is the highly coupled function. In its own words:
/* LOOK_FOR_OBJECT
subroutine to look for an object and give the player his options if an object
was found.
do_ident; identify item: T/F
do_pickup; pickup item: T/F
do_action; prompt for actions on object: T/F
*/
It doesn't look like combat is handled here, but I suspect that the next time the source compiles, the game will be 80-90% converted.
The maze display isn't up yet because I'm missing lookforobject, but everything is going smoothly.
I'm still trying to keep my graphical text rendering separate from the actual Larn game code. Unfortuantely, that means that there are two active game loops. I've managed to get around that by threading and sharing the TextConsole object (a char array with terminal functions (add text, move text, etc. Basically a VT100/Ansi equivalent)). The DX9 engine creates the Larn game on a separate thread and waits until it creates a TextConsole, which it then grabs a reference to use for pulling data for rendering.
The biggest issue that I'm having is that I'm very nervous about race conditions with the Cursor object. I currently pass around an object reference, but I think I'm going to need to stop doing that and only pass around the Vector2 position. It's currently possible that an update from the rendering engine will cause the cursor to start being displayed. If the Larn engine then attempts to move the cursor, the two could stomp over each other. I haven't seen it happen yet, but it could.
Almost into the game. Create.c is converted, now I've got 3 functions left to finish the dependencies for before I'm in the game.
makeplayer
newcavelevel
checkmail
I think I've spent at least 20% of my time doing explicit casts. One core difference between C# and C is that C# considers casting to a smaller size to be a compile error that requires a specific cast (which is fair).
Aw, code, it grows up so fast!
main() calls welcome();
welcome() calls openhelp();
If welcome() can't open the helpfile (I haven't copied the data files over yet), it calls drawscreen()
drawscreen() calls bot_linex()
bot_linex() calls lprintf(" Exp: %-9d %s\n",(long)c[EXPERIENCE],classname[c[LEVEL]-1]);
since c[LEVEL] = 0, that attempts to access classname[-1], which is invalid.
the bug is that drawscreen() shouldn't be calling bot_linex() at this point. There is a special flag (d_flag) that would have prevented it, but it isn't getting set in this corner case. It's possible that the variables used to detect if d_flag should be true are getting set are improperly getting set. I just added an extra flag to drawscreen in this case.
