Build Your Own Arcade Controls Forum
Main => Software Forum => Topic started by: Tiger-Heli on April 13, 2004, 08:48:33 am
-
I have 2 questions -
Many of the more recent games (like Cruisin, Blitz) etc. are really only playable by underclocking the CPU's using the cheat menu - i.e. start the game with -cheat, then use the tilde menu and reduce the CPU overclock speed until the game speeds up.
Q1 - What do you lose (gameplay, wise) by doing this?
Q2 - How hard would it be to add an option where this could be specified either on the commandline or preferably in a game specific .ini file?
i.e. mame.exe crusnusa -cheat -cpu0_15 -cpu1_15
or
crusnusa.ini
cpu0 15
cpu1 15
Thanks in advance!
-
Because there are 100 some odd processors in mame it would be difficult to do it via the command line. See in the cheat menu the processos are alreayd loaded, so it doesn't have to look for them. It is possible, it'd just be difficult.
By underclocking the main thing you loose is accuracy. It screws up the sound on timing criticla games, you get less polls to the input driver so your controller can be less-responsive, less fps are drawn ect.... Basically it slows down the whole game, which may or may not do anything. It jsut depends.
-
Because there are 100 some odd processors in mame it would be difficult to do it via the command line. See in the cheat menu the processos are alreayd loaded, so it doesn't have to look for them. It is possible, it'd just be difficult.
Would it be easier for mame to load it from a game specific .ini file?
And do you think anyone would add it to a mame build?
By underclocking the main thing you loose is accuracy. It screws up the sound on timing criticla games, you get less polls to the input driver so your controller can be less-responsive, less fps are drawn ect.... Basically it slows down the whole game, which may or may not do anything. It jsut depends.
Thanks, that's what I was wondering about.
-
Well I thought it was a good idea, so I just tested a few things on the games you mentioned. Unfortunately the interface isn't the problem.
Take Crusin Usa for example:
During the bootup sequence it checks the processor speed.... if it isn't correct it reboots the cpu and keeps doing it until the reading is correct.
It appears to be the same with all harddrive games with the "computer like" bootup screen.
So they would have to be done after the fact. :(
-
Well I thought it was a good idea, so I just tested a few things on the games you mentioned. Unfortunately the interface isn't the problem.
Take Crusin Usa for example:
During the bootup sequence it checks the processor speed.... if it isn't correct it reboots the cpu and keeps doing it until the reading is correct.
It appears to be the same with all harddrive games with the "computer like" bootup screen.
So they would have to be done after the fact. :(
Does it matter if you run the hardrive games with -ssf and this option to bypass the computer like bootup screen.
Could it be set so it overclocked the CPU after a timed delay for the CHD games?
-
Take Crusin Usa for example:
During the bootup sequence it checks the processor speed.... if it isn't correct it reboots the cpu and keeps doing it until the reading is correct.
It appears to be the same with all harddrive games with the "computer like" bootup screen.
Actually, Cruisin' USA isn't a harddrive game, it just acts like one. FWIW!
-
ssf wouldn't do any good.... ssf doesn't actually skip frames, it skips the rendering of frames. So the check would still take place. A delay would be a waste of time as the only games you would use this on would be games that don't run full-speed. So how long of a delay?
-
ssf wouldn't do any good.... ssf doesn't actually skip frames, it skips the rendering of frames. So the check would still take place. A delay would be a waste of time as the only games you would use this on would be games that don't run full-speed. So how long of a delay?
Okay, -ssf wouldn't speed anything up, but - we know the check for processor speed occurs when the computer board is visible, before the initial graphics start.
And from -ssf, I know that between -700 and -725, I am past this screen and into the main program. And this value should be the same regardless whether I'm running a 3.0 Ghz P4 or and Pentium 66, so . . .
what if we passed the underclock percentage, and a delay (in frames) before o/c, like this (it would still take a long time to load, but be fairly playable after that . . .)
crusnusa.ini
o/c_delay 725
cpu0
-
Additional idea - I saw in the http://www.arcadecontrols.org/yabbse/index.php?board=1;action=display;threadid=18209;start=new (http://www.arcadecontrols.org/yabbse/index.php?board=1;action=display;threadid=18209;start=new) Extra buttons thread Reply #18 that PatickL is pressing F10 to turn speed throttling off during boot-up and back on again. This would be similar to the DECO cassette turbo load option in NoNameMAME.
Idea - how hard would it be to specify a -unthrottle_strartup_frames (-usf) command that could be added to the gamename.ini file as
-usf 725
With the command above, MAME would turn speed throttling off for the specified number of frames (725) and then back on again.
Theoretically, you could use all the new features together -
crusnusa.ini
o/c_delay
-
I still think it's a good idea, but I still think it's a butt-load of work and I doubt anyone would be willing to invest the time in it.
-
Found a way to over or under clock the CPU without having to press ~ and messing with the CPU speeds every time the game loads. I've tested it on Cruising usa and it seems to work. Edit the cheat.dat file for Cruising usa to look something like this:
; [ Cruis'n USA (rev L2.1) ]
:crusnu21:65004000:00000000:00004500:00000000
:crusnu21:65004000:00000001:00004500:00000000
:crusnu21:65004000:00000002:00004500:00000000
crusnu21:0:003DDA4:0F:000:Infinite Time
crusnu21:0:003DDA5:27:500:Infinite Time (2/4)
crusnu21:0:003DDA6:00:500:Infinite Time (3/4)
crusnu21:0:003DDA7:00:500:Infinite Time (4/4)
These Three lines refer to CPU1,CP2 and CPU3
:crusnu21:65004000:00000000:00004500:00000000
:crusnu21:65004000:00000001:00004500:00000000
:crusnu21:65004000:00000002:00004500:00000000
you can edit "00004500" to show "00020000"
00004500 = CPU clock % of around 27%
00020000 = CPU clock % of around 200%
you'll need to also enable the cheat option in your mame ini file. Also, you can test different values to see what % works best.
I've tested this with Crusing USA with a clock of around "00004500" or 27%. I still get a little slow down, but it does seem to make a difference and it loads the cheat everytime.
Steve
-
I've tested this with Crusing USA with a clock of around "00004500" or 27%. I still get a little slow down, but it does seem to make a difference and it loads the cheat everytime.
Steve
Thanks for the tip - I saw this in the cheat.c file in the source, but wasn't sure how to make it work.
Here's where I run into problems, though - Your method works at CPU0 and 1 of 27%, but that only gets me to 75% framerate on a P4 1.8 Ghz. CPU underclock of 10% gets me 100 percent framerate, but if I set this in cheat.dat, the game gets stuck in an infinite loop and never clears the game initialization screen.
What I need is an automatic method that will run with no overclock for xx frames, and then run at 10% underclock after the hardware check screens.
(or ideally, at 27% overclock for the hardware initialization and at 10% afterward).
BTW, the conversion is decimal % times 65536, then converted to hex.
so for a 10% underclock, the value is .10*65536=6.5536 converted to hex = 1999.
-
Did some more testing for anyone following this thread - the limiting value for avoiding a re-initialization is CPU0 at or above 20%. CPU 0 at 19 % causes a reboot. Unfortunately, this is only good for about 65-75% framerate (on the P4 1.8).
I was able to drop the CPU1 speed to 1% and start the game, but the framerates did not increase much.
FWIW.
-
There isn't any built-in support for something like that, but it'd be pretty easy to add.
Change the kCustomLocation_Overclock handler (cheat.c line 8426) to this:
case kCustomLocation_Overclock:
{
UINT8 cpu = address & 0xFF;
if(cpu < cpu_gettotalcpu())
{
UINT32 delay = address >> 8;
if(delay)
mame_timer_set(TIME_IN_MSEC(delay), (data & 0xFFFFFF00) | cpu, HandleOverclock);
else
HandleOverclock((data & 0xFFFFFF00) | cpu);
}
}
break;
and add this before the HandleLocalCommandCheat function:
static void HandleOverclock(int param)
{
UINT32 overclock = param & 0xFFFFFF00;
UINT8 cpu = param & 0xFF;
timer_set_overclock(cpu, ((double)overclock) / 65536.0);
}
Then you can specify a delay (in milliseconds) for the overclock to be activated by putting it in the upper 24 bits of the address field. So, to make the crusnu21 cheats activate one second (of gametime) after startup, use these cheats:
:crusnu21:65004000:0003E800:00004500:00000000
:crusnu21:65004000:0003E801:00004500:00000000
:crusnu21:65004000:0003E802:00004500:00000000
-
There isn't any built-in support for something like that, but it'd be pretty easy to add.
<snipped>
Then you can specify a delay (in milliseconds) for the overclock to be activated by putting it in the upper 24 bits of the address field. So, to make the crusnu21 cheats activate one second (of gametime) after startup, use these cheats:
:crusnu21:65004000:0003E800:00004500:00000000
:crusnu21:65004000:0003E801:00004500:00000000
:crusnu21:65004000:0003E802:00004500:00000000
Thanks Ian.
I didn't follow all of that, but someone who understands C will.
Quick Questions - I was thinking of using frames rather than milliseconds, but I don't guess it matters - but - I need the cheat to happen after 720 frames so I assume 720/60 fps = 12 sec = 12,000 milliseconds = 2EE0 hex milliseconds so the cheat becomes
:crusnu21:65004000:002EE000:00004500:00000000
Also, would it be possible to use the following commands:
:crusnu21:65004000:00000000:00003333:00000000
:crusnu21:65004000:00000001:00001999:00000000
:crusnu21:65004000:002EE000:00001999:00000000
This would run CPU0 initially at 20%, CPU1 initially at 10% and then drop CPU0 to 10% after 12 seconds of gameplay?
Would the order that the entries are listed matter?
Finally, could you add this to a future MAME build, or do you mind if someone submits it or adds it to a derivative?
Thanks again for your assistance! Great job!
-
Quick Questions - I was thinking of using frames rather than milliseconds, but I don't guess it matters - but - I need the cheat to happen after 720 frames so I assume 720/60 fps = 12 sec = 12,000 milliseconds = 2EE0 hex milliseconds so the cheat becomes
:crusnu21:65004000:002EE000:00004500:00000000
That's right. I used milliseconds instead of frames because the MAME timer system doesn't support it, plus it avoids complications with games that change their refresh rates.
Also, would it be possible to use the following commands:
:crusnu21:65004000:00000000:00003333:00000000
:crusnu21:65004000:00000001:00001999:00000000
:crusnu21:65004000:002EE000:00001999:00000000
This would run CPU0 initially at 20%, CPU1 initially at 10% and then drop CPU0 to 10% after 12 seconds of gameplay?
Yes.
Would the order that the entries are listed matter?
Not unless you do weird things like make multiple overclock requests at the same time on the same CPU.
Finally, could you add this to a future MAME build, or do you mind if someone submits it or adds it to a derivative?
I don't mind if someone uses it in a derivative build, but stuff like this doesn't really belong in the main build.
-
I don't mind if someone uses it in a derivative build, but stuff like this doesn't really belong in the main build.
I don't really see why not - it's basically just an expansion on the overclock ability that is already present in the cheat.c file which is part of the main build, but no worries.
Thanks again for the assistance!!!!
-
That code will not compile.
C:\Documents and Settings\Sunookitsune\Desktop\noname>make
Compiling src/cheat.c...
src/cheat.c: In function `HandleLocalCommandCheat':
src/cheat.c:8443: incompatible type for argument 1 of `_mame_timer_set'
make: *** [obj/noname/cheat.o] Error 1
-
Just curious if this needs to also be added?
"Static Void HandleOverclock(int Param);"
Before this?
"static void HandleLocalCommandCheat(UINT32 type, UINT32 address, UINT32 data, UINT32 extendData, char * name, char * description);"
-
Still nothing.
-
That code will not compile.
Oops, fixed in local file but didn't copy over to the messageboard. Use
timer_set(TIME_IN_MSEC(delay), (data & 0xFFFFFF00) | cpu, HandleOverclock);
instead of the other mame_timer line.
Just curious if this needs to also be added? (function prototype snipped)
Doesn't need to be, as long as HandleOverclock is before HandleLocalCommandCheat, but I prototyped everything else at the beginning of the file, so if you want to stick with the same coding style go ahead.
-
Okay, it works now. It'll be in the next release of No Name MAME.
-
I don't mind if someone uses it in a derivative build, but stuff like this doesn't really belong in the main build.
Ian, first off, I would again like to say thanks for coding this. I think it's a great addition to MAME and personally, I'm glad it will be available in a derivative build, if not in the main build.
The rest of this is more academic/hypothetical, but let me spend some time on the high horse and hopefully it will at least lead to some good discussion.
My personal feeling is that not only does this delay function belong in the main build, but the whole overclock CPU function should be in the main source code and out of the cheat function, so that high score saving is not affected. (or the cheat function should be modified so overclocking the CPU does not disable high score save, but I think that would be more difficult to accomplish).
More on this theory: I understand why if I play a game with infinite lives and infinite power-ups, I shouldn't overwrite high-scores that were legitimately obtained, but CPU overclock really doesn't make the game easier, just makes it playable on a slower computer. I don't see how it's really any different than playing a game at frameskip 8 instead of frameskip 0 or settting samplerate to 11025 instead of 44100 (except it's usually more transparent than either of these changes), both of which I could make and still save high scores.
Anyway, that's the main thing I wanted to say, and I would welcome anyone else's thoughts on this issue. (And I realize it's unlikely to be changed no matter what I think, and that's okay with me too!)
-
My personal feeling is that not only does this delay function belong in the main build, but the whole overclock CPU function should be in the main source code and out of the cheat function, so that high score saving is not affected. (or the cheat function should be modified so overclocking the CPU does not disable high score save, but I think that would be more difficult to accomplish).
It already works that way. Highscore saving is only disabled if you enable a cheat, and from a technical standpoint these aren't cheats. I just put this code in the cheat engine because it's a good framework for doing game-specific things, and because I'm very familiar with the code.
-
My personal feeling is that not only does this delay function belong in the main build, but the whole overclock CPU function should be in the main source code and out of the cheat function, so that high score saving is not affected. (or the cheat function should be modified so overclocking the CPU does not disable high score save, but I think that would be more difficult to accomplish).
It already works that way. Highscore saving is only disabled if you enable a cheat, and from a technical standpoint these aren't cheats. I just put this code in the cheat engine because it's a good framework for doing game-specific things, and because I'm very familiar with the code.
Ok, my mistake. I assumed (and you know what that does) that anytime I ran MAME with -cheat enabled, high score saving was turned off. If that's not the case with this, than I couldn't be happier.
(Except I still think it belongs in the main build, even though most people wouldn't know how to activate it (like I didn't before yesterday)). 8)
Thanks again!
-
For anyone following this thread, I just tested (kinda) on a P4 1.8 Ghz with these values:
:crusnu21:65004000:00000000:00003333:00000000
:crusnu21:65004000:00000001:00001999:00000000
:crusnu21:65004000:009C4000:00001999:00000000
This corresponds to a CPU1 overclock of 10% and a CPU0 overclock of 20% for 40 seconds and 10% thereafter.
In-game framerates were fluctuating between 83% and 114% with the average around 88%, so it's not full speed but very playable.
I also dropped the CPU overclock down to 9% and the game re-booted even after the hardware initialization, so I guess we know this is about the minimum CPU capable of handling this game!
EDIT: Fixed the time delay value in the code above.
-
It works great for Crusin USA but how can I get it to work for other games?
-
It works great for Crusin USA but how can I get it to work for other games?
Ok, what part didn't you understand?
Basically, the steps are -
1) Start the game with the "-cheat" option enabled.
2) Type F11 so you can see how fast the game is running.
3) Press the Tilde key and underclock/overclock each processor to see which settings give you the desired framerate. (Note the in-game speed may be different than attract mode). Write down settings.
4) Convert to hex and add an entry to the cheat.dat file.
5) Start the game and see if it runs with that setting. If it re-boots continuously, add a delay to get past the initialization screens, then underclock (by less than the final amount) to get these faster.
BTW, I posted an announcement about this on the MameWorld Submit News board and got responses anywhere from "It's not arcade authentic and screws up the game logic" to "Not this Lameness again."
I feel that I should point out that by doing this, you are changing the game physics similar to skipping frames.
I also feel that I should point out that Cruisin' at 88% speed with underclocked CPU's is a lot more playable than Cruisin' at 15% speed with non-underclocked CPU's.
And for everyone else that thinks this is a bad idea - It's an OPTION (and not a particularly easy one to implement). If you don't want to use it, just ignore it.
-
I think your efforts should be commended, but just a quick question/comment....
It's not just me, underclocking totally screws up the audio right?
If that's the case with everyone, then what exactly is the point? Say what you will, but a game with bad audio is just as unplayable as a game that's too slow.
-
I think your efforts should be commended, but just a quick question/comment....
It's not just me, underclocking totally screws up the audio right?
If that's the case with everyone, then what exactly is the point? Say what you will, but a game with bad audio is just as unplayable as a game that's too slow.
Ermmmn, dunno - I don't think I'd say it totally screws up the audio, I'd say it doesn't fix the audio, but I only tested it on two computers - P4 1.8 Ghz with audio working but speakers off (just tested with speakers on - distorted audio) and a Duron 850 with audio that can only hit about 55% speed with full overclock, so is basically unusable.
The audio sounded pretty poor at 15% of full speed with non-oveclocked CPU's, so I'm not sure you've lost anything, and the graphics flow better.
-
No it definately effects the audio.....
Without underclocking my 2600+ plays the audio more or less fine. Now the sound effects skip a lot, but thats because the processor is displaying the game too slowly and the audio is timed.
When it's underclocked the pitch of the audio is distorted as well as the speed.
Again though, this doesn't make a difference.... if the audio doesn't work then it isn't playable. If the audio worked before hand is beside the point.
Kinda like the zn games.... I am glad to see them in mame, but I can't figure out why some of the devs are deeming them "playable" when the audio is screwed up. I guess they are playaable if you are deaf and never heard the sound to begin with.
Audio is a very important part of a game. I'm one of those people that can't play a game muted because it messes my reaction time up. I'm not in the minority either, a lot of people are that way.
Anyway, I didn't post that before just to start an argument, I wanted to make sure I wasn't doing something wrong and missing out of crusin at full speed. Thanks for confirming.
*sigh* back to the n64 port it is then :(
-
No it definately effects the audio.....
Without underclocking my 2600+ plays the audio more or less fine. Now the sound effects skip a lot, but thats because the processor is displaying the game too slowly and the audio is timed.
I just tried on the P4 1.8 and the audio is better with no overclocking at 11% of full speed. On a 2600, it's possible you could get away with no overclock on CPU 2 and more on CPU1, or vice versa, rather than a balanced overclock, and some combination might work better for the audio.
Kinda like the zn games....
The which ???
Audio is a very important part of a game. I'm one of those people that can't play a game muted because it messes my reaction time up. I'm not in the minority either, a lot of people are that way.
I can't play with sound turned off, muted or distorted I can deal with.
Anyway, I didn't post that before just to start an argument, I wanted to make sure I wasn't doing something wrong and missing out of crusin at full speed. Thanks for confirming.
No problem, I didn't think you were being argumentative, I just had audio turned off while I played with the overclocking settings.
*sigh* back to the n64 port it is then :(
Sorry! Does that work okay? I never got it playable on the Duron 850, slowed to about 60% whenever the car was not driving in a straight line.