Universal Console Dashboard Project.

[Howard_Casto]

My hatred of the SuperBowl is your gain!  With absolutely nothing on tv tonight I decided to look into a project I've been meaning to do for a while, after I worked on mamehooker a little of course. 

Anyway, you know where on modern game consoles you can press a button on your controller and bring up a menu (aka a dashboard) that allows you to do various things including load and save states and exit the emulator?  Yeah we'll I'm making one.  There is a great need for this as many of the console emulators expect you to whip out a keyboard to do basic tasks like load a save state or even exit the emulator (often the exit key can't be remapped or binded to a joystick button).

Recently all of the popular console emulators got lua scripting support.  That allows me to draw on-screen and make a menu, which helps tremendously. 


I've made a test lua menu for fceux 2.2.2 (included below) which, while ugly allows you to access a rudimentary menu via your controller of choice.  If while holding start to pause the game you also hold select, the menu appears.  I've already managed to get a reset button and power button (exit the emulator) hooked up.  What I'm having trouble with is save states.  Even though I've followed fceux's documentation to the letter and even tried various other ideas I can get things to save and load properly.  This seems to be a common issue amongst the emulators (several of the 'X' emulators are using a common lua core). 

So I'm thinking I can just launch a keypress simulator app via os.execute... but os.execute steals focus away and displays an ugly command prompt.  Are there any ways to avoid this?  Perhaps there is a way via lua scripting to call the keybd_event api directly?  Any help would be appreciated as if I get this menu working properly it'll almost automatically work in snes9x, gens, pscsx and a few others. 

And yes, I will make it pretty, but we've got to get it functional first.

===================================

Update: 

GensRR now has a fully working menu!



Update 2: 

FCEUX is also done.  Includes Game Genie support!



Update 3:

Snes9x-rr is done!



Update 4:

You can now download the UCDP files from my site:

http://dragonking.arcadecontrols.com/static.php?page=AboutUCDP

[Howard_Casto]

Wow, I figured there would be more interest in this.  Upon further inspection it appears that fceux's lua implementation is borked... I wasn't doing anything wrong coding-wise.  I might see if there is another build out there that works better. 

In the mean-time I wanted to see how portable the system is.  The answer is pretty portable!  I changed only a couple of lines of code and got it working in Gensrr 11b.  Save and Load actually work in this emulator.  Right now I've got it hard-coded to slot 1, but I'll eventually add a menu allowing you to select the slot.  Again, right now this is just a proof of concept deal, I'll make it pretty and add the nice features later. 

If you want to play with it I'll include it below.  With this one you pause, hold and press the "mode" button.  I'm not as familiar with Genesis operations so we may have to change that.  Also note the menu isn't centered due to increased resolution.  I'll fix that later. 

I know there is also lua support for snes9x and I believe a few of the n64/psx emulators support it as well.  Quite frankly that's all I care about in terms of console emulators. 

[Howard_Casto]

Hmm, maybe there isn't any interest due to the title and lack of pics. 

The goal here is to make an in-game menu for all the popular console emulators so that you can do all the major tasks, including loading and saving states, resetting the console and saving the game using the original controller. 

Here's a pic of the Gens Menu, which I've gotten the furthest along with.

[pfcwintergreen]

It's a cool idea, and I share you hatred of the superbowl,  but as far as lack of interest goes it might be because of existing projects...namely Hyperpause; If I understand your concept correctly it's pretty similar(albeit Hyperspin-only). The problem with Hyperpause is that it's a configuration nightmare(at least in my experience) due to the fact that different emulators respond in unpredictable ways to the program's attempts to suspend the emu's process. I suppose going the lua route will fix that, right? But then wouldn't there be a lot of emulators that don't support lua? I am interested in this but I don't know if I would implement it on my cabinet if it could only work with a few(lua-supporting) emulators.

Well, in any case thanks for looking into it and all your other tools(troubleshooter 2 etc).

[Howard_Casto]

Hyperpause, with all due respect is the most convoluted way you could possibly do it.  I'm not a fan at all.  Much respect to whoever decided to tackle that one, but I've tried making various external methods over the years.  They never work and when they do it's so convoluted that nobody will bother anyway.

This is for console emulators only.  If you are on a mame cab you'll have access to a keyboard ect and savestates aren't that important, but on the other hand if you are using a console emulation box, you have a gamepad, and hopefully that's it. 

There is zero configuration involved with this method, unless you count having to add "-lua menu.lua" to the command line string when you launch a rom.  Because it's lua the menu is actually rendered in game, so it's a part of the emulator essentially.  You don't even have to configure the buttons... these lua scripts use the game button memory addresses, not the physical joystick buttons, so it automatically looks for whatever you have mapped to select + start or what have you. 

It looks like there are lua enabled emulators for nes,snes,genesis,n64 and psx and I believe Atari 2600.  That's all you really need.  Earlier consoles don't have anything to save and newer ones should have the ability to save at any point. 

[Le Chuck]

Support for all my fav consoles would be pretty great really, NES/SNES/N64/SG

Keep it up. looking forward to you again making my gaming life easier 

[nullPointer]

Holy Crap!  I just stumbled across this.  What a great idea Howard.  I can't wait to see where you go with this.

Just as a general question, are the visual elements divorced from the "functional bits", or is everything pretty well tightly integrated?  I'm not overly familiar with Lua, but if one were interested in skinning the GUI without screwing up the functionality, is that something that would be possible?  (And yeah, I know you said you would prettify it at some point, I was just curious).

Keep up the great work!

[Draco1962]

Fantastic idea!  In addition to user skinning, will the application be frontend friendly?  I am really looking forward to seeing how this develops!

[Howard_Casto]

In terms of skinning, it's possible, BUT we'll probably want to make two separate versions, a graphical one and a "lite" one that just uses internal rendering. 

The loading of images requires the gd image library for lua to be installed.  While you only have to do it once, it isn't exactly a walk in the park to install.  Also I'm unfortunately limited to the game resolution.  So for snes/genesis, ect something fairly nice can be added, but for the nes / mastersystem ect I don't know how much can be done graphically.

The idea was to try to theme it around the console.  I've since refined it a bit from the screenshot, but the genesis one uses that classic grid pattern, ect.   

Right now my biggest challenge is finding the best versions of each emulator.  Gens works flawlessly, but the others have some issues.  I can't get save states to work in fceux... it might be fixable because the source code is available.  Snes9x is having some sort of issue, but it has to be something I'm misunderstanding because it errors out when trying to read the gamepad, which is pretty basic functionality.  I haven't looked at the others yet. 

These are all offshoots of the old "rr" project that helped people make emulator assisted videos.  So in theory the lua scripting is universal amongst the emulators but in practice there are various minor inconsistencies.  Since Gens is fully working I'll start with that, and modify the script for each of the other emulator's quirks. 

This is one of those spare time deals..... much like fix it felix, it isn't a huge project.  I'll finish the gens script later tonight and work on the others when I get around to it. 

[Howard_Casto]

Ok here's my first completed prototype, a Menu for use with Gens-rr 11b. 

Installation:

1.  Place this lua script in your "Gens11b\lua_samples" folder.
2. Configure your FE of choice for Gens as normal only add the command line flag "-lua c:\gens11b\lua_samples\GensMenu.lua" to the end for launching options.  (Note the full path might not be necessary, I'm not sure.)
3.  Enjoy!

Usage:

(Note:  When I mention buttons I am referring to the virtual buttons on the Genesis gamepad for player 1, what you have them mapped to is dependent upon how you've got Gens setup.)

To bring up the menu, press Start, which should pause your game and while holding start press the "Mode" button.
While in the Menus, Up and Down navigate, the B button selects and the A button backs out.  Start and Mode don't do anything while in the menu.

Menu Features:

A "fake" reset I made via capturing a save state when the emulator starts.
A power button, which exits the emulator. 
Load/Save State selection menus, allowing you to choose from any of the 10 standard slots to save/load a game.

Bugs:

I need to implement better button de-bounce code.  Right now you need to be careful when you go into the load/save menus or you'll accidentally jump two menus and select a slot by accident! Just tap the buttons for now and I'll fix it tomorrow hopefully.

[Howard_Casto]

A set of screenshots (note, I had to do these in windowed mode and Gens doesn't scale well... it looks better at full-screen):

[Howard_Casto]

Ok so I looked into the snes9x issues.....

What happened was that for whatever reason they stopped making a "rr" version at around 1.52 and 1.52 is borked.  If you use an earlier version the scripts work just fine.  I even plugged in my gens script and aside from some save state issues (saves are coded differently in snes) the menu looked and behaved identically.  So we'd have to run 1.51 or earlier.  I'm not sure what has been changed in snes9x over the years, but even version 1.53 is around 4 years old.  The source to 1.52/1.53 is available on google, so if somebody wants to get it working....  I can help but I'm not up for a huge project atm. 

[Howard_Casto]

So I opened an account on the TAS forums... immediately got a response as to my fceux issue, which is always nice. 

So now I've got a way to implement save/load on fceux. 

I also made a script for snes9x that is more or less the gens script save some graphical changes.  There is an issue with snes9x though, namely you can't launch a lua script from the command line.  I might have to do a quick compile of the latest build an add command line support at a later date. 

I also looked into the "gd" image format.  It's all text based, so rather than require the gd library I could just write a quickie program that converts a standard image to a bit of code.  It might take a while for a program to parse an image, but it would be as simple as using the "getpixel" api on each pixel in the image and converting it to a format like so:

"\alpha\r\g\b" and adding it to the string along with a header specifiying the dimensions. 

[Howard_Casto]

Ok GensMenu 2.0.

Second verse, same as the first!  For use with GensRR 11b or higher.

Fixes:

Improved Visuals.
Fixed de-bounce, so now you won't accidentally blast through both menus.
Menu no longer disappears after a selection... you'll have to back out via the "A" button, which seems to make more sense.
Loading and Saving fully working with full error handling. 

Long story short, this version works perfectly.  All the versions for the other emulators will be based on this script.  Enjoy!

[Howard_Casto]

I'm on a roll!  Fceux is finished!  Any version that supports lua scripts should work. 

With this one install/syntax is a little different. 

fceux.exe -lua nesMenu.lua "c:\path\to\rom\rom.nes"

Also put the lua script in the same folder as the exe, NOT in the lua scripts folder. 


It looks a little different (nes color scheme) but it operates exactly like the Gens version.  Just press start to pause and hold select to bring up the menu.  If you have problems fceux not reading inputs, check the "background inputs" box in the emulator's options.

[Le Chuck]

Awesome, keep after it.  You're going to make my HTPC so much more user friendly!

[Howard_Casto]

Thanks, I'm trying. 

I looked at Mupen RR... is that a good emulator?  I always used project64 back in the day.  Anyway, the syntax seems straight forward, but the render loop now works in a different manner, so I can't just drop it in and tweak away like the others.  It would be straight forward to fix, but Mupen's documentation is in Japanese, so there's that. 

I'm not going to do anything newer than the psx/n64.  After that they figured out that it might be nice to be able to save games at will.  It only took 20 years. 

Something I haven't mentioned is that the TAS Video community has moved away from the RR builds and on to bizhawk, which is some sort of multi-console emulator.  If I write a script for it, it'll work on multiple systems.  That being said much like mess it's a jack of all trades, master of none.  Some features and emulation "thingies" that are standard on other emulators aren't in it yet.  So it made sense to me to work on more familiar emulators first. 

It should be a viable emulator for older systems like the 2600 and Master System though.

2600 should be interesting.  I would like to write a menu for it that brings up the dip menu and gives you access to reset and power.  The question is how would you bind a hotkey?  Hold the fire button for a really long time?

It would also be nice if I could somehow read the rom name.  If I could then I could take snapshots when the user saves and use those in the load/save menu instead of numbers.

*EDIT*

Oh btw I've got a working snes9x script as well.  The problem is the emulator doesn't support the loading of lua scripts via the command line?  The source is out there, I can fix it, but it'd be nice if somebody else helped me on this.  I don't have a compile environment setup and call me lazy, but that sort of thing takes a long time to configure. 

[Howard_Casto]

Ok so I was checking my email and ran across an article to read the state of the 360 guide button.  I thought that was pretty cool so adding guide button support to these scripts might be nice.  Honestly I should know this stuff... I had to learn how to use xinput for mamehooker, but people keep finding undocumented functions in the xinput dlls.

I can't (easily) do it directly.... the lua scripting reads virtual buttons on the gamepad, not unmapped joystick buttons.  Since this would be useful for other stuff, an app that allows you to bind the guide buttons to keyboard keys, combined with the "power off" app I linked to in another thread, would probably be the way to go. 

I CAN get the input state of all keyboard keys, so I could map the guide button, to, let's say the tab key and then write the scripts to also respond to tab being pressed. 

[wp34]

I just stumbled across this and am very interested.  I'm starting to look at a console emulator/HTPC and this looks like the cat's meow.

Thanks Howard.   

[Howard_Casto]

So I was perplexed by the lack of support on snes9x... looked into it.  Apparently there is a bsnes (superior) port out there with lua support.  The reason I didn't find it?  It's named lsnes???  Seriously every other "rr" build is either the name of the emulator +"rr" or the name of the emulator +"X".  Why lsnes?

Anyway, I'm going to try to make a script for that tonight.  I honestly would still rather use snes9x though.  While lsnes touts better emulation, man whoever designed the interface must have been an engineer.  That's all I'm gonna say. 

[Howard_Casto]

I mentioned earlier that the lua implementation doesn't natively support the importing of normal image formats and that I might write a "gd" converter.  Well I did that last night, tested it and it didn't work.  I took another look today... it turns out I forgot to set the read mode in lua to binary file.  So yeah with the help of my converter we should be able to skin the menus without the need for the gd library. 

I set a practical limit on the image dimensions to 255x255, namely because I can't figure out how to add large image dimensions to the gd header.  That sounds small, but keep in mind that we are limited to the screen resolution on these games, which is around 240p. 

I did a quick test below.  The cut-off point on the test image is 255 pixels to give you an idea.  That seems more than large enough and we can always tile images.  Before you ask, the magenta all around the image is just due to my sloppy image editing... it's a color key system (full transparent or full opaque) and lacks a true alpha value.

One oddity is that you are stuck with not only the game's native resolution, but it's bit depth as well.  Genesis and Snes are 16 bit systems so graphics look pretty much unmolested, but the NES... ugh... 8 bit graphics people.  We might need a pixel artist to do that one. 

[Howard_Casto]

I wanted to see what I could do graphically with the gdoverlay function so I whipped up a test menu for the genesis.  As you can see either the grid or that font has to go, but the point was to see if it looks stupid.  Looks pretty good regardless. 

Just for the record this massive menu is only 186x180, so yeah, I don't think the 255x255 resolution limitation I imposed is going to be an issue. 

[liquid8]

Great job, Howard. This will be another handy tool from you 

I haven't messed with lua much lately, but if you needed help with any testing or menu creation for other emus, I'd be willing to help out. I'm okay with graphics and have a lot of programming experience.

How limited is the lua for emu control - does it allow you to perform any functions or only ones that are exposed to you? For example, could you change emu-specific settings? Can you load roms on the fly from the menu?

How limited is the lua scripting in general and with image support without gd? Could you load boxart, history info, etc? Can you use other fonts? Is the 256x256 limit for the whole menu or per image?

The genesis menu looks pretty good with the system logo - anything with gridlines is probably not going to be great. I'd suggest going with a simple system theme like:

NES


I hadn't seen these before, but some interesting ideas and menu concepts:

http://devster.monkeeh.com/sega/radica/#whatisit


https://code.google.com/p/genplus-gx/

[Howard_Casto]

It varies from emulator to emulator.  Typically what we have control of is very limited.  Aside from what I've already exposed, you can load roms and sometimes apply game genie codes and that's about it. 

You can run external program via os.execute, but like with most lua implementations, the function works poorly, showing the command line, not retaining focus ect. 

In terms of the examples you posted fceux is probably going to get something basic like that due to the 8 bit limitation.  The gens plus menu is probably beyond what I can do... the resolution I have available is half that.  Ignoring the gd limitation, the genesis screen resolution is 320 x 223 and gens gx uses a 480p menu system.  That's the reason I cut the "sega" off of the genesis logo btw.... at that low a res it looks like a blurry mess. 

Image support without the gd library is non-existant.  The engines will only render/load images in gd format, so they have to be converted.  A manual conversion takes about 1 minute for a 255x255 image.  Now a couple of the emulators have an auxiliary image library built in, but it isn't universally supported. 

Fonts aren't supported at all.  Obviously you can make an gd-based font, but other than that you are stuck with the emulator's "system" font, which is what you see in the earlier screenshots.  It's very small and very ugly.   

The limit is 256 x256 per image.  Each image takes up around 256k of memory, which by modern standards is nothing, but it's something to keep in mind. 

[liquid8]

here's a couple quick mockups:





let me know if you like that.

Also, I took a look at the lua stuff, seems fairly simple. I was trying to play around with the emu.advanceframe and emu.pause - is it not possible to prevent input in the game while in the menu? I guess the lua is part of the emulation, so if you don't advanceframe or if you pause, the menu won't work...

Do you have a new lua you can provide where the graphic can be overlayed?

[Howard_Casto]

Yeah I was rather disappointed with that as well.  Emu.pause doesn't press the pause key, rather it halts emulation.  So your code loop halts as well and thus it's useless.  You can simulate a button press via joypad.set, but seeing as how you wouldn't know if the user already paused the game... again, a dead end.  Now if the state game pause is held in a universal position in memory, there are memory read/write functions available, so maybe it can be done that way... I dunno. 

That's why I binded the hotkey to start.... this way the user hopefully pauses the game as they bring up the menu. 

Both look good.  I think we can do better with the font, but other than that.   

The lua code in using for the graphics test is just that, it isn't hooked up yet and just displays an overlay.  I'll post my gd converter and test script this evening. 

Before we get all graphical I want to look into retrieving the rom name.  I think I have limited access to the winapi, I might be able to read the window caption that way and parse the rom name.  If I could then I could use the screenshot function to save an image each time a save state is created, which would be better really. 

[Howard_Casto]

Ok here is something to play with.  I've included my gdi converter.  It's pretty straight forward. Load a jpg bmp(preferred) or gif then click the save button.  The resulting gdi file can then be read into lua via a generic binary read.  Anything magenta will be made transparent.

I've also included the graphics test script I whipped up.  Keep in mind it just shows the graphic and nothing else.  An odd quirk about Gens is that the root directory as far as lua is concerned is the exe path, not the lua script path, so the gdi file needs to be with the exe.

[Howard_Casto]

Ok I looked into getting the rom name somehow.  Gens doesn't include winapi support... fceux does.  More inconsistencies (*sigh*).  So for gens we have to do it the hard way.  Luckily sega is so anal about labeling their roms.  @ 0x120 there are 48 bytes in each cart that is the rom name.  So problem solved on that one after a bit of clever memory reading and byte/string manipulation. 

I'll see if I can manage to make and reload a screenshot as a gd file. 

[Howard_Casto]

Ok time for another sigh. 

Gens is just being difficult.  Now that I have the rom name I can indeed save a snapshot to file.  Unfortunately the gdoverlay function in Gens doesn't allow you to scale images. 

So yeah, I guess I could do something fullscreen?

[liquid8]

OK, tried the img2gdi, but I'm getting an Runtime error '6' Overflow and just a blank image.gdi file. I tried in bmp, jpg and gif formats.

It looked like fceux has an option to take a screenshot without gd.. does gens not have that?

I don't know if a screenshot for the save state is really necessary - especially with limited real estate.. what about just storing the date and time of the save?

[Howard_Casto]

What are your image dimensions?  Remember 255x255 (one byte by one byte in the header) is the maximum size allowed. 

Nope, gens doesn't have any image libraries attached unfortunately. 

I know on modern consoles (Wii, Wii U, ect) a snapshot is always used to identify the save state and honestly it is a lot easier that way.  I can always draw on top of the snap, so perhaps a "Select a state" message along with up and down arrows indicating you can scroll through them. 

[Howard_Casto]

Ok so I had one of those "duh" moments after I took a break.  The game saved me a full res gdi, so why not look at it's header to determine the format?  It turns out what I thought were null-terminators weren't, so that was the issue. 

This new version will support any resolution, although obviously we are still limited by the game resolution.

I might look into doing a full screen menu with this new found freedom.  I wasn't going to attempt it if we had to deal with tiling. 

[liquid8]

Yep, my mistake - my psd still had the dimension of the system resolution

Playing around a bit.. here's the result



I'll post more tomorrow...

[Howard_Casto]

Looks good man. 

I figured out something as well via a net search.  You can do a "fake" pause which will work for our purposes.  What you have to do is put the frameadvance in a a if statement and call a manual redraw and wait command whenever you want to fake a pause. 

So emu.frameadvance()

becomes:

if MenuDis==0 or MenuDis==nil then
   emu.frameadvance();
else
   emu.redraw();
   emu.wait();
end;

Basically we check to see if the menu is on, if it is, we pause. 

Now this brings up three additional issues.  First off the game renders unthrottled, so the dbounce variable I have towards the top has to be changed to a crazy high number like 40.  Secondly you can't read the gamepads with joypad.get... use joypad.peek instead.  Lastly the sound buffer screws up when you halt the screen, so call a sound.silence() when the menu first pops up. 

So yeah, we are getting somewhere now. 

[liquid8]

bah.. here's a fully working version   

https://www.dropbox.com/s/qop66ag80adyyrc/gens-menu.rar?dl=1

I did modify some of your variables in that though 

[Howard_Casto]

I took a look at some old genesis boxes.  I'm wanting to base the menus off of the consoles artwork.  The aesthetic was very similar to the virtual console on the Wii, so I mocked this up.

I figure I can have the buttons float in the center like wii menus do, only make them rounded black buttons like those on the Genesis rev 2. 

I want to keep working on the script and make the whole thing fully skinnable via swapping out a few variables at the top. 

I know it's ridiculously big btw, but I started thinking that in a htpc/emu box situation you'll be sitting far away from the tv, so maybe a small menu isn't the best option.

[Le Chuck]

Keep it up, that looks great

[liquid8]

I took a look at some old genesis boxes.  I'm wanting to them the menus off of the consoles artwork.  The aesthetic was very similar to the virtual console on the Wii, so I mocked this up.

I figure I can have the buttons float in the center like wii menus do, only make them rounded black buttons like those on the Genesis rev 2. 

I want to keep working on the script and make the whole thing fully skinnable via swapping out a few variables at the top. 

I know it's ridiculously big btw, but I started thinking that in a htpc/emu box situation you'll be sitting far away from the tv, so maybe a small menu isn't the best option.

Looks good.. yeah fullscreen menu would be nice - unless you aren't able to make the "pause" happen, then i'd keep it small so you can still see what is going on in the background.

Is it possible to use external fonts or at least modify the font size? I couldn't figure that one out.

Would it be too taxing to load up multiple images and overlay them on top of one another?

[Howard_Casto]

Pause works well.  Now the only thing that makes me worry is the part about the game running unthrottled.  People might have to adjust the dBounce variable based on their own computer's speed, so I'll put it at the very top of the script. 

Well there's no reason to use text really.  We have 4 buttons and that's it.  So just make an image. 

Now if we start having some reason to draw text on the fly, then we can look into a gdi-based font or something. 

[Howard_Casto]

Alright, I've got the first menu scripted with graphics anyway.

Yeah those buttons are too big.  That's my problem. I'm working in 640x480 resolution and then shrinking stuff down when I'm finished, but I forgot that the Genesis resolution is 320x224, not 320x240, so they turned out way too tall.  I'll go back and fix it later. 

I'm not super fond of the red as a highlight, I might rework that to make the selected button have full on white text and a white border with unselected having a black border. 

Anyway, all the stuff I've added thus far is fully skinnable.  At the top of the script is a X position, Y position, Alpha Value and URL for both an "On" image and a "Off" image.  To make a new skin you would simply run your individual images through the gdi converter and change the variables to your liking. 

Here's how I'm going to do save states, for Gens at least... Snaps with be optional and have a Boolean value at the top of the script to turn them off/on.  The select a slot menu will be similar to how it is now, and if snaps are enabled they will be displayed behind the menu where the game normally shows through as you scroll down the list.  You should be able to see enough of the image to tell which save it is and this way it doesn't look out of place.  When the image is missing a default image will be shown.  If you use the lua script exclusively for saving, this will allow you to tell which slots are already used when saving, which was kind of the point. 

Anyway I'll work on all of that later tonight.   

[Howard_Casto]

Well I got the load/save state menus all sprite-ified.  The snapshot loading/saving looks pretty good as well.  I might have to put it behind the dimmer box though... sometimes it's hard to see the state numbers. 

I need to do some cleanup either tonight or tomorrow, but I think the first menu is fully done! 

It'll be superficial to transfer this over to the Nintendo emulator, I just need to make new graphics. 

[Howard_Casto]

Well I was going to get all fancy and use the "registerhotkey" function in lua so you could also bind a keyboard key to bring up the menu.  Unfortunately the function seems to be halfway broke.  It keeps throwing a error every so often for no apparent reason.  So I hard-coded it to tilde.  That seems like a good one as it'll be mame compliant. 

I think I'm done with Gens at least.  I mean I could obsess over the graphics but I've made it skinnable so somebody else can worry about it.  I'll post snaps and the Menu system later tonight. 

[Howard_Casto]

Well the walking dead is on in a few, so that might be the last you hear from me tonight (unless I log on to complain about TWD in everything else )

I'm just trying to keep people updated.

I started thinking... I'm already reading the rom name from the cart in memory to name the screenshots so I guess I might as well read it all.  I made a little function (which will probably be optional) that reads the "base system" entry in the game header and auto-select between one of three menu images.  One for the Genesis, one or the 32x and one for the Sega CD.  It probably isn't 100% reliable because the SCD shows up as a megadrive but it'll do. 

Something oddball popped up that I'm wondering if someone can confirm.  The only Sega CD gam I have to test with is Batman and Robin.  When the cd is booting the menu shows fine, but once you are in-game the menu is stretched past the screen on the right.  Maybe a buffering thing?  If it's just some cd games I won't bother, but if it's all of them we might have to make a custom skin just for the Sega Cd. 

[Howard_Casto]

Ok I'll release the Gens Menu either late tonight or sometime tomorrow.

In the mean time we've progressed enough for a Demo vid. 

[nullPointer]

Dude!  That is badass!!     Great job on this Howard.  Just awesome!

[Howard_Casto]

Ok here is the "final" version.  Of course we all know it never works out that way. 

I've included the img2gdi converter and an actual readme file this time.  I've also moved all the loose files to their own folders so the Gens folder isn't all cluttered.  To launch stuff from a relative folder you use lua-style syntax, so now the flag will be:  "-lua ".\Menu\GensMenu.lua" "

I'll post my photoshop templates and ect if anyone is interested later.  This will eventually get posted to my website, but I learned with the Fix it Felix wrapper that it makes for a better use of my time to just post small stuff here until the releases start slowing down.  FCEUX is next!

[BadMouth]

For those not following closely or discovering the thread later, a running list of supported emulators in the first post would be nice. 

[Howard_Casto]

If I had that info to give, I would, but atm I'm tackling this on a case-by-case basis.  I know the FCEUX fully supports roughly the same scripting as Gens, so that's what I'm currently working on.  snse9x was a pseudo-bust so I'll have to look into lsnes.  Mupen64's gui engine seems to flicker like crazy, so n64 support may be completely out of the question. 

This is very much a WIP thread.

[Howard_Casto]

Ok so aside from not figuring out how to pause the game like in Gens, I got everything working in fceux.  Below is my initial design for the menu.  It may be too artsy-fartsy, I dunno.  The emulator has a very low color palette so I'm trying to get the color count down.  Again, like with Gens I went to the game box art for inspiration. 

We'll see how it turns out in testing before I go on with this design. 

[Howard_Casto]

Eh it's not looking too great. 

The working resolution of 240x224 is pretty low so I can't scale things down well.  It looks like this one might have to be done manually at the native resolution.  Pixel by pixel. 

[Howard_Casto]

So I did a new menu pixel by pixel for the most part.  It turned out decent, pretty retro as you can see below. 

And yes that's a game genie menu item... fceux supports game genie codes, so I don't see any reason not to include support.  I'll create a simple text file format and you'll be able to pre-load GG codes and turn them on and off at will in the menu. 

[Howard_Casto]

I started adding the Game Genie stuff, which is taking longer than I had hoped. 

I had to learn how to read a text file into a 2d array in lua, which is a pain in the butt compared to other language, syntax speaking.  Also FCEUX does something incredibly retarded.  When you add a GG code it saves it to file so that it'll enable each time the game is played.  So I'll have to delete all game genie codes prior to exit. 

[liquid8]

Lookin' great, Howard.. I've been out a few days with a nasty flu and a dentist visit.

Gens looks real nice - only suggestion would be to make it a little easier to see the save state positions.. and I still like to see a save date/time for a save game if it is possible to read the save state file date

The NES menu could use some work - I'm sure someone is good at some pixel art and could make it look super nice. The game genie is a cool touch 

Any word on "pausing" FCEUX? I could take a shot also if you are still having trouble.. it'd be nicer if any emulator function could be implemented in lua as well but I guess that is a per-emu basis decision

[Howard_Casto]

Well strictly speaking I can fake a pause, but nobody would be able to stand using it. 

I wrote a function that makes a temporary save state when you first enter the menu.  While the menu is up the state is constantly re-loaded at each render loop, essentially freezing the game. Once you exit out of the menu, the state is released and things unpause.  The only problem is the sound buffers.  Gens had an option to clear them, but fceux doesn't.  So yup, you've got stuttering sound the whole time you are in the menu.  Now if anybody knows the memory location to zero out to clear the sound buffers, it could probably be fixed, but it's disabled for now. 

The winapi dll is built into fceux... I thought I would be able to use it to pass keyboard keys to the emulator and essentially fake hotkeys, but it doesn't really work.  About the only thing I've found useful about it is I can read the window title to get the rom name. 

As for the graphics and what-not, they are done as far as I'm concerned (except for the game genie menu of course).  If someone wants to tweak them they are welcome. 

[Howard_Casto]

Ok it took the evening, but for the most part game genie implementation is complete. 

You make yourself a text file like this:

-----------------------------------------------
0|Infinite lives for Mario and Luigi|SLXPLOVS
0|1 life for Mario and Luigi after continue|AEKPTZGA
0|9 lives for Mario and Luigi after continue|AEKPTZGE
...
...
------------------------------------------------

Then you name it after the rom and put it in the "GameGenie" folder and it shows up like the included snapshot. 

I still need to do some minor things like save the current states or possibly use the "cht" file format that the emulator uses natively.  Anyway, this one will be done really soon.

[Howard_Casto]

Still some more cleanup stuff to do, but:

[stigzler]

This looks fantastic!

Having recently spent weeks mapping emu hotkeys the cab function buttons, this would have been a godsend!

I'm wondering if there are any plans to add things to the dashboard menus. For instance, lot of emus have hotkeys for things lile start avi recording of tKe snapshot. Eg2 pcsx2 apply filters or change anti aliasing

I guess some kinda user configurable menu item text and corresponding sendkey (sending relevant hotkey?)

Great job.

[Howard_Casto]

send keys just isn't working, I've tried.  So I'm limited to what I can hook up by what is implemented in that particular emulator's lua scripting.  Like the reason fceux's menu has game genie codes and Gens doesn't is simply because Gens doesn't support game genie.

I could add movie options of course, most of the "rr" emulators have that stuff implemented, but I'm not sure how useful that would be.  I've only got so much screen real-estate to deal with, so I'm trying to add only functional additions.  In the case of fceux I would really like to add the ability to switch controller types, but I haven't figured out how to do that yet. 

[Howard_Casto]

Ok so a guy over on the TAS forums clued me in on how to fake a pause... it actually works pretty well. 

I've got to cleanup all the junk code I made with my method and test a bit more, but I think this will do it. 

[Howard_Casto]

So I was playing around with the built in win_api functions in fceux.  There is a "shell" function that works much better than the OS.execute you normally get.  So I made a generic keypresser and went to town. 

Although it will probably be optional, I can now exit the emulator via simulating the "esc" key, which should allow you to retain any settings you might have changed upon exit. 

Also I might add input preset support.  I actually setup the keypresser to press f4, f5 and f6 and mapped those keys and it worked well.  The only thing is that from my testing presets might not even be needed.  I fired up a lightgun game and it had sense enough to understand that it needed to use mouse input.  I'll have to test on a 4-score game or something exotic I guess. 

[Howard_Casto]

Ok the FCEUX script is done! 

You can download below.  Note that there are two features, exiting via simulating a keypress, and the presets menu that are turned off by default.  This is because they rely on an external key presser program, which might not play nice with your system, and require additional setup.  See the readme for details. 

Edit:  OOPS!  I forgot to update the menu image, which has squished the "I and N" together in "Entertainment System"  You can download the link below, but it's going to be removed in a second.

Update:  1.1 is up, download and enjoy!

[Howard_Casto]

It doesn't look like anybody has actually downloaded any of the scripts I've been writing... maybe I'm wasting my time, but in case I'm not:

I need help on this one.  I have assessed our snes options and they all have something wrong with them.  The "most working" appears to be snes9xRR, only it doesn't support the launching of lua scripts from the command line, so I wrote this ahk script:

---------------------------------------------------------------------------------------------------------------------------------------------------------
IniWrite, FALSE, snes9x.cfg, Display\Win, Fullscreen:Enabled ;Ensure fullscreen is off
IniWrite, SnesMenu.lua, snes9x.cfg, Settings\Script, LastScriptFile ;Write to the ini file the lua script name

Run, snes9x.exe,,, PID ;Launch snes9x
WinWait ahk_pid %PID% ;Wait until emulator loads
sleep, 50
WinMenuSelectItem, ahk_class Snes9X: WndClass, , File, Lua Scripting, New Lua Script Window... ;Open lua dialog box
WinWait ahk_class #32770 ;Wait for the dialog to load

sleep 50

ControlClick, Run, Lua Script  ; Clicks the OK button  ;click the Run button on the dialog box
 

sleep 50

WinMenuSelectItem, ahk_class Snes9X: WndClass, , Config, Video, Full Screen  ;Go to Full Screen mode

WinWaitClose ahk_pid %PID% ;Wait for exit.

IniWrite, FALSE, snes9x.cfg, Display\Win, Fullscreen:Enabled ;Set the fullscreen mode back to false.             
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Now technically this script works, but it's unreliable.  I would say it manages to press the "run" button to start the lua script about 50% of the time.  So are there any ahk experts out there that can make this more robust?  Thanks. 

[Howard_Casto]

It doesn't seem like anyone is interested in this, but oh well, I want to at least get a snes emulator working. 

I managed to robust-ify the ahk script.  It's 95% reliable now, which is good enough. 

So I think I've finally got all the kinks out of the snes9x script as well.  The one thing I couldn't manage to do was fake a paused state while in the menu, so I did the next best thing.  Upon entering the menu I save the state to memory and upon exiting it I reload the state.  So even though the game runs in the background, you'll get returned to your original state prior to entering the menu, so it doesn't matter. 

Here's the snes menu.  It looks pretty good considering the 256x224 resolution.  I've still got to do the load/save state screen, but this one is about done.

[nipsmg]

I am actually really interested in this... i've been wanting to make a console-only box with some common UX across the experience for a while...

Problem is same with everything else.. no time.  Too many unfinished projects. 

I hope this one doesn't end up dead, I just wish I had time to contribute to it.

[Howard_Casto]

Well that's the issue with me as well.  I don't mind doing these projects but seeing as how I essentially have to do everything from scratch and never get any help, I have to pick and choose which ones to tackle anymore. 

Anyway, a real quick snes9x preview:




The script needs a bit of cleanup, but I'll have it done tonight most likely.  This is probably as far as I'll go for now.  There are certainly other emulators that need a menu, but either they don't have lua support, their lua support is broken, or the emulator itself is out of date. 

Sega Master System was one I wanted to do, but I thought about it and the lack of select/start buttons would make it really hard to achieve my goal of bringing up the menu on the original controller.  Plus I can't find a SMS emulator with lua support. 

I wanted to do the n64 as well, mostly because of it's awkward save hardware (you have to remove the rumble pack, even on a virtual n64, before saving) but Mupen 64rr, the only one that works, doesn't seem to have really great gui support.... I'll look into it though.   

[gonzo90017]

Awesome project!

[Howard_Casto]

Thanks. 

Snes9xrr is done. 

I'll work on making a page tonight maybe. 

[Howard_Casto]

Update: 

The UCDP now has a home at my website... all downloads can now be found here:

http://dragonking.arcadecontrols.com/static.php?page=AboutUCDP

[Howard_Casto]

Ok I've probably gone as far as I can in regards to the popular emulators out there, but I did run across this:

http://code.google.com/p/mame-rr/

So yeah lua scripting for Mame/Mess 144.  I just don't know if it'd be worth doing.  That's 10 full versions behind the current build and I know that MESS recently made some pretty dramatic leaps in emulation.  I mean maybe for some of the older systems like the master system and the 2600, but other than that....

Comments?  Suggestions?  Dirty Looks?

[nullPointer]

I just wanted to say thanks again for all your hard work on this Howard!  This project also has a bit of a following over on the GameEx forums.  Hopefully it's cool that I took the liberty of re-posting over there.  Thanks again!

[Malenko]

any way to make the GUI skinnable? that NES one is pretty ugly.

[Howard_Casto]

They are already skinnable, and pro tip.... don't insult someone when asking for a feature. 

If you'd follow along in the thread you would know on the nes you are limited to 4 colors and a very low resolution.  That's about as good is you are going to get. 

[Howard_Casto]

I just wanted to say thanks again for all your hard work on this Howard!  This project also has a bit of a following over on the GameEx forums.  Hopefully it's cool that I took the liberty of re-posting over there.  Thanks again!

Nah man it's cool.  My only rule on this thing is to make sure you let people know who's doing it.  I had a problem several years back in regards to someone posting my stuff elsewhere and passing if of as their own.  Now that might get you a home visit. 

[Malenko]

They are already skinnable, and pro tip.... don't insult someone when asking for a feature. 

If you'd follow along in the thread you would know on the nes you are limited to 4 colors and a very low resolution.  That's about as good is you are going to get.

WAS following the thread, I dont re-read the entire thing every time there is a reply. Dont know how saying the skin is ugly is in any an insult towards you. good luck with it.

[Howard_Casto]

I checked out that build of mess.  It's got some odd quirks, but I think it may be usable for a few emulators. 

Because mame/mess converted all drivers to full color ages ago, there are no longer any color limitations.  So it might be work the effort to convert a few of the ones I've already done over for their mess counterparts. 

I looked at the 2600 driver.  I can make a menu for it but save states would be a bit redundant.  While the Reset/Select buttons are hooked up to the "gamepad" and I can control them (and thus put reset and select toggles in the menu, allowing you to start the games with a 2600 joystick. ) The A and B selector toggles have been setup as dipswitches, which I cannot control. 

Master System has some rendering issues, so I don't know if I can do anything with it.  I may do a single generic menu for MESS and let you guys go to town. 

[Howard_Casto]

I messed around with the Atari 2600 in Mess.  While it IS possible to do a menu I don't exactly see the point.  I mean would you need save states for a 2600 game?  What adventure maybe?  And while I can control the reset/select dips you'll still need a button combo to open up the menu.  Since the 2600 controller has one singular button... well how exactly could you bring it up?

So I looked at VBA-rr.  It behaves identically to snes9x so my 9x script just plugs in aside from having to read a different address for the rom header.  Now the good news is almost everything works fine.  The bad news is that one thing that doesn't work is saving states.  It's a bug in the code and as apparently fixed on Jan 10th... and no binary has been released since.  So I don't know when/if we'll get a fixed version.  If somebody wants to download the svn source and compile a version I can whip something up fairly quickly.... otherwise. 

[Howard_Casto]

So since the well of stand-alone emulators has dried up and the mess version is kind of crappy, I've moved onto Bizhawk.  This is some conglomerate emulator the TAS guys have made.  Basically they took all the open-source console emulators out there and combined them into one. 

The reason I'm doing this one last is because it's very much in it's early stages.  Even things as simple as using a zapper or getting a proper aspect ratio aren't quite there yet.  Also many of the emulators are a tad slower so the dedicated versions are a better option atm.  That being said, unlike the other emulators I've done thus far, this one is still very much in active development.  Also it has nicer lua functions available, like being able to set the render filter and scanlines ect... from within lua.  Also I can just use plain old png images with it, so the menus would look much better and I don't have to jump through hoops to make and load a screenshot. 

The current aspect ratio problems make me leery of doing full-fledged emu specific menus atm, so what I might do is make a very very simple menu that'll work with all of them. 

After that I'm done and I'll leave it to you guys.  Bizhawk, while not the most popular emulator on the surface, actually uses the source code to a lot of popular emulators like bsnes, fceux, gens, ect.....  It supports every major home console released and a good chunk of the portables, so it will probably be enough to cover most people's needs. 

[KIguy]

I just wanted to reply and say thank you! Definitely going to throw these on my htpc this weekend!

Kudos my man 

[Howard_Casto]

Thanks, it's nice to be appreciated. 

[markronz]

Hello!  Love the project.  Just happened upon it yesterday and I've been playing around with it.   I have dedicated Save and Load buttons on my machine, and ideally I'd like to map those keys to launch your menu.   Right now I'm just using the NES version.   I saw in the lua file that you said we would set tempInput.tilde to something else, but what I'm not clear on is what format I need to put it in?    Like if I wanted to change tilde to 's' how would I do that?   I tried changing tempInput.tilde to tempInput.s and that didn't work.  Then I tried the virtual keycode table value, and I tried both simply '83' and to tempInput.83 and it didnt seem to like either of those either.  So what format do I need to use? 

Also, my other problem is a focus issue.   FCEUX launches into full screen for me.  But there is also a "Lua Script" screen that comes up as well.  You can't really see the window, because FCEUX is full screen, but the Lua Script screen apparently has focus.  I have to click with the mouse on the screen to get the focus back onto FCEUX.   So is there any way for the Lua Script to be hidden?  Or for FCEUX to just get the focus correctly?   In case I didn't make it clear, I can tell it doesn't have focus because it doesnt recognize any of the keypresses on my control panel, that is, until I click on the screen to get FCEUX back in focus.

Any help would be appreciated!

[Howard_Casto]

tempinput.S

No you can't hide it. 

Turn on "background input" in the FCEUX options.

[markronz]

That worked, thanks much!

[garwil]

Just wanted to say this looks awesome! I'm hoping to build a HTPC at some point, running a few classic console games (got some USB SNES adapters and a couple of original controllers ready to go) and this is just the sort of thing I need. Don't want to have to dig out a keyboard and mouse! Thanks dude.

[bleasby]

This project came to my attention just now.

First of all, congratulations on your project. As usual you are always doing high quality stuff for the community and we have to thank you for that.

I read this thread today and I though that I should give some explanations about some comments made here just to give to any reader all the info possible.

I one of the developers behind the HyperPause feature on HyperLaunch, so just to answer a few comments,

...namely Hyperpause; If I understand your concept correctly it's pretty similar(albeit Hyperspin-only).

HyperPause is not for Hyperspin-only. HyperPause is part of HyperLaunch and from version 3 and above, we made sure that it could be used on any frontend that you like.

We tested it on GAMEEX, xbmc, 3darcade and romcollectionbrowser. It will work with anything that can send it CLI. You just need to call the HyperLaunch command line in the place of the emulator command line.

Hyperpause, with all due respect is the most convoluted way you could possibly do it.  I'm not a fan at all.  Much respect to whoever decided to tackle that one, but I've tried making various external methods over the years.  They never work and when they do it's so convoluted that nobody will bother anyway.

HyperPause always had as aim to support all HyperLaunch supported emulators (that some more than 120 supported emulators right now). That is indeed a big task.

I have to agree that on its initial release the HyperPause had more limited support, but we are in a continuous update work, and right now we support more than 100 emulators without issues with HyperPause. If you follow the necessary instructions (that are basically just keep your HyperLaunch install up to date), things will work flawless for you.

A lot, but a lot of persons do use it and can attest for its stability. I am saying more than 10,000 downloads were made of the program, and we tried to help on all problems or doubts that emerged on the support forums. So I think that the comment above was a little strong, specially on the part referring that nobody would bother.

That is all that I wanted to clarify. It was not my intent to hijack your tread, but I got the feeling that I should answer to some incomplete information provided.

Anyway, as I am one of that crazy OCD guys, I will also make sure to install your dashboard solution and give it a shot. More is always better, and for certainly it can live together with HyperPause in my setup. Also, who knows until ere you will reach with it.

I am really excited to see new ideas on the integration of such features and you certainly did a very visually pleasant job on this one.

Thanks for this extra feature.

[Howard_Casto]

If I offended you I sincerely apologize.  That's about all I can do on that one. 

Just for the record though, you guys need to quit naming your stuff "hyper____" if you want people to use it with anything other than hyperspin. 

[bleasby]

If I offended you I sincerely apologize.  That's about all I can do on that one. 

Just for the record though, you guys need to quit naming your stuff "hyper____" if you want people to use it with anything other than hyperspin. 

  Yeah, I know about the name thing. It more or less pursues us. Sometimes for good and sometimes for bad. But as the program began as part of HyperSpin we never took the decision to pull it out entirely from its origins.

By the way, I am not offended at all. Just giving some additional info to avoid confusion on any users that doesn't know our contributions also, nothing more.