From: cas_at_strotmann.de
Date: 2002-12-19 16:52:49
Hi, > > On Tue, Dec 17, 2002 at 10:26:25PM +0100, Carsten Strotmann wrote: >> If it's ok for you I will put the code into the ATARI readjoy.s, >> selectable by a "define" (at this time). > > Personally, I don't like defines, because they make the code difficult > to read and to test. But Christian will have to decide this. Ok, I understand, defines are bad (TM). > > If the code is able to distinguish between a machine with and without > the multi joystick interface, my suggestion would be to do just this and > accept higher joystick numbers for the readjoy function. One problem we have to find a solution is that the multijoy needs initialization. before first use, the 2nd ATARI Joystick port must be switched into write mode (6 instructions, 15 Byte) the init could be done every time a joystick is read, but this is overhead for games. I'. thinking of an init_joy function. This function can return the number of joysticks attached, so it's also useful for normal joystick ports. The init routine could also be used to switch from normal joystick to multijoy or other input devices. The readjoy function would then read a global flag set by the init routine and branch to different code. Games can present a menu for all known Joystick Options available for the platforms and set the choosen one with the init_joy function accordingly. After init, the joystick api can be used transparent with any valid number of joysticks. If the init routine set/change a vector to the joystick code, the additional cost is one JMP instruction, which is ok even for games. Is the use of function vectors supported by cc65? (Sorry if this is a dump question, I'm not a 'C' wizard) Only accept higher joystick numbers would not work with every joystick hardware extension, because, for example, when using multijoy, the code for reading the 2nd to 4th joystick is differnt than reading from the build-in joystick device. > > Another transparent solution is to enocde the interface into the > joystick number. For example, the lower nibble could be the joystick > number while the high nibble could be the type of the joystick. This > way, we don't have to change the API, just add some additional defines > in the form > > #define JOY_STANDARD 0x00 > #define JOY_MULTI 0x10 > > Both solutions wouldn't need any defines in the sources, which is an > additional advantage:-) I fear that this would lead to different "high-nibble-flags" on different hardware plattforms, so a 8 joystick multiplayer game would not be (easily) portable from ATARI to, for example C64 Joystrick extensions. I will work on a proposal and sample source for the "init" solution, which for my view gives least speed-penalty and no evil defines. Regards Carsten ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2002-12-19 17:12:38 CET