Greetings! This freeware Monchr.exe game seems stuck and the "@" does not move or gets stuck in any directions. Also the dots in the screen do not appear properly in subsequent tries. I tried running at 3000 cycles and also 200 cycles , not much of difference.Any help please.....
Be sure to turn on NumLock and use the keypad for moving. The game's default delay is for a relatively fast system, no doubt because it was released in 2000. Increase cycles or use the game's /D parameter to reduces its delay to something that works better with lower cycles. For example: /D20 seems to work fairly well with 3000 cycles.
As for the appearance of the "dots", it seems the character used for them is random: sometimes a dot, sometimes a block.
That was incredibly fast! The suggestion you gave was making it run fast for me. I tried @ 400 cycles and /d4. The speed is now OK. But the keystroke buffer is spoiling the game. For each keypress or the duration , the next key would not work till it is through. Any help? Thanks anyway..
I'm not sure from what you wrote; is the keystroke buffer really the problem, or the keystroke repeat delay? If it's the repeat delay, you can use the utility program here to minimize the delay: How to increase keyboard response time in Dosbox?
For example, you'd run the utility program by typing "TURBOKEY A1" to have the fastest repeat rate and lowest repeat delay.
Yeah tried that from A1 to D4. Seems to lock the keys and nothing moves.Hope I had done that correctly. What I was saying was that a single key press keeps the @ moving continously . While it is traversing up , if I make 2 up key presses , it will go to the end and would not return if I press down for a few seconds as if to exhaust the info in the buffer..
The keyboard buffer backs up when you have too much delay for the amount of cycles. For more authentic timing, how the game ran on machines in 2000, you should be increasing cycles, like 10000 to 15000 or even higher, and chose a delay value that works well for that.
The instantaneous keystroke recognition seems to work only when the game runs very fast , with a low setting of delay. As I find , even at higher cycles say at 15000 or 20000 if the game delay is increased to make it playable , the buffer issue catches up.
Meanwhile googling I found this article at MS http://support.microsoft.com/kb/60140 .
There's no "issue" here that I see, the game is working as designed, even if you don't like the design. When you use the delay to slow down the enemies to a speed that you consider "playable", you also reduce the response to your keystrokes because the game is not processing them while in its delay loop, so they pile up in the buffer. The delay affects both you and the enemies; that's just how this very simplistic game works.
Okay , I will be careful to not to repeat the keys.
But I was wondering this sort of a situation could come up for other games as well. If on low cycles if the delay is say 200ms , it means that during those times any keys pressed would add only to the buffer and not effective. Can there be a fix by which keystrokes are registered only as per the delay settings so that the unnecessary ones are taken care of.
In the present game , once a direction is choosen subsequent presses in the same direction does not work at all except to contribute the buffer. Can something like ..if a key is pressed , the next time only some other key would be registered.... be implemented?
Just curious...
Well, you can try using "TURBOKEY Z4" to slow down key repeating to a crawl...
The game could have been programmed to process keys as soon as they are pressed, yet still have the enemy movement on a selectable delay; but that's not how it is, key processing is also delayed.
If you run the game with a /? parameter, you will find the author's name, email address, and mailing address. There's a request for a donation, so maybe if you're generous you can get the BASIC source code and change it to be the way you want it, or maybe after a dozen years the author will just give you the source simply for caring enough to ask.
wrote:Well, you can try using "TURBOKEY Z4" to slow down key repeating to a crawl...
The game could have been programmed to process keys as soon as they are pressed, yet still have the enemy movement on a selectable delay; but that's not how it is, key processing is also delayed.
Might be as I said earlier , would have to contend with it. But since DOS Box is an interface thru which the game is played , I was wondering if there could be a fix at all (forget about its being worth to do , whether there exists a remote possibility..). Turbokey delay the keys and I was talking about denying them.
wrote:If you run the game with a /? parameter, you will find the author's name, email address, and mailing address. There's a request for a donation, so maybe if you're generous you can get the BASIC source code and change it to be the way you want it, or maybe after a dozen years the author will just give you the source simply for caring enough to ask.
Appreciate the humor. I am enjoying my time here... 😁
