zimjoe - thanks for coming over, trying it out, and for exercising some of my other games!

Suuuure. I think you're catching on - you had that great game last night where you only needed #7 to make a 5 in a line. Fun and dramatic to watch the ball swirl right out of #7 and plop directly into #13.

Also, I think we may have a new one ball fan! zimjoe played the Turf King that Ava restored and really liked it quite a bit. That one's on coin play, and I think you pumped about 40 nickels in across the various games you played (not counting the winners)!

...Perhaps I should do something like this for one ball games?! Well, only 110ish games left to implement before I start on that.

I like it, too. At this juncture, it's helping to feed the continued development.

My daughter's birthday is today - turning 6! I am likely not going to be working on the game tonight - unless it is really late - so I would not expect further updates today. Tomorrow is another day.

Graphics day. I've finished the graphics for two more six cards and am working on another six card. Some of these games are not super well-loved and good backglass images do not exist. I am having to reproduce large portions of the graphics.

Hoping to finish another few games' graphics and fix the couple of oddball issues with the resizing from a few days ago.

Finished all three of the graphics for the games I was working on. They are starting to get extremely complex. Tons of layers. That's what happens when I jump out of order.

I received a beautiful United 4" bell today, I've polished and installed in the head beside the sounder. Works beautifully. I have a few updates to make to take advantage; only Zingo is currently using the bell. While I'm updating Leader, I'll fix the extra ball logic.

I've got a plan to finish the graphics for all the six cards where I can find a source image, probably finished in the next few days, then I'll continue working on the programming.

Very excited to be playing again tonight.

Yes, on United's early games, they included a bell which would go off with features/odds increases as well as for replay wins.

Similar to the sounder in early Bally games, just sounds better.

That's true, Vic! I don't know of any other Bally games with a bell, but Bonanza will ring as appropriate.

Otaku, more than happy to show you around the real bingos, as well as my funky hybrid system. As NoQuarters says - if you play one and understand what you're doing, you'll want to have one of your own.

So much thought, so much drama, so much fun!

Looking forward to seeing you in just a little over 2 months!

Yep! I plan on bringing the Multi, though I may not have the stencil complete by then. I'll just ask folks to put prettier games beside it.

I haven't decided what real bingo I'll be bringing yet, but I'll definitely be bringing a second game, too. Most of the folks that were there last year have committed to bringing bingos this year, too. I think we'll have a good turnout of games for York this year, too. I'm excited and daunted - Back to programming.

Tonight's work - three more games' artwork complete. I'm trying to finish all of the six card artwork that I can so that I have a clear path to implement all of those games.

I've also reached out to an owner of Super Wall Street to see if I can get a better picture of the backglass to work with.

Looks like... 8 more games to work with, but I only have photos for 3.

I've got two different games' artwork in progress now, so I may be back to coding quicker than imagined.

I received several fantastic photos of a Super Wall Street! Now I'm ready to get that game started, too. The photos contain a small french "For Amusement Only" sticker on the backglass, which I will likely leave in place as a reminder where the game came from (Quebec). It only covers a small part of the cityscape on the lower left.

Three more games' artwork are complete. On top of that, I found a 'good enough' image of the original Fun Spot, so I will be able to make a Barrel 'O Fun as well!

Hey alexanr1 - no, I have not taken on any of the dynamic (backglass animation) games yet. I initially started with Night Club, but being thrown into the deep end of modeling the mixers, reflex, control unit, etc. was a little much with the added challenge of how to handle illuminated moving artwork.

By Magic Card, do you mean 'The Twist'? That's actually one of the games I am most excited to play, as it appears to give the player a lot of opportunity for scoring in a similar method to the Magic Screen games, but without the section scoring.

I'm working through the games right now that have smaller amounts of portioning - 'The Twist' is also unique in that it will tell you what the next coin will grant. I'm also curious to know if that will translate into lots of additional coins.

I've never played a 'The Twist' in real life, but the nice thing is that assuming my portioning is correct, I will get at least the basic experience.

As far as difficulty, I don't think it will be too difficult to either model that game or work out the portioning. The backglass animation will be done in three layers - one for the outer artwork, one for the inner card artwork, and a third for the numbers (on the chain mechanism in the real game). The third layer will actually slide from side-to-side, rather than rotate. But that's mainly because I'm not a 3D animator (yet), haha!

Each of the games will have animation that is fairly similar - meaning, it will move on 2D planes - but I can stack them as deep as I want. Lamps actually are another layer on top of the backglass artwork.

Hope that answers your question - if not, just let me know.

I'm itching to play again... I've been sitting at another computer doing artwork for the past few days, and not getting those 5 in a row hits that I know I would have had if I had been playing.

I'm simulating Stock Market right now! Double or nothing and corners scoring works. (Had to take a break from artwork for a minute)

