Interest in JVS libraries for Taito TypeX development?

[trap15]

Been working on interfacing with JVS for a project on Taito TypeX2, and I figured maybe some of the folks around here would be interested in using my work to get their projects onto REAL GENUINE ARCADE HARDWARE As it stands, it's only available to C/++ projects, and I don't really intend to make it work on anything else. Obviously Windows-only, as that's all you'll ever find on a TTX. If your game runs on a Windows XP box, it should run on a TypeX.

The API is currently somewhat bare and simple, but I think it's nice like that. Documentation which clarifies all the fields and their formats will be made soon enough.

Sample code
Output from jvs_io_dump

Let me know what y'all think.

[BPzeBanshee]

Sounds great!

[Stompp]

This is great! Thank you for the share

[emphatic]

Cool beans!

[n0rtygames]

Erm, it occurs to me that if you're making an API you want it to be usable by others. This is not to knock your code, far from it - rather suggesting that the majority of people will not be used to working at such a low level as yourself... So, I would contemplate writing some helper methods to expose stuff like this:

if(jvs_io->sw.data[j + (l >> 3)] & (0x80 >> (l & 7)))

This is gonna be pretty unreadable to most. What people will probably find useful is for you to store bools and make these accessible via nice simple helpers. For example (in delightful hungarian notation I might add):

Code: Select all

// Declare this at whatever size I dont care
bool[] mbPressed; 
bool[] mbWasPressed; 

// In some loop...
void SomeReallyLateUpdateLoop()
{
    // We want to call this at the end of an update loop to cache the state of all switches this frame
    for (int i=0; i<mbPressed.length();++i)
    {
        mbWasPressed[i] = mbPressed[i];          
    }
}

/*-----------------------------
 * On to helpers..
 -----------------------------*/

// return whether the switch is held down (useful for levers and fire buttons)
bool IsSwitchOn(int alX)
{
    return mbPressed[alX];
}

// return whether the switch was held down last frame
bool WasSwitchOn(int alX)
{  
    return mbWasPressed[alX];
}

// return true only if switch has been pressed this frame
bool IsSwitchPressed(int alX)
{  
    if (mbPressed[alX] && !mbWasPressed[alX]) return true;
    return false;
}

// return true only if switch has been released this frame
bool IsSwitchReleased(int alX)
{  
    if (mbWasPressed[alX] && !mbPressed[alX]) return true;
    return false;
}

I can already feel your reaction from all the way over here in foggy UK and I know it's not pretty... however, it's the feedback you need to hear.. not what you want to hear/see

If you plan for this to be used by others.. or at least dangle the carrot for people to delve deeper in to topics such as "how shit works" - your API shouldn't be too daunting. Your job as I see it, when creating an API is essentially to take this complex beast and wrap it up in a way where you can explain it to someone else like they're five. I don't mean any offence by this at all but I suspect most people making games here in gamemaker (given they're all shmups) have never even had a reason to do any sort of bitshifting or similar - so stuff like that just isn't gonna make sense..

But if there are nice helpers which you can follow the breadcrumb trail to - a few quick "Jump to declaration"s later and your end user is gonna at least be exposed to whats underneath and go "Ah, so that's where the input bool gets set... ohh.. this is how it works!"

[trap15]

I can already feel your reaction from all the way over here in foggy UK and I know it's not pretty... however, it's the feedback you need to hear.. not what you want to hear/see

Actually this is exactly what I wanted to see/hear I'll see what I can come up with, but at some level it'll still involve bitwise operations and knowledge of the controls attached. It should be less opaque with good documentation though. I'll post back in a few weeks or something when I have something cleaner for folks to poke at.

[BPzeBanshee]

I thought it was pretty clear you were going to polish the details later as said in OP anyway, but I understood most of it. Not completely retarded.

Speaking of Game Maker though, I've been thinking about how this would be done to allow GM games to make use of the API. The trick would be making a DLL which GM can use. Looking at this tutorial here I think it wouldn't be all that difficult to do, providing the documention is good enough for the average joe to figure out.

[Stompp]

What about hosting the project on GitHub? That way anyone how wants can contribute or fork

[n0rtygames]

I'll see what I can come up with, but at some level it'll still involve bitwise operations and knowledge of the controls attached.

I can't see any reason this should be the case...

Are Taito Type X games written for specific cabinet setups? By this I mean - if I'm looking to run Raiden IV, how is my cabinet wired up? Am I configuring what each button does with the software itself? Or is it a wire that goes from button to pin which dictates which switch that is? What is the issue requiring me to have intimate knowledge of hex codes in order to write for this? If I was writing for a console sure I'd still need to check this stuff to properly poll inputs from gamepads etc if I was writing input manager components but... its standardized hardware. I thougt the TypeX was standardized too? What's the deviation between setups that requires me to think so much? How is it all wired up?!!? I have no idea

Most of us aren't going to have the hardware - so you want it as simple as possible for us to just plug in and then throw at you for testing

e.g You want to poll ALL inputs found each frame. At the start of your main games loop, just include a call to a function that checks all states - then you just query it at an extremely high level.

I guess my little pseudo code snippet above was basically the first thing I'd be doing if you handed me that.

As for n0rty's jip on Game Maker

I wish you'd stop taking offence to every comment about Gamemaker! I didn't mean to imply that you were a moron, but we do have other GM users here who by their own admission are "not the best programmers" and probably don't have a clue what half of Traps voodoo does.

[BPzeBanshee]

I wish you'd stop taking offence to every comment about Gamemaker!

Every comment?! <insertsocialjusticewarriorslanghere>!1

My bad, wasn't intended to come across as "offended" at all, merely connecting the tangent. Edited for clarity.

