(08-28-2015, 06:53 AM)Blyss Sarania Wrote: [ -> ]How would it remain compatible with the current INI if we change the values? And presets? Without changing them and without conversion code? Both avih and rama explicitly stated that they wanted to make sure those things remained compatible.
It would , there is no reason for the values to conflict the INI file in any certain way , only the function of the values will be changed.
presets needs to adjusted in the code itself , what do you mean by conversion code ?
just to be clear, I'll give some examples code in a moment on what I'm talking about.
@Blyss
I think using the wxSL_INVERSE style will do what you want - UC on left and OC on right without affecting the compatibility of the current ini and preset settings. Documentation at
http://docs.wxwidgets.org/trunk/classwx_slider.html .
EDIT: Still might be confusing with high values on left, low on right. Oh well.
(08-28-2015, 09:48 AM)turtleli Wrote: [ -> ]@Blyss
I think using the wxSL_INVERSE style will do what you want - UC on left and OC on right without affecting the compatibility of the current ini and preset settings. Documentation at http://docs.wxwidgets.org/trunk/classwx_slider.html .
EDIT: Still might be confusing with high values on left, low on right. Oh well.
I tried out using wxSL_INVERSE before and it worked well but had a little bug , when you click on any of the values it would move the slider marker to the opposite direction of the value you had pressed. this method doesn't retain the compatibility of the presets.
@Blyss
here is my idea for moving OC to right and UC to left, note: percentages are not accurate, just to show the order.
on iR-5900-32.cpp,
Code:
switch( EmuConfig.Speedhacks.EECycleRate )
{
case -4 : // 50% EE
scalarLow = 8;
scalarMid = 10;
scalarHigh = 8;
break;
case -3: // 65% EE
scalarLow = 6;
scalarMid = 8;
scalarHigh = 6;
break;
case -2: // 80% EE
scalarLow = 5;
scalarMid = 7;
scalarHigh = 5;
break;
case -1: // Stock EE
return s_nBlockCycles >> 3;
case 0: // 110% EE
scalarLow = 2;
scalarMid = 2;
scalarHigh = 2;
break;
case 1: // 125% EE
scalarLow = 2;
scalarMid = 1;
scalarHigh = 1;
break;
case 2: // 150% EE
scalarLow = 1;
scalarMid = 1;
scalarHigh = 1;
break;
Ofcourse you also need to change the text in speedhackspanel.cpp to make the users aware of it. the other remaining thing to do is modify the preset to make sure that it works well on EE cyclerate.
But this is not compatible with current values of the ini or?
(08-28-2015, 12:00 PM)willkuer Wrote: [ -> ]But this is not compatible with current values of the ini or?
currently it uses the value 0,1,2. from now on, it will be using -4 , -3, -2, -1 , 0 , 1 , 2 for values. the values are compatible but the functions will be different, example: 1 at old code will reduce EE cycle rate whereas new code will increase the EE cycle rate with lower scalar values.
And that is exactly the concern if I understood correctly. When people now want to use their old ini-Files in new version they will not get what they expect.
I would still recommend to remove this stupid switch command. Using the current implementation I would rather recommend:
Code:
scalarLow = Math.Max(3.75 - 0.7 * EmuConfig.Speedhacks.EECycleRate, 1);
scalarMid = Math.Max(4.5 - 0.8 * EmuConfig.Speedhacks.EECycleRate, 1);
scalarHigh = Math.Max(3.75 - 0.7 * EmuConfig.Speedhacks.EECycleRate, 1);
Then you can determine granularity and limit values at a different position (e.g. in the UI). If there is some recommendation to use low precision values (as 1.5 instead or 1.48453) one could as well put a rounding in front.
@Blyss Do you know the exact values?
Quote:The scalar defaults are ~3,5,3 or so,
(08-28-2015, 12:52 PM)ssakash Wrote: [ -> ]the values are compatible but the functions will be different, example: 1 at old code will reduce EE cycle rate whereas new code will increase the EE cycle rate with lower scalar values.
Unless the results are exactly the same, that is not backward compatible. I don't really understand what the problem is, though. Just write a conversion function. It's very easy.
(08-28-2015, 02:06 PM)willkuer Wrote: [ -> ]And that is exactly the concern if I understood correctly. When people now want to use their old ini-Files in new version they will not get what they expect.
They could still change the values either in the GUI (or) INI files afterwards though.
Quote:I would still recommend to remove this stupid switch command. Using the current implementation I would rather recommend:
Code:
scalarLow = Math.Max(3.75 - 0.7 * EmuConfig.Speedhacks.EECycleRate, 1);
scalarMid = Math.Max(4.5 - 0.8 * EmuConfig.Speedhacks.EECycleRate, 1);
scalarHigh = Math.Max(3.75 - 0.7 * EmuConfig.Speedhacks.EECycleRate, 1);
the scalar values are only needed for cycle scale block function and temp variable (float values don't matter) . a simple switch case statement is fairly enough and would also be much more flexible.
Quote:Unless the results are exactly the same, that is not backward compatible. I don't really understand what the problem is, though. Just write a conversion function. It's very easy.
backward compatibility ? only the function values would be changed at the method though. the older function would be present at a different value.
(08-28-2015, 06:00 PM)ssakash Wrote: [ -> ]the scalar values are only needed for cycle scale block function and temp variable (float values don't matter) . a simple switch case statement is fairly enough and would also be much more flexible.
At least you should write a function that returns scalar values. Can't you formulate it? Where do the values come from?
(08-28-2015, 06:00 PM)ssakash Wrote: [ -> ]backward compatibility ? only the function values would be changed at the method though. the older function would be present at a different value.
If it's backward compatible, it's fine.
