Author Topic: HD/VGA Pyprocgame -- new version on the horizon  (Read 7194 times)

Rosh

  • Moderator
  • ****
  • Posts: 667
  • Josh Kugler
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #30 on: February 04, 2015, 09:59:13 AM »
distract him?  I'm not the one who told him to go play with 'particle generation', I'm the one trying to get him back on track.  Guess it is all the snow in boston, and the Patriots winning the Super Bowl, that has side tracked his mind,  I'm sure he will snap out of it soon.  ;)

Rosh

  • Moderator
  • ****
  • Posts: 667
  • Josh Kugler
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #31 on: February 06, 2015, 10:40:21 AM »
just to update.  MOcean has now finished the splash screen and claims to have fixed the text outline issue, but I haven not had a chance to test it. 

He had I had a lengthy debate late yesterday on an question of whether a GroupedLayer should have a black background by default, as it does today.  We have reached an agreement that it should be transparent (grouping layers should not suddenly add a black background), but will provide a flag to say 'fill with black', which would make it fully backward compatible.  However, I will be encouraging folks to 'clean that up', when they move over, since transparent is real the correct behavior.  But if you don't do the conversion, you will stuck with black and always using blacksrc to then make it transparent.  In theory, if you are using opaque correctly in your animations and layers, it should be a minor issue at most, however, due to it being black by default, I'm sure often it is not marked as opaque when it should be since you are not seeing it.  You will find this out pretty quick when you move to the framework if you have the flag on transparent, so another good reason to go with transparent, since it will let you see and correct the opaque issues you may have.

You want to be sure you are using opaque correctly in your game, especially if you are running your game on a single board computer.  Using opaque ensures the game is not wasting time/resources drawing layers that won't be visible.   For those who are not familiar, the drawing code will work its way down the mode queue looking for layers that need to be draw (including checking all the layers in a GroupsLayer), when it hits an opaque layer, it will stop going down, and will then go back up doing the actually drawing, layer by layer.   

Also, there is a feature on layers for 'enabled', if a layer is not enabled, it will not be drawn.  I use this often if I want to let a lower priority layer show through, without removing the layer from a higher priority mode, but just setting it to enabled=False. 

All of this applies to all versions of the pyprocgame framework.




Frank Gigliotti

  • Wizard
  • *****
  • Posts: 174
  • Wrath of Olympus Dev Team
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #32 on: February 06, 2015, 10:59:27 AM »
Wow, nice work guys. Did you try this version with any single board computers (like the cubietruck?) or does it require a beefier PC?

Rosh

  • Moderator
  • ****
  • Posts: 667
  • Josh Kugler
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #33 on: February 06, 2015, 11:22:00 AM »
we haven't tested it yet, but I hope to test it on a cubieboard2 in the next couple of weeks. 

However, MOcean was running it yesterday at 60FPS (which is way overkill), on a 240x480 screen, full color and was getting a loop rate over 5K on a lower end pentium.   I think the key will be the type/quality of the video on the single board computer.  The big difference with the new version of the color framework is that the display stuff is leveraging hardware acceleration in the GPU, which the current pygame based framework does not.   I would expect this change should make some of the single board computers viable for color, question will then be around color combined with screen size.

Right now I anticipate that the cubieboard2 and/or cubietruck will run 96x192, full color, with dot overlay, at 30FPS, without issue.   Of course, I don't know what I don't know, so, we shall see. 

We are adding some additional debug logging right now that will help us assess performance on various CPUs.   




Frank Gigliotti

  • Wizard
  • *****
  • Posts: 174
  • Wrath of Olympus Dev Team
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #34 on: February 06, 2015, 11:26:27 AM »
How does your 30FPS translate to loop rate? I'm getting around 100hZ loop rate with my cubietruck and our game.

MOcean

  • Moderator
  • ****
  • Posts: 822
  • Michael Ocean
    • View Profile
HD/VGA Pyprocgame -- new version on the horizon
« Reply #35 on: February 06, 2015, 01:51:54 PM »
To clarify, that 5k loop rate was on a low-end i5, but at 480x240@60fps, I'm pretty happy. I will test that in the older pentium at some point soon.

As for the loop-rate frame rate relation, this is how pyprocgame works right now (and the same is true of the VGADMD fork):

