Every console in 1 light gun project.. anyone try this?

[marioxb]

I was thinking about making a light gun that would work on PC, PS1, 2, 3, Saturn, Dreamcast and Wii. I know theymake dual compatible PS1/ Saturn guns, but what about the other systems? I plan putting the guts of an Aimtrak (PS3/PC), one of those PS1/Saturn guns, a DC gun (Japanese?), Saturn stunner and a Wii Remote and PS Move all in one shell. Would that work?

[Slippyblade]

Part of the problem you would run into is that those guns use different tech.  If you plan on using original hardware then some of those consoles used CRT blanking and others used LED triangulation.  Not compatible at all.

If you can make it work, awesome!  But I don't see how it's possible.

[Howard_Casto]

It's not possible. 

PC:   Requires svga refresh rates, standard lightgun tech.
Dreamcast/Saturn:  Requires NTSC/PAL refresh rates, standard lightgun tech.
Ps1/2:  see above, but requires a connection to the playstation serial interface bus for the extra buttons.

All the above require a curved, CRT display and are therefore obsolete on a modern setup.


Wii:   IR camera is inside the wiimote using IR LED strip (sensor bar) on the tv for position calculation.  NOT A LIGHTGUN!!!
PS3:  IR camera is on the tv and a visible led is on the wand for tracking.  Wand uses proprietary Bluetooth interface.  NOT A LIGHTGUN!!!

These two work essentially backwards from each other and thus there is no way to use one gun for both consoles. 

Essentially you'd need to cram a pc lightgun, a playstation lightgun, a generic lightgun, a wiimote and a move wand all in one shell, which needless to say is impossible.  Even then you'd have to somehow get all these conflicting optics aligned in sucha  way to where they don't interfere with each other and yet all aim the same way regardless of which system you are playing. 

Better option:

Get a uber powerful pc, and use a single gun solution along with emulation.  That'll handle everything but the ps3. 

[marioxb]

I was thinking all of the guts would be in one shell, but I didn't know if they'd fit. I was planning on playing on a CRT. Well, the Aimtrak would work on PS3 and PC though, right? But that's probably just for Guncon 3. On PS3, I want to play House of the Dead 4 and all of the Time Crisis games. So maybe just an Aimtrak and move would fit in one shell? There would be a switch or something on the gun to turn on the correct "mode".

So, emulation, would all of those consoles be emulated as well as the real thing? What would the minimum specs need to be? I just want to be able to play ALL gun games on one cabinet and not have multiple guns per player. I know the pre-PS1 games are emulated well enough.

[Le Chuck]

I have this vision where the CP only has a joystick.  Depending on the game you select small iris doors in the CP open and the right number of arcade buttons for that game rise up and lock into place then return down once you exit the game.  The joystick would look like a simple bat top but would in fact mechanically switch between 2 way, 4 way, 8 way, analog, and rotary automatically based on game selection.  A spinner would also rise out of the CP when necessary, ditto a trackball - and what the hey, let's toss in another joy as well to maximize game selection because it'd be a shame to leave out Robotron. 

What you're describing is harder to make than the above.  I'm not saying it's impossible, and you might as well go for it, I'm just saying you've described a grail and grails are historically hard to acquire.  That's why they are grails. 

[ark_ader]

The LCD TopGun works on  my Xbox, PS2, and PC.  What doesn't gets shot on the CRT.  How many lightgun games do you play on the DC?  Xbox?  PS2?  Not many.  Friggin loads on the PC.

Nice idea Howard, but you would be better tasked on your multi console controller.

[yotsuya]

I have this vision where the CP only has a joystick.  Depending on the game you select small iris doors in the CP open and the right number of arcade buttons for that game rise up and lock into place then return down once you exit the game.  The joystick would look like a simple bat top but would in fact mechanically switch between 2 way, 4 way, 8 way, analog, and rotary automatically based on game selection.  A spinner would also rise out of the CP when necessary, ditto a trackball - and what the hey, let's toss in another joy as well to maximize game selection.

I love you, LeChuck, and I want to have your babies. 

[danny_galaga]

Whether it can be done or not, all in one shell is going to make for one big arsed gun! I say go for it, maybe a bazooka 

