Daphne Install & Dragons Lair Tutorial

ChristianG

@caver01 Moved the files over and Dragons Lair is working on the arcade. Now I am trying to figure out how to configure the sanwa joystick and a sword button. I am being told to use the dapinput file but man am i confused. How do I know what variables to use for me existing button or joystick? Any experience with this?

Thanks...

Clyde

@ChristianG This is explained in the dainput.ini:

# The third number is the joystick button code (or 0 for "none")
# Since 0 is reserved for special meaning, joystick button 0 is identified
# as 1 here.  Button 1 is identified as 2, and so on.
# 
# Find the button you want to map by running:
# jstest /dev/input/js0

So, use jstest with your joystick and add +1 to its button numbers. Put the result as the third value of a given line in the dainput.ini.

Example: jstest shows that the button you want to use for your sword (KEY_BUTTON1) is number 1. Add +1 and you'll get the number for Daphne:

KEY_BUTTON1 = 306 97 2

edit: This applies if your joystick is connected as a game controller, e.g. by using Bluetooth or a zero delay encoder like the common "DragonRise" encoders. If it is connected as a keyboard, e.g. by using an Ultimarc IPAC or IPAC2, you'll have to use the resp. keyboard codes. See your encoder's manual and Daphne's keycode list to get the correct codes and put them as one of the first two values in the resp. line in dainput.ini.

ChristianG

@Clyde Well i was reading a thread that talked about the fact that whatever you changed those numbers to it doesnt work. I have tried changing them to no avail. When you run jstest you get some crazy numbers like 3257 and -3257 for both the x and y axis on the sanwa joystick. Someone explained there is something innately wrong with Daphne and you need some code to fix it. Evidently a lot of people building arcades using arcade joysticks have this issue with getting the joystick to stop working backwards and upside down in Daphne.

My sanwa is connected via these boards. Are these considered dragon rise?

https://www.amazon.com/gp/product/B07CK1NJP8/ref=ppx_yo_dt_b_asin_title_o02__o00_s00?ie=UTF8&psc=1

caver01

@ChristianG sorry, I have an IPAC 4 and I use happ sticks and I ave never had to map anything in Daphne, probably because my player one stick sends arrow keypresses which is a default config for almost everthing.

Clyde

@ChristianG It's hard to say something to such vague information. Could you link to the thread you mentioned?

Did you try to setup your controller in Daphne yet? From your posts, it seems like you only read about other people's problems until now. Sorry, if I am mistaken.

The boards you bought seem to be the typical "DragonRise" encoders. jstest displays the name of the encoder:

$ jstest --event /dev/input/js0
Driver version is 2.1.0.
Joystick (DragonRise Inc.   Generic   USB  Joystick  ) has 7 axes (X, Y, Z, Rx, Rz, Hat0X, Hat0Y)

The axis values of 32767 and -32767 are normal. As far as I know, it's the way jstest shows digital joystick axes. Because it also supports analog sticks that have axis values from 32767 to -32767, a digital axis however will just show the maximum and minimum values for each axis.

@caver01 Although my DragonRise encoders do work fine in most emulators, getting the first one to map to /dev/event0 (as Daphne expects it to my knowledge) gets more and more difficult the more usb controllers I have (latest additions: two AimTrak lightguns and two SpinTrak spinners). Because of this, I'm beginning to fancy an IPAC just to simplify my Daphne setup. Luxury problems … 😛

caver01

@Clyde said in Daphne Install & Dragons Lair Tutorial:

I'm beginning to fancy an IPAC just to simplify my Daphne setup. Luxury problems … 😛

Mine is an older version that only acts like a keyboard. It has not been a probem, but it is harder to assist others since my experience does not include gamepad on this device.

Clyde

@caver01 In which way is your older IPAC different from the newer ones?

caver01

@Clyde it does not have he option to emulate a gamepad. It is keyboard only. It also has a ps2 style connector. Old school, but it does support an adapter cable to USB which is what I use.

caver01

I think it probably looks different than a modern IPAC 4 too with the huge DIP chips running down the middle. I think my model maybe does not support the most recent firmware features. That said, it has been extremely solid, reliable, and never fails to work as expected.

Clyde

@caver01 I'm primarly ogling the IPAC2, but I didn't look too deeply at the specs for all of them. Thanks for the info about yours.

