That's How I Roll! (Skeeball build)

[Le Chuck]

Folks have used 5cm range digital distance sensor on other skee ball builds.  I know you probably don't want to switch lines of effort yet but if you get stuck these might be the way to go: http://www.pololu.com/product/1132

[thatpurplestuff]

Folks have used 5cm range digital distance sensor on other skee ball builds.  I know you probably don't want to switch lines of effort yet but if you get stuck these might be the way to go: http://www.pololu.com/product/1132

I actually bought 8 of those for my build and hooked up one of them.  It worked GREAT for the old wooden balls that I was using when I first built the machine... unfortunately for me a few years ago I bought NOS official black skeeballs and have been using those ever since... well after testing with those wooden balls I went and tried out my shiny black Skeeballs and it's like they are freakin invisible.  Literally nothing happens even if I wave the damn ball back and forth in front of the sensor.  Turns out that the IR doesn't play nice with dark and/or shiny objects.   Considering that I dropped ~$20/ball on the black ones, those balls are staying and I have to come up with a different sensor option haha.  I would definitely recommend trying those sensors to people that are using regular Skeeballs though!

btw your R2Beer2 is amazing!

[Le Chuck]

Oh ---steaming pile of meadow muffin--- man, I need to reread before posting. I remember you talking about that before.

Thanks for the kudos on R2AU, I love this build of yours and want to tackle my own at some point.

[PL1]

I think I understand the basics of getting the LEDs wired up, but getting the photodiodes going is just something I can't seem to wrap my brain around (specifically how to wire them up so that they don't send a trigger until the light beam is broken rather than just always being triggered because of the LED always being lit).

Based on posts here, here, and here, when light hits the reverse-biased photodiode, it allows current to flow through the photodiode which then flows through resistor R2, resulting in a voltage drop across R2. (voltage developing resistor)

With the right size resistor (somewhere between 10k and 470k ohms?), the voltage drop will be close to 5v.

The encoder interprets voltages close to 5v as "button not pressed".

When the light is blocked, current doesn't flow through the photodiode and resistor, which results in no voltage being developed across the resistor.

The encoder interprets voltages close to 0v as "button pressed".

Before connecting the circuit to your encoder, mount your IR LED (w. current limiting resistor) and photodiode in one of your sensor rings, and add either an easily-swapped fixed or a 470k variable resistor to test the output voltage with your multi-meter.

When the beam is unbroken, you want about 4.5 - 5v.

When the beam is broken, it should drop down close to 0v.

Once you meet those criteria, hook the output to the encoder input and test it there. (The variable resistor will let you experiment with different values to dial in the best results once you get the whole circuit working.)   

As always, remember to only measure resistance (ohms) when power is disconnected from the circuit -- unless you want to damage your meter.   


Scott

[samej71]

I'm sorry I haven't had time to help with this.

I had a 5v supply and I used a 100k 1/4 watt resistors with each photodiodes (in the manner PL1 discussed in his most recent post). I haven't looked at the specs for the digital inverter/not chip to see what its thresholds are. My goal was > 4v for digital 1 and < 1v for digital 0. I had a distance between the led and photodiode of around a foot, larger than the hole of a skee machine, but I suspect that resistor value will probably still work.

Link to photodiode resisters I used:
http://www.radioshack.com/product/index.jsp?productId=2062350

[nickels]

Glad to see this thread revived! I am in the process of writing a few games for my SkeeBall machine (based on the ideas from this thread). Here is my first original game - playable, up to 4 players, really fun:
Skee Wars:
#I removed a dead, old link#

I am about halfway done writing my newest game: TimeBomb
This is a level based skill game where you have to hit the targets in a certain order to defuse the bomb. YOu have a time limit for each stage. The early levels are like - get a 50. Get 100. Then it gets tough: get 30 then 40, or get 100 then 30. The final levels you have to get three in order: 20, 50, 100 or 40, 30, 50. If you miss one you start over. If the time runs out the bomb explodes and the game ends.