[Slippyblade]

Whether it can be done or not, all in one shell is going to make for one big arsed gun! I say go for it, maybe a bazooka 

How bout this gun?

[danny_galaga]

Whether it can be done or not, all in one shell is going to make for one big arsed gun! I say go for it, maybe a bazooka 

How bout this gun?

YES!

[Howard_Casto]

[stallone]   IYAM DA LAW! [/stallone]

[SavannahLion]

I don't really give a rats fezz about playing light guns on the older CRT consoles, much less having one gun for all of my systems (double decker couch anyone?). The only LG games I owned back when belonged on the ATARI XEGS and they sucked for reasons we won't get into. I never got into the LG games on the NES or any other later consoles never bothering to fire the LG games up so my knowledge is cursory at best. However, I would like to present this train of thought.....

PC:   Requires svga refresh rates, standard lightgun tech.
Dreamcast/Saturn:  Requires NTSC/PAL refresh rates, standard lightgun tech.
Ps1/2:  see above, but requires a connection to the playstation serial interface bus for the extra buttons.

All the above require a curved, CRT display and are therefore obsolete on a modern setup.

If we agree that the dominate LG tech involves marker tracking and a camera (whether this tracking is Marker&Screen/Camera&Gun or vice versa is not the issue) then wouldn't the virtualized CRT support be a short hop away?

This is what I mean. The XEGS LG (XG-1) worked by blanking the screen when the trigger is pulled. Then scan line is started with white (or some bright color) and goes down line by line until the LG sensor picks up the "bright" light. X and Y is latched by the POKEY which is then read by the software.

I assume the SEGA Master System also works on a similar principle since it is common to hack the SMS gun in lieu of the XG-1. I would bank all other old school CRT light gun games for the home console also works on very similar principles. I think the NES  (or was it the SNES?) just blanked the whole screen and "lit" up the targets.