More importantly -- the complex search function for player-controlled searching and polling for Double or Nothing is implemented! On top of all that good news, I figured out how to write a blinking routine for the Double or Nothing panel. This opens the (complex) door towards my understanding of blinking lamps (say, in the titles of the games).

For the interested: the searching has to be tweaked as the player can initiate the search at any time. Aside from checking the replay counter position on each card, I also had to check the status of two relays: Double or Missed. This also has to work when you shoot another ball. On my dev computer, it all works!

Note that Stock Market is the first game with a fourth digit on the replay counter that I've implemented. This required some reimagining of my replay step up function, because the vast majority of games have three reels.

I just spent the last hour testing winning double/nothing/regular wins with replays up to 1000 or so, then stepping down. Bugtested and ready to roll! Stock Market is complete!

On to the next game.

Original Fun Spot is also complete!

...Back to artwork again (for now).

Last update for tonight - the art is complete on the Super Wall Street I received the photos for yesterday!

Stock Market

Ticker Tape!

Fun Spot

A programmer friend was over last night and checked out the MB. He was quite impressed with what I was able to accomplish (he knows my poor programming skills), and I asked him some pointed questions about a few lingering bugs with my implementation.

In particular, we focused on a bug that prevents my 'full screen' display from actually, you know, displaying full screen! This has been bugging me forever, but the odds on the 70s six card are actually displayed underneath the backglass image, and you can't see them unless it is full screen.

I've searched and searched through my code to try to figure out why it wasn't launching in full screen mode... and I have never been able to figure out why... until earlier today. I started thinking about the modifications I made to the underlying library to prevent/replace DMD support... and yes, I hard-coded a resolution in that library which is incorrect. (oops!)

Good news, I should be able to change that resolution, recompile the library/reinstall, then all should be well!

Other bugs - my menu doesn't quite quit gracefully in some circumstances, and will also start the wrong game in certain circumstances.

Lastly, my search algorithm's race condition. My friend pointed out (correctly) that I have a separate loop for pygame running (otherwise, how could graphics function?)... and that this will interfere with the switch handling/processing logic... (geez, rookie mistakes).

Anyway, in order to fix the menu stuff, I likely have to examine how I am exiting each game. This will also prevent certain bugs (like winning credits on a game and coming back to the same number of credits displayed), and various other (rare) crashes and so forth.

The search algorithm is much tougher. I think I'll have to re-architect the display code entirely to fix it, and as he pointed out, I'll still not be able to completely avoid this particular issue... that may wait until I have everything else complete - I think I might be able to wrap the standard display() method in such a way that it can execute async from the rest of the code... but I'm not raring to fix this bug.

Basically, the game can 'forget' how many replays it needs to add if you don't wait for it to finish registering before shooting and pocketing a fifth/sixth/etc. ball. Normally what this means is that you get the odd single extra replay. Occasionally, on the earlier games, your search can be ill-timed in such a way that it misses the hit. This is an issue because you as a player cannot control how the search happens - it just 'does'. I'll figure out something, like, for example, modifying the ball lift code to auto-search if you press the override button after 4th ball has been shot.

This weekend, I have some power supplies coming that will hopefully stop my randomly rebooting score and instruction screens, then next week I have yet another playfield coming!

I am working on another game, but it is much later and MUCH tougher (with regard to portioning) than the games I have recently implemented. I'm looking forward to playing it, though! Once I solve the portioning for this game, I will be able to implement another three that are drawn (schematic) in the same style.

One is a surprise, and unlikely one that you might expect.

I also have another several lined up with completed artwork. If I get overwhelmed with the portioning on this one, I'll move on to one of the other, simpler, games.

And I also have the artwork 1/2 done for the next game chronologically... lots of stuff to do! And then there's the game I left off after finishing the artwork... in the middle of portioning.

The list is down to 114 that are not complete and functioning.

Gotta stop jumping around so much! But I'm having lots of fun, and that's one of the important things, isn't it?

Wired in trough switch #8 tonight, and fixed my fullscreen code. Made a dumb mistake that prevented the screen from going fully fullscreen. Trough #8 allows me to completely rewrite my lifter code, which I am in the middle of doing. New power cords for raspberry Pis arrived , which have made them much more stable.

IMG_20160723_014412_(resized).jpg

Thanks! Games with a third score/instruction card will get this treatment. Mostly a lot of the 70s 6 card games.

Lifter info.

I spent the remainder of the evening working on some annoying shutter issues. I think I will have to rewrite the shutter to function on a timer like the lifter. It is not as critical as the lifter, but it is not disengaging the relay which drives it quickly enough. It is like the switches are not being sensed quickly enough to stop the motor.

Looking at the console while the game is running, I can see that the switches are being detected, so I'm not sure why it is acting up.

Here's what's happening:

