Jump to content

Darkfall

Platinum Member
  • Content Count

    138
  • Joined

  • Last visited

Community Reputation

0 Neutral

2 Followers

About Darkfall

  • Rank
    Full Member
  • Birthday 01/15/1971
  1. Wow. This thread has been dead for 2 months. Are we still happening here? Is there a build thread somewhere that I didn't see?
  2. I bet that's gonna look awesome. It's too bad PinMAME doesn't try to emulate the glow. I'm sure it could be done, with a little fiddling.
  3. Well - kind of. The limiting factor should be the LEDWiz's ability to process commands fast enough, and when it can't, the PC is forced to stop and wait for it to be ready for the next command - which causes the calling program (VP in this case) to wait, too - thus the stutter. A fast PC shouldn't really help, in that case. Perhaps the problem is lessened just enough to help the stutter, but it shouldn't have a massive impact in theory. I wonder if if it's a VB code that causes the slow down? Maybe it's a combination of things. Some testing is probably in order to really find anything out for sure. At this point, it's all a bunch of guessing.
  4. $100 USD Paypal'd. Awesome idea, man!
  5. This may just be crazy talk, but if the LEDWiz OCX is using synchronous communication, as Mr. Silver mentions (and I believe it probably is - it's not really designed for heavy load, so the concept of it using a buffer probably never entered RandyT's mind when he was rolling the OCX code in VisualBasic), wouldn't it be possible to write a new OCX that buffers incoming commands and sends them to the LEDWiz on a separate thread, thus isolating us from the synchronous communication? Sure, if enough commands come down the pipe from VisualPinball, the buffer will fill up and commands to the LEDWiz will get behind, but the delay to get the commands through wouldn't be excessive in most cases (in fact, I bet you'd be hard pressed to even notice it), but the important thing is that a command given to the OCX would return immediately, rather than waiting for the LEDWiz to accept the command, so VisualPinball isn't delayed - and this would only happen under heavy load. Under normal circumstances, the LEDWiz would be keeping up and commands would shoot through as fast as always. It sounds to me like the stuttering problem is more of software issue than a hardware issue. Judging by the little LEDWiz utilities you can download from GroovyGameGear, it wouldn't surprise me to discover that the OCX does the absolute bare minimum to get commands processed (the little utilities are really clunky and slow), which means it's using blocking code that waits for the LEDWiz to acknowledge the command before continuing - which is fine, if we have a separate thread accepting and buffering incoming commands to be sent when the LEDWiz is ready for them. There are LEDWiz DLLs out there that can be used to roll such a multithreaded OCX. Sadly, I wasn't able to locate any source code for the DLL, so we'd have to actually use the DLL (as opposed to including the code directly in the OCX), but that's not entirely terrible. I even found some example code in various languages that show how to use the DLL I found. Maybe something worth thinking about?
  6. NO and NC don't matter much, since you're not actually using the contactor to switch anything - it's just there to make noise, so which way it switches doesn't make much difference, so long as it makes noise when it's energized (which it will). Since these are 24 volt, you'll need a 24 volt power supply on top of whatever other power supplies you need for your other devices, which is no big deal - but it's an extra expense. In terms of how much "thump" you'll get out of these models, it's hard to say. I'm sure you'll get something, but will they sound the same as the other ones? That's a very solid "maybe".
  7. Maybe drill a hole in the weight and use some wires to join it to the game pad's stick by wrapping it around it? That should be strong enough to hold almost anything, with thick enough wire, I'd think.
  8. Totally awesome, Blur! I've posted on the LEDWiz mod thread on VPForums on what to do. Once they get this going (which is super easy!), they won't have to install FPLaunch, then install the LEDWiz mod over it - just install FPLaunch and go. Thanks again, Blur!
  9. I fiddled around with the UHID-G, but found that, like most accelerometers, it's not sensitive enough to detect subtle nudges that I want it to. I was more impressed with the upside down gamepad with weight on one of the sticks. It seemed to be more sensitive, and the "feel" seemed more right to me. Tuning the gamepad setup is probably going to be entertaining as I work out the correct amount of weight, distance from the sticks pivot point, mounting, etc. For either solution, you do need the modified VP executable (except for the SideWinder, if you want to go that route).
  10. Could be - but even then, why would it work fine under HyperPin? What is HyperPin doing that is solving the problem, I wonder?
  11. Also weird. I have no issues with the LEDWiz and Windows 7 x64. A couple of speed issues with HyperPin, but everything else is working good for me. Everyone's setup is different, though, so there might be something I did without being aware of it that solved the problem for me.
  12. The first thing that comes to mind for me is power. Are the CREEs drawing a little more power than the LEDWiz can stand, and thus the LEDWiz is resetting, causing the PC to lose the LEDWiz for a moment, which would generate a delay for Windows as it tries to communicate with it? I know that before I put the diodes on my contactors, everytime they engaged, the LEDWiz would reset due to the back flow of power when the coil was de-energized. That caused everything to pause and stutter like crazy. Perhaps an excessive power draw on the LEDWiz would do the same kind of resetting? It might be worth checking the power draw of the lighting setup. It might just be under full load, or only the strobes (if they're not firing through a relay - and is that relay maybe causing a reset issue because it doesn't have a diode on it?), or something. Why things would change when launched from HyperPin is a total mystery, though. I have no explanation for that, other than maybe it's a fluke. Have you tried it more than once with the same table to ensure it wasn't just a lucky attempt via HyperPin vs VP alone? I can't think of any reason why HyperPin being in the mix should matter - unless you're using my little FPLaunch mod and it's resetting the LEDWiz ahead of time and that's making it happy somehow? Weird.
  13. It does sound like a fairly significant amount of work - but the results look really nice!
×
×
  • Create New...