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

Rosh

  • Moderator
  • ****
  • Posts: 667
  • Josh Kugler
    • View Profile
HD/VGA Pyprocgame -- new version on the horizon
« on: January 26, 2015, 11:42:02 AM »

Just a heads up on the HD/VGA pyprocgame framework, we have done a ton of improvements on it over the last few months that will get rolled out in the not to distant future (well maybe a touch longer). More significant is that Michael for last couple of weeks has been doing a major upgrade to the display stuff, that will have significant impact on increasing loop rates and insuring a more accurate FPS, something that we had made nice progress on, but his latest work will take that up another notch. We are currently testing and converting secondary display features (e.g transitions) to work with the new framework, and we are feeling pretty optimistic right now that this is all going to come together.  We have not yet moved "Sound" over, but if we are successful in doing so, we may be able to remove all dependencies on pygame. 

So far in converting my two games over, it has required very little alteration to the code, and some of those changes would no longer be needed based on progress we have since made.

While we have plenty of testing still do to, we are seeing incredible improvements in loop rates.  On my mac running the casino game, and hitting the slot machine mode, which is using over 150 layers, in multiple nested groups, I am seeing loop rates over 3,000 which is nearly double what I have seen previously. This is running full color at 900x450, and I don't think anyone is running anything bigger than that right now (when I 'scale' it by 2,  my loop rate does drop to about 2600, but we have not yet tried to optimize that).  More important, is that while in the past I could have a great loop rate (1400), it was still dropping frames during slot machine, so far it appears that is never happening with this.

Whether or not this will work with a traditional DMD vs an LCD, we do not know yet, since neither of us currently run our games using a traditional DMD.   We have also not done any testing yet on single board computers, but I am cautiously optimistic that we will see similar improvements in loop rates.

One impact will be on how images are used relative to blacksrc vs transparency.  The goal is to make the changes so they have little impact on existing code, but, there will be impact, especially if you not already using our asset manager.  Blacksrc, which has been my preferred approach today for handling transparency, will basically be phased out, preferring the use of pngs with true transparency.  It should still work, if going through the asset manager, which will convert the blacksrc to transparency.  It is possible we will create some tools to assist with this.  However, my primary point being if you are looking at moving to the HDVGA framework and are making graphics, be sure to keep the original material you are working with, or save version for both blacksrc and transparency.   Currently support for full alpha bit transparency is working.

It is amazing to me how quickly Michael got the first crack at the conversion done, although I think he may now be bald from pulling the hairs out of his head.  But each time he hit a wall, and after I would tell him to take a break, he would come back and knock that wall down.   Oh, he is also working on what he calls a 'skeleton game' to make it easier to get started creating a game.

While I am giving a shout out to Michael's hard work, I also want to thank him for this swtichGUI tool he rolled out a couple of weeks ago.  This builds on Brian's great OSC work, but the ability to so quickly take a photo of your playfield and drop buttons to where all the switches are and use that to test your game, is amazing. It is much easier then using an off the shelf OSC client and certainly better then just using the keyboard.  I know he has more work planned on it after we finish up the upgrade to the framework.





 

Mark Jarzewiak

  • Wizard
  • *****
  • Posts: 244
  • Mark Jarzewiak
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #1 on: January 26, 2015, 02:21:16 PM »
Heard about this skeleton game and really looking forward to it.  I will probably try building a game with both MPF and pyprocgame.

Frank Gigliotti

  • Wizard
  • *****
  • Posts: 174
  • Wrath of Olympus Dev Team
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #2 on: January 26, 2015, 02:45:23 PM »
Exciting features guys! Are you using true type fonts too?
Is it possible to run both versions (current and hd vga) in different folders?
a skeleton game would be terrific for the new starts, and we could compare methods.
I still like the dots so hopefully there is an option to retain the dot look ( maybe 192x96)

Rosh

  • Moderator
  • ****
  • Posts: 667
  • Josh Kugler
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #3 on: January 26, 2015, 03:02:19 PM »
The dot look is expected to be there, Michael was testing that last night. However,  I would not attempt to use dots beyond 96x192 or 240x480. I will say that the 96x192 is a really nice nice.  It lets you maximize the space between the speakers, get a slightly denser resolution, but still have a very nice dot look.

