Some good ones there. Thanks.
1) Careful, it uses unsigned chars by default, on x86 it is more common to use signed chars, but there's a compiler-switch for that. So if you use code that worked with MSC or BC++ or such, and it doesn't work in OpenWatcom, see if it's your chars.
I rarely if ever have use for sign on a byte width element, and the defaulting to signed never made a lick of sense to me and was one of the things that pissed me off about C and made me favor pascal; the distinction between byte, shortint, and char. If yer gonna call it char, it should be unsigned... of course Joe forbid anyone use the word "byte" in C. You'd almost think they were worried about still supporting 6 bit systems or something.
This of course is the same thing that led to the C99 standard types that remove all the ambiguity, which I usually include define for in compilers that don't support them.
I'll take uInt8_t, int8_t, int16_t, int32_t, etc, etc, over the original C standard types any day. Particularly with the asshattery that you never know what the *** the compiler is going to give you when you say just plain "int". I HATE ambiguity in programming languages.
That was one of those long overdue changes.
But that's like float and double. Makes me feel like ordering a soda at a fast food place where the ONLY sizes are medium, large, and extra-large... or worse walking into some hipster joint like Starbucks and dealing with their artsy-fartsy names and ending up storming out like a second rate Dennis Leary just because you asked for coffee flavored coffee...
"Whatever the hell that is"
Which is starting to happen to me IRL -- went into a Dunkins a few months ago and asked for a dozen... lip pierced nose pierced twig tattoo on her face that made her look like she needed a shave skank reeking of either patchouli or the worst BO ever
(there's a difference?) behind the counter says "A dozen what?"
... and get off my damned lawn! 
2) I've had some inconsistent results when using floating point. Couldn't quite put my finger on it, but sometimes it seems the floating point precision/rounding is very bad. I think there are some bugs in its x87-backend. I had some routines that initialized things like sin-tables, sqrt, 1/x-related stuff... And my code broke in OpenWatcom, while it worked in BC++ and MSC. I ended up just precalcing the tables on another system, and including them in the binaries, as a workaround.
I'm assuming this is emulated since there would be no reason for there to be a difference with hardware, unless the actual routines use a different approach. Usually I EXPECT certain routines -- trigonometric functions in particular -- to NOT be compatible across different browsers just due to implementation differences.
Thankfully in Paku Paku -- or really any game I would be writing -- the only need I have for that is distance checking, and I'm using a lookup table for that since the range is a divide by 3 8x8 cell. (well, I made it 8x8 to simplify the math, the actual max distance is 7). To speed that up I do a box check first of course before diving for the table.
Blaine (aka Clyde from the real game - last ghost out of the pen) has a funky logic where if he gets 7 tiles (a tile is 8x8 in the real pac man, 3x3 in mine) away while in "chase" mode, he switches back to "return to corner" behavior until he's farther away than that, at which point he will switch back to chase. This makes it hard to get him close enough to catch after eating a power pellet unless it's the one in his corner. (bottom left)
3) There is a bug in the FPU detection routine which locks up an 8088 or 8086 system when no FPU is installed. I have patched the libc to fix this issue (doesn't impact machines with FPU or 186 and higher, so you can use these libs for any 16-bit target)
Is this an issue if you have ZERO plans to use any floating point code and are not declaring any variables that would use it, or is the compiler too stupid to recognize that and sets up for it anyways?
I'll have to test that one.
