Qbasicnews.com

Full Version: MULTIKEY Sound interference
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I'm using this MULTIKEY program and it's causing problems with
the SOUND and PLAY statements in my game.

This MULTIKEY program makes a noise on the PC speaker (something like what a PLAY"T255p64" would sound like)

It makes this sound after every PLAY or SOUND statement I have after I press another key or even the same one held down.

Any idea what ? Can this be fixed for me?

Here is the MULTIKEY program I am using:
Code:
'===========================================================================
' Subject: NEW ASSEMBLY MULTIKEY FUNCTION    Date: 12-20-97 (10:33)
'  Author: Joe Huber, Jr.                    Code: QB, QBasic, PDS
'  Origin: Milo Sedlacek                   Packet: KEYBOARD.ABC
'===========================================================================
DECLARE SUB KEYTEST ()
DECLARE FUNCTION MULTIKEY (T)

'New and Improved MULTIKEY function!!
'This version eliminates the key lock-up problem from
'previous verions.  And is MUCH, MUCH faster!!

'ASM Interrupt & support code by Milo Sedlacek
Hmm...

Milo's keyhandler uses some ASM to track multiple keypresses... I assume Blitz and v1c's ugl library uses a similar system, because in the documentation it says that SOUND and PLAY will be messed up if you try to use ugl's timer at the same time (I know you're not using UGL, this is just to give an example):

[syntax]======================================================
3.5.1 - tmrInit
======================================================

Prototype:
declare sub tmrInit ()

Arguments:
none

Returns:
Nothing

Description:
Sets up the timer ISR, has to be called before
trying to use a UGL timer. Do _not_ use QB's PLAY
routine or the PIT will be reprogrammed and the ISR
won't stay in control of this module.

Example:
timer.bas[/syntax]

I don't know much about assembly, but I do know that it can sometimes interfere with the PLAY and SOUND statements (don't ask me how). I just make a habit of not using them.

--j_k
Just guessing but it is possible that multikey reprograms some timer
in the computer while running, it is possible that PLAY etc. depends
on that timer.
Well is there another MULTIKEY program I can use that is as good as this one that doesn't intefere with SOUND statments or PLAY statements?

I used the older version of this MULTIKEY program before and the keys always got stuck on if you pressed two keys simutanusly really fast. That's why I switched to this better one listed above.

ASM is fine as long as I can use MULTIKEY presses and it doesn't get keys stuck and doesn't intefere with SOUND or PLAY statements.

Can anybody give me some good options?

I appreciate all the help I've gotten from this site so far.
I dunno, Multikey is the best out there. I'd suggest you to drop all PLAY and SOUND calls in your program as they are annoying as hell Tongue But to actually answer your question I'd suggest you to look for "Z Keyboard handler" lib, the one which was included with Future.Lib. It should be available for download in one of those thousands of QB sites. A lil' google search could help.

The site was http://www.gza-wu.freeserve.co.uk but alas, it's down Sad
I was thinking of dropping the SOUND and PLAY sound effects and trying something like .WAV or some sound effects for a Sound Card.

I Read a few posts on this forum regarding these sort of things and it seems that programming that kind of stuff is, rather, not very easy.

Of course, I read that using a ASM or some program that makes it easy would help though.

Would this be the other route I would take in place of SOUND and PLAY statements?
You can use DMAPLAY to play WAV files in the background. A fast google search would do. If you can't find it and you can wait until tuesday, I'll post it.