it does use True type fonts (must be TTF format), like the current HDVGA version.  Michael has the basic font stuff working as far as color, and I think he now as the outline working (I've not yet tested it), but he is still trying to decide how best to do fonts with an animated fill. 

I am currently switching back and forth between both version of the HDVGA, current and new to validate behaviors, etc., but have not tried to run my game against the original framework in a long time, since it requires color.    I might have a 'code base' someplace for a DMD only game, and if I get a chance I'll point that at the new framework and see what happens (might work fine in fakepinproc, but possible not with a real DMD, don't know). 

MOcean

  • Moderator
  • ****
  • Posts: 822
  • Michael Ocean
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #4 on: January 26, 2015, 03:10:36 PM »
Thanks Josh!  This really went from crazy idea to proof of concept to "shockingly viable" in a very short amount of time (well, a lot of hours across relatively few days). Without Josh prodding me to actually turn it "real" I don't think this would be nearly as far along, and he's been invaluable in joining the good fight on this and has been porting portions as well.

Frank: yes, the goal is to maintain compatibility with the previous VGADMD release (and that release was like 98% compatible with vanilla pyprocgame code), so you will still get support for both bitmap fonts and TrueType fonts (and line borders and animated fonts should be back by the end of the day).

The dot filter works and has been tested, too.

There's the ability to add a slew of new features as well. One "teaser" I've played with is multiple windows, so eventually this should support folks wanting to do multiple displays on their games (e.g., lcd based dmd + apron display).

SkeletonGame will get its own thread when it's closer to reality. It's probably close enough to let people start playing with now, but since it's intended for "new" games (and probably new pyprocgame users), I would be uncomfortable distributing it before it's less susceptible to changes that a user would notice.

Anyway, solid teaser. I hope everyone is excited as I am. I'll post video soon and maybe even some archival video from earlier in the week when things were more broken. They're pretty hilarious in a weird way.

Okay. Back to work :)

- Michael

Mark Jarzewiak

  • Wizard
  • *****
  • Posts: 244
  • Mark Jarzewiak
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #5 on: January 26, 2015, 03:58:59 PM »
Like I said, really excited for this.  Planning on potentially adding a video monitor for DW as a second mini-display so this would be great!

Spinape

  • Wizard
  • *****
  • Posts: 214
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #6 on: January 26, 2015, 04:14:34 PM »
Count me in as excited! This right up the alley on stuff I was inquiring about

briancox

  • Full Member
  • ***
  • Posts: 45
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #7 on: January 27, 2015, 12:24:46 AM »
Does the dot filter work on-the-fly? I was considering pre-processing all my animations, but mainly because I'm targeting a small processor.

And, I might be answering my own question here, but does anyone think that the standard 32x128 dots is enough for an "evolutionary" game today? Seems like 48x192 gives you almost the exact same look, but with enough resolution to actually see some detail in a complicated animation.

That being said, the lower-res animation may re-gain some of its detail (in the minds eye) once things are moving around...

B

Spinape

  • Wizard
  • *****
  • Posts: 214
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #8 on: January 27, 2015, 12:40:03 AM »
So this could add support for LCD DMD as a primary backglass display and the traditional DMD I purchased as a topper display? thats where I think I want to put an invertory display.

The other thing im gathering, making games for video mode would be much closer to making a game with pygame?

MOcean

  • Moderator
  • ****
  • Posts: 822
  • Michael Ocean
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #9 on: January 27, 2015, 09:04:57 AM »
The dot filter is added on the fly, and you can use it right now on the old VGADMD version, too. That dot filter tricked I picked up from Koen long ago so props to him for thinking of it. His was prebuilt for the fixed dot size of 128x32 so i extended that idea to arbitrary resolutions.

The dot filter is basically an oversized image that gets built based on your dot resolution and scaled down when first start your game, then blitted on top of every frame drawn to the virtual dmd if the feature is enabled.

Against the new version that scaling and blitting is done in hardware so while in the old version you can notice the impact of enabling the dot filter in that version (lower loop rate) in the new version it's pretty much unnoticeable unless, like Josh and I, you are measuring the hell out of every little thing in the pursuit of quickness.

I think you'll find a very bifurcated audience here when it comes to display technology. On one extreme you find the P3, and on the other there are a slew of AlphaNumeric only projects.

For now, my all but abandoned Hook is running at 450x250 just like Buffy.  My T2 runs at 224x112 which is a very nice upgrade over 128 as it allows for more detail without losing the dot filter. Notice for all of these I advocate using a 2:1 display ratio instead of 4:1. SEGA did this with their huge dmd (baywatch, maverick, others) and it really affords a lot more real estate. The modification to the speaker panel is easy and there's another thread that has examples of opening up the dmd opening.

