It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
One thing that I have been thinking about lately:

What framerate do the first two Might and Magic games run at? For that matter, does this question even make sense? (Do these games run at a framerate, or do they just not update the screen until input is received?)

(I could also ask this question about the early Wizardry games (1-5).)
M&M1 and the early Wiz titles update when the game receives input. There might be an absolute upper limit to how often it can update the screen, but I don't think it really matters realistically. Though it's worth noting that the Apple II versions of Wiz 1&2 had very slow screen update algorithms, and took so long that you could actually lower the ingame draw distance to speed it up.

M&M2 has some animations at a varying but still pretty low frame rate. I'd guess that the upper range of frame rate is 15fps. The blacksmith seems to be hammering at around that rate, though most monsters move a lot slower than that. No idea if the input polling rate is faster than that or not.
avatar
ikantspelwurdz: M&M1 and the early Wiz titles update when the game receives input. There might be an absolute upper limit to how often it can update the screen, but I don't think it really matters realistically. Though it's worth noting that the Apple II versions of Wiz 1&2 had very slow screen update algorithms, and took so long that you could actually lower the ingame draw distance to speed it up.

M&M2 has some animations at a varying but still pretty low frame rate. I'd guess that the upper range of frame rate is 15fps. The blacksmith seems to be hammering at around that rate, though most monsters move a lot slower than that. No idea if the input polling rate is faster than that or not.
It occurs to me that one could use a TAS-capable emulator to check this out. Play the game one frame at a time, and check which frames the game takes input on. If the game doesn't override the standard keyboard interrupt (does it?) one could even check the keyboard buffer to see when key presses are removed from it.

Speaking of Tool Assisted Speedruns, the absolute upper limit on screen updates could actually come into play, especially if it's lower than the limit on how fast the game can accept keyboard input. Basically, in a TAS input will need to be entered on the earliest possible frame unless some RNG manipulation is being done (and knowing these games, RNG manipulation will be important).
Wasn't there some kind of real-time based puzzle at the end of MM1? If so, what framerate it was balanced for (and what amount of cycles in DOSBox)?
avatar
Sarisio: (and what amount of cycles in DOSBox)?
This would depend on your machine.
avatar
Sarisio: Wasn't there some kind of real-time based puzzle at the end of MM1? If so, what framerate it was balanced for (and what amount of cycles in DOSBox)?
I think it's at the end of MM2, actually. And I'm not sure it's a framerate-dependent thing, I think there's just a timer and you have to enter your response before it ends. Not sure if cycles affect the speed of the timer or not.
avatar
Sarisio: Wasn't there some kind of real-time based puzzle at the end of MM1? If so, what framerate it was balanced for (and what amount of cycles in DOSBox)?
avatar
Waltorious: I think it's at the end of MM2, actually. And I'm not sure it's a framerate-dependent thing, I think there's just a timer and you have to enter your response before it ends. Not sure if cycles affect the speed of the timer or not.
There was one at the end of MM1. Rotating door or something. For which you really had to lower DOSBox cycles.
I don't remember any rotating door in MM1.

I did an experiment on framerate. I used the Apple II version, since emulation is probably more precise than DOSBox, and the CPU cycles are fixed and won't throw the timing off. Using screen capture software, I found that when you hold an arrow key down in the map, the screen updates 5-6 times per second. In combat, with Ctrl+A held down, the screen updates exactly 10 times per second.

This isn't a perfect test. It could still be affected by emulation errors, or by screen capture inaccuracy, and it could just be that this is measuring the keyboard autorepeat speed. But I think the fact that the 3D view updates at an inconsistent speed suggests that it really does take the game that long to render it.

The DOS version is faster, depending on your CPU cycles. At 2000 cycles, the 3D view updates slightly more than 30 frames per second.
avatar
ZFR: There was one at the end of MM1. Rotating door or something. For which you really had to lower DOSBox cycles.
I don't remember this either. I remember some locations (maybe just one?) that had "spinners", which would spin the party around and the player had to try to exit them at the right time in order to get where they wanted to go. Those ran really fast unless I lowered cycles. But they were just in some dungeons, they weren't specific to the end of the game.

But maybe I'm not remembering the end of MM1 correctly?
avatar
ZFR: There was one at the end of MM1. Rotating door or something. For which you really had to lower DOSBox cycles.
avatar
Waltorious: I don't remember this either. I remember some locations (maybe just one?) that had "spinners", which would spin the party around and the player had to try to exit them at the right time in order to get where they wanted to go. Those ran really fast unless I lowered cycles. But they were just in some dungeons, they weren't specific to the end of the game.

But maybe I'm not remembering the end of MM1 correctly?
No. Those are the ones I meant. I just visited them towards the end of the game.
avatar
ZFR: No. Those are the ones I meant. I just visited them towards the end of the game.
Got it!

Actually, I wonder if the spinners are good places to test the screen update rate. There's no issue with keyboard input lag in that case, since the screen keeps updating constantly without any player input.

Of course, it might not work because the spin rate is not necessarily the same as the screen update rate; it could have been programmed to spin at a certain speed which is lower than the maximum screen update rate.
Post edited September 05, 2017 by Waltorious