Press the R button to enter a game.
If the shutter is open, it will close.
Press red button to start the game
Shutter opens
Shoot 1st ball
Shutter closes
Press red button one or more times to start game
Shutter opens and closes a two times
Usually, it stays open.
Occasionally, it will close itself before shooting the 1st ball.

Frustrating.

Thank you!! Always very nice to hear that someone is enjoying my craziness. Especially enough to use their first post to say something so nice. Thank you.

Ryan is correct, I'll be bringing it to York in about 2 months! A bit of a hike from KS, though.

Spent a little bit of time this morning running the real bingos with Sophie. She always has a blast with Night Club (like her Dad). I got a couple of great hits on Caravan.

Last night I had some pretty good games on Bright Lights while troubleshooting the shutter and lifter.

I realize now that I didn't bother explaining WHY I rewrote them.

It was because I wired in trough switch #8 and trough switch #4 directly. I lost #4 in the last great wiring frenzy and #8 was intentionally disconnected to save switches.

Having #8 allows me to know absolutely 100% for sure when a ball is returned. This is important for an upcoming rare game that uses the ball return to step a feature (carry-over) more on that later.

The shutter issue just bugs me. I have no idea why it is not working as intended. There are only three times the shutter can move , and it just has to know 'am I open?' or 'am I closed?'. The reason it is getting a bit confused is a mystery to me.

Aside from this, I have thought of yet another way to approach the search issue: by utilizing the search index relay!

In the real games, race conditions are avoided by latching the search disc in place. By checking for the boolean search index relay's value, I should be able to avoid multiple concurrent searches finding the same winners. (maybe).

Needless to say, when these improvements are complete, they will be ported to all sixteen current games. I have lots of minor tweaks to make before York!

It works!!! Search index addition allows it to score in order correctly. Very exciting. Unfortunately, it seems to have prevented additional searches for an existing winner.

I'm able to test for the race condition by putting balls in 11 and 19, then shooting and catching two balls and simultaneously placing in 20 and 22. This should score 8, and does. But, if I put another ball in #4, it should score 40 and does not search. Just have to find the bug and should be all good!

Shutter still eludes me. I have to imagine it is some kind of induction issue or other funkiness. I'm thinking about moving the switch pair to the bottom of the motor stack - I've probably already mentioned that, but it will likely be important. I'll figure it out eventually!

Slow progress this weekend, been very busy, but hope to ramp up a bit this week. We shall see.

OK, figured out what was wrong, and it's infuriating.

If you get a vertical hit in reverse order, for some reason it will not find the winner if it is a four or five in a line.

Works fine if top to bottom. Oddly, the way it works should not allow this to happen. I thought I had this particular bug squashed a long while ago. :-/

I'll fix it - but have hit my wall for today. I've got the race condition fixed, so there's that.

Remaining bugs in Bright Lights:

1) Reverse-order vertical hits don't search for more than three in a row (for some reason).

2) Shutter is acting poorly. It works, but I want to make it just stay open when you first put in a coin/press the button.

3) Replay reset should turn the backglass gi off and on quickly. A simple animation, but I haven't done it yet, aside from leaving menu to enter game.

Menu bugs:

1) The menu/game are not exiting cleanly, and continue to run in the background when you return to menu or start a new game. I have to figure out how to cleanly exit. I am stopping the loop when I hit the key command to leave the game, but this doesn't actually fully stop it... I can tell easily if I leave the game with credits on it, then return later. The new #0 will be whatever I've left on the meter.

Overall bugs:

1) Extra balls and their integration with the lifter function. Still have to troubleshoot now that my extra trough switches are wired in.

Graphical bugs:

Did I mention that I've replaced all the artwork for the score/instruction displays with the correct resolution? I've also fixed a few graphical issues with Coney Island. Now, I have something to do for Palm Beach and everything should be good, graphically.

I have the occasional problem with the lifter, but this is due to the trough1 switch being a little funky. I've cleaned and adjusted, and cleaned the pin (then lightly lubricated it when it was still having a small amount of trouble moving). The ball lifter override does fix this when it happens. I'll adjust it some more before York since this will impact each game.

I changed my ball sensing functions to work off of 60ms of state change on the switches. Higher numbers (I was using 120ms) were too noticeable. Lower causes repeated switch hits.

A boolean is either true or false, 1 or 0. A perfect model for a relay, which is either on or off.

Lunchtime!

So... I have a list of holes which have a ball in them. For example, [9,10,16].

This is a winner, and to determine this, I check through all the positions of the search disc very quickly. When it finds these numbers in the dictionary of the search disc position, for example {9, 10:2, 16:3, etc} it takes the second number and uses that as the search relay.

If there are three or more in a row, it engages the search index, then scores via a delayed function until you have enough credits. Then, it releases the search index and allows the wipers to continue through their run.