Does the dot filter work on-the-fly? I was considering pre-processing all my animations, but mainly because I'm targeting a small processor.

And, I might be answering my own question here, but does anyone think that the standard 32x128 dots is enough for an "evolutionary" game today? Seems like 48x192 gives you almost the exact same look, but with enough resolution to actually see some detail in a complicated animation.

That being said, the lower-res animation may re-gain some of its detail (in the minds eye) once things are moving around...

B

MOcean

  • Moderator
  • ****
  • Posts: 822
  • Michael Ocean
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #10 on: January 27, 2015, 09:18:13 AM »
I'm very unlikely to make this version still retain compatibility with the traditional dmd.  There are a number of technical challenges to doing so, and it's increasingly feeling irrelevant.  If Eli is able to make the "real" color dmd happen and can come up with a VGA interface then I can easily support it.  In fact, I'm sure I can set up something to stream the bits back through USB, but we'd lose a lot of the advantage of doing everything on the video card (in the GPU and VRAM) if we then pulled each frame back out of VRAM to send it over USB.  Of course, with only 128x32, that can do that right now on the old version, too, but not with two different display windows.

I think an apron display for inventory and/or minimap probably makes sense for this pin, but I don't want to tell you how to design your game --just how to program it, if asked  :)

Making games won't be any closer to Pygame, but I could make an option to turn off drawing for a particular window and just let the caller directly use my blitting/drawing functions... Not sure that this would be a "good thing" though...

- Michael

So this could add support for LCD DMD as a primary backglass display and the traditional DMD I purchased as a topper display? thats where I think I want to put an invertory display.

The other thing im gathering, making games for video mode would be much closer to making a game with pygame?

Curbfeeler

  • Wizard
  • *****
  • Posts: 239
  • Dan - Des Moines, IA
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #11 on: January 27, 2015, 10:30:41 AM »
Wow, I could not be more excited about this!  Thanks so much for working so hard on it, both of you.  Timing ends up being excellent as far as my Pinbot project.  I just finished wiring my 4 ball trough assembly over the weekend and am now ready for the next phase.  Testing this would make a great "next phase," so consider me available!

For those who don't know of my Pinbot project, the game's backglass has spaces in the art for two 7-digit 14-segment displays and two 7-digit 14-segment displays.  Below that are 4 digits designed for ball and player number, etc.

Since I'm aiming to keep the game "classic 80's retro," I want to keep these displays.  In fact, I'd really contend that the game is spoiled without them in all their original glory.  But let's face it, that's not a lot of space to "show off," which is a lot of the fun with these re-writes.  Besides, now that I'm moving to complex modes within each planet, I really need to be able to communicate quite a bit more information to the player.

Enter my apron display.  By having an apron display, I can continue to keep score, ball count, player count, etc. on the backglass, but I can get fancy with the apron display.  I can have animations, give the player mode-specific instructions, etc.

Anyway, I'm in the "woo-hoo" camp on this one, for sure.  Thanks again.
Dan

dave_h

  • Wizard
  • *****
  • Posts: 185
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #12 on: January 27, 2015, 12:33:37 PM »
Does the dot filter work on-the-fly? I was considering pre-processing all my animations, but mainly because I'm targeting a small processor.

And, I might be answering my own question here, but does anyone think that the standard 32x128 dots is enough for an "evolutionary" game today? Seems like 48x192 gives you almost the exact same look, but with enough resolution to actually see some detail in a complicated animation.

That being said, the lower-res animation may re-gain some of its detail (in the minds eye) once things are moving around...

B

192x64 for the win!

Code: [Select]
use_virtual_dmd_only: True
dmd_grid_path: C:\P-ROC\FullColor-hdDMD-pyprocgame-master\
dmd_dots_w: 192
dmd_dots_h: 64
dmd_dot_filter: True
dmd_no_frame: True
dmd_fullscreen: False
desktop_dmd_scale: 4
dmd_framerate: 15

I don't know how much it's changed/improved yet but I've found that using any larger (and if you have a lot of content) uses a lot of memory, I wouldn't worry so much about processing.

Those images aren't from the VGAdmd but just a mock up? I wouldn't kill those nice images with a dot filter. Just from my experience AND opinion, the dots are good to mask film video frames, score text and not for awesome images you have there. Maybe you could separate the frames from your score board.

