As best as I can understand, the reason OpenWatcom does not work is because of the precompiled libraries (BUILD, HMI, Smacker, etc.) that are needed to build the EXEs, something was changed across versions that breaks libraries compiled with the older versions of Watcom. It's a known problem.

The SMK playback fix seems to work well. The one SMK that it isn't needed for is the descending stairs clip that plays between levels, it was never a problem presumably because it has no audio (Corvin earlier found that turning audio off was a potential workaround for the problem with the other ones.)

As for whether there are still bugs with EGwhaven, more than I'd like. Tinkering with this again I can see that some things I thought were fixed with regards to the clock problems are only reduced by the changes I made, not actually fixed (jump height still clearly varies if I set different cycles speeds on DOSBox). So I will have to dig a lot deeper into what's actually going on with those issues since it's not the simple omission I initially thought.

If I happen to get some free time, I might look into potential jump fixes, too. I'm not very familiar with the games, so it would be hard for me to compare to the pre-DOSBox look-and-feel of things and really know the ins-and-outs of the game itself though.

More updates coming soon, but for now I want to say that I've tracked down the exact reason why some of the random checks flake out while others work. For instance, considering the check for poison traps in a chest, which is a fairly simple one:

The error is due to a misunderstanding of the quirky way in which C orders with the operators in question. == (equality check) is evaluated before & (bitwise AND), so while the programmers were thinking that the game was first going to do the "krand()&2" part (giving a 0 or 2 based on the krand return), then check if it's zero, what actually happens is:1. Do "2 == 0". 2 does not equal 0, therefore the result is "false", which is represented as zero.2. Do "krand() & 0". The zero comes from the "2 == 0" check before. Anything put through a bitwise AND operation with 0 is 0, so the result is always zero (false).3. Therefore the result of the whole check is always false/zero, and the code inside the if block never executes. You will never find a poison trap on a chest in the vanilla game.So the issue has nothing to do with the krand() function itself, or even the practice of limiting its returns with bitwise AND (which is how Ken Silverman himself demonstrated the use of it), only the fact that it's being misused due to an incomplete understanding of the finer ins-and-outs of the C language.

Next version will have cleaner/more correct fixes for these instances.

With regards to testing for clock speed related issues: you can do this on DOSBox by messing with the cycles setting. If you do "cycles = 30000", "cycles = 100000" and "cycles = max" and run the game each time, and see that jump height is demonstrably different each time (or even glitches out, usually in the case of max cycles) then you can tell if the problem is still there or not. Likewise for the other issues of that type. The thing that would require an old machine would be trying to replicate exactly how the game behaved on the devs' machines to know what they intended.

I haven't yet looked into the jump stuff. Do you know what frame rate the game *expects* to run at?

What I think most games do in order to be able to run at different render speeds is create an internal clock that handles the game logic while the main loop still renders frames as fast as it can. The main loop checks the internal logic clock to see if a tick has passed and if so, the game logic is performed before rendering. This ensures a constant rate.

This is what I had plan to look into when I have the chance. I also develop my own games, so I have a bit of time balancing to do.

The BUILD engine, AFAIK, runs with a timer that has 120 ticks per second.

The insidious thing about the clock timing issues in Witchaven (possibly TekWar too, I haven't got my copy of that running correctly yet) is that most of the game uses the engine timing correctly. There are just a few functions, like the vertical movement of the player, and vertical movement of projectiles, that work in some renegade way that's CPU-sensitive, which causes them to manifest noticeable bugs when run on a system that's considerably faster than what the game was developed on. So it's not quite like your typical case from the 80s where a game might be programmed specifically around the speed of an early IBM PC model with no foresight to that otherwise backwards-compatible machines with faster CPUs would come out; it's more of an accidental thing that only became apparent once systems got significantly faster.

Les Bird's page says "From what I remember, the compiler we used to build the games was Watcom C/C++ V9.5 and the target machine was a 486 50+mhz running MS-DOS V5 or higher." The system I've got for old game purposes has a K6-2 at 333mhz; slow by today's standards but still considerably faster than a 486.

EDIT: Might be better to read the next post first. I think it solves the sync/timing problems best.

I have been looking at the jump / synctics issue some and I think the best way to manage things is to force every synctic to be handled individually. (I've been doing this from the context of WH1, not WH2, but it should be the same.)

If calculations are done based on an entire range of synctics, then it's very possible that moving from point A to point B instead of taking all the steps in between can really throw things off. The game clock does hope for 120 tics per second, but I doubt that the game does that on the original systems. Even in DOSBox I only get above 120 when running at 320x200 with cycles > ~50%.

I tried moving the synctic calculation out of processinput() and into playloop() and processing each synctic individually and I started to get a consistent jump height. I did have to alter the JUMPVEL and GRAVITYCONSTANT because the player would jump extremely high otherwise. The reason is that GRAVITYCONST was being applied once no matter whether or how many synctics actually occurred. This erratic behavior made things look good when the game runs at around 40 FPS, but at 120, the player makes quick, short jumps. I think the game seems to run well at around 40 FPS. I might be wrong though. It "feels" pretty good at around that speed, but I'm not familiar with how the game runs on a system from that time.

I know that you likely know all or some of this, but I'm making posts sort of like making notes of my own journey into the code. Perhaps some will help, I don't know.

drawscreen(plr); if (synctics > 0) { // Handle each synctic individually so that all calculations are done the same no matter at what speed the game is running. long realsynctics = synctics; int s; synctics = 1; for (s = 0; s < realsynctics; s++) { // TODO Lava floor is done in here, but it does damage too quickly! It needs to be toned down. // GRAVITYCONSTANT and JUMPVEL were adjusted in LES.H. processinput(plr);

I had to make some changes to the MAK file to be sure that whobj and whinp are re-compiled when LES.H is changed.

It might be worth looking into adding a synctic accumulator into playloop and only process input only when 3 synctics have occurred to keep the game logic clock at 40 FPS. This might also help with other non-synctics based things, such as lava damage. 120 is just too fast for it's game logic clock in my opinion.

Last edited by adambiser on Sun Oct 02, 2016 10:33 pm, edited 1 time in total.

EDIT 2:I happened to notice that at 40 FPS the footstep sounds weren't playing when walking across the wood bridge at the beginning of level 1. When I drop the FPS to 24 using synctics of 5 instead of 3, they start playing again, so perhaps the game is meant for around 24 FPS..?

Hi Adam,I've been trying the speed fix you recommended and it seems to work pretty well with a fast DOSBox. On a slow DOSBox or on my native machine though, it gets flaky, particularly in that weapons can be swung much faster than they should be sometimes.