I many more game ideas. Too bad I have three kids now, it's summer, and I have zero time to Flash code.
Hopefully I can get some of your games to save me time. There is no way I'll be able to program half of the games I'd like to make.

[thatpurplestuff]

Scott- thank you for the info!  I think I'm slowly starting to wrap my brain around this one haha

Just a quick update... samej71 was kind enough to offer help by drawing up a wiring schematic of all the sensors for me.  He hasn't actually done it yet since he had some questions for me regarding my setup, but once he's had time he is going to summarize some of the info that we've discussed and post it here.  Needless to say I am very thankful, and who knows I may actually get these optical sensors installed after all!

Regarding the software, I'm pretty much ready for a first release once I have an opportunity to test all of the new modes on the actual machine and make sure everything works like it is supposed to.  It's as configurable as I want it to be right now (meaning only UI stuff like organizing the games list and defining your own keyboard inputs for driving the menu, rings, gutter).  I thought about making all of the timers, ball counts, etc configurable for different games but I sorta like the idea of everyone that runs Free Skee playing by the same rules.

I've tested it on a couple different widescreen monitors and it has worked great, the one caveat being that since it was designed for an 800x600 display it can look a bit pixelated on larger monitors (although many elements are vector so they scale nicely).  It has the curtains that hide what would normally be empty black bars on either side of any monitor that is wider than 4:3, so no matter what aspect ratio you are running it won't look super awkward.

Along those lines, I am going to be upgrading the tiny 15" 4:3 LCD that is currently in it to a 20" 16:9 display, and also updating the PC that is running in the machine.  Right now the software was written exclusively for a tiny-screened very slow computer, so some of the effects that I would have liked to incorporate (like glow effects on the scoreboards) had to go by the wayside to make sure everything ran full speed.

What all this really means is that AFTER the first release, I will be overhauling Free Skee to run at a higher resolution and have all my originally intended bells and whistles added back in (and formatted for 16:9 monitors instead of using the curtain fix to make it work on them).  I may also take this opportunity to make the switch from AS2 to AS3, but that really all depends on how rough the transition is between the two.  Below is a mockup of the new layout for my scoreboard... the speakers that are on my current scoreboard will have to be moved to a new location, possibly to the front of the machine.



Will post any sensor updates when they happen!

[PL1]

Scott- thank you for the info!  I think I'm slowly starting to wrap my brain around this one haha

Glad to assist.

I've also posted a more in-depth explanation here in Le Chuck's Space Base thread of IR LEDs wired in series like the water-wheel image.


Scott

[eds1275]

I see a list of different types of games there. Are they something you designed, or is there more than just going for a high score?

[PL1]

I see a list of different types of games there. Are they something you designed, or is there more than just going for a high score?

He did the coding himself  and describes some of the game rules here.

Some of the games in action -- video is several years old.




Scott

[thatpurplestuff]

Thanks Scott!  Here's a newer video that shows most of the games (Shuuz is no longer on the list, and Splat! has been added), no sound though!  The up/down menu buttons double as rules/hi score buttons in-game so that's what the blue info windows that pop up are.

[nickels]

I still think we should combine our efforts as we are probably the only two people on earth with skeeball machines creating Flash games with LEDWiz being used as the main controller. I can make my games available to you so that you can add them to your package if you are interested. SkeeWars took me forever to code, so I am happy to get it out there for everyone to enjoy.  I just need to make a few changes so that my games can use your variables for the controls.

Since your games and mine use the LEDWiz we should at least coordinate how they are connected. Do you have two lights for each scoring hole, and can you list the connections to lights? Ex: 50's light #1 to slot 17, 50's light #2 to slot 18... etc. If these aren't aren't connected the same the games will not control the lighting correctly. Oh yeah, I also have a relay on one of the LEDWiz output slots to control the siren on top of the machine. Mine also has a small "control panel" on the front with an up arrow, select button, and a down arrow. I use them to select games and control the menu system. Coordinating this between us sounds like a big hassle, I know. It just seems like a waste to have two people doing the same thing but not working together doing it.

As for AS3, I figure why bother? AS2 works, you already have the code figured out, and Flash is all but dead. Why waste time learning a new, complex programming language when that time can be spent writing more games?