2 of the 8 games I've been working on with VGAdmd:
https://www.youtube.com/watch?v=-qlWfgQag5E
https://www.youtube.com/watch?v=xD7ekgONP3c

Rosh

  • Moderator
  • ****
  • Posts: 667
  • Josh Kugler
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #13 on: January 27, 2015, 01:16:21 PM »

I don't know how much it's changed/improved yet but I've found that using any larger (and if you have a lot of content) uses a lot of memory, I wouldn't worry so much about processing.


In some cases you may not be aware of CPU constraints since the game may function correctly, but you may be losing frames on the display.  Probably not often or likely unless you are pushing it is hard as I have (450x900, 24bit color, and as I have mentioned in one case, over 150 grouped layers in use at the same time).

Memory can definitely be a constraint, however, I have not done any analysis yet of how that might have changed.  The approach of most animations being created at the start of the game and if you are using a larger screen, can make memory constraints a challenge.

There is no doubt that I can see a performance hit, if I am running it on my machine with no available memory vs ensuring a gig or two is free (at least with the previous version of the HD/VGA framework).  On my actual machines I have 4 gig, so it is really not an issue.

Regardless, one strategy to employ is to not pre-build longer/larger animations that are only used on rare occasion in the game, and are needed when (or shortly after) the ball is a 'resting' position.  So, the real world example is that at the start of a 'game mode' or 'mulitball' where the ball is likely held, that is a time where you can just load the animation right then and then dump it when the mode is over, to not be tying up memory for the entire game.  This can work for both the 'intro' to the mode as well as any other animations needed during that mode.  So, there is a fine line between what to pre-build and what to not.  Want you do want to try to avoid is building any animations from disk, when the ball is in play.  While typically it won't be an issue, I would say best practice is not to avoid doing that.

Following up on my blacksrc comment from earlier in the thread.  If you are using blacksrc, you will be required to change the animation load calls to include a new composite_op parameter vs setting it for the layer after the fact, which will no longer have an impact.  When we create the animation, if blacksrc is specified, at the time we convert the black to transparency.

Also, groupedLayers, which today start with a black background, will now start with a transparent background instead.  In most cases, this just means you can remove the composite_op blacksrc you may be setting after the fact, on the flip side, is if you were relying on that being black, you now have to use a black layer in your groupedLayer. 

Also, all DMD (and HD) fonts will be built with a transparent background as well (vs black).  This will also remove the need for many composite_op=blacksrc commands, which can then just be removed.   We recommend using TrueType fonts for lots of reason, but many of you will have been using DMD Fonts (as I have with the Kugler game, although they were color DMD fonts), so the support for that will continue.









dave_h

  • Wizard
  • *****
  • Posts: 185
    • View Profile
Re: HD/VGA Pyprocgame -- new version on the horizon
« Reply #14 on: January 27, 2015, 01:55:18 PM »
I am guilty of pre-loading the whole lot. :) I haven't tried your asset manager but it works similar to CCC.

I'll be honest I've never tried to load frames on the fly yet. For all I know it could be absolutely fine with no noticeable lag. Once I did check to see the loop rate but haven't looked at that since, I don't have a problem with dropped frames as far as I can see. With VP running @ a steady 350fps, VLC & VGAdmd on the same screen it's great.

With Robocop I think I settled for 420x240 25fps and that was getting large very quick with high memory usage, but as you mention there's a few things in that game that wouldn't hurt to load when they're needed. The mystery hole, multiball kickers & attract would be fine without a pre-load.

Quote
Following up on my blacksrc comment from earlier in the thread.  If you are using blacksrc, you will be required to change the animation load calls to include a new composite_op parameter vs setting it for the layer after the fact, which will no longer have an impact.  When we create the animation, if blacksrc is specified, at the time we convert the black to transparency.

Also, groupedLayers, which today start with a black background, will now start with a transparent background instead.  In most cases, this just means you can remove the composite_op blacksrc you may be setting after the fact, on the flip side, is if you were relying on that being black, you now have to use a black layer in your groupedLayer.

Nice. It shouldn't be too much of a problem to migrate. I normally just have one function to call for all of the frames & text layers so not much will have to be adjusted.

I have never used DMDFonts, only system fonts. Feeling quite glad I missed the boat there because building the fonts sounds like a pain to me.

Looking forward to the changes anyway! Thanks for the great work on it so far, I've had lots of fun with it.