Let's figure out the minimum parts to build a whitewood


By Aurich

2 years ago


Stats

  • 1,817 posts
  • 110 Pinsiders participating
  • Latest reply 2 months ago by toyotaboy
  • Topic is favorited by 119 Pinsiders

Find

Search this topic for posts matching certain words or written by a specific Pinsider. Or both!




Linked Games

No games have been linked to this topic.



    Topic Gallery

    There have been 299 images uploaded to this topic. (View topic image gallery).

    20170711_204158 (resized).jpg
    20170711_204145 (resized).jpg
    20170711_204208 (resized).jpg
    playfield doodle.jpg
    IMG_0619 (resized).JPG
    IMG_0415 (resized).JPG
    IMG_0407 (resized).JPG
    IMG_0399 (resized).JPG
    IMG_9575 (resized).JPG
    gunclub (resized).png
    IMG_9498 (resized).JPG
    IMG_9492 (resized).JPG
    IMG_9502 (resized).JPG
    IMG_9499 (resized).JPG
    IMG_9413 (resized).JPG
    IMG_20161111_140114262 (resized).jpg


    There are 1817 posts in topic. You are on page 24 of 37.
    #1151 2 years ago

    I think Zitt used hall effect sensors in the mirror universe pin.

    #1152 2 years ago
    Quoted from BloodyCactus:

    how close does the ball get before detection?

    4-29mm depending on which sensor you go with
    http://www.omega.com/pptst/iPROX.html

    #1153 2 years ago
    Quoted from BloodyCactus:

    i wonder about their accuracy with more than one ball in proximity. how close does the ball get before detection? can it detect really fast ball movement? their magnetic, there is lots of metal on a pin, and lots of interference from the coils and magnets.

    Every CNC mill uses Hall Effect Sensors at VERY high speeds, to protect very expensive equipment.

    A common value is 1 mm although you can get them in .1mm.

    #1154 2 years ago

    Added Williams and DE/SEGA/Stern inlanes. Unfortunately they are Solidworks 2014, I can't run 2013 since I upgraded to 64-bit windows.
    http://pinballmakers.com/wiki/index.php/Files_Section#3D_Templates

    1 week later
    #1155 1 year ago

    Possible interesting in this thread too for a homebuild playfield. In the post https://pinside.com/pinball/forum/topic/medieval-castle/page/4#post-2649187 pinballwil uses an interesting way to coat the play field in his medieval caste pinball. He is using glass epoxy/photo epoxy to coat the playfield instead of a clearcoat. This is a self leveling clear component that only needs a single layer. You don't even need a spay gun!

    Has anyone tried this compound?

    #1156 1 year ago
    Quoted from DDDwingmaster:

    He is using glass epoxy/photo epoxy to coat the playfield instead of a clearcoat.

    I'll be very interested to see how it holds up.

    2 weeks later
    #1157 1 year ago

    Maybe I should start a new thread, but if people are still following this I'd love to get thoughts on embedded computers. I took a break from working on Alien yesterday to have a Sunday off, and spent pretty much the whole day reading the Mission Pinball Framework docs. Killer work there, it's a really exciting project, but also really well documented. Not working great in OS X at the moment, but a fix is coming, and I'm not free to dive in right now anyways.

    But I did think it would be fun to start looking at hardware options.

    Now it's easy to just get a little $300 PC to power things. Combine it with FAST or P-Roc and call it a day. But that feels kind of lame. It would be way cooler to design and build a machine that was actually able to be produced in a realistic way. You murder your BOM going with a full PC over embedded. Even if you never make more than one it feels better to plan from the start for the possibilities.

    It seems like the bottleneck is graphics. And that's going to really depend on what kind of graphics you want to do I guess. I'm thinking if you're doing heavy 3D or anything like that you're on your own in PC land. But most people would like to be able to play movie clips and show PNGs and stuff like that on an LCD screen. Let's say 1080p as a target.

    I'm doing my homework now, but I've never paid more than passing attention to the embedded space. The easy popular options are a Beagle Bone Black, or a Raspberry Pi 2, anyone have thoughts or experience on them, or other alternatives?

    IIRC the RP2 is around $35, and the BBB is more like $50.

    #1158 1 year ago
    Quoted from Aurich:

    I'm doing my homework now, but I've never paid more than passing attention to the embedded space. The easy popular options are a Beagle Bone Black, or a Raspberry Pi 2, anyone have thoughts or experience on them, or other alternatives?

    IIRC the RP2 is around $35, and the BBB is more like $50.

    raspberry pi2 model A is only $20 and I believe the same processor as B (just less internal memory, only one usb port, and lack of wifi). Both will easily do HD 1080p video (1920 x 1080) and probably all the 3d you can throw at it (it'll run Quake 3 at 60fps):
    » YouTube video

    The fact that mission pinball supports linux is awesome, it keeps it cheap and low powered (raspberry pi 2 only consumes a max of 130mah at 5v).

    #1159 1 year ago

    Did we ever find out the minimum parts to build a whitewood?

    #1160 1 year ago
    Quoted from Captain_Kirk:

    Did we ever find out the minimum parts to build a whitewood?

    The answer is: 42, or 3 licks
    tootsie-pop-owl[1].jpg

    #1161 1 year ago
    Quoted from toyotaboy:

    just less internal memory

    It's that less memory that makes me wonder about things. Maybe not a huge deal if you load and unload in assets to memory as part of starting and ending modes.

    #1162 1 year ago

    I have experience with many of these small form-factor computers. (I'm the guy writing the Mission Pinball Framework.) They're not technically embedded PCs since they are just regular computers with a regular file system that run regular Linux. They just happen to be very small and run off of flash memory.

    Raspberry Pi 1 is too slow for anything we're doing.

    Raspberry Pi 2 is fantastic. Quad core which is huge (MPF is multi-process so it can make use of multiple cores--1 for game logic & hardware control, and 1 for graphics/sound/media/DMD/LCD). Plus it has 1GB RAM which is nice because we can pre-load a lot more stuff in memory which just makes everything faster. Downside is it's proprietary (which may or may not be an issue, depending on whom you ask).

    Beagle Bone Black Rev C. This is fine for DMD-based games and older (128x32 pixels, 8-bit/1-byte per pixel only). No way it works with LCD-based backboxes. (Even just having the GUI running slows MPF down to about 7 ticks per sec. We use it with MPF by running without a GUI.) It's only single core and it only has 512MB RAM. Plus is the hardware is open and you can get them built yourself if you wanted to go into production.

    ODROID. Also seems nice. This is what we used in Big Shot last year at expo. Ordering it is tricky because it only comes direct from Korea. Not too much support. We had weird issues with our OSC interface which disappeared when we switched hardware.

    At this point, all things considered, it seems like the RPi2 is the way to go, but running Ubuntu, not Raspbian. Several MPF users are running this, and even with LCD graphics it seems to hold its own. (And when we move MPF to SDL2 in a few months, we expect better performance.)

    Obviously this is a moving target since this market changes every few months.

    EDIT: RPi2 will also be able to run Windows 10 which is nice for "non-Linux" people. Haven't tried that yet though. (Actually I don't even know if it's available.) We'll get to that at some point though in the next few months and I'll post back here when we do.

    #1163 1 year ago
    Quoted from BrianMadden:

    EDIT: RPi2 will also be able to run Windows 10 which is nice for "non-Linux" people. Haven't tried that yet though. (Actually I don't even know if it's available.) We'll get to that at some point though in the next few months and I'll post back here when we do.

    I was excited about this too, and I gave it a go. It's not a windows desktop, it's basically an IoT shell for the Pi 2.

    I get what they were going for, but it fell a little short of my hopes.

    #1164 1 year ago
    Quoted from BrianMadden:

    Raspberry Pi 2 is fantastic. Quad core which is huge (MPF is multi-process so it can make use of multiple cores--1 for game logic & hardware control, and 1 for graphics/sound/media/DMD/LCD). Plus it has 1GB RAM which is nice because we can pre-load a lot more stuff in memory which just makes everything faster. Downside is it's proprietary (which may or may not be an issue, depending on whom you ask).

    Another plus, is that RP2 is cheaper than the BBB. Not a big deal for one-offs, but nice if you're trying to see what kind of a BOM you can actually hit.

    I'm very curious about what the realistic numbers look like for hobby machines. If you can get your PC for $20 less then that's $20 shaved off.

    Quoted from BrianMadden:

    (I'm the guy writing the Mission Pinball Framework.)

    If there are people in this thread who don't know this then I suggest they spend a day here https://missionpinball.com !

    #1165 1 year ago
    Quoted from Wolfmarsh:

    I was excited about this too, and I gave it a go. It's not a windows desktop, it's basically an IoT shell for the Pi 2.
    I get what they were going for, but it fell a little short of my hopes.

    And you need a Windows 10 PC to even be able to set it up, right?

    #1166 1 year ago

    Im using RPI2, not for MPF, I'm not a python guy, but I am using SDL2/OpenGL for driving graphics to LCD and also for mp3/wav decoding to the 2.1ch amp.

    RPI2 is very nice, lacks a bit in GPIO but otherwise its all there in cpu/gpu for driving LCD just fine.

    the problem with other things like ODroid, they are less supported so getting things like accelerated framebuffers and such for LCD is a real pain because its all super closed samsung hardware compared to the binary blob for RPI2.

    the other cool thing, RPI2 SDL does not need X/Gui to load before you can use it, odroid boot into full X/GTK server etc if you want graphics output.

    there are other things like underperforming banana pi, pcduino, A10 allwinner stuff (a very poor arm cpu), hummingboard etc.

    hummingboard was interesting before rpi2 showed up, but they all lack the support the PI has.

    #1167 1 year ago
    Quoted from BloodyCactus:

    RPI2 is very nice, lacks a bit in GPIO but otherwise its all there in cpu/gpu for driving LCD just fine.

    Just curious, what would you use a more versatile GPIO for in a pinball? I'm ignorant when it comes to this topic, but I can't really think of a need for that kind of general purpose connector.

    #1168 1 year ago
    Quoted from BloodyCactus:

    Im using RPI2, not for MPF, I'm not a python guy, but I am using SDL2/OpenGL for driving graphics to LCD and also for mp3/wav decoding to the 2.1ch amp.
    RPI2 is very nice, lacks a bit in GPIO but otherwise its all there in cpu/gpu for driving LCD just fine.
    the problem with other things like ODroid, they are less supported so getting things like accelerated framebuffers and such for LCD is a real pain because its all super closed samsung hardware compared to the binary blob for RPI2.
    the other cool thing, RPI2 SDL does not need X/Gui to load before you can use it, odroid boot into full X/GTK server etc if you want graphics output.
    there are other things like underperforming banana pi, pcduino, A10 allwinner stuff (a very poor arm cpu), hummingboard etc.
    hummingboard was interesting before rpi2 showed up, but they all lack the support the PI has.

    Spot on.

    Fwiw, I've successfully run PyProcGameHD, which is SDL2 accelerated, on the RPi2 (without loading X first) and it runs quite well.

    The RPi2 is a really impressive little thing.

    #1169 1 year ago
    Quoted from Mocean:

    The RPi2 is a really impressive little thing.

    Sounds like this is the consensus winner for the time being.

    #1170 1 year ago

    so i read the 5 or 6 pages, sorry if this was covered already, but did anyone end up doing a whitewood kit like what was suggested in the beginning of the thread?

    #1171 1 year ago
    Quoted from Aurich:

    Sounds like this is the consensus winner for the time being.

    Typically you can grab one for $30 at microcenter. What's not to love?

    #1172 1 year ago
    Quoted from InfiniteLives:

    so i read the 5 or 6 pages, sorry if this was covered already, but did anyone end up doing a whitewood kit like what was suggested in the beginning of the thread?

    There have been offers, if you really want it I'm sure someone will do it for you, but nothing where the ground work has been done by someone already.

    Quoted from Mocean:

    Typically you can grab one for $30 at microcenter. What's not to love?

    Yeah, even the people who are "gouging" on the price have it at like $40. I almost just grabbed one for that price from Amazon just now, but I really don't need it yet. Need to get more done on Alien before I'm free to play. I'm building an equipment list though.

    #1173 1 year ago
    Quoted from Aurich:

    Just curious, what would you use a more versatile GPIO for in a pinball? I'm ignorant when it comes to this topic, but I can't really think of a need for that kind of general purpose connector.

    You won't need to use the GPIO for pinball, the timing is hard to control anyway. If you are using FAST or PROC you just connect them via USB and off you go.

    My FAST Pinball Playground software runs on Pi 2 with no problems.

    #1174 1 year ago

    yeah I'm not using GPIO on the RPI2, I'm using its UART (ok im using its RX/TX io pins) to do RS485 communications. The PI2 GPIO is too slow to reliable do stuff like read a bunch of input switch chips and stuff (when I compare it to using a real uc like PIC32).

    #1175 1 year ago
    Quoted from BloodyCactus:

    yeah I'm not using GPIO on the RPI2, I'm using its UART (ok im using its RX/TX io pins) to do RS485 communications. The PI2 GPIO is too slow to reliable do stuff like read a bunch of input switch chips and stuff (when I compare it to using a real uc like PIC32).

    Ah yeah, well I'd just pair it up with FAST hardware, so no need for that kind of direct hardware performance.

    #1176 1 year ago
    Quoted from Aurich:

    Ah yeah, well I'd just pair it up with FAST hardware, so no need for that kind of direct hardware performance.

    When you get rolling on your stuff, there's a decent number of us that can help support you now too.

    By the time you start, I'll probably have released the FAST Playground for general use. Just got some tidying up I want to do, and I need to add support for some of the other boards I don't have access to yet.

    All that has to wait until after expo though. I've seen some of the stuff that the FAST crew is bringing to Expo, and I think you all will like it. The games are really moving along, and the MPF is growing up before our eyes. It's an exciting time for sure!

    #1177 1 year ago
    Quoted from Wolfmarsh:

    By the time you start, I'll probably have released the FAST Playground for general use. Just got some tidying up I want to do, and I need to add support for some of the other boards I don't have access to yet.

    I'm a ways off from having the free time I would need to really start getting my hands dirty, Alien has a lot of work left, and I'm starting a redesign of Ars Technica that's a pretty major project too.

    But as cool as Alien is it's someone else's baby, both in terms of Heighway and Fox, and my brain just gets cranky when I can't plot out my own stuff, so I'm kinda back burner cranking up some things. I haven't done any programming in a while, and I've never used Python, so might as well start ramping up.

    What is the Playground you're working on? I looked back through this thread and didn't see you referencing it before.

    #1178 1 year ago

    The Playground is just a piece of software that knows how to talk to the FAST hardware. It gives you a simple interface to do things like see switches triggering, set lights certain colors, and fire solenoids. It has some other features too, but the idea is to get you something that you can immediately tinker with, without having to set anything up. It even auto detects your FAST hardware for you.

    I think I posted an early screenshot in one of the FAST threads, but I use it constantly for sending raw commands or fiddling with the hardware.

    I've also begun the discovery process on a config wizard for MPF. The MPF team has given me some good suggestions of features to start with, but that's at least a month or two away from seeing the light of day.

    #1179 1 year ago
    Quoted from InfiniteLives:

    so i read the 5 or 6 pages, sorry if this was covered already, but did anyone end up doing a whitewood kit like what was suggested in the beginning of the thread?

    one issue is there are so many parts options that can determine the lower third design / layout and then affect the middle and top third - ball flow / shots.

    check out page 23 of a graph that I put together to try and help others for the lower third with standard off the shelf parts

    also check out Pinball Life as they have a homebrew section and one specifically for playfield assemblies
    http://www.pinballlife.com/index.php?p=catalog&parent=394&pg=1

    #1180 1 year ago
    Quoted from Wolfmarsh:

    The Playground is just a piece of software that knows how to talk to the FAST hardware. It gives you a simple interface to do things like see switches triggering, set lights certain colors, and fire solenoids. It has some other features too, but the idea is to get you something that you can immediately tinker with, without having to set anything up. It even auto detects your FAST hardware for you.
    I think I posted an early screenshot in one of the FAST threads, but I use it constantly for sending raw commands or fiddling with the hardware.
    I've also begun the discovery process on a config wizard for MPF. The MPF team has given me some good suggestions of features to start with, but that's at least a month or two away from seeing the light of day.

    So the FAST Playground is in addition to MPF? Or is it an alternative, but just for saying 'fire solenoid 4' for testing purposes? A config wizard for MPF would be nice as I'm a mechanical person and could probably get a basic config set up, but entering values for number of lights/switches/coils would be one less thing for me to mess up.

    #1181 1 year ago

    Has anyone who is talking about the RPi2 actually used in a fully running game and monitored for both loop rate and frame rates to really see if it is keeping up during actual game play? Looking at 'average loop rate', can be very deceiving, you may get a loop rate of 100 but that does not mean there are times where it is significantly slower and creating latency. In some case latency won't be an issue, but in some cases it can really effect game play. If the video is not keeping up, that can create oddness as well, but is certainly less critical.

    So, who has a game fully running on RPI2 with an LCD? What hardware setup (P-roc, fast, other?), what size LCD size (using a dot overlay?), what framework (pyprocgame, mpf (what method/engine for graphics?), VGApyprocgame, HD(SDL)pyprocgame, other?) and how have you measured/validated performance?

    #1182 1 year ago
    Quoted from desertT1:

    So the FAST Playground is in addition to MPF? Or is it an alternative, but just for saying 'fire solenoid 4' for testing purposes? A config wizard for MPF would be nice as I'm a mechanical person and could probably get a basic config set up, but entering values for number of lights/switches/coils would be one less thing for me to mess up.

    It's in addition to MPF. The playground is just a quick way for someone who received their hardware to play with it out of the box, without setting anything game related up. It's just a supporting tool to use when building a pinball game based on FAST hardware. The playground only works with FAST stuff.

    I find it helpful to fire up the playground and just send test stuff or test my wiring without getting near game code.

    The config wizard is the complement to MPF that will hopefully give people who don't want to mess with the actual config files a more visual way to set up their game. It won't be capable of creating complex game logic, but people who want to go that far will need to learn some coding anyway. Since the config wizard is a complement to the MPF, it will work on any platform that the MPF supports. (PROC and FAST)

    #1183 1 year ago
    Quoted from Wolfmarsh:

    It's in addition to MPF. The playground is just a quick way for someone who received their hardware to play with it out of the box, without setting anything game related up. It's just a supporting tool to use when building a pinball game based on FAST hardware. The playground only works with FAST stuff.
    I find it helpful to fire up the playground and just send test stuff or test my wiring without getting near game code.
    The config wizard is the complement to MPF that will hopefully give people who don't want to mess with the actual config files a more visual way to set up their game. It won't be capable of creating complex game logic, but people who want to go that far will need to learn some coding anyway. Since the config wizard is a complement to the MPF, it will work on any platform that the MPF supports. (PROC and FAST)

    While it won't happen til I finish tiling the house, I plan on using MPF/FAST for my build. Both of the things you are working on are appreciated, in advance.

    #1184 1 year ago

    What kind of loop rate is considered high enough?

    #1185 1 year ago
    Quoted from Aurich:

    What kind of loop rate is considered high enough?

    Obviously the higher the better. The main issue with looking at loop rate, is that it is an average, and will not tell you about periods of time the game is not keeping up. Unfortunately, the only way to get a real accurate assessment of that is to add logging to look for any loop that is longer than desired, so as to to highlight areas in your code that may not be optimal. In my experience, a loop rate under 75, will definitely have windows of latency. If you are over 100, and the code is relatively clean, then I would not expect to see much issue, but I suspect there will be occasionally latency. I'm more comfortable with rates over 200, but again, that is an average.

    I know MOceans work on the pyprocgameSDL platform has dramatically changed the speed of the original framework, and resulted in loop rates in excess of 3000 on my mac as well as on a low end pentium system (linux) and over 300 on a system running a low end Atom processor. This is running will a full color 900x1800 resolution LCD (actual graphics are 450x900 and then doubled up to display size).

    Hopefully he will pop in on this thread and give us some more stats on what he has seen with an RPI2, which he posted earlier he had tried. Sounds like it would likely perform similarly to the Atom.

    I did a post about this in the pinballcontrollers forum (http://www.pinballcontrollers.com/forum/index.php?topic=1453.msg13278#msg13278 ), but you might find this excerpt interesting . . .

    "Let me play Mr. Whoopee for a minute (not sure how many of you know that reference), but lets assume a pinball, when going around an orbit, is moving at 15 MPH, if my math is right (a big IF), that is 22 feet per second or 244 inches per second, lets round that up to 250/second, which translates to moving .25 inch per millisecond. If you have a switch triggering a diverter that is three inches away from a switch, you need a response time that is faster than 12 milliseconds, which is a loop rate of 83hz. So, if your average loop rate is 100 you would be okay, except that clearly some loops are taking longer since that is an average, which means this diverter could be late if the loops in question are slower then average."

    The P-roc (not sure about Fast) allows you to map switches directly to solenoids in the p-roc itself (via command in your code), which eliminates any latency issues relative to flippers, pops and slings (assuming you properly enable and disable those mappings as needed). Use of those mappings may be required in other aspects of a game to insure no issues from latency, however, that is not always feasible to do, sometimes you need on the fly logic to decide, for example, to raise or lower a post or energize a magnet based on a switch hit. Obviously even a few milliseconds of latency can result in the post or magnet not activating in time to catch the ball.

    #1186 1 year ago

    To add to what Rosh is saying, picking an ideal "loop rate" is tough to do because it means different things in different scenarios. Plus one of the problems with just looping your code balls out as fast as it goes is that you peg the CPU at 100% and it gets hot and you can't do anything else. (Not that you'd want it to do anything else while you were playing pinball, but even things like saving audit data could take 10 seconds when one thread is pegged and not yielding because it's looping as fast as it can.)

    There's a difference between the "loop rate" of your main game "tick" and the loop rate that hardware is polled. The main game loop rate doesn't have to be crazy high to have a great player experience. True, you need a damn near immediate response for fast moving balls with diverters near switches, but as Rosh says, that's all handled by the pinball controllers (true for FAST and P-ROC), so your game can have a loop rate of 5hz and you still won't miss the diverter.

    For example, in MPF we set the main "timer tick" to 30hz by default. That means the machine is waking up every 33ms, running through its loop (updating the display, dealing with timers, etc.). So the code wakes up, does it's thing, and if it takes 10ms to do that, then it goes back to sleep for 23ms.

    While it's "sleeping" it will periodically wake up (configurable, set to 1ms by default) just to poll the hardware controller for switch changes (both P-ROC and FAST have to be polled), and if any changes occur, those are processed immediately (including anything tied to them.. events, effects, score, lights, sounds, etc.). So that's sort of done "out of band" of the main machine looping tick.

    Same for timers. (Say you have something you want to happen every 15ms.) Those timers wake up when they're supposed to wake up, outside of the main game loop tick.

    I've played with taking the switch polling sleeping time up to 2, 3, 4, 5ms.. and of course I can't tell a difference because I'm a human. (Again this assumes that slings, pops, flippers, diverters, etc. are written as hardware rules to the pinball controller.) I've also played with taking the main loop rate down from 30hz to 25, 20.. I even went down to 5. The only effect is that drops the display fps down, but it doesn't effect game play otherwise.

    As Rosh said, you can measure whether the loop is lagging, but that requires instrumenting the loop itself which can effect performance. (Though not in a way that's measurable as far as I can tell.) In MPF we have two loop options. The default one which is bare bones, not logged, and then there's an "instrumented loop" which watches for that sleeping time period and will log warnings if the main timer-tick loop is running longer that the time allotted via the configured HZ rate. (Basically if it comes back from the main loop and it's already past the time to do the next loop, it logs it.) Though honestly that's not needed because you can just look at the CPU utilization of the Python process. On my Windows VM on my laptop with a 30Hz main loop and a hardware polling sleep time of 1ms, the MPF game engine takes about 12% of the CPU core. (That's another advantage of not running balls out as fast as you can. In the balls out case, the Python process will always be super high. With the sleeping and polling every 1ms approach, the CPU utilization correlates to the actual percentage of time it's busy, so you know whether your hw can handle it just by looking at the CPU utilization.

    The other key about getting good performance on the the RPi2 which I can't stress enough is that it has four cores, which means if you do run into performance issues but you only have a single process pinball engine, then you either have to get faster hardware or re-architect your code into multiple processes. (I'm not saying that all pinball engines have to be multi-process. I'm just saying that if you do run into CPU bottlenecks and you have a multi-core machine, switching to multiple processes is like a "free" hardware upgrade.

    That's what we did in MPF for this exact reason. The MPF game engine is a separate OS process from the thing we call the "media controller" which is responsible for graphics and sound, and in our case when we've seen things get bogged down, it's always (100.0% of cases) been the media controller process that gets slowed down, which is kind of cool in a way because it means the game engine is still running full speed and won't get behind. The solution for the media controller is just to drop frames (which sucks of course), but really the only alternative to that is to use a more powerful computer. (Actually the other solution is to have better code. PyprocgameHD which is what Mocean and Rosh created uses SDL2 which leverages the GPU to do the graphics processing so it's way faster than the CPU-based method that the original Pyprocgame and MPF use. In fact they have subtlety suggested that we move MPF to SDL2 as well, and we're going to take them up on that with that effort starting next month.

    I've used the RPi2 with great success with DMD-style games, including color DMD. No lag, even after hour of play. No dropped frames. No delay. But that's a "loop rate" of 30, though like I said with the 1ms hardware polling and timer interrupts, combined with the pinball hardware handling the instant response drivers, the code is still doing things while sleeping in between ticks.

    So we'll see if we can get good LCD (way more res than 128x32) out of an RPi2 when we go to SDL2. I feel like it will be solid for color DMD maybe up to 192x64 or so. (It's decent there now and that's before we go to SDL2.) But if you're wanting a 1920x1080 LCD display or anything like that, then you're using a $200 mini PC board with a real GPU, not the RPi2.

    #1187 1 year ago
    Quoted from BrianMadden:

    So we'll see if we can get good LCD (way more res than 128x32) out of an RPi2 when we go to SDL2. I feel like it will be solid for color DMD maybe up to 192x64 or so. (It's decent there now and that's before we go to SDL2.) But if you're wanting a 1920x1080 LCD display or anything like that, then you're using a $200 mini PC board with a real GPU, not the RPi2.

    Or, you know, just don't use Python for your graphics.

    #1188 1 year ago
    Quoted from ecurtz:

    Or, you know, just don't use Python for your graphics.

    hahaha.. Word.

    That's an option too. There's a group of folks who made a Unity 3D media controller which also works with MPF (it just replaces the MPF media controller) for people who want to do "real" graphics.

    #1189 1 year ago

    A RPi2 should handle 1080p video fine though normally though, no? It's got some Broadcom chip for hardware accelerated playback I thought.

    #1190 1 year ago
    Quoted from Aurich:

    A RPi2 should handle 1080p video fine though normally though, no? It's got some Broadcom chip for hardware accelerated playback I thought.

    Yeah but that's more like a hardware H.264 1080p video decoder versus a general purpose GPU. So if you just want to play 1080p videos, yeah, no prob. But if you want to do other GPU things needed to create dynamic effects... rendering, particles, textures, floating point math, etc., the GPU in the RPi2 is benchmarked way, way lower (like 4-5x worse) than the next lowest-level GPU the testers could find, and it's like 100x worse than the $150 Nvidia GPU they tested.

    Source: http://www.geeks3d.com/20150603/quick-benchmark-of-the-raspberry-pi-2-gpu-videocore-iv/

    #1191 1 year ago
    Quoted from BrianMadden:

    Yeah but that's more like a hardware H.264 1080p video decoder versus a general purpose GPU. So if you just want to play 1080p videos, yeah, no prob. But if you want to do other GPU things needed to create dynamic effects... rendering, particles, textures, floating point math, etc.

    Makes sense. So are you thinking more like an Intel NUC?

    http://www.newegg.com/Product/Product.aspx?Item=N82E16856102004

    #1192 1 year ago

    I hope you guys forgive the short trip down memory lane, but I'm absolutely loving this conversation, and it reminds me of the feedback I most commonly received when first designing the P-ROC.

    Just about everybody who reviewed the board (not just a couple of people, but practically everybody) told me to remove the usb port and design in an embedded cpu.

    The biggest reason I didn't do that was because of this exact conversation. I wanted people to be able to choose the processing engine that fit their needs. That was in March 2009, three years before the release of the first raspberry pi. I used an old MacBook pro and a desktop Linux box for development, and I ran my first P-ROC game (JD) on an original Beagleboard.

    Fast forward 6.5 years later, and we have some users using $25 credit card sized single board computers and others using full sized computers to do real-time rendering on 1080p displays using game engines like Unity3d.

    It's been a crazy ride and fun to watch the evolution of custom and boutique pinball development. Can't wait to see what's to come!

    See you guys at Expo!

    - Gerry
    http://www.multimorphic.com

    #1193 1 year ago

    With the RPi you have to be conscious of media loading times from the SD card.

    It doesn't have enough memory to preload 1080p clips, so there is always some lag in starting a video and getting the initial stream from the SD card. At least, that was my experience when I tried it.

    #1194 1 year ago
    Quoted from gstellenberg:

    I wanted people to be able to choose the processing engine that fit their needs.

    +1,000,000 for this design decision!

    I mean let's be honest, by the time anyone here is ready to choose the "final" hardware for their machine, we'll be talking about the BBB Rev D and the RPi3 and which ones support 4K.

    EDIT: And think about what CPUs existed in 2009. The fact that the same P-ROC from 2009 is what you sell today brings this home.

    Love the new avatar Gerry!

    #1195 1 year ago
    Quoted from gstellenberg:

    Fast forward 6.5 years later, and we have some users using $25 credit card sized single board computers and others using full sized computers to do real-time rendering on 1080p displays using game engines like Unity3d.

    And the real beauty of it is that the full sized computers are going to turn into those $25 credit card sized ones before long. The small PC world just keeps growing and we can reap the benefits.

    #1196 1 year ago

    following up on Brian's post. One of the big changes MOcean and I made to the pyprocgame framework (in the hd/sdl version) was changing how the display stuff was done and it now runs at 30FPS, so in the normal game loop it will only look to update the display at the appropriate rate (so similar to what MPF is doing with sleeping). We chose 30 since that is pretty much standard video rate (at least in this part of the world) (MOcean had Buffy running at 60FPS, but I ultimately hounded him sufficiently to see the light and go to 30). I should point out that the original framework was focused on a DMD and was doing low level bit manipulation in c++ which has extremely low load on the system moving to larger screens and color was the necessity for invention. Koen and Eric had done the first color work for the pyrocgame framework for BOP2.0 and CCC, but they only needed a limited palette so a more radical change was needed to support full color. MOcean and I started with the concepts they were working with, but then went through three or four different technologies/approaches over the last year or so to get to where we are now, and we are pretty pleased with the results.

    Oh the framework also supports "sleeping" to limit the speed of the main loop as MPF does if you don't want to pin your CPU.

    With the MP4 video stuff, we actually convert it to a texture on the fly so we can treat it like anything else the display technology is processing, so it can easily be overlaid/composted with any text, images or animations and can therefore be used like any other 'layer' and does not required the game coder to do anything different then a text layer or image layer or animation layer (image sequence), also makes it much easier to start with a static image and then change later to a video clip.

    Oh, I agree with Brian, love the new avatar Gerry!

    #1197 1 year ago

    Look at the new beaglebone beast that's coming soon ($200-$250):
    http://makezine.com/2015/10/14/beagleboard-officially-reveals-the-x15-and-its-a-beast/

    Dual-core Sitara AM5728 ARM Cortex A15 @ 1.5Ghz
    750-MHz C66x DSP for analytics
    Quad-core PRU for real-time control
    Dual-core Cortex-M4 for even more real-time control
    4GB eMMC
    157 general purpose input/output (GPIO)
    20-pin ARM JTAG
    eSATA
    HDMI
    2 1Gb ethernet ports
    2GB DDR3L
    µSD card slot
    Micro USB 2.0 slave
    3 ports on a USB3.0 host
    Audio in and out jacks

    #1198 1 year ago
    Quoted from toyotaboy:

    Look at the new beaglebone beast that's coming soon ($200-$250):

    I just wonder at that price point if you wouldn't be better off with a NUC or something. Once I'm paying that kind of money I'm looking at better GPU etc.

    These little boards are really only attractive when they're super small and dirt cheap, because there's plenty of room in a pinball cabinet for something larger if need be.

    #1199 1 year ago
    Quoted from Aurich:

    I just wonder at that price point if you wouldn't be better off with a NUC or something. Once I'm paying that kind of money I'm looking at better GPU etc.

    I'm kinda with you on that.

    For just slightly more you could get something that is modular (motherboard, processor, memory, vid card) so individual parts can be upgraded as needed.

    That new Beaglebone X15 is certainly cool, but it seems like a decent chunk of the new price is spent in areas that don't really benefit a pinball game.

    The draw of the Pi is that it's $40 for the most powerful one, and that could certainly run a DMD game.

    I've been through a lot of processors for Spaceballs, in the end I came back to the standard PC. It helps that I have a bunch of extra ones lying around, so that influenced it a little bit.

    #1200 1 year ago

    -Big monitors/1080p video on backbox
    -30FPS video

    My notes on cost and reality:
    When you're playing a pin you're about 4 feet away. If observing, usually further unless you're one of those kids who hang on to the side to see what the player is doing.

    Putting the largest possible HD-TV or higher-res display in the back box may seem cool but you're probably wasting most of those pixels on folks with average vision. Your visual acuity determines what detail you perceive from a certain distance, a fact well-known to HD-TV installers.
    Here's a handy spreadsheet that helps determine monitor/TV size and resolution for a specific viewing distance:
    https://iraknol.wordpress.com/article/visual-acuity-advisor-what-size-hdtv-or-3ncxde0rz8dtk-11/

    For a typical pinball display in the back box a 24" (diag) monitor at 1280x720 is good enough. Also interesting on this spreadsheet are recommended font sizes and character heights for your viewing distance.

    24p or 30p?
    When ripping DVD media, say for example you're making a Mad Max Fury Road pin and you want clips to embellish your game, practically all movie DVDs are 24p. If you try to play a 24p clip at 30p you'll encounter common rate-adaption issues (called pulldown in TV land) that can make your clips look blurry or choppy if you didn't rip correctly.
    Most computer's media players support 24p which looks great, but not all monitors sync with 24p -- most are stuck at 60Hz...the side effect is an occasional line-tear in your picture.
    You also might have a "wait on sync" configuration in your graphics setup which helps avoid tearing, but now your game display loop seems sluggish... there's always something!

    So what?
    If you're rolling your own media display you might uncover video stuff that we normally take for granted when watching all sorts of video on all sorts of devices. After messing with low-level video for a few months I have a better appreciation of VLC/QT and even lowly Windows Media Center!
    -r.e.

    Promoted items from the Pinside Marketplace
    $ 109.00
    Cabinet Parts
    Tilted Pinball
    $ 9.99
    $ 149.99
    Playfield - Toys/Add-ons
    Lighted Pinball Mods
    $ 66.95
    Cabinet - Shooter Rods
    Super Skill Shot Shop
    $ 29.99
    Cabinet - Sound/Speakers
    Lighted Pinball Mods
    $ 34.00
    Playfield - Toys/Add-ons
    The MOD Couple
    $ 150.00
    Lighting - Interactive
    Professor Pinball
    $ 40.00
    Lighting - Backbox
    Rock Custom Pinball
    $ 48.00
    Cabinet - Other
    ModFather Pinball Mods
    $ 244.99
    $ 15.00
    Electronics
    Third Coast Pinball
    $ 24.99
    Lighting - Interactive
    Lee's Parts
    $ 63.50
    Playfield - Toys/Add-ons
    Lermods
    From: $ 42.00
    Cabinet - Shooter Rods
    ModFather Pinball Mods
    $ 208.87
    $ 430.00
    Cabinet - Armor And Blades
    MI Pinball Refinery
    $ 44.99
    Lighting - Interactive
    Lee's Parts
    $ 69.99
    Playfield - Toys/Add-ons
    Lighted Pinball Mods
    $ 22.00
    Cabinet - Sound/Speakers
    ModFather Pinball Mods
    $ 48.00
    Cabinet - Other
    ModFather Pinball Mods
    $ 48.00
    Playfield - Other
    ModFather Pinball Mods
    From: $ 14.95
    There are 1817 posts in topic. You are on page 24 of 37.

    Reply

    Wanna join the discussion? Sign up for a Pinside account, or log in if you already have an account.