[nickels]

You should check out my menu system for selecting games. It shows how many players and the rules, and is easy to customize for adding new games (and also changing the bg music):

http://johnkalnin.com/skee/games/SkeeBall-MainController.swf

1 - move up
P - move down
5 - select game

[thatpurplestuff]

nickels-

In regards to merging the projects, I just have to be honest and say that I'm a total control freak and I really wouldn't be comfortable combining the two.  I've literally poured hundreds of hours into this software and I'm pretty proud that I did it on my own, plus I am very inconsistent in regards to the time I spend on it and trying to coordinate with someone would more than likely take a lot of the fun and spontaneity out of it for me.  Please don't take anything personally, your SkeeWars game looks awesome and I definitely want to try to play it sometime on my machine once I get it all put back together!

For the LEDwiz, each ring has an RGB led so I use 3 outputs per hole.  I'll have to go back and look to verify, but I'm fairly certain that Ring 10 is slots 1-3, ring 20 is 4-6, ring 30 is 7-9, ring 40 is 10-12, ring 50 is 13-15, left 100 ring is 16-18, and right 100 ring is 19-21.  Again, not positive on those but I'm pretty sure that's the way they are.

About ActionScript, I've read that AS3 executes code up to 10 times faster than AS2, which might be beneficial to those that are running slower hardware.  Other than that there wouldn't be a whole lot of reasons to switch over.  Again, I may make the jump it just depends on how much of a pain in it is.

About the menu, the latest video isn't entirely accurate since there has been a lot of coding done since it was recorded.  It's almost the same visually, but it now shows very faint light gray text at the bottom of the screen showing # of players for each game as they are highlighted.  The menu system is pretty robust as well, since it accesses an external settings file that you can modify to rearrange games in whatever order you like.  The ball characters all correspond to specific game modes and swap out correctly no matter what order the games are in, which took me much longer than I care to admit to get figured out haha.

[nickels]

I know how you feel, and totally understand. No hard feelings on my end cause none of my work would even be possible without this thread. I'll just make a sub-menu that launches to your menu or mine so that I can have all of them working at once. I'll figure it out once you release your software.

Oh crap! I am using a LEDWiz GP+ with only 16 available outputs. So, I can't use RGB lights due to not having enough output slots for all of the lights. Damn damn. I figured it would be easier to have one device doing everything, and that is the price for going that route. Hopefully the lights aren't a major part of your games.

Cheers to you for doing this, inspiring me, and I look forward to the day that your software is available. 

[PL1]

Any chance that you might add a simple configuration menu or file?

It would be great to allow people to:

  * Select 4:3 vs 16:9

  * Configure the inputs for a keyboard-style encoder vs a gamepad-style encoder.

  * Use an open-source LED-Blinky compatible controller like this one.


Scott

[thatpurplestuff]

nickels- I've made sure when creating the games that while the lights are helpful, they are not essential to being able to play any of them.  Any time there is a specific hole lit, there is something on the screen that indicates the same thing.  Right now the software just loads LWA files to the LEDwiz to light up holes, so you could always modify those LWA files so that the lights work with your setup.  That wouldn't help a lot for games that use multiple colors, but it would definitely help for some.  Thanks for the kind words!

PL1- Yeah right now there's a basic config file that could definitely be expanded upon to allow users to customize more options.

1) 4:3 vs 16:9... I still need to figure out how exactly I want to make the switch.  It will most likely end up with me redesigning every game for widescreen, but that will take a long freaking time so I think the best solution in the interim is to just increase the resolution of all of the assets so that they are crisp on 1280x720 or something.  Right now the game will go fullscreen as large as it can vertically, then any extra real estate is covered by the curtains that swoop in to begin and end each game.  Right now there's no need to tell the game if it's widescreen or not, but if I do end up remaking widescreen versions of each game then I will definitely add that as something that the user can configure via settings.

