Build Your Own Arcade Controls Forum
Main => Software Forum => Topic started by: ids on March 26, 2013, 02:55:21 pm
-
Since there are several recent threads discussing things like second display, marquee, move lists, etc, I thought I'd chime in with the software I've been slowly working on. Some history here. (http://forum.arcadecontrols.com/index.php/topic,123151.msg1338894.html)
The goals for this were:
1) zero config
I hate setting things up, and the mame world is very dynamic in terms of what artwork is available, etc. So the goal was to have software which would not need to be configured - it would figure it all out by itself. It would scan to see what images are available, what format (png, jpg, bundled in a zip or dir, etc) then auto-configure the layout to accommodate while avoiding blank spots, etc. Images would auto-scale, and if appropriate (e.g. wide street fighter instruction cards) would scroll automatically rather than downres to the point of being illegible. As an added bonus, if there wasn't much by way of images, the history.dat info could be displayed in some manner with nice fonts, colours, etc. It also checks the mamehooker dir to see if there is a display file for the chosen game, and does nothing if so. A lot of things ARE configurable to taste, but it should work like a charm out of the box.
2) performance
This thing needs to use as close to 0 resources as possible (cpu, mem, ...) to avoid interfering with Mame and anything else that is going on. I have worked very hard on this using very tuned code and various tricks to optimize performance without sacrificing the user experience too much. I call this one goal achieved.
3) Run anywhere
This was a secondary goal which became very important to me more recently. It has to run anywhere. I have personally run it on windoze, mac, and linux. The latter was actually a raspberry-pi using a USB based display-link monitor.
I've recently added:
- a default image for startup, and when mame is not running
- an option to cache scaled images to improve start-up time
- integration with mame through MisterB's app (http://forum.arcadecontrols.com/index.php/topic,118943.msg1343472.html#msg1343472)
- a fully commented config file with all options and their default values - yes, this is a "zero config" app, but this file helps when one wants to tweak
Any interest? Any additional features I should add? (old videos of it running are in previous thread linked above)
-
Yes. After reading the other thread I'm super keen to know how you're driving the screen. Yeah, USB, but .. never mind I'll Google it.
You won't have to apologize to anyone for using Java. Java IS NOT slow anymore. I'm a fan of .NET as well, which is also not slow.
I seriously think you may be onto something here.
I would also be very keen to see the code for that, if you don't mind.
-
Nice! I missed the original post somehow, but that looks pretty compelling for any secondary display. Those little USB monitors in particular.
It reminds me a little of my screensaver app that hooks into whatever media player happens to be running and grabs a bunch of images from google/bing/etc based on the artist/track/album playing, and shows them pan/zoom Ken Burns style. That might be a slick little extra to throw in. ie grab 5-10 "pac man" images off the web when you fire up pac man and throw them into the mix. Just be sure to turn on the safe filter :)
-
Nice! I missed the original post somehow
You didn't miss it. You posted in there a couple times. :)
-
sandheaver:
Driving the screen: custom build of the r-pi linux kernel to include the display link driver, then it's just standard X Windows and Java/Swing. It would be cooler to skip X and draw directly, but to handle history.dat text stuff, we need fonts and font metrics and.....at this point X is ok.
Java was never as slow as people think. Back in '99/2000 we had a massive swing based app which performed like any native app -- this at the time people were doing custom AWT stuff for performance. ???
The code is not very presentable at the moment (various hacky bits and some work in progress bits), but if you want it, pm me an email addr to send to (I don't see attachments as option in PMs)
drventure - your screensaver app sounds very cool, and very impressive - an interesting idea as well. I'll definitely put this on the to-do list, it'd be a great addition. Especially since I've been testing with only marquee images and instruction cards, and many classics don't have both - it gets sparse, and I find the history.dat text kind of ugly.
Nice! I missed the original post somehow
You didn't miss it. You posted in there a couple times. :)
:laugh2: Blame it on the fact that it's very late (at least in my time zone)
-
fwiw, as it is currently configured in my cab, part of the hyperspin AHK script includes:
UrlDownloadToFile, http://10.0.0.53:8080/%romName%, junkfile
this tells the program which game to display, and inadvertently creates an empty file called "junkfile" - not sure if this can be avoided, but it's no big deal either. This will all go away when I deploy a version with better mame integration, but I may need an update to MrB's app first.
-
fwiw, as it is currently configured in my cab, part of the hyperspin AHK script includes:
UrlDownloadToFile, http://10.0.0.53:8080/%romName%, junkfile
this tells the program which game to display, and inadvertently creates an empty file called "junkfile" - not sure if this can be avoided, but it's no big deal either. This will all go away when I deploy a version with better mame integration, but I may need an update to MrB's app first.
I believe curl can do what you want without creating any files. You could also just put the file in %temp% and let the system clean it up.
-
Nice! I missed the original post somehow
You didn't miss it. You posted in there a couple times. :)
Doh! I must be getting old. :-[
-
I believe curl can do what you want without creating any files. You could also just put the file in %temp% and let the system clean it up.
Thanks for the options, good to know. I went the AHK route out of laziness - Hyperspin uses the AHK script to launch all emus/games, so it was the easiest. (I then realized I had to tune my app to respond immediately so it wouldn't hold up the game launch. Previously it was coded to respond with a message relating to whether or not the game was known and had useable assets.)
I will leave the psuedo-web interface in, but plan to switch over to the mame-driven approach using MrB's MameWeb app. This will allow me to do more interesting things, such as recreate the workings of Mamehooker display files for those games with more interesting effects (e.g. gorf, lunar lander, spy hunter, atari football, etc). I imagine other things will become possible with the data feed from the mame output system. And having it all running on an r-pi with its GPIO....so many possibilities...
I am somewhat surprised that nobody from the linux camp has commented, given that most apps are written for winblows.
-
winblows
*sigh*
-
winblows
*sigh*
ok, sorry, i retract, i dont want this thread going into PnR ;D
-
fwiw, finally got around to testing the cache update. I create a dir based on the current resolution in use, as this will affect the final size of scaled images. This way, if you change resolution, or go windowed at some funky res'n, images will be rescaled and re-cached as appropriate. Under this, game specific subdirs are created on demand. Within each game specific dir the assets are cached based on type, etc. I also added code to search for assets in related (clone/parent/etc) games if we come up empty handed otherwise, in order to maximise the user experience. As part of this, I also added a low-pri background worker thread to produce hi-quality versions of the scaled images and write to the cache. The high-quality scaling is a relatively slow process, so it is kicked off after some minor delay, in the background. In order to present something to the user as quickly as possible, a low quality scaled image is quickly generated and used, then swapped as soon as the better image is available. The swap should be mostly unnoticeable (I haven't noticed it myself).
Overall, the startup time, when there are previously cached images, is noticeably improved.