Main > Main Forum

Dynamic Button Display, ABM

<< < (2/2)

Yvan256:
Not to continue stealing the thread, but without pictures... :dunno


--- Quote from: SavannahLion on January 17, 2015, 10:05:52 pm ---I think you're on an interesting path but overlooking a few details. I have a similar scheme in my project but I don't have to deal with a shitload of games.

Here's a few thoughts.
[...]

If I'm misunderstanding, feel free to clarify. I like the idea, I just don't know if it's something that's absolutely necessary given the current landscape right now.

--- End quote ---

You understood perfectly, however like you said storing the data on an SD card would overcome the problem of too many ROMs. Is there really so many people with thousands of games on their cabinet?

But as far as front-ends go, do they allow you to run a program when selecting a game, not just when you run it? Doing so for things like a rotating monitor or motorized joystick would be a bad idea, but in the case of my mini-marquees LCD I'd like for it to change when you are in the front-end menu selecting games. It's a minor thing but I think it would be neat.

But yes, being able to run a program with the emulator name and the ROM filename would be enough to be future-proof too and still allow anyone to work the way he wants.

edit: goldengears5, can you attach the images to your first post? All we see is the error message attached to my post.

Yvan256:

--- Quote from: nitrogen_widget on January 18, 2015, 12:28:16 am ---Don't the recent versions of Mame just do this with its abikity to address multiple monitors?

--- End quote ---

In my case it wouldn't work since my tiny 128x160 pixels LCD connects via SPI, not VGA/DVI/HDMI. It probably wouldn't work for goldengears5 either because if he's using the displays I think he's using, it's probably SPI too. We need a microcontroller to talk to the small LCDs.

SavannahLion:

--- Quote from: Yvan256 on January 18, 2015, 09:30:22 am ---You understood perfectly, however like you said storing the data on an SD card would overcome the problem of too many ROMs. Is there really so many people with thousands of games on their cabinet?

--- End quote ---
True, not everyone does. But if you create a Diddle that does Daddle, how can you guarantee that whomever decides to use your Diddle limits their game selection to X? You can't.

This problem would be further compounded by the problem of new games being added. There is no way to expect a user to "lock" a game list onto their cab over a given span of time. It would be foolish to assume so. As soon as a user finds out they can't add game X or Y because they lose some of that functionality because the game isn't on the Diddle's game list, it'll go into the trash. The feature becoming a hindrance.

One of the controllers I have in my set up has a whopping 8k of Flash. I haven't done a code analysis on it yet, but I imagine I'm using at least 2k just for the framework (for testing). The remaining 6k would be quickly overwhelmed if I decided to allow it to manage game specific data. So my controller does what it does best, it continues sending the same data, regardless of the "mode" the rest of the system is in. We'll get to that in a minute.


--- Quote ---But as far as front-ends go, do they allow you to run a program when selecting a game, not just when you run it? Doing so for things like a rotating monitor or motorized joystick would be a bad idea, but in the case of my mini-marquees LCD I'd like for it to change when you are in the front-end menu selecting games. It's a minor thing but I think it would be neat.

--- End quote ---
I doubt it, but I could be wrong.

For that functionality, you'll likely be left modifying the source code of an existing one or writing your own. If enough people select your FE over another, the other FE authors will likely take note of your feature set and begin to include them.

That's a tough thing to accomplish though and I don't bother expecting people to use or even download my FE if I elect to make it available. The market is astronomically small for FE's, even smaller for the type I'm drawing up, and about 1/∞ for anyone that'll actually use it.


--- Quote ---
But yes, being able to run a program with the emulator name and the ROM filename would be enough to be future-proof too and still allow anyone to work the way he wants.

--- End quote ---

Given your requirements and features, I would suggest creating an FE with a "plug in" architecture where you have a configuration setup that allows specific data constructs to be broadcast (so you don't flood the system with hundreds or thousands of unnecessary even broadcasts) and a "receiver" that manages the game list and transmits the bulk of the desired functionality to the devices. I think there are a couple of FE's with similar functionality but I don't know if they do exactly what you want.

It might even be easier to do it in Linux as opposed to Windows since Linux environment tends to have the "do one thing and do it well" mentality so there are a very good mechanisms for communicating between tools. Windows has many of the same functions, I just find it a hell of lot easier to access them on Linux than I do on Windows.

Navigation

[0] Message Index

[*] Previous page