2) joystick input... just from a really quick cursory Google search, it looks like there is no way in AS2 to directly read joystick inputs.  It does sound like there may be a workaround though, and one that wouldn't require much work on my end.  If I use an 3rd party SWF wrapper while I am creating the .exe then in theory that wrapper could do all of the joystick/keyboard conversion on the fly, although again this is just me blabbing after reading a few pages online and I'd have to look into it a lot further to know whether it was something I was capable of or not.

3) open source LED-blinky compatible controller... I am definitely open to supporting this, but it would have to be able to read clipboard commands at the moment.  Right now the way that the software interacts with the LEDs is the only thing that I am not really satisfied with.  I have to use the clipboard to send commands to the LEDwiz, which seems to work fine but is definitely not ideal and just feels dirty haha.  Now that you mention it, I may want to look into the way that other programs interface with LEDblinky because that could very well be a workaround that I have missed.

I'm really just a fake-it-'til-you-make-it programmer, as this is the first thing I've ever really programmed in ActionScript and I really only learn new things when I encounter something that I want to add and don't know how to.  Apologies if I missed anything, I typed this up during my lunch and was a bit rushed!

[nickels]

2) I use Joy2Key
http://joytokey.net/en/

Not sure if this will help you at all, but this is how I convert my switches' inputs to keystrokes for Flash interaction. The LEDWiz sees my switches as if they are coming from a joystick, then this software converts that to keyboard keystrokes for use in the Flash games. You can open up the software and change the inputs to any keystroke that you want. Works great.

[thatpurplestuff]

Been playing with LEDblinky and I'm amazed at how easy it is to create animations and transitions between colors.  I bought my copy of it like 6 months ago for the arcade cab that I will be building at some point, but I literally had never even loaded the program up until now.  I really want to use it for Free Skee, but I'm afraid I might have hit a dead end regarding functionality.

Not sure how to word this, but does anyone know if LEDblinky allows for incremental control of LEDs?  By this I mean is there a way to send one command to light the 10 ring, then send another command to light the 20 ring and have the 10 ring remain lit?  So far every time I send a command via LEDblinky it seems to just wipe all the LEDs states before it makes the new changes.  If there isn't a way around this, it's pretty much a dealbreaker for me since many games require individual rings to be turned on and off while the rest remain unchanged.

The only thing I've found regarding this is in the animation editor documentation regarding single frame animations, but it appears that you can only do what I'm wanting in a very limited manner (by using LEDblinky events like "FE Active" or "Game Play" but even then I don't think I can do what I need to do).

Any LEDblinky experts out there know if there's a way for me to get LEDblinky to do what I need it to?  If not, is there an easy way to convert the .LWAX XML files that LEDblinky uses to the .LWA files that the standard LEDwiz software uses?

edit: Found an app on the forum by headkaze http://forum.arcadecontrols.com/index.php/topic,69102.msg714226.html#msg714226 called LWA2LWAX which seems to work for converting LWA to LWAX, but when I check the "Reverse" box to convert LWAX to LWA I get an "Unhandled exception has occurred in your application" error.  Bummer!

[nickels]

Since you brought it up, how do you do that using the LEDWiz controller? I have no use for it on my current games but I was wondering for future games. All I know how to do is send commands from flash to activate my lwa files: System.setClipboard("LWZ-FLP:16-LED");
In that example the file 16-LED.lwa simply activates the 16th slot on my LEDWiz - this file is created using the control panel/software. That is how I turn on the siren light on mine.

So how do you activate slot 15, then activate 12 but do not disable anything else? Basically what you are saying to turn on and off one slot at a time yet ignore the other other slots active or disabled states? Do I just create lwa files that activate/disable one slot at a time and call them as needed? My LEDWiz is connect to my skee ball machine and cracking it open to test is not easy.

Here is the nonsense code in the 16-led.lwa file probably not important

Code: [Select]

"3"
"LWZ-DUR:250"
"LWZ-PBA:48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48"
"LWZ-SBA:0,128,0,0,3"-meaningless to me!

Not even sure i'll need this as I have no plans on recreating games you've already made. It would be nice to know though just in case. Thanks in advance.

[thatpurplestuff]

nickels- I use Randy's software to create an animation that only turns on one ring (it can be multiple slots on the LEDwiz since I've got an RGB setup) and then use the clipboard to call up that LWA animation.  It keeps the existing states the same on the rest of the LEDs while only updating the LED slots that I specify.