So unfortunately, I am checking for 9,10,16 - that works. If I add the fourth number, it will not see it. I have absolutely no idea why...

All three in a row winners work.

Four and five work - most of the time. Something in my comparative function is not working properly.

Oh. man. I am a dummy. I had the search totally working - I remember now. I removed one of the for loops as a misguided attempt at streamlining. Thought it wasn't necessary, and, to be fair, it wasn't for the vast majority of cases. This is not one of them...

I'll put that back in place and we'll see what happens.

Gosh. Yep. That fixed it. Haha! Feel pretty silly now. That code I wrote on the airplane a couple months ago was actually correct.

Worked a bit on the shutter. It's working perfectly, except in the instance when the game drops balls. In that instance, it will get i/o bound (I think) loading a new sprite set x5-8 times (one for each ball on the field).

I'm thinking of just emptying the list of numbers and ignoring removal of numbers (based on hole switch deactivation). I had originally written it this way, but wanted the brief display of numbers like on a real game. I think I can let that go since it doesn't work well as written. Shutter is more important.

Ha! Works absolutely perfectly. Actually has a better animation than it did before, too... wow! Just replay reset animation to add.

Shutter demo

Bright Lights Replay reset animation

Lunchtime! I tested the changes to Broadway '51 and Atlantic City.

Broadway is buttoned up, but Atlantic City has a couple of issues - namely, the extra ball functionality. I'm sure if I crawl back through these posts I'll find where I said that before.

I have either the portioning way too tight, or I have an error somewhere that prevents the be unit from stepping.

I was able to find a bug - though it is very unlikely to occur during actual gameplay. If you manage to shoot a ball and land in a hole with a three-in-a-row score ticking up, you can confuse the lifter and allow for two balls to be placed in the shooter lane. I'll need to see how often that happens at the show to determine if I want to fix or not. Basically, if you have the replays ticking up, then land in another hole, it will think about displaying that change... and ignore some switch presses. I am avoiding making a stack of graphics ops by just making them fast.

I also realize that my rendering functions are speedy enough, but the images themselves are too large, since I'm using per-pixel alpha. I need to do some slicing and dicing on the more graphically complex games, or the ones with light shows to make them render more quickly. I'll play around with that. I think that this change may also prevent the above bug, so I'll probably experiment with Bright Lights (since it has fewer images to move around).

Right now I'm making a separate image for each number on the playfield - I can optimize this completely if I am rendering only the small circles of light required to light the numbers. Will either be much faster or take just as long with a six card game... I'll find out! Improved animations will be the last of the tweaking on each game, and I will need to think of a better way to animate each search - I'm ignoring the spotting disc position right now and just doing a really simple animation.

Lunchtime and nothing to show - last night I recorded a new episode (though I probably should have waited for tonight) of the podcast and worked a bit on aligning individual lit graphics with the backglass (my new, should have been my first, approach).

So here's an example of where being lazy/wanting a quick demo gets you in trouble down the road. I knew I would have to address this before York, but time is of the essence now!

I'm working on Atlantic City, currently, and will post a before/after video of the difference (assuming this does the trick). I don't see why it wouldn't be about 1000% faster, though. I was doing it in the most code-efficient, laziest way possible before - this is more verbose, but will be muuuuch faster to render.

Oh. Man. I have rewritten Atlantic City's animation routines... and it is really quite a crazy difference. I'll film a couple of short videos. It's incredible.

I thought I had a portioning problem in AC's Extra Ball routines... but it seems to be pretty good. This was a game where one of the units that is critical in the award of EB step-up was not documented.

I'll try it on real hardware. I think my animation loop was sooooo slooooow that it caused me to mis-remember how many button presses were hit.

Videos on the way!

Games with extra balls required a slight adjustment to my lifter routine: it is really a chicken and egg situation knowing if the eighth ball has been lifted. This is especially true if the ball is returned.

Using the 8th trough switch, my ball return method is rather good (if I do say so myself), emulating the older games with a ball count unit.

But identifying that the game has already lifted ball #8 is difficult. I can verify that yes, all trough switches are in their default states, and yes, there's a ball in the shooter Lane - but less clear is how to identify a ball being shot that has not yet passed the ball gate.

I've handled this by checking the position of the ball count unit - if the trough switches are open and a ball is in the shooter Lane - cancel the constant polling for balls to lift.

Because my new graphical method is so much faster, I can now potentially ditch the denounce time on each numbered switch, since I'm running into issues with the eb animation when a ball is in play. It only renders the full layer set twice during the animation, so sometimes you have to wait for a bit before your number appears.

Anyway, all that to say that Atlantic City with fully working extra balls is incredibly, amazingly fun. I just got my first five in a line on it - admittedly, I had three spotted numbers and my first extra ball, but I thought I'd post.

IMG_20160727_233736_(resized).jpg

(Still felt good).