2nd Display Software fail

[ids]

I put some hours into developing a flexible bit of software to drive the display embedding in my control panel.  I know there are things such as Marquee Magician and MameHooker (the latter of which I use and is a very important part of my cab - in fact the code I wrote goes idle/invisible if there is a MameHooker display file for the selected game).  What i find missing (maybe I am wrong) is a system that will look at what media assets are available, their sizes, aspect ratios and so on, and automatically work out the best way to display that stuff.  A bit of a pipe dream to be sure, but one of the flexible aspects built in was an ability to control things, override defaults, etc.  So if the normal processing did not live up to expectations for a given game, it could be overridden.  It seems to me that Marquee Magician and MameHooker excel at what they do, but they require static display files.  The available assests for each game tend to vary quite a bit, and I also wanted to include the Instruction Cards available from Mr Do - these tend to be zip files with several images, that may also include one or more instruction card images.

So, I built the app, it was configurable, could pull images out of Mr Do's zip files, ignore (some) japanese images (not a bias, just not a language I can read), animate/scroll images that are large, animate a sequence of images, show a "nicely" formatted History text if all else fails, etc.  And after optimizing this code, it ran mostly at 0-1%CPU on my desktop.  The fail is that when running on my Mame cab, it eats the CPU.  Mame cab is an older AMD x64 dual core, desktop is a newer quad core i7, mame cab second display is a Liliput USB monitor (main is a TV hangin off a decent vid card), desktop is ... well, its a solid machine in all respects.  Even on my 2.3GHz Mac laptop, this app eats about 15%CPU (which, in this case, should not impact playing the golden age games, but still....)

Due to the performance on the Mame cab, this effort is dead.  Sorry to vent my frustrations here.  I have been forced to create a utubez acct to host the vids, fwiw:

This shows animation across multiple instruction cards with different aspect rations
http://youtu.be/VEhe6aKRn6A


This shows Popeye, which has no instruction card, so a formatted History text is scrolled instead:


And SF2 - a wide instruction card being scrolled back and forth



The watermark on the vids are from the screen cap software used - demo version

sorry, this post is a waste of bandwidth, but I felt a need to vent - all that work and I cannot use it 

[nadcraker]

That looks awesome! Just because it isn't working out on your cab doesn't mean you should just kill it. 

I think it's impressive, maybe someone else has ideas to optimize it for that USB display?

[RandyT]

The first thing I would do is try a different physical USB port.  If that makes no difference, test the MAME cab with a different display type for your second screen (add another video card,  or use one with dual output capability.)  This would at least tell you if the USB display device is the bottleneck....my guess is that it's probably causing the extra system overhead.  Could be a poorly implemented USB port on the system, shoddy drivers, etc.

You may also want to try an older version of MAME to see if the two are just adding up to more than the system can handle.  Since it's a dual core system, you might also play with core preferences and application priorities.

[drventure]

Looks like a cool project. I wouldn't necessarily give up.

A few questions

1) What's it written in (.net, WPF, winforms, C++, flash?)
2) What frame rate are you using (ie if you're hitting 30fps, you might try 15-20 instead).
3) Is the USB monitor USB3 or 2.0. If you can get a 3.0 monitor (and 3.0 USB port on your pc), that should help a lot).
4) I notice there's a +very+ subtle transparency to the scrolling part. You might try getting rid of that, as any transparency really amps up the horsepower needed to run an animation (at least, that's what I found working on my Now Playing Screensaver).

If it's an option, I found that .net using WPF is actually incredible capable even on lower end machines, primarily because it leverages directdraw, which in turn can leverage whatever power you have on your graphics card. Unfortunately, for this, that might be moot, because if you're talking to a USB monitor, there is no fancy graphics card to do the heavy lifting, so it'll all be done in software. In that case, reducing transparency and the frame rate should help quite a bit. Otherwise, a heaftier CPU should help, albeit a most $$$ solution.

[cigardude]

I would definitely add a second video card or replace the main video card that can support two monitors. If you move from USB you should be fine.

I have a projector at work that works from vga and usb. When hooked up to the USB port of any PC, its laggy as hell and sucks the CPU. Attached to the VGA port and it works fine.

[cigardude]

It's an awesome idea, I would definitely try to get it working.

[ids]

Thanks everyone for your kind feedback - I think I've been inspired to put a bit more effort into this one before putting it to rest.