I've figured out how to call up the animations using LEDBlinky just fine, but it seems to wipe the current states of all LEDs before it applies the new state no matter what I do.  I created a thread in the main forum about this issue hoping that arzoo sees it and can shed some light as to whether it's possible or not to do what I need it to do.  If I could get LEDBlinky to work with my software, it would address Scott's request for supporting open source LEDblinky compatible controllers while also allowing for more slick animations than I'm capable of creating right now.

[nickels]

Thanks again. I see the LEDBlinky creator is here:
http://forum.arcadecontrols.com/index.php/topic,73905.msg1452489.html

arzoo seems to be pretty active, so you should get an answer pretty quick if you post it on that thread.

[Nephasth]

Shuuz is no longer on the list, and Splat! has been added

Very cool!

[thomas_surles]

Another game suggestion. I just like coming up with fun ideas.

How about a board game 1-4 players.
Each player rolls to see who goes first (or not, not sure how that would work out)
But an on screen board game is displayed,  a 10 moves you 1 space, 20 is 2 and so on...
Maybe some chance spaces to make the player advance or move back spaces. First to the finish wins..
That could be cool.

Also I had an idea for a very complex fighter or turn base rpg type scene.
Like a certain roll could determine the attack used. That would be really awesome but hard to code.
The player an enemy would have a certain hp and the goal wold be to kill the enemy before he kills you.
Or even easier than a computer enemy with random attacks would be player vs player.

It would be really cool if you could have an on screen fight scene maybe in an 8 bit style or something.
Could name it skee fighter or skee kombat.

[PL1]

Could name it skee fighter or skee kombat.

Skee't Fighter?  Skee It Fighter?

Health bars at the top.

Roll to see who attacks first.

--Message on screen "P1 Ready" . . . (variable delay 2-5 seconds?) . . . "Roll"

--Message on screen "P2 Ready" . . . (variable delay 2-5 seconds?) . . . "Roll"

--Highest score attacks first. In case of tie, whoever scored fastest is first.

(For this example, P1 scored higher)

Attack/defense sequence

--Message on screen "P1 Ready" . . . (variable delay 2-5 seconds?) . . . "Attack"

--Message on screen "P2 Ready" . . . (variable delay 2-5 seconds?) . . . "Defend"

--P1 higher score = successful attack, damage based on P1 attack roll - P2 defense roll
(10 = minimum damage, 100 = maximum damage)

--P2 higher score = successful defense, no damage

--In case of tie, whoever scored fastest wins minimum damage (P1) or successful defense. (P2)

--Update health bars and play an animated attack (based on amount of damage and whether a fatality has occurred)

--If neither player has been killed, repeat the attack/defense sequence with the player numbers reversed.


Scott

[thomas_surles]

Could name it skee fighter or skee kombat.

Skee't Fighter?  Skee It Fighter?

Health bars at the top.

Roll to see who attacks first.

--Message on screen "P1 Ready" . . . (variable delay 2-5 seconds?) . . . "Roll"

--Message on screen "P2 Ready" . . . (variable delay 2-5 seconds?) . . . "Roll"

--Highest score attacks first. In case of tie, whoever scored fastest is first.

(For this example, P1 scored higher)

Attack/defense sequence

--Message on screen "P1 Ready" . . . (variable delay 2-5 seconds?) . . . "Attack"

--Message on screen "P2 Ready" . . . (variable delay 2-5 seconds?) . . . "Defend"

--P1 higher score = successful attack, damage based on P1 attack roll - P2 defense roll
(10 = minimum damage, 100 = maximum damage)

--P2 higher score = successful defense, no damage

--In case of tie, whoever scored fastest wins minimum damage (P1) or successful defense. (P2)

--Update health bars and play an animated attack (based on amount of damage and whether a fatality has occurred)