The run-loop consists of processing the most recent round of switch events, keyboard events, then seeing if it's time to add dmd draw events to the event queue. Most times through that loop it might not add any dmd draw events (at my 5000hz loop rate, that's polling the switch events and responding 5000 times per second or every .5ms). To have 30fps you will generate a new frame draw event every 33ms (so at 5kHz I'll  go about 65 run loop iterations before I generate a frame event). The frame event then builds the frame from all the active modes and then blits it to the screen. If the loop rate is too slow you might have more than one frame draw event required (ie, falling behind) and in that case the missed frames are generated but only the last one is drawn. This is rare but can happen in crazy scenarios and/on low end hardware.

As Josh has said, the new code offloads a lot to video hardware and this is more than just the final blit. I'm keeping almost everything in "texture memory" (aka the gpu's vram) and therefore compositing takes place without full frames going across the system bus. Most things happen on the gpu.

In theory, loop rates might go up if the dmd composition is a burden and the gpu acceleration really does speed things up, but it's important to know we haven't tested against a single single board computer yet.

The Microcenter location near me sold out of the raspberry pi b+ in a few hours, and I wasn't lucky enough to grab one. I do have a Pi B, but I don't have he highest hopes for that.

In the path to this re-write, I did write a multithreaded drawing approach. Not only was it not consistently faster, it also introduced some graphical glitches. The problem there was that Python keeps threads in the same process and if you want to take advantage of multicore you need multiprocessing (which is tricky). Once we have some benchmarks on single boards, I'll reevaluate whether I'll go down that road -- in full disclosure, my to do list has many higher priority items on it, though.

Hope this clears some things up..?
- Michael
« Last Edit: February 06, 2015, 01:55:48 PM by MOcean »

Rosh

  • Moderator
  • ****
  • Posts: 667
  • Josh Kugler
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #36 on: February 06, 2015, 04:13:38 PM »
not sure I understand the question, in general loop rate and frames per second (FPS) are different things, but the FPS, or in reality drawing/updating the display will have an impact on loop rate which can affect game play.

What the HD framework does is a more precise control over frame rate to minimize any extra work in drawing layers then they are not needed since there is no display update being done that loop.  It is also does this to insure that graphics run at the intended speed.  It will however 'catch up' if it does for some reason have a delay that causes it to be late on drawing a frame, but it needing to that would indicate potential performance issues.  We have not really seen that (falling behind) with the new version, but something we will be doing more testing for.     Falling behind can result in a snow ball effect as well.

Keep in mind a traditional dmd is using 8bit for the DMD 'dots', well, it is really only using 4 bits (16 shades), but the original code is set up as 8 bit.  Eric (and Koen I believe) leveraged this 8 bit for their color implementations, since it gave them 240 colors (plus the original 16 shades of 'orange').  8 Bit 'blitting' can be pretty efficient, but once you move to 24bit color, or 24 bit color with full alpha support (32bit), things become more complex, and doing updates of the display content is more costly.  Obviously the bigger the display the bigger the load.  The 'desktop' module in the original framework, already had some controls to limit the frequency of updates to the desktop display vs the dmd display, but it was still far more frequent than needed. 

If too much time is spent doing drawing, which is the heaviest load on the game, then it can result in latency in your game (and in your animations).  To be honest, while many will argue that a loop rate of 100 is sufficient, what that potentially hides are windows of time where the actual loop rate is significantly lower.  You won't even realize this unless you are looking for it or you suddenly realize that something did behave correctly. I first became aware of this the last time I was doing testing with a single board computer, and while at first everything seemed fine, I realized that occasionally a diverter was not firing quick enough after a switch hit, (and where I was not using a switch rule in the P-roc for various reasons).   An example of this could be where you are loading a large animation at the time it is needed, if it took say a half a second to load that animation, if you normal getting a loop rate of 100, you are obviously getting well below that during that window of time.  Odds are it would have no impact, but it could.

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. This could certainly be the case if that switch not only triggers the diverter, but first throws up an animation (so always do the switch request first).   So, 100hz is probably okay, but really depends on what is happening on the playfield in conjunction with what you are doing on the display.  In some of my testing on the version of the HD framework prior to our latest work, I've seen the display update takes as much 30 milliseconds during an extremely complex layer setup, you can see in that case the loop rate for that second would be significantly lower and could cause issues.  That update of that layer in the new framework takes about 1/10 that time.

Obviously this is probably a bigger factor if you are doing more complex animations and layering.   Also the latency is likely not an issue in most games unless you have some key timing things like diverters, that for whatever reason are not using a switch rule (so latency of this type should not be an issue with flipper, pops or slings, which you should always be using switch rules for).

So, bottom line, when you think about loop rate, you need to remember it is an average, and you do have to give consideration to any impact relative to when the loop rate for a given window is significantly lower.   So is 100 okay, probably in most cases, but really depends on the complexity of your game.  Good thing is for most games, this upgraded framework should run significantly faster, reducing the chances of any latency issues.

