It was written in Java - and i purposely omitted this fact originally because a lot of people think Java sucks for performance.  Now, I would not write a first person shooter in it, necessarily, but I will admit that due to performance considerations I tested a very early version before putting much effort in, and found even then that it was not using much CPU, etc.  I chose Java because it's what I have primary used over the last ~15 years, so it was obviously the easiest and quickest way to make this happen.  Having worked with .Net before, I'm not sure if it will do any better.  .Net is also an interpreted language.  And from my experience, I know there are areas in which .Net sucks terribly in comparison to Java, such as having massively worse performance within a debug build, with exception handling, and other areas.  Though, my experience with .Net does not cover specifics related to this kind of app.  I had thought about going all the way down to C, but the effort to relearn all the API's lacked some appeal - it also felt wrong given the preexisting products mentioned earlier are probably in C/C++ or something similar.

The Frame Rate is actually configurable.  The app "sleeps" for a configured amount of time between screen refreshes.  I've tried a variety, from 60fps to 10fps, all of them are very demanding on the cab, yet no option I've tried makes the desktop go over ~5% CPU.  On the Mame cab, I tested without anything else running - and assumed that with such high CPU usge, Mame would suffer. (I should test this, I guess)

USB monitor is on USB ver. 2.  It's a Lilliput, something like this but an older model: http://lilliputweb.net/index.php?Controller=User_Product&action=ShowProduct&product_id=83.  I would not be surprised if the system is taxed when drawing to this device due to a lack of dedicated video hardware for it, but would need to investigate more.  A second video card is not an option for two reasons: the mobo is old, predates PCI, and the monitor embedded in the CP cannot easily (or cheaply) be changed to something a vid card can support.  The vid card I have has dual outs, and before committing to a final CP, I tried connecting other things to it, for example, one of those rear-view mirror monitor things.  The image was absolutely terrible.  The CP i have now has a hole routed to the specific dimensions of this decased mini monitor, and I would really not want to start again with something else.

I'm not actually using transparency effects.  Perhaps what you are noticing is the watermark left by the screen cap software?  In fact, the drawing routine is fairly simple, and bits that do not change are not redrawn on each refresh.  If something were to obscure the window temporarily, it could be a while before those bits got repainted again, as I chose performance over all other concerns  IMHO, the most taxing bit would be the text scrolling, maybe?, since, instead of just blitting an image, the text gets redrawn for each frame (the layout, formatting and stuff are all precalc'd tho, and bits that are offscreen are not drawn, a clipping region is also put in place, etc).

I have also not mentioned....version2....an app to assist with generating static display files for MameHooker (or Marquee Magician, etc).  It shows available artwork assests, lets you pick the layout, and ta-da, instant display file.  It's work in progress, but maybe I should go back and investigate more how to make version 1 work. I really do prefer a dynamic, runtime generated scheme with the animations.  I was also considering stuff like - well, if you look at SF2 for example, start with the instruction card zoomed out, to fit the width of the screen, the slowly zoom in to the size shown in the vid, then start the scrolling.  That would be good for games like golden tee as well.  And then, there are those games whose marquee is more of a advert type image (large portrait image), games with more than one instruction card, etc.  I had a fair bit worked out for these cases but....

One more thing - out of laziness, it seemed the easiest way to tell to a "resident" program which game to show, was to have it listen on a socket - so things like autohotkey etc could invoke a URL, like http://localhost/gamename (port is also configurable, fwiw) and the app would immediately switch to that game (unless there was a MameHooker display file )  That part was working quite well also, and it seemed like a good, generic way to tell it what to do.  Command line is another option, but rather than start/stop the app, I thought it better if a front end could just tell it "switch to game-X now please".

[drventure]

.Net is also an interpreted language.

Not that big a deal, but this isn't quite true. .net is "compiled" to MSIL, which, while not technically a machine language is far faster to execute than an actual interpreted language.

However, things get even more interesting from there. Generally speaking, on most hardware, the MSIL is actually dynamically "assembled" when the app is run into whatever machine code is applicable for the hardware that the app is currently running on, whether it be 32 bit or 64bit, etc.

Now, I know nothing about Java and the JVM, so I'm not even going to try to compare the performance between the two.

My suspicion is the bottleneck is the USB monitor itself. Since there's no graphics card involved, all the display work will have to be done by the actual CPU, and that's just going to dog it down, likely no way around that without resorting to a different monitor/ card combo.

About your API, a socket is fine, but will be hard for most people (and apps) to use.

One trick in a scenario like this is to go ahead and use the socket, and then code up the app such that if it's run a second time with a command line switch, it then connects to the socket, send the applicable message to the already loaded instance and quits.

If there's no loaded instance, it executes the command and stays loaded.

Also, sending registered windows messages is a very common api approach, as is COM objects, or named pipes.

Just a few other ideas to throw out there.

[ids]

Java and .Net are much the same - compiled into something that isn't machine language, and then at runtime, that something gets turned into native machine code.  Java does a really good job of this, tuning the generated machine code according the hardware underneath.  In this particular case, the app performance is, unfortunately, limited by things outside itself.

Agree that USB is probably the limiting factor - that's a lot of pixels to push over the wire as well.