--If neither player has been killed, repeat the attack/defense sequence with the player numbers reversed.


Scott

I like it,
You could also take this same idea and do a boxing game but when the hp goes down the player has 10 seconds to recover and regain a little hp by hitting a certain hole or something

[thatpurplestuff]

Cool game ideas!  I've banned myself from creating any new games until I have all of the features and updates finished that are on my list of things to do, but I will most likely add more games after I get everything else dialed in.  Speaking of which, I've decided that the resolution that I am writing the software for is 1366x768.  I started adding all of elements that I could in vector format and got about halfway done, but then realized that vector data is more cpu intensive than raster data and I don't want to waste valuable processing power that could be used for doing things like glow effects, shadows, etc.  Will be going back and importing each raster element at the exact resolution that it needs to be for best performance.

Here's a screenshot of the current menu in full 1366x768 resolution... you'll notice that the Free Skee logo has been removed in favor of making the Skeeballs larger.  The software is still called Free Skee, I just removed it from the menu screen since it might conflict with any themes that people have.  The title above the Skeeballs changes depending on what game is selected, and the text along the bottom lists the number of players each game allows.  Like I posted earlier in the thread, the software now reads from an external config file that will let users put the games in any order that they want.


After spending a bunch of time upping the resolution of the different game modes, I'm honestly not sure if I'll ever remove the curtains from the sides... I feel like this is an elegant solution to different monitor aspect ratios and I actually think it frames the screen well.  Either way even if the curtains did go away, it wouldn't be for quite a while since it would require remaking every single game theme and I want to have a stable release done a lot sooner than that.

[Le Chuck]

I can't tell you how excited I am for the eventual release of this.  It looks fantastic.  I don't know if I'll have a skeeball anytime soon but whenever I get one this will be the mod package I go with.  Fantastic!

[nickels]

Hope the OP is still monitoring this thread, technical Flash question...
I am using AS2 and the script

Code: [Select]

System.setClipboard("LWZ-FLP:3-LED"); to light up the LED on the 3rd slot for example. I am trying to use this code to light up the LED lights on the table in sync with some music for one of my games. However, there seems to be a delay when using this setClipboard code. I was wondering if you found any workarounds to this problem?

[thatpurplestuff]

nickels- To be honest, I haven't tried to do any LED sync'ing with music but I'd imagine it would be tricky.  I am actually trying to have my software interface with LEDblinky now rather than the LEDwiz software... this serves to both add support for open-source hardware as well as allows me to use some more fancy animations.

I've written my own little AHK script to monitor the clipboard which then processes it and runs LEDblinky with the appropriate commands.  It works really well and allows for the more detailed animations that LEDblinky provides, but the one potential dealbreaker is that by default it clears all of the LEDs before it runs any animation (which is a huge problem if you don't want the lights flickering every time a new animation loads).  Arzoo said that he will look into adding a backend option to not clear the LEDs if it's not to much of a pain for him, so I've got my fingers crossed that LEDblinky will be the way to go.

This was basically a longwinded way of saying that all of my LED coding has been put on hold while I wait to see if arzoo is able to make some magic happen, but even then I don't really know of any workaround to use the LEDwiz software or LEDblinky that doesn't use the clipboard (which will most likely always have some level of delay).  Sorry I couldn't be more help!

[thatpurplestuff]

Figured while I'm at it I would give a quick update on progress.  I haven't heard anything back from samej71 yet in regards to drawing up the circuit diagram, but I've made huge leaps and bounds with the software in the meantime.

First, I've completely redone all of the sound code and I've added support for custom background music.  Each game can have a total of 3 songs associated with it... the software will load up songs that you specify for that game and randomly select one as the game loads.  The ability to turn the music on and off can be triggered with a combination of menu buttons as well.

