Software Support > PowerMAME
PowerMAME - New Derivative Build
MikeQ:
--- Quote from: Buddabing on February 15, 2006, 05:29:29 pm ---
--- Quote from: MikeQ on February 15, 2006, 05:15:57 pm ---
--- Quote from: Buddabing on February 15, 2006, 04:25:21 pm ---
--- Quote from: Silver on February 15, 2006, 01:53:20 pm ---This may have been covered before, but I can I just repeat/suggest that:
1) Each change is available as a seperate source edit, available in seperate diffs (or controllable with 1 switch in the compile settings)
2) I think *every* change made should be controlled by an option in the ini. I'm thinking about the input changes here mainly - but if we are changing what inputs a game uses to better suit authentic hardware, then I think it would be a good idea to keep changes optional for those with different hardware. eg "dial" input for rotary games - not authentic or right for real mechanical rotaries, but great if you have a spinner....
--- End quote ---
I totally agree. The lack of this change control is what killed NoNameMAME.
--- End quote ---
Which lack of change control? Not being able to compile each option or not being able to turn on/off each option via .ini?
--- End quote ---
Both. Ideally, there should be a process, similar to Linux configure, where the user checks off what options he wants, then the configure script builds the source changes and compiles it.
--- End quote ---
I don't see adding build options. It will mean for N features I will need to build 2^N configurations. This would quickly get to be impossible. If a feature is in PowerMAME and can be turned off via an .ini or menu selection in PowerMAME32, then it shouldn't matter to the user if the code exists in the binary.
BTW, Is your led controller available? It's a parallel device, correct? Does it require a kernel driver? It would be nice to add support for it too. At some point once I work through some of the controls stuff, I'd like to take a look at LSE too.
RandyT:
--- Quote from: Buddabing on February 15, 2006, 05:29:29 pm ---
--- Quote from: MikeQ on February 15, 2006, 05:15:57 pm ---Which lack of change control? Not being able to compile each option or not being able to turn on/off each option via .ini?
--- End quote ---
Both. Ideally, there should be a process, similar to Linux configure, where the user checks off what options he wants, then the configure script builds the source changes and compiles it.
--- End quote ---
I'm going to venture a guess that the large majority of folks aren't going to be too concerned about the ability to perform a feature selective compile.
My opinion is that unless there is some compelling reason (like features being mutually exclusive) then being able to turn off features via an .ini would suffice for all but a few users.
RandyT
Silver:
--- Quote from: Silver on February 15, 2006, 01:53:20 pm ---This may have been covered before, but I can I just repeat/suggest that:
1) Each change is available as a seperate source edit, available in seperate diffs (or controllable with 1 switch in the compile settings)
2) I think *every* change made should be controlled by an option in the ini. I'm thinking about the input changes here mainly - but if we are changing what inputs a game uses to better suit authentic hardware, then I think it would be a good idea to keep changes optional for those with different hardware. eg "dial" input for rotary games - not authentic or right for real mechanical rotaries, but great if you have a spinner....
--- End quote ---
(Weird quoting myself!)
I should have added underneath, that correctly implimenting number 2 would make number 1 (almost) redundant, or at least not worth the (large amount of) extra work. i.e. say every addition you make defaults to off, then running your mame without tweaking the ini should essentially behave exactly like normal mame. All I'm really saying is remove nothing, only add. This may sound obvious, but its more geared towards 'correcting' or changing inputs to games, where even if we make a game more accurate control wise, leave the option to have controlled as it was.
I was thinking at the time of the post that if you make every addition an on/off option, then it would be easy to make it on/offable at compile time using a switch in the make file or whatever. However, my experience here is rather limited.
As for seperate diffs - I realise that is probably a huge amount of work, and as mentioned, probably not used by many.
I think the NoName issue was that loads and loads of changes were piled into one build, then mame completely rewrote some of its internal systems one update, and I think (guessing here really) that it was a huge task to attempt to work through and find out what was breaking where or how to re-impliment them, and there was no way of looking at one group of changes at a time, it was all or nothing.
Anyway, I'm really chuffed about this build no matter how its implimented....
mahuti:
One thing I might mention, re: lighting function of PowerMAME.
While working on the setledwiz app, I thought quite a bit about how to handle the difference between single color LEDs and RGB leds. With the setledwiz app I eventually decided to handle the LED lighting with 2 sets of configs. One CFG deals with which terminal the LED is connected to; i.e.
1 COIN1
3 KEYCODE_X
OK. So that powers on LED 1&3. If you are using an RGB LED it's set up to use
1 COIN1
2 COIN1
3 COIN1
4 KEYCODE_X
5 KEYCODE_X
6 KEYCODE_X
Basically that CFG is the same as LedWiz.cfg is with PowerMAME. Beyond that however, I wanted to control the colors more than just ON/OFF. My solution was to add another CFG file for the colors with intensities corresponding to the LedWiz app. This makes for a nice compromise between automation and custom.
1 48
2 0
3 0
(this would be solid red)
4 48
5 38
6 5
(this would be yellow)
7 35
8 48
9 48
(this would be white)
10 129
11 0
12 0
(this would be pulsing red)
This would be a nice feature to continue to have in PowerMAME. The SetLedWiz currently has this, but it's much nicer to pursue the all-in-one solution. I haven't had time to look at the source yet of PowerMAME. I'll look tomorrow and see what's goin on.
Tiger-Heli:
--- Quote from: XtraSmiley on February 13, 2006, 10:10:04 pm ---
--- Quote ---Yes, we are using hidden cameras and you need to stop picking your nose. :P
--- End quote ---
Holy $hit, I started picking my nose just as I read this...
As for the individual game start up, can't we just have a generic option to start all games like 5 minutes into it? I realize some games don't need a lot of time, but they would end up just repeating the attract screen right? If 5 minutes isn't enough it could be any amount of time (or user set able). Would that solve the problem? If I'm ignorant of how this works, don't worry about explaining out why it won't, just say, no, that won't work Mo... If you wasted time to explain it to me, it would just waste time! :)
Keep up the good work.
--- End quote ---
Here I go wasting time explaining it to you!!! :angel:
You can sortof do what you want, but -ssf does not start the game a certain number of frames into the game, it just doesn't write X number of frames to video, so you see a black screen for a few seconds instead of the initial startup routines.
If you wanted a common value (say skip the first 500 frames), you can just add -ssf 500 to your C:\mame\mame.ini file and remove it from your C:\mame\ini\gamename.ini files.
The problem is what do you set the value at. If you choose 500, PacMan probably works fine, but crusnusa will blank about 1/4 of the startup sequence and then display the rest of it. If you choose 5000, crusnusa will work ok (after the 10 second black screen), but PacMan will look like it is doing nothing and then come on in the middle of the attract sequence after 10 seconds.
HTH . . .
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version