[trap15]

What about hosting the project on GitHub? That way anyone how wants can contribute or fork

I've already got it on bitbucket, as a private repo. I don't want it public until there's a stable API and for all intents and purposes it's complete.

I can't see any reason this should be the case...

Are Taito Type X games written for specific cabinet setups? By this I mean - if I'm looking to run Raiden IV, how is my cabinet wired up? Am I configuring what each button does with the software itself? Or is it a wire that goes from button to pin which dictates which switch that is? What is the issue requiring me to have intimate knowledge of hex codes in order to write for this? If I was writing for a console sure I'd still need to check this stuff to properly poll inputs from gamepads etc if I was writing input manager components but... its standardized hardware. I thougt the TypeX was standardized too? What's the deviation between setups that requires me to think so much? How is it all wired up?!!? I have no idea

Taito TypeX games are not written for specific cabinets, they're written for a minimum button count usually. The game has no say in how the buttons are mapped or where they're located. JVS is extremely open-ended. You could have a mahjong panel, or a 4 player panel with 6 buttons each, or a 1 player panel with two sticks and 200 buttons, and it all is reported the same way through JVS.

Generally, you could be safe to have your game just throw an error if there aren't enough buttons attached, but that's about it. There's no way to tell what type of controls are attached, just how many switches; for a 1L6B panel for example, that'd be 2 (start+service) + 4 (lever) + 6, totaling 12, in which case jvs_io->sw.buttons will be 12.

The whole fancy deal with jvs_io->sw.data is that it contains all the button data. The first byte is always "special" stuff (usually just the TEST switch), and then it's sets of bytes for each player. So with 12 buttons, each player gets 2 bytes of data. It could be possible to make an interface like this fairly easy, which I might do:

Code: Select all

DWORD jvs_io_get_player(JVS_IO *info, UINT player);

And that could return all the player data, with the first byte at the top, 4th byte at the bottom. It would cover almost all use cases, and then I could maybe provide useful bitmasks like this:

Code: Select all

enum {
  JVS_SW_START = 0x80000000,
  JVS_SW_SERVICE = 0x40000000,
  JVS_SW_UP = 0x20000000,
  JVS_SW_DOWN = 0x10000000,
  JVS_SW_LEFT = 0x08000000,
  JVS_SW_RIGHT = 0x04000000,
  JVS_SW_BTN1 = 0x02000000,
  JVS_SW_BTN2 = 0x01000000,
  JVS_SW_BTN3 = 0x00800000,
  JVS_SW_BTN4 = 0x00400000,
  JVS_SW_BTN5 = 0x00200000,
  JVS_SW_BTN6 = 0x00100000,
  [...]
};

In which case doing stuff would be as easy as:

Code: Select all

DWORD btns = jvs_io_get_player(jvs_io, 0);
if(btns & JVS_SW_START)
  // start game
if(btns & JVS_SW_BTN1)
  // shoot bullet, idk
if(btns & JVS_SW_BTN2)
  // bonbaaaaa

[Cagar]

Code: Select all

DWORD btns = jvs_io_get_player(jvs_io, 0);
if(btns & JVS_SW_START)
  // start game
if(btns & JVS_SW_BTN1)
  // shoot bullet, idk
if(btns & JVS_SW_BTN2)
  // bonbaaaaa

wTf?? Didn't know that you were making a shmup!!!
Though i think it's kinda lame to just have shoot and bombing trap... we've had the same shit for the last 20 years.. time to invent something new!
also make sure that button 1 shoots a burst of bullets like in dodonpachi, instead of just 1 bullet. because that might make you run into autofire-problems! (currently your code shoots a single bullet)
(also bombing is called bomba not bonba)

[Stompp]

What about hosting the project on GitHub? That way anyone how wants can contribute or fork

I've already got it on bitbucket, as a private repo. I don't want it public until there's a stable API and for all intents and purposes it's complete.

[nasty_wolverine]

probably guessing there is custom window headers included. Any thoughts on whether SDL can be ported to it or not?

[trap15]

It's Windows XP embedded. Chances are, anything you write that works on WinXP will work on it. It doesn't come with any DLLs essentially, except for DX9. They also don't support nearly anything over USB or whatever, so the only other option is keyboard basically. If you want me to try something on the one I've got, pass it along.

[rtw]

Nice work trap15.

If you are going to make an API which is to be usable on a Celeron (TTX1) I would use macros (#defines) or inline functions.

I like the part where you use enums to provide bitmasks

Just watch out for enums since enumeration constants are of type int which makes it slightly hard to set bit 32

[arcade-stg]

This is great!

Keep up the good work!

[PC Engine Fan X!]

Will the JVS libraries for Type X work on the 1st-gen Taito Type X arcade hardware as well?

I understand that with a Taito Type X2 setup, it'll run the older Type X games also but with such a Type X setup, it will run only such Type X games at best (and not Type X2 games whatsoever).

I do have a 1st gen Type X setup being used with a Sega Ver. 2 I/O that runs on a Taito Egret II candy cab in 15kHz low-res mode. It's been further custom modded to run the Type X game roms directly from a CF memory card rather than the usual Type X HDD setup. The only issue is, that if you change a previously loaded game (from last boot-up) to a different game rom, the previous game's high scores and high score initials are lost for good. Surely, there's a "work around" solution to address that issue of saving such scores & high score initials for posterity, right?

PC Engine Fan X! ^_~

[arcade-stg]

That Type X2 looks like the one of alamone.

In my opinión an API is great for developers (which is very good), but maybe an application that enables windows to use the JVS as a regular keyboard/joystick would be better. Hopefully the API may enable the development of that application.