Second, I'm very close to being done increasing the resolution for the games to 1600x900.  Everything is all smoothed out now too, so even going a little bigger looks pretty good and it's light years better than the 800x600 that it was originally.  For now I am just keeping the red curtains on the sides so I don't have to completely recreate every theme to support widescreen, and that's honestly probably how it will stay since I really like the look of it (and it's nice to have the option of using different aspect ratios like 4:3, 16:9, etc without changes).  I've also made a point to start fine tuning all of the small bells and whistles that I've been wanting to add, like the bowling pin particle generators in the video below (thank Youtube for muting the entire video because it had "The Man in Me" from The Big Lebowski playing as the background song).



Pretty much all of the important stuff can be modified via settings files now (input keys, menu list organization, background music, misc options) and it's honestly getting pretty close to being ready to go.  Once I get my optical switch circuits figured out I will be able to give everything a thorough testing (there are still a bunch of these games that I haven't even played a single time yet) and hopefully by that point I will know one way or the other about LEDblinky support so I can either finish converting all of the lighting over to LEDblinky's format or make the switch back to the LEDwiz software.

Once I get pretty close to launch I will make a new thread in the software forum to announce it and hopefully help iron out any bugs.  Anyway, just wanted to let everyone know I'm still making progress even if it's ridiculously slow!

[nickels]

It seems that you are very close to the finish line while I feel like I just started the marathon. Believe me, I totally understand the reason this stuff takes months and years not days. I will continue to work on making the LEDs sync, but that seems like a technical problem that will take longer to solve than I feel like investing into it. I look forward to your release, and hope to have some new games myself one of these days. Eventually. At least these little talks get me inspired to get back to work. Thanks and good luck!

[nickels]

Technical update for thatpurplestuff - leaving this public in the rare case a Flash programmer using the LED-Wiz searches for some info...

In the process of making one skeeball game in particular, it has come to my attention that using the clipboard to control the LED lights there are some limits on what you can and can't do. As you know, in order to make the state of one light not effect the state of another you have to use commands such as

System.setClipboard("LWZ-S01:1");

That turns on the LED on the 01 position and ignores everything else. Let's say you want to leave that lit and now light the next light:
System.setClipboard("LWZ-S02:1");

That will light up the LED on the LED-Wiz attached to the second output position. It it also leaves everything else alone, so position 1 is still lit from before. Using this technique is about the only way I've found to turn lights on and off while ignoring the other ones. If you run a command like:
System.setClipboard("LWZ-FRP:animation-file-name,1");

That will run the animation that you have saved, but it will also turn OFF everything before it runs. So, this code is great for running lighting animations, but you lose control over all lights (or connected devices) that were turned ON prior to using that command.

I have noticed that if you run Flash at 30FPS, you can not make the LWZ-S calls in corresponding frames or even within 4 frames. For me to get consistent, repeatable results, the clipboard calls to control the LED-Wiz must be no fewer than 5 frames apart. I ran multiple tests and this seems to be the most reliable way to control the lights on the table.

Example of it failing:
Frame 1 actionscript:
System.setClipboard("LWZ-S01:1");
Frame 2 actionscript:
System.setClipboard("LWZ-S02:1");

Results when run - sometime only one light is lit, sometimes both. I believe it skips the first call frequently, and only the second light is lit. There is no documentation for the delay needed for the LED-Wiz to read the clipboard and react in time. In order for this to work here is the fix:

Example of it working:
Frame 1 actionscript:
System.setClipboard("LWZ-S01:1");
Frame 6 actionscript:
System.setClipboard("LWZ-S02:1");

Now, when I run the flash file the table consistently lights up both lights. Nothing is missed or skipped. So, if you want to have complete control over the lights without the code acting funky, keep your clipboard calls 5 frames apart running at 30FPS. Not sure if this is the same for all PCs, or a performance issue with the computer I use to run my games? Just be aware that making clipboard calls spaced close together in the flash frames results in some of the commands being ignored by the LED-Wiz. Of course the need for this is rare at best. My game needs this type of control and I was having a lot of trouble figuring out why my code wasn't always giving me consistent results? After running a bunch of tests and spreading out the commands, my results are now what I was expecting. Hope this info helps someone! There aren't a lot of resources out there for this kind of thing.

[thatpurplestuff]