Buying an IPAC only for Daphne may seem exxagerated, but since I picked up the Dragon's Lair 20th Anniversary Special Edition with Dragon's Lair I + II and Space Ace for only 4€ from a vendor on the Amazon marketplace who didn't seem know the value of this collection to the emulation scene, I could record it as a late supplementary payment. 😉 (I don't want to brag, I'm just still flummoxed about this lucky deal even after nearly a year.)

caver01

@Clyde Yeah, that’s a killer deal for sure. I would say that I have been very happy with the IPAC and although I might try using GPIO pins on a two player system, the IPAC has carried my interest in this stuff through multiple platforms. My first arcade was built on an Intel mini-ITX motherboard running WinXP. Worked great. The Pi has allowed me to simplify things—but the same IPAC has been through it all.

werpu

Hi since I patched a little bit in the daphne-pi input code recently for a custom joystick build, I think I can give a little bit of deeper explanation regarding the inputs.

First when I checked the code I had the feeling that the original Daphne dev did a full stop on the emulator for whatever reason and never finished the input code fully. That was probably around 8 years ago. Secondly, is it hard to add functionality to the input code. Apparently not, the code is well written and is based on what SDL can provide.

So what happens under the hood?

a) The really unfinished part is how the joystick numbers are handled, there was simply a hardcoded 0 for joystick registration with a todo. I lifted that restriction with my patch which today made it into the daphne-pi mainline code to allow to use a different joystick via command line. So the main gripe for many is fixed and hopefully will make it into retropie soon. (the parameter i patched in is -joynum
-joynum 0 or -joynum "0" means /dev/input/js0 -joynum 1 means /dev/input/js1)

See also https://github.com/Shmoopty/daphne-pi/pull/4

Why the original dev did not do this is beyond me, hence my conclusion of the full stop on the codebase.

b) The next part i saw was that you atm can only remap the buttons, that is already explained. So what about the sticks and pads, that is basically again hardcoded. Daphne fetches the left stick and pad and routes the directional commands from those inputs. So if a joystick can be registered it also will fetch the analog and digital pads and sticks on the left hand side automatically. However all this comes from SDL, if SDL knows how to handle the pads and analog sticks then you should be set, if not you are out of luck or have to remap the stick to something else (see below the moltengamepad part)

So what about multiboard configs like I have, well you have to nail a virtual joystick underneath and use moltengamepad to combine all of that into a virtual gamepad, which is a configuration adventure on its own.

I hope that explains a little bit.

Clyde

@werpu said in Daphne Install & Dragons Lair Tutorial:

a) The really unfinished part is how the joystick numbers are handled, there was simply a hardcoded 0 for joystick registration with a todo. I lifted that restriction with my patch which today made it into the daphne-pi mainline code to allow to use a different joystick via command line. So the main gripe for many is fixed and hopefully will make it into retropie soon.

That's really great, thank you!

(the parameter i patched in is -joynum
-joynum 0 or -joynum "0" means /dev/input/js0 -joynum 1 means /dev/input/js1)

I thought that Daphne uses /dev/input/event0, did you change that to js?

Why the original dev did not do this is beyond me, hence my conclusion of the full stop on the codebase.

Yeah, but although I don't know much about coding, I think that making the joystick/event number a variable that can be set by a command line option instead of a hard-coded 0 shouldn't have been that difficult before leaving the code to rot.

Don't misunderstand me, I hold Daphne's developer in extremely high regard for all of his work. But this single moment of negligence is such a show-stopper for so many people …

werpu

@Clyde Could be event 0, the code itself uses just the SDL slot, so whatever SDL picks up as slot X will be picked up. There are multiple event emitting files for a single joystick (JS and evt, the code states it uses js), but thankfully SDL isolates that so that you dont have to deal with this yourself.

I did not change the general registration logic itself, the heavy lifting towards the inputs is done via sdl. All I have done is to remove the hardcoded zero to something which can be customized via a command line option, a really harmless and small fix for an annoyance which is 8 years old.

As for the original developer, I could not pull off what he did, not my area of expertise, its just that there must have been some serious personal reasons not to finish the last 0.005% of the work when he already went as far as he did.
Nevertheless, this annoyance now to some degree is fixed (I´d rather prefer to have some kind of device pattern filter instead of a number, but atm I lack time to implement such a thing)
I just fixed the number scheme for my personal needs.