MOcean

  • Moderator
  • ****
  • Posts: 822
  • Michael Ocean
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #37 on: May 14, 2015, 04:15:37 PM »
Okay, it's here and released.  It's bundled with SkeletonGame, just to give me one less thing to maintain but you don't need to use SkeletonGame to leverage the PyProcGameHD stuff.  The code isn't half bad.  The docs are long, but still not half good :)

http://mjocean.github.io/PyProcGameHD-SkeletonGame/
(direct to gitHub: https://github.com/mjocean/PyProcGameHD-SkeletonGame)

Still very early releases.  I expect problems and questions, please fire away.

FWIW, I'm going to call this PyProcGameHD from now on, unless someone has a better name for it.

Also, yesterday I began some tests on the Raspberry Pi 2.  It has a lot of issues that need to be worked out, but compared to the PyGame version:

RPi2 running a 224x112 "dot resolution" game, set to 30fps:
PyGame version: 10fps w/ a loop rate of ~100hz.  No dot effect.  24bit color (no per-pixel alpha channel)
This (SDL2-based) version: 29fps w/ a loop rate of ~250Hz.  32b color (per-pixel alpha).

Since the rPI2 is still limited to only 1GB of memory, I'm not going to spend too much time on it.  If someone else wants to pick it up, let me know.
« Last Edit: May 14, 2015, 04:33:27 PM by MOcean »

Brian Madden

  • Wizard
  • *****
  • Posts: 498
  • Mission Pinball
    • View Profile
    • Mission Pinball
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #38 on: May 14, 2015, 07:42:40 PM »
Congrats guys! This looks awesome. I like the name PyProcGameHD since that shows that it comes from PyProcGame while clearly being a separate project.

Awesome that you're using PySDL2 to get hardware accelerated graphics! Nice work!
Brian
The Mission Pinball Framework (MPF) Project*
Twitter
* Disclaimer: MPF is a work-in-progress!

MOcean

  • Moderator
  • ****
  • Posts: 822
  • Michael Ocean
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #39 on: May 14, 2015, 08:05:55 PM »
Thanks Brian,

Since I assume you'll be looking through the SDL2 stuff for MPF, PySDL2 provides a lot of nice functionality that's very abstracted, but the sdl2.ext classes provide more direct access to SDL2 (via ctypes), so you may also want to take a look at the SDL2 tutorials from lazyfoo (http://lazyfoo.net/tutorials/SDL/) they are invaluable. I took an approach of blending the abstracted PySDL2 objects with the ext classes and a few direct ctypes calls for some stuff that wasn't wrapped in ext.

Getting things running at all under sdl2 was a very rough week and change, but when it works it's thrilling :)

Brian Madden

  • Wizard
  • *****
  • Posts: 498
  • Mission Pinball
    • View Profile
    • Mission Pinball
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #40 on: May 14, 2015, 08:14:18 PM »
Thanks for the pointer to that tutorial. I don't know what we're going to do with MPF other than to say I don't think we can stay on PyGame. (Probably for the same reasons as you.. their installers are a mess, the latest stable version is from 2009, and it's based on SDL 1.x which only supports one display, 2 channels of audio, one streamed music track, and everything is done is software.)

We actually just split what we're calling the "media controller" out of MPF and into its own standalone process which has a socket connection to the game engine. (Few reasons for that.. being able to leverage multiple cores is one, and also it means the built-in MPF media controller can be swapped out with another standalone one.) There's another group of guys who are building a media controller based on Unity 3D, so that gives us some breathing room for the moment for people who want to do crazy graphics. But even DMD-based stuff would hugely benefit from not being on PyGame, so based on what you're saying about PySDL2 and what you've done.. that might be the way to go!

Irrespective of that, though, I looked at PySDL2 awhile back, and what you've done for PyProcGameHD, seriously, that's a lot of work.. congrats again!
Brian
The Mission Pinball Framework (MPF) Project*
Twitter
* Disclaimer: MPF is a work-in-progress!

bonnevil69

  • P3 Developers
  • *
  • Posts: 698
  • Matthew Bonnema
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #41 on: May 14, 2015, 10:23:28 PM »
  awesome   Ill get reading   Doom will be using this for sure   Thanks Michael and Josh for all your hardwork
DeadPin and Doom

MOcean

  • Moderator
  • ****
  • Posts: 822
  • Michael Ocean
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #42 on: March 29, 2017, 04:30:16 PM »
The SkeletonGame/PyProcGame/PyProcGameHD Windows installer has moved:

http://skeletongame.com/files/proc_env_installer_wHD.exe

This version (1.12) has been updated to pull files from SkeletonGame.com instead of the now defunct Dropbox public link.

Also you can find a fair amount of documentation at http://SkeletonGame.com