nickels- I have actually stopped using the LEDwiz software to run the LEDs, instead opting to use LEDBlinky because of the slick animation editor and more detailed animations that I was able to create.  I created an AHK script that monitors the clipboard and runs LEDBlinky with arguments from the clipboard any time that the clipboard changes.  I'm not sure how often per second AHK checks for updates, but I'd imagine that a similar delay would be required compared to the LEDwiz software to make sure no commands are lost.

[thatpurplestuff]

First off, just wanted to publicly thank arzoo (the creator of LEDBlinky) for going out of his way and creating a patch that makes LEDBlinky work with my Skeeball software.  LEDBlinky allows for much more detailed animations, but I was having an issue with the LEDs resetting between animations... he kindly added an argument that can be added when running LEDBlinky that makes it so the states are not reset before animations, which is exactly what I needed and I am incredibly grateful for the time he spent adding such a random frivolous feature.  Now that I know for certain how I am going to be controlling the LEDs I can go about finalizing all animations and putting the final polish on Free Skee (I have capped myself at the 20 existing game modes until I get the initial release finished).  Below are a couple of shots of the latest finished games:


Each player starts with 150 and the goal is to get 300... the catch is that the only way to score is to suck points away from the other player!


Target starts at 10 and gets progressively more difficult.  Players take turns making the shots to "pass" the potato to the other player before it explodes.

Anyway now that the lighting situation is figured out, my final hurdle is to get these beam break sensors up and running.  I just ordered these:

IR Break Beam Sensor - 3mm LEDs
https://www.adafruit.com/products/2167

In theory these will either work out of the box or with a 10 ohm resister added to each receiver.  Once I get them in the mail and start testing them out I will post more details about how they function and if they are a good option to use... it seems that if they do work, they'd be a great option for other stuff like the current arcade basketball build that is going on.

[nickels]

Very cool! Those are some interesting new games you've created. Can't wait to get them up and running on my end when you go public.

I was going to ask about using LEDBlinky, but I don't have RGB lights (only one red and one blue per hole) so my need for animations is minimal. At least now I know about the delay and can get back to finishing the game I've been working on for what seems like a year now.

[thatpurplestuff]

Well the sensors came in the mail last night and I can't say enough good things about them.  I hooked one up to an IPAC (btw you know you have a BYOAC problem when you've got multiple spare encoders around to choose from)... I was thoroughly expecting the initial test to be a failure and I was amazed that it worked straight out of the box.  No pull up resistors needed, no modifications to it whatsover.  It just freakin works!

After discovering that the sensors worked, I decided to play around for a few minutes testing the size/speed of objects that would trigger the sensors.  I started off with large objects (skeeballs) and worked my way all the way down to the tip of a screwdriver and these sensors didn't miss a thing.  They are INCREDIBLY accurate and I can't wait to get everything wired up to finally begin testing out some of these new games I've written!

Thanks again to everyone that has helped me (or attempted to help me) get these sensors going!  This has given me a lot of steam to push forward... will be wiring up the sensors, adding a new computer, installing the new larger screen, moving the speakers to the front of the machine, and finally installing the leg covers.  Expect updates that actually contain pictures soon!

[Le Chuck]

That's awesome!  Glad to hear they work so well, I'll keep those in the toolbox for later use for sure!!  Now let's see this thing get finished.

[HanoiBoi]

Anyone know how the IR sensors would get wired up to an ipac?  I'm used to microswitch/buttons and am hoping to use these as a keystroke entry too. 

I realize the ground for emitter and receiver could daisy chain to the ipac ground, but what about the rest?

Since there are two pieces required, I'm just not sure of the wiring.  Do both red wires go to one ipac input? Or... does the white receiver wire go into the ipac?

[Entropy42]

From the adafruit site:
https://learn.adafruit.com/ir-breakbeam-sensors
You wire up both blacks to ground, both reds to 3.3 or 5V, and the white to your iPac.  The white is at the same voltage as your red, unless the beam is broken, then it is pulled down (I guess the iPac has a built-in pull up resistor?) to 0 V and that reads as a keystroke/button press.

I have not actually done this, but from reading that, I think that's how it goes.