I had considered the companion app, which would send data over the socket, but saw that autohotkey has a URL command, and there are other ways to do this.  IIRC, native windows apps (and thus, probably .Net as well) have a thingy where on start it knows if it is the only instance, or something like that?  I don't know of an equivalent in Java.  One could see if the specific TCP port is already bound, but there is no guarantee as to what is bound to it.

Not sure how Java handles registered windows messages, named pipes and such things.  Only a concern if Java is your platform of choice I guess.

Maybe a skeletal .Net test app would be worth trying, to see if I can get better performance at all.  From what I recall, going back ....way too long, one of the best performing ways to scroll in Windows is via some...kind of API whereby you say "that part of the screen needs to move over there" - and then you paint the exposed/remaining bit.  Is this idea still valid these days?  Is there an equivalent in .net?

[Lilwolf]

I've optimized java a lot throughout the years.  Depending on what your doing, its maybe 5% slower then C++... and .net is less. 

I'm guessing that your animation loop is really the problem.  Add a thread wait (even 10ms, but 100ms is probably better) will often take something that takes 50% cpu time down to 2%.  If you don't have a wait in there, it will try and take 100% cpu time when dealing with animation.

And this reminds me when I wrote my 100% 3d frontend.  It was pretty sweet.  You had rotating cubes for the screen shot and marquee and some slighty moving/dancing cubes at the bottom for the next/previous games.  Then when you went to the next/previous game, all of the cubes at the bottom moved to the new spot in different ways.  The main screen and marquee rotated with the next screen shot on the next part of the cube.  Later, I translated some of the 3d models for a cabinet and had the screen and marquee in a pacman machine that was floating in space.  If you hit random, the screen / marquee turned into a slot machine and rotated, and each slowing down at different rates and they all ended at the next game (and the cubes that bottom all went crazy then came back into the next position).

cool right?  Well, I moved it from my development machine to my arcade machine and found that it worked well on NVidia, but the 3d library I was using only went to 2-3fps on an ATI video card.  I was so pissed I dropped the project and converted the animation parts to 2d.

Sometimes its good to move incremental development to your production machines to make sure nothing is majorly wrong as you go.

[ids]

Thanks for the reply Lilwolf.  The loop is actually this: paint what has changed, Thread.sleep(depending on configured refresh rate).  There really isn't much more I can squeeze out of it, to my knowledge.  My guess - which I'll confirm asap - is that on my desktop, the JVM is using video hardware, and on the cab, it's not, due to the USB based monitor.

What 3d library were you using?  I understand there is an OpenGL lib for java as well - maybe that would help?

I am also investigating using a raspberry-pi to drive the monitor.  That way I could offload the rendering so the cab can be devoted full time to mame.

[nexusmtz]

I am also investigating using a raspberry-pi to drive the monitor.  That way I could offload the rendering so the cab can be devoted full time to mame.

Glad you're looking into this. One of the easiest ways to ensure that software doesn't use too much CPU on a particular machine is to not run it on that machine. That may sound like the "It hurts when I do this / Then don't do it" joke, but having a second processing device can make sense. Of course, that second machine has to support your USB monitor (displaylink?) and be sufficiently powerful for your application, so a Pi might not be suitable. I know that the Pi can run (not power) a displaylink monitor, but that only gets you half way there.

[ids]

Thanks - Pi powering issues haven't occured to me, but I guess a powered hub in the middle would solve that.  I have seen references to getting the displaylink driver working, and some mention of Java on Pi.  That's about as far as I am right now.

I've also made some tweaks to the app and brought the CPU usage down when running on the cab to about 10-15%, but without a sufficiently powerful rig, I think it best to offload processing if possible.  For those running Gauntlet Legacy or NFL Blitz at full frame rates, this little app would probably go unnoticed, but sadly my rig isn't that.

[gamepimp]

Would u b willing to share ur program with others? I have a 2nd monitor that displays marquee images on my cab and a 3rd monitor in my CP that I plan to have display controls for the games. I am using Marquee Magician right now which works. But sometimes it seems a little flaky because it relies on the IrfanView program which I find to be a little buggy. I would def consider giving another program a try...

[ids]

sure, np, you want executable, or source?  Note that it is not a replacement for Marquee Magician, which probably performs much better, since it is just presenting static images.  Also, my stuff is not done, makes a few assumptions, and is not driven by any display files - it tries to work it all out on it's own.  No problems giving it away, as long as the limitations are known.  I am open to suggestions for improvements and new features as well.

[gamepimp]

Actually I would take both. I am trying to learn Java so that I can create a replacement program that works similar to MM but would be better suited for my setup. Ur source might give me a good foundation that I can build on. But in case I find programming too complex for my small brain, having the EXE handy would be great as well. 

[matsadona]

