For the 100th time. SUBMIT THE CODE!
The latest idea to use the -joy & -mouse options to select between options in the driver code would be refused.
Whom did you consult, or is that just YOUR own OPINION?
Submitting code just to be refused is waste of time, no?
Are you back to actually try to learn something or just rant more. Everything in your new rant shows that you refuse to read anything. You actually cut the answers given right out of the quotes you make.
I explained why these options are not to be used. Also the proof is in the fact the no drivers do this. It limits the users ability to map inputs the way they desire.
If you actually read anything I wrote, I stated that my own first code submissions would be changed to meet core standards. I did not rant on like a child about that. I used it to learn and become a team member.
I will ignore the rest of your trolling and move on to your code. I will discuss it for the forum members that actually do want to learn from technical discussions. Feel free to actually learn from the discussion of it.
static READ8_HANDLER( leta_r )
{
static int last_in, input, rotations, last_angle, angle;
int aX= input_port_read(space->machine, "LETA0") - 127;
int aY= - (input_port_read(space->machine,"LETA1") - 127);
int relative_in = input_port_read(space->machine, "LETA2");
if(aX!=0 || aY!=0){
if((angle= atan2(aX, aY) *22.9183)< 0) angle+= 144;
if(last_angle > 120 && angle < 24) rotations+= 144;
if(last_angle < 24 && angle > 120) rotations-= 144;
input = (last_angle = angle) + rotations;
}else if(last_in!=relative_in)last_in=input=relative_in;
return((offset&3)<1)?
input_port_read(space->machine,"LETA3") : input;
}
First off, you removed the whole checking if the hander is only running from the 720 game. This will break all other games that use the LETA ports. Do not remove the "state->pedal_count != 0" check and handling that is in the original code. You can not overlook the fact that other games use these ports.
int aX= input_port_read(space->machine, "LETA0") - 127;
int aY= - (input_port_read(space->machine,"LETA1") - 127);
Interesting changing the -128 to -127. Unforunately 8-bit integers go from -128 to + 127. So this would be wrong.
We are tring to change an UINT8 (0-255) to a INT8 (-128 to +127). So if the UINT8 value is 0 it should move to -128.
0 - 127 = -127 (wrong)
0 - 128 = -128 (correct, at min)
255 - 127 = 128 (wrong, overflows to -1)
255 - 128 = 127 (correct, at max)
128 - 127 = 1 (wrong, not center 0)
128 - 128 = 0 (correct, at center)
I imagine your code only seems to work because you must have changed the port default from 0x80 to 0x7f.
FWIW you do not need to do (offset & 3) like the previous code did. That is done automatically by the core memory call. I only mention this to explain how it works. Leaving the code as (offset & 3) would not reflect poorly on the submission.
AM_RANGE(0x1810, 0x1813) AM_MIRROR(0x278c) AM_READ(leta_r)
Memory range 0x1810 to 0x1813 can only have an offset value in the 0-3 range.
I won't even bother to check if your changes to the joystick code is correct. But it does not seem so. This seems strange but it does not matter to the discussion:
if((angle = atan2(aX, aY) *22.9183)< 0)
angle += 144;
I also will ignore that you asign values in the if statement. I do not beleive Aaron would let that pass. It should be like this:
angle = atan2(aX, aY) *22.9183);
if (angle < 0)
angle += 144;
You really need to change the names of the ports. LETA0 is the centering, LETA1 is the rotate. And name the fake ports as such. That would have been the cleanup part of my original walkthrough, that you just ranted about instead.
MAME concerns itself with actually hooking up ports that the original hardware had hooked up. In my original walk-through I suggested just using the LETA ports to make things easy for the discussion. The unused LETA ports really should not be used this way. I would have discussed this after step 1/2 had been completed and we moved on to the cleanup. I would have explained why the fake joystick port tag should be renamed as such. And the original unused LETA ports be passed through unchanged.
So your code at this point should be:
static READ8_HANDLER( leta_r )
{
static const char *const letanames[] = { "LETA0", "LETA1", "LETA2", "LETA3" };
atarisy2_state *state = space->machine->driver_data<atarisy2_state>();
if (offset <= 1 && state->pedal_count == -1) /* 720 */
{
static int last_in, input, rotations, last_angle, angle;
int aX= input_port_read(space->machine, "FAKE_X") - 128;
int aY= - (input_port_read(space->machine,"FAKE_Y") - 128);
int relative_in = input_port_read(space->machine, "LETA1");
if(aX!=0 || aY!=0)
{
if((angle = atan2(aX, aY) *22.9183)< 0)
angle += 144;
if(last_angle > 120 && angle < 24)
rotations += 144;
if(last_angle < 24 && angle > 120)
rotations -= 144;
input = (last_angle = angle) + rotations;
}
else if (last_in! = relative_in)
last_in = input = relative_in;
return (offset != 1) ? input_port_read(space->machine, letanames[offset]) : input;
}
return input_port_read(space->machine, letanames[offset]);
}
The rest of the code, unfortunately is a complete hack. Unfortunately you refused to understand my code which shows how the game truly behaves. Your only concern in your code seems to be to make the game behave in the way you want it to. No concern for how it really behaves is shown.
I know you want to completely ignore the center disc and only concern yourself with game play, but that is not what MAME wants. You modified the joystick code to not return any centering data because "you" do not care about it. You are free to not care in your own build.
I have told you my spinner code lets you test the game code with simulated centering data that matches the real thing. You want to ignore that and are free to do so in your own build. As far as MAME goes, the game constantly polls this data. A way for us to test this is preferred. The service mode control test will only constantly pass this test with a real control or my spinner code. It will go out of sync otherwise. Again you are free to ignore this in your build. MAME does not.
So now, congrats you made it to step 2 of my original coding walk-through. Well even though you did not post the PORT code (step 1,) I can infer what it must be. You made both the real input and the fake joystick exist at the same time. Adding the spinner code like I did was not part of the original challenge. Though I would have moved on to explain it if we ever sanely got past the cleanup part after step 1/2 were done.
That leads us to the final thing I would have got to. The problem with making the fake/real controls exist at the same time. It would be nice to see your PORT code to see how you handled this. I would have suggested at this point an easy to use menu selection so the user does not have to see/understand why there are multiple inputs in the player control menu. A lot of users already have a hard time with the fact that inc/dec buttons exist at the same time as the analog axis. Adding more ports mapped together would only add to their confusion. So IMHO a user selection process if preferred to limit the player controls and analog settings to just the control the player wants to use.
One final thing is that the final submission should follow MAME coding standards. So each { } in if statements should be on their own line. I do not say this to be picky. It is a code policy that you need to be aware of. See:
http://mamedev.org/devwiki/index.php/MAME_Coding_ConventionsYou may feel that having standards is being too picky when your only concern is making one game behave the way you want. MAME has to concern itself with
marinating maintaining thousands of games. Standards need to be followed. MAME is an ongoing project. I'm sure you will find old drivers not up to current standards. These should not be used as an argument to justify old standards. MAME's policy when working on old drivers is to try to update them to new standards whenever work is done to them.
First submissions will not be refused for not following standards. If the code serves a valid need, it will be cleaned up and added. For future submissions to be continued to be looked at as good quality, the person will be explained the standards. If they learn from it they will continued to be guided when needed. Refusing to learn from the process, will reflect negatively.
1.) Do you want to know how to fix flickering animation?
2.) Do you want to know how to solve jittery analog motion?
Submit the code once you are sure it is correct. Not if it is anything like the code you submitted in your post. If it is it will be rejected. No one will bother giving you the in-depth explanation that I have here. MAME does not have a paid response team to to handle all messages. If a submission shows promise, someone usually tries to guide the person who submitted the code. If it is totally wrong like above, it most likely will not be responded to.
(edit) stupid spell checker - marinating?
Home
Help
Search
Login
Register
Send this topic
Print
Topic: 720 Real/Joystick/Spinner Test (Read 28034 times)
