Main > Main Forum

2nd Display Software fail

Pages: << < (2/5) > >>

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:


--- Quote from: ids on October 10, 2012, 10:50:52 pm ---.Net is also an interpreted language.

--- End quote ---

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.

Pages: << < (2/5) > >>

Go to full version