My guess - which I'll confirm asap - is that on my desktop, the JVM is using video hardware, and on the cab, it's not, due to the USB based monitor.

Well, it should be a significant difference running on the two (different) platforms. One the first one you have a dedicated GPU that handles the gfx. On the second you have no GPU, so the main CPU has to do that. If it is a lower spec PC the difference should be even more notable.

[ids]

Actually I would take both. I am trying to learn Java so that I can create a replacement program that works similar to MM but would be better suited for my setup. Ur source might give me a good foundation that I can build on. But in case I find programming too complex for my small brain, having the EXE handy would be great as well. 

Sorry, somehow missed this earlier.  Sure, will provide both.  Please tolerate a few days delay as I try to clean it up and tweak a few more things.  If you are new to Java, I'm not sure that this is something you want to jump into, as it is both a bit messy, and not very representative of typical programs.  If newish to programming overall, the code might prove challenging.  I could be wrong, I've been doing this stuff for a very, very long time.  Anyway, I will probably just post the code here when I feel she's ready for public viewing without too much humiliation.  If you can compile java, then no need for the "jar" file executable as well.  At that time I guess I should also post some basic info, such as the expectation for a history.dat, clone info, etc....

[gamepimp]

Sounds good. I'm newish to programming in general, but eager to learn and know that it will take some time to really grasp it. But hopefully taking a look at an example program whose purpose is to display images as well as videos on multiple displays might provide some pointers for me. My brother is a programmer and will undoubtedly mentor me thru the process. And perhaps if I'm just not able to grasp it, I might see if ur willing to tweak the program to do what I want it to do.  Thx again!

[ids]

Well, it should be a significant difference running on the two (different) platforms. One the first one you have a dedicated GPU that handles the gfx. On the second you have no GPU, so the main CPU has to do that. If it is a lower spec PC the difference should be even more notable.

Sure enough, there is no hardware accel w/ a USB monitor, and the difference IS noticeable.  However, it does report having some capabilities, like double buffering and such.  It's a bit of a challenge developing on a decent PC and then wondering how it will perform on a crappy one.  Interestingly, it also requires ~10+% CPU on my mac laptop, which is probably because the intel graphics are being used, rather than flipping to the good hardware.  Full screen mode would probably change that.

I have just added some additional optimizations.  On the good PC, sorting Task Mgr by CPU, the process is often so far down the list i have to scroll down to find it - on a 1920x1200 monitor, that's a lot of processes using more cpu.  They all show as 0%, but, instead of being in the top 5 with 0%, it's off the list most of the time.  Of course, it spikes when loading and scaling images, but the animation part is good.  Scrolling history still needs a bit of CPU, however - that hovers around 1% but is not as optimized at this point.

Just ran a loop trying all games with instruction cards, for testing purposes - took a while, but no noticeable bugs.  That was for 359 zip files claiming to include instruction cards, pulled from Mr. Do's site.

A clean, more optimal version will be posted here soon.   Not feature complete, but workable.

[ids]

Sorry, been very busy for some time and let this fall between the cracks.  Tweaked a few things to improve the UI a bit (see vid, tho not sure why the top bit is black throughout).  This is a rudimentary demo of how the app decides which bit of the screen is devoted to what artwork assest, how it scrolls the rest, etc.  Animation rates were cranked up to get through this quickly, but obviously, one would slow this way down so text is readable, etc. - these are all configurable parameters.  Lots of room for improvement, but here it is at the moment -vid: 

PM me if you want this early alpha code (Java).

[ids]

Finally got around to setting up an r-pi with Java and playing with this app.  Performance ranges from good to spotty.  To make it really hum, I think I need to reconsider time vs space optimizations in the app (mem is at a premium), and tune the OS a bit by removing unnecessary bits, such as NFS, SMB, sound, etc.  Perhaps this is the wrong forum, but if anyone has tips on which kernel build settings to play with, I'd be ever so grateful.  I do need basic networking so the mame-cab can tell it which game to show details for, display link driver, and X, but not much else.

[ids]

After a number of failed attempts, I finally got a kernel build to support the USB monitor and to use the full 512MB on the 'pi.  Performance, at first glance, is surprisingly good.  Found more sources of instruction card art etc.  I'm thinking this one has a future after all.

If anyone has interest in this, I'm open to sharing, and welcome feature requests.

Pics of CP with this going: 1) basic X startup, 2) arkanoid, 3) duck hunt

My only question now, is how to cleanly shut down linux when the cab goes down, but I'm sure I figure that one out in time.

[headkaze]

I know there are things such as Marquee Magician and MameHooker

You forgot to mention CPWizard 

[ids]

Sincere apologies.  I don't know how I left it off the list.  I was, in fact, running CPWizard for some time, and it is truly great software.

Thanks