With a little Trigonometry and some profile data for different, monitors, consoles, refresh rates, and games (such as to deal with the XEGS hardcoded crap), a person, in theory could create something in combination with a marker/camera gun to be compatible with the old LG CRT systems. Either by using a microcontroller to determine X/Y coordinates and "pulsing" the appropriate data line to simulate a scan line "hit" for the original hardware or via a software driver (don't most emulators already use the "mouse" when using light gun games??) to do the intensive calculations.

If it was a hardware "adapter", if you will, I wouldn't even consider an 8-bit controller like the AVR or PIC. I would bump it up to a good solid 32 bit controller with a nice high clock rate divisible by the target clock rate to get the good math functions and the larger memory maps for the profiles. As for a software driven layer for the emulators well  You know the exercise.

[SavannahLion]

I dug around a bit just to satisfy some details.

The SMS Light Phaser worked with the XG-1 for the Atari's because they're both modified light pens (the whole scanning line by line thing).

The NES Zapper was far simpler and is simply just a light detector. I assume the SNES Super Scope worked along the same thought pattern as the Zapper. I'm not sure, I didn't dig into the super generation.

That being said, the idea I presented above would not work on the Zapper or any other similar gun. It still can, in my opinion, be feasible for the guns by SEGA and ATARI.

[Howard_Casto]

Nope... It's pretty much impossible with current tech.... I looked into this ages ago, there are just problems to be blunt. 

Ok let's say you want to use a camera tracker on a crt screen to detect the scanline beam... well that won't work.  While a light sensor is incredibly fast and could register a hit in a fraction of a second, camera-based tracking requires a chip to analyze the picture it's looking at and detect points of interest.  It's laggy detecting what it's supposed to detect (a big old IR led), so it'd be impossibly slow reading the white as it goes across the electron gun. 

Now the other way around... simulating the electron beam and reading it with an old-school lightgun won't work either.  LCD's aren't bright enough and they don't give off the right frequencies of light.  Even modified with a special sensor it'd be difficult because again... speed...  Getting a piece of hardware/software that could accurately simulate that beam scan to work fast enough and timed reliably would be hard, maybe impossible. 

Now on real consoles, the lightgun interface is usually quite simple (with the exception of the playstation guns).  You've got two raw switches that are usually wired directly into the console for speed... the light sensor switch and the trigger switch.  All old guns, even the zapper use this... the software waits for a trigger switch to be pulled and then starts whiting the screen.  If the light sensor goes off in this cycle, it uses the refresh rate and the time elapsed to calculate the position. 

It's a simple as that, but that refresh rate is timing critical, as explained above, which is what makes it practically impossible. 

[SavannahLion]

Nope... It's pretty much impossible with current tech.... I looked into this ages ago, there are just problems to be blunt. 

Ok let's say you want to use a camera tracker on a crt screen to detect the scanline beam... well that won't work.  While a light sensor is incredibly fast and could register a hit in a fraction of a second, camera-based tracking requires a chip to analyze the picture it's looking at and detect points of interest.  It's laggy detecting what it's supposed to detect (a big old IR led), so it'd be impossibly slow reading the white as it goes across the electron gun. 

Now the other way around... simulating the electron beam and reading it with an old-school lightgun won't work either.  LCD's aren't bright enough and they don't give off the right frequencies of light.  Even modified with a special sensor it'd be difficult because again... speed...  Getting a piece of hardware/software that could accurately simulate that beam scan to work fast enough and timed reliably would be hard, maybe impossible.

You're mis-reading what I'm proposing. Nowhere am I talking about A: Using a camera to read a CRT screen nor B: using current tech screens and trying to get a CRT scanning gun to work with it. There is no CRT and no CRT gun involved... unless you hack one or the other apart but that's not what I'm talking about either.

What I am proposing is using a modern X/Y light gun with its established sensor/emitter pair with a bit of hardware to simulate the signal timing from the CRT based light gun. In essence, to "fire" off the appropriate signal when the old CRT light gun would have detected a hit.

At best, the adapter would strictly be a part of the assembly between (or hacked into the) gun and/or console. At worst, a pigtail on the video out would be required to capture the scanline timing. It would go without saying every case would have a calibration routine (ATARI can't go without one anyways).

Now on real consoles, the lightgun interface is usually quite simple (with the exception of the playstation guns).  You've got two raw switches that are usually wired directly into the console for speed... the light sensor switch and the trigger switch.  All old guns, even the zapper use this... the software waits for a trigger switch to be pulled and then starts whiting the screen.  If the light sensor goes off in this cycle, it uses the refresh rate and the time elapsed to calculate the position.

Yes, I believe I mentioned this? Oh, here it is.

This is what I mean. The XEGS LG (XG-1) worked by blanking the screen when the trigger is pulled. Then scan line is started with white (or some bright color) and goes down line by line until the LG sensor picks up the "bright" light. X and Y is latched by the POKEY which is then read by the software.

I assume the SEGA Master System also works on a similar principle since it is common to hack the SMS gun in lieu of the XG-1. I would bank all other old school CRT light gun games for the home console also works on very similar principles. I think the NES  (or was it the SNES?) just blanked the whole screen and "lit" up the targets.

I didn't bother going into detail about the specific hardware because, hey, I figured that it's pretty simple stuff

It's a simple as that, but that refresh rate is timing critical, as explained above, which is what makes it practically impossible.

See above.

I don't think it's impossible, just seems that way. Programmers and fans have been racing the beam for 37 years using nothing more than an 1.19MHz 8 bit CPU coupled to TIA. Racing the beam would become nearly trivial if moving to a 32-bit CPU/MCU running as low as 16MHz where there is far more than 50% CPU time available. Swap in a FPGA or a MCU/FPGA hybrid or a faster clock and what do we get? Something that might be workable. We don't need a 120+MHz CPU to stay ahead of a 63.5us scan line when all we're really interested in is vsync (in the case of the ATARI/SEGA).

To put it simply.
If we tap into Video out, we can get the scan timing. For the light pen, there isn't a need to know what is on the screen. Just when vsync occurs. All the rest is just timing it out within the controller. The NTSC signal timing is very well documented. Pick some reasonable multiple of the NTSC signal for your clock. The NES method is a little trickier with more required to interpret the video signal. However, we're not looking at the actual video the entire time, just the "firing" frames.

Think about it, I'm not proposing to create another TVP5160 or TVP5020 (though a dedicated decoder might make things a little easier ). Baby steps right? No one ever made an accessory that worked with every known console known to man in one go.  Not yet anyways.

The gun trigger is stupid simple and we will not discuss it here. If you can't handle a switch, just hush up.

The X/Y position of the receiver/emitter pair is where I think the real work will occur and what will separate the baby MCU from the real work horses. Receiving accurate X/Y positioning and doing the math required to accommodate the different variables present. Position of the emitters and receiver. Actual geometry of the monitor. Timing of the trigger pull and applying the necessary offsets when firing off the "hey! I sensed a light beam!" signal.

I'm not saying it is simple (except for that switch ). What I'm saying is that I think it's feasible.

[Howard_Casto]

Sorry man, you aren't making any sense.  Frist you say what I was talking about wasn't what you were talking about and then you talk about simulating a crt which is exactly what I was talking about. 

Think about what you are saying... if you are simulating the signal timing of a crt... for what purpose?  The beam of a crt and the lightgun itself are totally separate... as far as the lightgun cares any light will work just fine.  That's why I mentioned the switches that you foolishly dismissed..... the gun is just a light sensor and a switch and that's it.  It has nothing to do with the screen blanking. 

The trick is the ambient light a crt and only a crt is capable of giving off in terms of displays and the scaline drawing method, neither of which hdtv's can use or simulate because hdtv's draw things an entire scanline at a time. 

So you can't do it that way, and as I mentioned, due to timing issues, you can't do it the other way around either.....

Remember translation is the easy part, you've still got to have a gun capable of "seeing" a target on a lcd screen and/or sensors around the screen to get x and y position.  the only tech that works is cameras... and they are your slowest link in the chain which means all the other stuff is irrelevant.  I don't think you understand what I mean by timing.  When you pull the trigger on a traditional lightgun you typically have a single frame, maybe two or three to send that "I saw light" signal.  The signal is only valid while the trigger is pulled and the games/hardware have checks in place so you can't hold the trigger. 

Camera based guns just aren't that fast... they all have lag, so yeah you might technically get it to work, but the results would be so poor that you wouldn't care.  There is a reason that most wii/move lightgun games have a cursor on the screen.  It isn't because of that accuracy... they are pretty accurate, but rather the lag. 

[SavannahLion]

The first half of your post is nonsense Howard. It reads on the assumption that there is an actual CRT or CRT compatible gun in the mix. I already elaborated on that and clarified my point, re-read my post.

The second half is more interesting and more in tune. Have you crushed the numbers there then? If you haven't then I'll ask you to.

I believe the XEGS would accomplish the task in two frames (assumed) or 4/60th (rounded off of course) of a second. Which is about...37<T>73ms or therabouts? Without diving into the code or emulator it seems the NES is 1+i where i is the target count.  Here a minimum of 2 frames and a theoretical limit of whatever targets the NES hardware can track. But this system has the unfortunate requirement of analyzing the video stream after the "shot". This is my cursory understanding of the NES platform. I could be wrong.

I've seen varying accounts on the speed of the Wii camera (I have not bothered to try and track down a whitesheet) but 100Hz sampling seems to be a common citation though I've seen numbers as high as 200Hz. 100Hz might be more accurate. 12 byte positional packets and 400kHz on the i2c. Not sure what the overhead is on that, but it looks ballpark. So 100Hz has a period of what... 10ms? So on trigger pull and proper sampling would yield us about 27ms of wiggle room at worst or 73ms or more at best? Remember, no matter bow fast the ATARI/SEGA can read the sensor it won't latch the value until after the first blanking from trigger. In the ATARI, the Pokey happily does all the heavy lifting and presents XY cordinates at two memory locations after the CRT does its swep.

Moving along, I have not considered any buffering that might occur with the camera (hopefully not), the MCU or whatever controller is in place and the LCD screen if there's no game mode.

The trig is a bit trickier to calculate so I won't bother without looking at the different hardware.

How's my math so far?

update: did my initial calculations based on field timings but called it frames. Each frame of interlaced video consists of two fields. About 1/60th of a second