1. Bug in keyread.e?
- Posted by Robert Pilkington <pilking at BELLATLANTIC.NET>
Aug 06, 1999
-
Last edited Aug 07, 1999
Well, it's been a while since I posted here, but I still have the same
problem I've had since the last time I posted...
In Vector, after adding joystick support and a ingame menu to enable it, the
game crashes on the routine update_shots(), only if there are shots to
process. update_shots() doesn't call any machine code. This is a Causeway
crash, not caught by Euphoria.
Ok, first thing to try: Use safe.e. It worked. Kinda. Now it doesn't crash.
Obviously, it's because the memory is being moved around, since safe.e is
bigger than machine.e. (I tested with the updated machine.e and safe.e's,
too. Didn't help.)
Tracing? If I open the trace screen, then close it, there's no crash.
Now, the added include, joystk.e, only does BIOS calls. So the only machine
code I'm using at all is in keyread.e. It is the latest version of
keyread.e, as well.
Replacing keyread.e or joystk.e's routines with shell routines that do
nothing and functions that return defaults (like {} or 0) will get rid of
the problem. (Resetting the shots to none before update_shots() is called
also works.) If I got rid of the menu then everything is fine, too.
Disabling all calls to get_keys() and the joystick routines doesn't help. So
it must be the initial poking into memory when the include file is read in
and the top-level statements are executed. (Or a bug in ex.exe.) It still
crashes when the first shot is fired.
I'm wondering if it's related to the amount of memory the system has. It
runs fine on a Pentium II 233 with 128 megabytes of memory, but crashes on
the Pentium 120 with 48 megs that I use for development. It also crashes on
C. K. Lester's computer, but I don't know his configuration. (So far, it's
crashed on 66% of tested computers. A sure way to get the worst reviews
possible for your game. :)
Again, the problem seems to be only noticable with a relatively large
program. Smaller test programs don't seem to show the problem, which is why
it wasn't caught. Only a large program can cause it, apparantly. Maybe this
is why Lemon Headz crashes under certain modifications, from the same bug?
(Only Mark's game is a lot bigger than mine.)
I can't really do anything to solve this on my own, I can't read machine
code, so I can't check keyread.e.
I can think of 2 good solutions:
Someone checks out keyread.e for any problems.
Rob runs the debugging version of ex.exe to see where the problem is.
(Either running keyread.e alone or with the game, and assuming the debugging
version can catch program memory leaks instead of just ex.exe's problems.)
Development in Vector is (and has been) effectively halted until whatever
the problem is is fixed. (Hey, stop cheering!)
What would REALLY be nice is if somebody would actually complete a
relatively fast 3d engine comparable to X-Wing or TIE Fighter (the old DOS
versions). 
2. Re: Bug in keyread.e?
Robert Pilkington
The KEYREAD.E that I have has a note in it dated feb 4 1998.
A bug fix report That says to prevent crashs a clear_keys routine has
been added and should be called AFTER calling any input routines.
Maybe you have to call this after calling your joysticks because
they are input routines.
Bernie
3. Re: Bug in keyread.e?
>Robert Pilkington
> The KEYREAD.E that I have has a note in it dated feb 4 1998.
> A bug fix report That says to prevent crashs a clear_keys routine has
> been added and should be called AFTER calling any input routines.
> Maybe you have to call this after calling your joysticks because
> they are input routines.
I'm using keyread.e properly. The only place I have a clear_keys() statement
is after every get_key() statement. (get_key() is used for name input in
high scores, the menu system, and to get out of pause mode. They are all
outside of the main game loop.)
4. Re: Bug in keyread.e?
I wrote:
>In Vector, after adding joystick support and a ingame menu to enable it,
the
>game crashes on the routine update_shots(), only if there are shots to
>process. update_shots() doesn't call any machine code. This is a Causeway
>crash, not caught by Euphoria.
More info:
I started up in pure DOS mode. (F8 on Starting Windows 95... then hit
Shift+F5.)
I started Vector after adding Eu to the path and adding the EUDIR variable.
The first time a shot was fired, I got a Causeway crash filling several
screens of information too fast to read (repeating the same information, it
appears), then a complete system freeze. After rebooting, CW.ERR was 0
bytes. The message was:
CauseWay Error 09 : Unrecoverable internal exception, program terminated.
This happened three times (I wanted to get the message correct), and when I
went to Shut Down.. Restart in DOS mode, the computer rebooted after the
crash automatically (the crash probably conflicted with a driver that time).
Anyway, this shows that the crash was related to Euphoria, or MS-DOS 7, and
not any driver problems or conflicts with Windows 95. It's a problem either
in ex.exe or keyread.e (the only things using machine code in the game,
everything else is pure Euphoria (although joystk.e is doing BIOS calls,
it's not doing any machine code)). It's a bug that I cannot fix, and would
really like some help in getting rid of it so I can continue developing
Vector (and so I can rest assured I won't run into this problem again when
I'm programming something else that uses keyread.e).
5. Re: Bug in keyread.e?
Robert Pilkington writes:
> It's a problem either in ex.exe or keyread.e (the
> only things using machine code in the game,
> everything else is pure Euphoria (although joystk.e is doing
> BIOS calls, it's not doing any machine code)). It's a bug
> that I cannot fix, and would really like some help in getting
> rid of it so I can continue developing Vector
This doesn't sound like a bug that I could solve
in a short time. It's probably not a Euphoria bug. It probably
has something to do with hardware interrupt handling.
You might try to contact Michael Bolin. The last e-mail
address I have for him is:
bohemian13 at juno.com
You might also look in the Archive at:
Lewis Townsend, "Animated Car with Sound Effects"
http://www.fileseu.addr.com/CAR.ZIP
This is a program that uses Michael's latest keyread.e
and it runs ok on my system, although it doesn't seem to call
the new clear_keys() routine anywhere.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
