(Topic ID: 243998)

What we've learned from our homebrews

By Gornkleschnitzer

4 years ago


Topic Heartbeat

Topic Stats

You

Linked Games

No games have been linked to this topic.

    Topic Gallery

    View topic image gallery

    image_127187.gif
    image_127195 (resized).jpg
    IMG_20190310_123551319 (resized).jpg
    IMG_20190510_200636176 (resized).jpg
    IMG_20190410_223505807_BURST001 (resized).jpg
    IMG_20170819_192223585 (resized).jpg
    IMG_20180607_221313262_LL (resized).jpg
    #1 4 years ago

    Well you guys, I promised I'd make this thread a while back (during the MGC if I recall), so here you go.

    This thread is meant for those of us who have already been through all or part of a homebrew pinball project, so we can all share our experiences and pitfalls for the rest of the community. I'll be adding more posts below as I think of things I dealt with in the process of building Undertale, and with the impressive stuff I've seen from the rest of you I'm sure this can turn into a very nice resource for future homebrewers.

    Keep in mind that every pinball machine is different, and every homebrew is unique in both design and construction choices. Some of the advice offered in this thread might not apply to you based on your decisions. For instance, most people are probably not crazy enough to go and build the entire cabinet, electronics, and software. If you do, however, much of my own experience might be of use to you. Mental help might be of use to you as well in that particular case!

    Since my project started from scratch, I will do the same on my posts for this thread. If you don't intend to go this extreme, focus on other people's posts.

    Rule number one. TAKE YOUR TIME.

    When you build a custom game, you're taking on a personal project. You're not on a professional team with a looming deadline. The only customer is you, and the way to please that customer is to build something you can be proud of. Don't rush your reference measurements (if you're copying an existing cabinet design). Try not to get antsy and assemble your cabinet before you've remembered to cut and route every necessary hole. If you have other activities going on, don't try to cram design or assembly in between them - wait until you really do have some free time.

    This is what happens when you try to rush cabinet construction. You get horrific squaring disasters like this. Don't be like this person.
    IMG_20180607_221313262_LL (resized).jpgIMG_20180607_221313262_LL (resized).jpg

    Don't be afraid to go back and cut just a little bit more off an edge, or even (after a few deep breaths) cut a new panel if a hole is misaligned or botched beyond repair. If, after all the work you've done, your playfield sits 1/4" lower in the rear left corner than on the other side... you're going to be sad.

    As a general rule, your lower cabinet needs cuts for the following components. Make sure these are all addressed or else you'll be filling an assembled cabinet with sawdust as you haphazardly cut the necessary holes with drills and saws at awkward angles. No, I definitely didn't do that at any point...
    -Lockdown bar reciever, mounted with carriage bolts. The method that I used was to assemble the full cabinet, unpainted, dragging the carriage bolts all the way in and letting them create their square holes in the process. I then disassembled the cabinet, painted and dressed it as desired, then reassembled. With the holes already prepared for the bolts, no vinyl decal damage occurred.
    IMG_20170819_192223585 (resized).jpgIMG_20170819_192223585 (resized).jpg

    -Coin door, mounted with carriage bolts.
    -Start button, typically recessed - drill a large hole with a forstner or spade bit, then drill the small hole all the way through, preferably with a sacrificial wood backer to prevent damage at the exit hole. Make sure the larger hole is deep enough that the start button will not stick out past the cabinet face. Otherwise it is very easy to accidentally trigger it if you lean against the machine.
    -Plunger, launch button, or clever game-specific launch handle. Bear in mind that if using a traditional plunger, the playfield mounting depth matters very much. Copy measurements and mount hardware, or if this is not an option, perhaps consider cutting this one hole after you've dropped your whitewood into the cabinet and had a chance to measure it.
    -Flipper buttons, recessed the same as the start button but probably with different sized holes.
    -Possibly additional buttons for magna-saves or other extended gameplay features.
    -Playfield hinge mounts. You might as well decide NOW how you plan on hinging or supporting your playfield, as your decision will affect where you can place playfield mechanisms and where you must have carriage bolt heads sticking through the sides of the cabinet. Make sure you fully understand (even if you're building your own hinge system) where the playfield will sit, how high it will swing up, the footprints of the brackets, and precisely where the holes need to be drilled in the side of the cabinet. If you're basing your cabinet design on an existing game, this is easy - copy it. If you're doing a playfield retheme, half the work is done. If you're like me and you built everything including the frickin hinges, measure it half a dozen times so you don't screw it up.
    -A hole for the power button/switch. Make sure it is in a sensible place; test it by FEEL before drilling a hole. Or do as I did, make a blind guess, and then cover that terribly positioned hole with a metal grate and drill a new hole in a better spot.
    -Bottom ventilation holes. Get them even and straight if you don't want to feel embarrassed when your machine is folded up on its back.
    IMG_20190410_223505807_BURST001 (resized).jpgIMG_20190410_223505807_BURST001 (resized).jpg

    -A large hole for the bass speaker. You may want to actually seek out the desired speaker ahead of time so you can measure it and cut the hole appropriately. Or get creative like Scott Danesi and build something custom to make it sound far better.
    -Leg bolt holes. A number of people have come up with interesting ways of drilling these nice and straight, and perhaps someone will chime in on this thread with their suggestions. Or do as I did, and eyeball it, ending up with leg bolts that are annoyingly tight.
    -Rear ventilation holes.
    -Skids. Unless you want the back of your game to look like you scraped it across a few concrete floors (which, most likely, will actually happen), affix wooden runners to the back of the cabinet. Do not attach plastic/rubber feet until cabinet has been painted.
    -Mains cord inlet hole. There are a few ways of doing this - a plug receptacle like you would find on a WPC game or a desktop computer, a large hole into a can that holds the plug out of harm's way during moving, or simply cutting a notch at the top of the cabinet for the cord to feed out. Parts can be found with a little shopping around at the usual suppliers.
    -Corner joints. If you're building a cabinet, you need to be able to join the corners cleanly. High quality router bits are available for the types of joints you need. They can be expensive. Buy them. You won't regret it, and you can use them for professional results in future projects too, even non-pinball-related.

    If you started by repurposing an existing cabinet, you probably need little more than a bit of reconditioning and painting. If you paid to have a cabinet built, you might need to drill a few game-specific holes as needed. Otherwise, you're in for a LOT of woodworking. But if you get a lot of satisfaction from having done an entire project yourself, it's worth it. And cheaper.

    I won't dump too much into one post. Backbox advice will come next/later. Anyone else is welcome to join in here - there are many ways of building a pin, and my way is only one of them!

    #2 4 years ago

    Agreed - don't give yourself a deadline. Also, be conscious of costs, but don't set a strict budget (things will go wrong and parts will have to be re-bought or re-made. Don't let it get you down).

    I re-purposed a cabinet and playfield, which saved probably a year of work and shaved at least $1000 off the supply budget.

    Most importantly, start with the end in mind. Before starting anything, visualize how you want the game to look, feel and sound. Write out lists and draw diagrams of how the game modes should work and progress. Sketch some artwork. Think about what you do and don't like on existing games.

    Lastly, before you begin, identify people who can help with electrical and programming issues and with artwork and printing. I could not have made Queen without the P-ROC and MPF online forums.

    #3 4 years ago
    Quoted from TopMoose:

    be conscious of costs, but don't set a strict budget

    100% this. I spent WAY too much building UT. Part of it was a stubborn desire to build it as traditionally as possible (which resulted in $200+ in bulbs and sockets alone when cheaper modern alternatives are available), and another factor was not really knowing all the parts I needed. I placed more than 60 orders, all told, with various suppliers to build this game, and nearly every single [censored] one of them carried a shipping charge. Looking at it in hindsight and realizing I probably spent $400 or more in F*&%ING FREIGHT COSTS makes me see a pretty major part of my project's expenses right there.

    Quoted from TopMoose:

    P-ROC and MPF

    These two places have been a huge asset to the homebrew pinball community. A scratch build requires:
    -Woodworking
    -Playfield design
    -Artwork
    -Assembly
    -Electronic design and manufacture
    -Computer programming
    -Audio design
    (and probably other fields I can't think of right now, shut up it's late)
    P-ROC's offerings essentially knock the fifth item right off that list, and MPF pulls a significant amount of weight off the sixth. I would have taken advantage of both, were I not a stubborn tinkerer and ex video game programmer. (Don't look me up...)

    Quoted from TopMoose:

    Most importantly, start with the end in mind.

    Quoted from TopMoose:

    Write out lists and draw diagrams of how the game modes should work and progress.

    This is another really good one. My layout has three prominent lamp inserts in the center of the playfield, and a green arrow insert pointing into the side passage. Guess what features they represent?

    C'mon, guess.

    NOTHING.

    I have ideas how to take advantage of them, but nothing ended up making it into 1.0 code. Perhaps the green "SAVE" could have been a red "JACKPOT" and the center inserts could have been dropped in favor of collected item status lights. Before diving into your final playfield cut, review all the features you've planned and take note if anything is incomplete. This might even save you some money if you decide to drop a feature that requires additional expense. For instance, I bought a side eject assembly that was originally intended to turn the Grillby scoop into a subway ball lock. When I realized I was going to need more solenoid drivers than I had, I dropped the lock idea - but not before I'd ordered the assembly.

    Speaking of features, make sure you know early on whether you want a simple game or a complex one. Complicated games take longer to build, require more programming, and typically cost more - however, I feel they have the advantage of being more interesting to play and, at least to me, more worth the time spent building them. 'Course, if you're re-theming, that decision has already been made for you.

    Now, as promised, the backbox. There are MANY ways to build a backbox, particularly because the backbox is a place where you can get creative with the woodworking and still have a game that fits reasonably well next to the rest of a lineup. To cite a notable reference: Look at literally anything the Pinball Amigos build!

    My first mistake on my own game: Rushing the construction. If you read the first post in this thread, this should not even be a surprise. All the noticeable flaws in Undertale's backbox could have been prevented by slowing down and measuring more carefully.

    If you're going original, the sky's the limit, but if you are big into a particular manufacturer's design choices, get some real measurements first and foremost. I liked the backbox style used on Bally games between around 1989 and early 1992 - display in translite cutout, speakers on top, T-molding on the oversized edges - and chose to build a game to match. It looked pretty nice sitting in my basement.

    And then I bought an EATPM, and suddenly my replica backbox didn't look so good anymore.
    IMG_20190510_200636176 (resized).jpgIMG_20190510_200636176 (resized).jpg

    The right thing to do would have been one of two choices. Either drop that design and build something in a style I already owned, or contact an actual owner of a game with the desired construction and politely ask for measurements.

    But again - if a replica isn't your goal, GO NUTS. Your backbox is the first eye catcher to a player, you do not have managers dictating your construction constraints, and you can build it in whatever size, shape, and color suits your personal tastes. I refer you to pinballrockstar a second time.

    Now here's the thing about the backbox. Depending on your choice of electronics, it may or may not be your most convenient place to store them. But if you decide you're not going to need much backbox wiring, do NOT skimp on wire access holes.

    Why, you may ask? Why dig a big hole if you're only running a few wires through it?

    Because it might not end up that way.

    Undertale was originally going to be driven by a Raspberry Pi until it proved underpowered (more on that later). It needed almost nothing in the backbox - the Pi itself, a tiny power cable to a cheapo audio amplifier, and half a dozen wires to drive some lights and the knocker. There was definitely no reason I would ever have to run more wires than that.

    I've seen enough hen--uh, homebrew - to know where this is going.
    IMG_20190310_123551319 (resized).jpgIMG_20190310_123551319 (resized).jpg

    Basically, the big lesson here is give yourself space! Cut large access holes, don't design playfield structures to a tighter tolerance than you can build, and make sure your electronic brains have MORE memory and input amperage than they need, not less.

    To follow the trend of the first post, here are the backbox holes you can expect to drill.
    -Wire access hole(s). Make them big enough.
    -Bolt holes. Drill them into the cabinet too - preferably at the same time, with the backbox positioned where you want it. You might as well mount the rear latch during this process as well, as it'll at least mark where the screws will go after you paint and reassemble.
    -Carriage bolt holes for attaching the sides. Even backboxes with routed corner joints tend to be reinforced with angle irons and carriage bolts for additional support, and really why not. Note that you can probably get a better price deal by purchasing a length of raw angle iron and cutting it for your four corners, rather than purchasing four separate shorter brackets. Plus you have control over where the bolts are placed.
    -Carriage bolt holes for attaching the hinges. Whether your backbox sits on pivoting strap hinges like a modern title, or door hinges on a neck like an 80s title, you'll want to make sure those hinges are mounted very securely.
    -If you intend to use an insert panel - and you should, as it makes your lighting much more efficient - you will want to mount it firmly. Carriage bolts through the left side of the backbox tend to be the go-to solution. Visualize and/or prototype your insert panel hinging system before final assembly to avoid unpleasant surprises related to binding hinges and smashed light bulbs. I got very lucky in this particular situation.
    -Your backbox should also have vents, generally near the top. Depending on how much processing power your game needs - and what climate it will be sitting in - you may need to install some fans in these vents. Plenty of hours of testing showed that Undertale did not require any fans besides the built-in power supply and CPU fans.

    There is probably more backbox advice to be offered, and I will post it when I think of it!

    #4 4 years ago
    Quoted from Gornkleschnitzer:

    Undertale was originally going to be driven by a Raspberry Pi until it proved underpowered

    I started with a RasPi B+ and quickly discovered that the processing power is way too slow for pinball. I ended up with an Asus Tinkerboard - same footprint, twice the power and speed.

    Quoted from Gornkleschnitzer:

    -Wire access hole(s). Make them big enough.

    Along the same lines, give yourself more cable than you think you need leading from the playfield to the backbox. 6' is barely enough - give it 8 or 12 to be safe. You don't want to keep yanking the connections out every time you lift the playfield. Being stingy with wire is one of my regrets on Queen.

    Quoted from TopMoose:

    Most importantly, start with the end in mind.

    Since my project used an existing playfield, I had to think up a use for every insert - I had to use all of them and couldn't drill any new ones. For example, my concept didn't include bonus scoring, so the bonus lights became a mode progress meter and the two bonus multiplier inserts became playfield scoring multiplier indicators. A row of three inserts on the right side are only used like runway lights, directing the player to lock the ball.

    #5 4 years ago

    Were you "rpi is too slow" people using mpf? I'm curious since otherwise I can't fathom a Pi being too slow. My last build used an 80MHz arm processor, I'd been assuming a Pi would have tons of extra oomf :/

    #6 4 years ago
    Quoted from zacaj:

    Were you "rpi is too slow" people using mpf? I'm curious since otherwise I can't fathom a Pi being too slow. My last build used an 80MHz arm processor, I'd been assuming a Pi would have tons of extra oomf :/

    You can totally run an MPF game on a RPi3. It might require some tuning of your game. Especially of your video and graphic assets (right compression algorithms and codecs).

    However, we strongly recommend you not to develop your game on a RPi (see: http://docs.missionpinball.org/en/dev/hardware/computer/index.html). You might save a few bucks that way but is simply not worth your additional time. Go with a stronger PC during develop. And if you are developing an on-off then go with that PC. If you want to build 100+ machines sure spend a few days tuning and ship it with a cheaper PC.

    #7 4 years ago
    Quoted from zacaj:

    I can't fathom a Pi being too slow

    Very fathomable for me. My RPi3B chugged pretty hard as soon as I tried to push full-screen sprite animation via the Allegro graphics library. No MPF in my project - the entire game code, multimedia aside, was written in raw C++ that ran smooth as silk on the desktop motherboard that eventually powered my game.

    Now, granted: I don't know for sure that the Pi was "too slow" for the job. If you could play a realtime 3D game, in software mode, on a PC from 1994, then one of the latest and greatest SBCs really ought to be able to draw static images at 30FPS.

    Given that people play HD video on a Pi 3, I do wonder if perhaps the Allegro library was simply not optimized for the hardware. The Pi runs on an ARM processor that is not directly compatible with binaries compiled for x86 or 64. I will be looking into other multimedia libraries for my next build, just in case - I have some past experience with the Irrlicht engine and will have to see if I can get better results. Shader support is nice too.

    Quoted from jabdoa:

    However, we strongly recommend you not to develop your game on a RPi

    Yes. My experience was that having the full power of a desktop mobo made the debugging and development process a LOT easier, so I fully agree with this statement. The Pi was also throwing me undervoltage warnings (possibly due to the three dev boards plugged into it), which might have contributed to the poor realtime performance.

    I will definitely be looking into a smaller controller for my next build; if I can get the desired graphics working on my Pi3 or a Tinkerboard, I'll go with that - $30 for a computer is a lot cheaper than $200+. Now that I've developed a working game program, I can port it over fairly easily.

    Quoted from TopMoose:

    You don't want to keep yanking the connections out every time you lift the playfield.

    Yup. I had no issues with this particular situation on my build, but here's a little addition - you also need wire clearance for backbox hinging. A standard WPC hinge will pull the backbox about a foot away from the cabinet. Your bb->cab wiring might fit nice and tight and tidy with the game assembled, but you might be in for a rude awakening when it comes time to move the game, and you lower the backbox and RIIIIIP.

    I had a very close call with backbox wire length the first time around, so when I had to pull my wires out and redo the game, I made sure to allow plenty of clearance the second time around.

    #8 4 years ago
    Quoted from zacaj:

    Were you "rpi is too slow" people using mpf? I'm curious since otherwise I can't fathom a Pi being too slow. My last build used an 80MHz arm processor, I'd been assuming a Pi would have tons of extra oomf :/

    I used MPF and P-ROC hardware and a Raspberry Pi 3 was too slow. Even without elaborate display graphics, there's a ton of stuff all going on at once - sounds stack up and a game can run a dozen or more sub-routines and timers all at the same time. It gets more complicated than you may suspect.

    #9 4 years ago
    Quoted from TopMoose:

    sounds stack up and a game can run a dozen or more sub-routines and timers all at the same time

    This is why the use of simplified programming tools (high level scripting languages and frameworks) gives me pause for concern. Sound cues, and the background functions that a pinball machine would reasonably use, are all fairly lightweight operations that a computer from 1986 had no problem with... think System 11. I don't know how efficient the popular homebrew programming tools are, but I wrote my entire game program from scratch in C++ to avoid any such question. Repeated benchmarking tests proved that my only bottleneck was the full-screen graphics. Had I found a more efficient graphics engine or dropped the HD monitor entirely, my RPi3B would have been more than adequate to run the game.

    The problem with avoiding a script library and writing code in raw C/C++ is that you have to literally reinvent the wheel and come up with your own framework. Right down to background timers and light blink patterns. So unless you get great pleasure from low-level software programming, a simple script-based engine and a more powerful computer is your preferred choice.

    #10 4 years ago
    Quoted from Gornkleschnitzer:

    I will definitely be looking into a smaller controller for my next build; if I can get the desired graphics working on my Pi3 or a Tinkerboard, I'll go with that - $30 for a computer is a lot cheaper than $200+

    Try the up board. It's about $100 and has about ten times the performance of a RPI3. In my experience a modern i5 is also about ten times faster than the up for MPF (i5 is about 100x fastee than the RPi3).

    Quoted from TopMoose:

    I used MPF and P-ROC hardware and a Raspberry Pi 3 was too slow.

    The P-Roc libpinproc unfortunately waits on usb synchronously which will block MPF. This is even much worse on the RPi3 because the USB controller is crappy. We refactored all that stuff to a separate thread for the P-Roc recently. Not sure if that is enough.

    Another problem on the RPi is slow disk IO because of the SD card. The up board has eMMC which is much faster in my experience. I really recommend that board. TNA also uses it.

    Quoted from Gornkleschnitzer:

    This is why the use of simplified programming tools (high level scripting languages and frameworks) gives me pause for concern.

    We can rewrite the hot paths in C or Rust. We already did that in the audio and video path. But for the general logic we prefer ease of development and memory safety. We figured that in MPF 0.52 we spend about 90% of our time writing log lines. Even when we did not write them to disk. Just the string processing. Putting some condition around log in hot section increased performance 20 fold.

    #11 4 years ago
    Quoted from jabdoa:

    $100 and has about ten times the performance of a RPI3.

    Ooh, I'm liking this. I will have to check it out.

    Thanks for the technical details on MPF! Seems to further reinforce the fact that it's a very well designed system. Didn't know that about the P-Roc library - I suppose that scores another point for writing a custom hardware interface.

    #12 4 years ago
    Quoted from Gornkleschnitzer:

    Ooh, I'm liking this. I will have to check it out.
    Didn't know that about the P-Roc library - I suppose that scores another point for writing a custom hardware interface.

    The library is very convenient and written in C. It it also open source. We could either change the behavior or rewrite it. We didn't because we did not want to loose the convenience. On normal PCs USB is fast enough. So this is an unfortunate mix. This is really nothing against the P-Roc in particular. It works very well and there are generally very few problems.

    #13 4 years ago
    Quoted from jabdoa:

    The library is very convenient and written in C. It it also open source. We could either change the behavior or rewrite it. We didn't because we did not want to loose the convenience. On normal PCs USB is fast enough. So this is an unfortunate mix. This is really nothing against the P-Roc in particular. It works very well and there are generally very few problems.

    Hey Jab! Curious, how often is MPF polling the hardware USB data?

    #14 4 years ago
    Quoted from Compy:

    Hey Jab! Curious, how often is MPF polling the hardware USB data?

    Configrable. By default at 100Hz. I found that the poll sometimes blocks several ms on the RPi. Especially if you also use other stuff on the USB such as network. That is part of the reason why we moved the libpinproc loop to another thread.

    9 months later
    #15 4 years ago

    Looking through a lot of the homebrew projects most seem to use lcd showing video assets. Has anyone made a homebrew and created their own custom dots? Is there even a program out there not under Sterns roof that could make dot animations?

    #16 4 years ago
    Quoted from jabdoa:

    Try the up board

    @jabdoa, does MPF support the Up board's GPIO ("Hat Header") https://up-board.org/up/specifications/

    #17 4 years ago
    Quoted from J85M:

    Has anyone made a homebrew and created their own custom dots? Is there even a program out there not under Sterns roof that could make dot animations?

    Off hand, I don't know if anyone has, but it's certainly possible. I wouldn't be surprised if MPF supports DMD output, I'm sure jabdoa can confirm or deny. For more advanced builders, there's reverse engineering the standard DMD board (plasma or XPin), or constructing a color DMD out of two of these panels:
    https://www.adafruit.com/product/2279

    I believe there are one or more pinball-ready displays made with this product already, if you don't care to design mounting and drive hardware for these panels from scratch.

    As far as animations, you don't need any particular special program to do it. A dot matrix animation is no more than a low-resolution (and usually low-color) string of bitmap images, usually combined with text that could likely be drawn just the same as on an LCD. Exactly how you would create your dot art, and how you would program it to be displayed, would vary based on your choice of computer and hardware.

    To me, an advantage to using a DMD instead of an LCD is because the far reduced number of pixels takes a lot less processing power, and your entire video output could be handled by a capable microcontroller. I was giving serious consideration to controlling my entire next game (Volcano Blast) entirely using microcontrollers and a DMD. Ended up going with PC/LCD instead due to the visual clarity and audio capabilities, but the bare metal option is not off the table yet as far as future projects.

    #18 4 years ago
    Quoted from MOSFET:

    jabdoa, does MPF support the Up board's GPIO ("Hat Header") https://up-board.org/up/specifications/

    Not yet. Do you have any particular hat in mind? There seem to be python bindings available so this should not be hard to do: https://wiki.up-community.org/RPi.GPIO

    Quoted from Gornkleschnitzer:

    Off hand, I don't know if anyone has, but it's certainly possible. I wouldn't be surprised if MPF supports DMD output, I'm sure jabdoa can confirm or deny. For more advanced builders, there's reverse engineering the standard DMD board (plasma or XPin), or constructing a color DMD out of two of these panels:
    https://www.adafruit.com/product/2279

    MPF supports monochrome and RGB color. DMDs. Several hardware platforms are supported: http://docs.missionpinball.org/en/dev/hardware/dmd_platforms.html. If you got something else we can also add support for that.

    #19 4 years ago
    Quoted from J85M:

    Looking through a lot of the homebrew projects most seem to use lcd showing video assets. Has anyone made a homebrew and created their own custom dots? Is there even a program out there not under Sterns roof that could make dot animations?

    My first homebrew used an RGB DMD and I created a lot of animations for it. I used a program called Aseprite and it's perfect for this type of thing. It's what game artists use to create pixel style art - which is basically what DMDs use. MPF works perfectly in getting animations to run on a DMD.

    The reason most people use LCDs now (including me for my current project) is that it's significantly easier to create content for an LCD than it is for a DMD. It's so much easier that I won't build a pin with a DMD ever again.

    For example, I had a mode where I wanted to set up nine asteroids on the DMD and have animations to show you shooting and blowing up each individual asteroid.

    Here are the seven frames I created in Aseprite to show the first asteroid exploding:

    image_127195 (resized).jpgimage_127195 (resized).jpg

    This took an hour or so to draw. Now here's the animation for that one asteroid (I had eight more to create after this):

    image_127187.gifimage_127187.gif

    The animations for that one mode took me hours of non-stop animating to create and they're over in a flash (if you're looking at the playfield you won't even see them).
    Now imagine doing a full game. It's a ridiculous amount of tedious work. That's why the few people who have made games with DMD tend to only use text - it's just a crazy amount of time needed to create good-looking DMD animations.

    #20 4 years ago
    Quoted from matthies:

    My first homebrew used an RGB DMD and I created a lot of animations for it. I used a program called Aseprite and it's perfect for this type of thing. It's what game artists use to create pixel style art - which is basically what DMDs use. MPF works perfectly in getting animations to run on a DMD.
    The reason most people use LCDs now (including me for my current project) is that it's significantly easier to create content for an LCD than it is for a DMD. It's so much easier that I won't build a pin with a DMD ever again.
    For example, I had a mode where I wanted to set up nine asteroids on the DMD and have animations to show you shooting and blowing up each individual asteroid.
    Here are the seven frames I created in Aseprite to show the first asteroid exploding:
    [quoted image]
    This took an hour or so to draw. Now here's the animation for that one asteroid (I had eight more to create after this):
    [quoted image]
    The animations for that one mode took me hours of non-stop animating to create and they're over in a flash (if you're looking at the playfield you won't even see them).
    Now imagine doing a full game. It's a ridiculous amount of tedious work. That's why the few people who have made games with DMD tend to only use text - it's just a crazy amount of time needed to create good-looking DMD animations.

    Awesome thanks for replying and giving such a detailed answered, probably one of the most interesting posts I’ve read on here in a long time. Also makes me appreciate the dots on TWD 100x more than I already did

    #21 4 years ago

    I know what you mean. I always liked the style of DMD animations, but I never appreciated how well done many of them are until I tried to make my own. Some of them (like TWD) are incredible in how they deal with the limited resolution.

    You don't realize how limited you are until you see a 128x32 pixel grid and try to fit something on to it. If anybody is considering making a pin with a DMD, load up a program like Aseprite, Photoshop, Paint, or anything else and create a 128x32 size image. Try to draw something or import any images you were thinking of using. I don't want to discourage anyone, but I think it will be eye-opening for most people.

    Take Undertale for example. At first glance, it seems like the perfect theme with the pixel art used. Those characters would look awesome lit up on a nice RGB DMD.
    Then you realize that most of the characters are over 32 pixels tall, so they wouldn't fit on a DMD. While you can easily resize them on an LCD to any size and make them look good, it doesn't work on a DMD. As I quickly found out, pixel art quickly falls apart when you try to scale it down even a tiny bit.

    #22 4 years ago
    Quoted from jabdoa:

    Not yet. Do you have any particular hat in mind? There seem to be python bindings available so this should not be hard to do: https://wiki.up-community.org/RPi.GPIO

    I'm designing [on paper so far] a custom controller PCB based on OPP that will interface with a Pi4 or Up board, and I'd like to use the GPIO pins for auxiliary inputs (switches) and outputs (lamp drivers and maybe extra coil drivers). For the Pi4 I'd use the MPF Raspberry Pi support ( http://docs.missionpinball.org/en/latest/hardware/rpi/index.html ). Since I'm not sure the Pi4 will have enough processing power for a homebrew machine I'm thinking about, I'm exploring using the oft-recommended Up board.

    #23 4 years ago

    Back on topic,
    I’ve learned that next time I’m using 8-32 for everything.

    My first build(still in progress) has so many different screws/bolts it’s a nightmare.

    All the mechs I designed I used metric bolts. (I personally think it’s time America goes metric)

    All the off the shelf parts are imperial.

    So there are all different lengths of m3, m4 , 6-32, 8-32 and 10-32.

    8-32 is strong enough for everything and not much bigger than 6-32.

    Damn I need wood screws too.
    I guess #8 wood screws also. F!

    #24 4 years ago

    We also use metric parts. Mostly M3. They fit everywhere. M4 might be better but they don't fit though most posts.

    Quoted from MOSFET:

    I'm designing [on paper so far] a custom controller PCB based on OPP that will interface with a Pi4 or Up board, and I'd like to use the GPIO pins for auxiliary inputs (switches) and outputs (lamp drivers and maybe extra coil drivers). For the Pi4 I'd use the MPF Raspberry Pi support ( http://docs.missionpinball.org/en/latest/hardware/rpi/index.html ). Since I'm not sure the Pi4 will have enough processing power for a homebrew machine I'm thinking about, I'm exploring using the oft-recommended Up board.

    That should be possible unless you want hardware rules or very precise timings. I wound not use them for addional coils. They works better for servos, steppers, serial leds and similar stuffs. Inputs are probably also better for digital stuff than switches unless you add protection to them.

    1 week later
    #25 4 years ago
    Quoted from J85M:

    Awesome thanks for replying and giving such a detailed answered, probably one of the most interesting posts I’ve read on here in a long time. Also makes me appreciate the dots on TWD 100x more than I already did

    The reason I'm using an LCD rather than a DMD is just for amount of info I can convey. I've got a real-time troubleshooting window that shows the state of what every insert, coil, and switch should be according to software, graphically shown in a similar orientation to the playfield, which is much easier than it would be on a DMD. It's also easier to spit up point values and alerts onto the screen without having to do too much prioritizing. I can clean it up later, but it's been a huge help in troubleshooting. My graphics are just a flat image background and some static images that pop up for mode select, etc.

    If you're looking at animation, I haven't been through it but some may not be too much more difficult on a DMD if you're using existing IP. I've heard part of the reason they were able to use so many movie animations for Data East Star Wars (and others, I assume) is that a DMD-digitized version of movie animations are no longer accurate enough representations to need the permission to use actors' likeness.

    Creating my own animation is way past my skill set regardless of medium

    #26 4 years ago
    Quoted from etlandfill:

    If you're looking at animation, I haven't been through it but some may not be too much more difficult on a DMD if you're using existing IP. I've heard part of the reason they were able to use so many movie animations for Data East Star Wars (and others, I assume) is that a DMD-digitized version of movie animations are no longer accurate enough representations to need the permission to use actors' likeness.

    Data East Star Wars may not be what you're thinking of because those animations are all hand-drawn. They may be based on movie clips, but they would have taken just as long to hand draw as an original IP - pixel by pixel.

    A better example of using a DMD with movie clips would be GOT because that does use the video clips from the show without having to redraw them. It's still a lot more work than it might seem by looking at the animations because scaling a video down to such a low resolution will turn into a mess unless you know what you're doing.

    So if somebody is considering using a DMD with an existing IP, they'll end up with something like GOT (fairly easy to do) rather than Data East Star Wars (just as hard as hand-drawn original IP).

    #27 4 years ago
    Quoted from matthies:

    Data East Star Wars may not be what you're thinking of because those animations are all hand-drawn. They may be based on movie clips, but they would have taken just as long to hand draw as an original IP - pixel by pixel.
    A better example of using a DMD with movie clips would be GOT because that does use the video clips from the show without having to redraw them. It's still a lot more work than it might seem by looking at the animations because scaling a video down to such a low resolution will turn into a mess unless you know what you're doing.
    So if somebody is considering using a DMD with an existing IP, they'll end up with something like GOT (fairly easy to do) rather than Data East Star Wars (just as hard as hand-drawn original IP).

    Hmm, interesting. I know it was DESW that I was thinking of at least in the context of not having to pay royalties on the images because they were so grainy, but maybe part of it was that they hand drew them.

    I think the difference in quality is part of why I forget sometimes that GoT and some of these other modern-ish games were still DMD. I assume the resolution improved over the years too? Did the later DMDs allow for grayscale also? This lock down is messing with my memory lol

    #28 4 years ago
    Quoted from etlandfill:

    Hmm, interesting. I know it was DESW that I was thinking of at least in the context of not having to pay royalties on the images because they were so grainy, but maybe part of it was that they hand drew them.
    I think the difference in quality is part of why I forget sometimes that GoT and some of these other modern-ish games were still DMD. I assume the resolution improved over the years too? Did the later DMDs allow for grayscale also? This lock down is messing with my memory lol

    Resolution has stayed the same. 128x32. Not sure how many shades of Grey the data east driver board was capable of.

    #29 4 years ago
    Quoted from zacaj:

    Resolution has stayed the same. 128x32. Not sure how many shades of Grey the data east driver board was capable of.

    Probably 4 shades, same as williams dmd boards (off, 1/4th, 1/2, 3/4 and full power).

    I believe P-Roc allows for 16 shades in theory, but only up to 5 is useful, if you try to use more than 5, the shades get too close to eachother.

    I found info that Sterns system (probably what GoT uses) allows up to 12 shades. Not sure how many are actually used.

    #30 4 years ago
    Quoted from aeneas:

    Probably 3 shades, same as williams dmd boards (4 states: off, 1/4th, 1/2, 3/4 and full power).

    Do you know if that's the same on WPC89 and WPC95 with the new AV board?

    #31 4 years ago
    Quoted from zacaj:

    Do you know if that's the same on WPC89 and WPC95 with the new AV board?

    http://bcd.github.io/freewpc/Dot_002dMatrix-Performance.html#Dot_002dMatrix-Performance

    There's a lot of good information in the freewpc docs.

    Reply

    Wanna join the discussion? Please sign in to reply to this topic.

    Hey there! Welcome to Pinside!

    Donate to Pinside

    Great to see you're enjoying Pinside! Did you know Pinside is able to run without any 3rd-party banners or ads, thanks to the support from our visitors? Please consider a donation to Pinside and get anext to your username to show for it! Or better yet, subscribe to Pinside+!


    This page was printed from https://pinside.com/pinball/forum/topic/what-we-ve-learned-from-our-homebrews?hl=matthies and we tried optimising it for printing. Some page elements may have been deliberately hidden.

    Scan the QR code on the left to jump to the URL this document was printed from.