Solitaire
Re: Solitaire
Seems ReadPowerSwitch() does not work the same on Uzem and real hardware though it's not a big deal. It would be cool to finally do something with the console buttons. This seems a pretty easy thing to add to Uzem?
Re: Solitaire
I put the newest version of Solitaire up and there are a couple small bug fixes since last version. I think mouse should work in either port now and support being plugged/unplugged at any moment, I will have to try tomorrow to find where I even put that thing since it's a late night at this point!! Let me know if any other bugs are found, otherwise I'm calling this final besides Uzenet script testing down the road.
Re: Solitaire
Great! I'll give it a good play and report on it.
Re: Solitaire
I say it's pretty polished and good to go. Only a little thing though. The demo gets in to way fast, I don't even have time to click on thing and I loose control of the mouse! And I can't seem to go back to menu without using the other controller. I'd crank the delay a bit and perhaps as soon as the player moves the mouse it should deactivate the auto-play?
Re: Solitaire
Does it work for either port on the mouse now on your end? I read some mice firmware *might* need a full sensitivity sweep before their output means anything. I figure there are what..2? people with the SNES mouse so I wont worry about a problem that isn't there 
Especially because a "proper" mouse detect is not very fast at all if you want to check every frame. I think a lot of these timing and other things that are "required" are only thought to be so because someone put an oscilloscope on their SNES and Mario Paint happens to do it that way. I don't think I care enough, but it would be nice to know I'm not wasting anymore cycles than are necessary. The game always reads the extended mouse data even if there is not a mouse connected, then afterwards deciphers the meaning based on the device signature.
You are right that delay is really short I might triple it actually. I'll check, once it starts fading out I don't think it turns back even if you were moving. You can always hit a non-dpad joypad button or a mouse button to skip the AI playing, I will see if there was any reason I avoided using mouse move to do so. So I really wish it was a 3 button mouse like the genesis one, but hey it was the early 90's. I did put a way for the mouse to access the menu though. You will see a small red check mark above your score and you can click that with the mouse to open it up.
One question, on your end moving the mouse on the main menu/title screen does hold off the demo mode as long as you keep moving it correct? At this point I honestly do not take anything for granted on the mouse working correctly, but on my end it seems to be so.
Edit-Crap! Clicking new hand some times corrupts things. I don't think it did this before, and it is probably a cycles thing from the mouse. SO want to get this off my mind
It might be as simple as not letting Uzenet run if the user clicked or releases something, since that's when expensive game logic happens
Especially because a "proper" mouse detect is not very fast at all if you want to check every frame. I think a lot of these timing and other things that are "required" are only thought to be so because someone put an oscilloscope on their SNES and Mario Paint happens to do it that way. I don't think I care enough, but it would be nice to know I'm not wasting anymore cycles than are necessary. The game always reads the extended mouse data even if there is not a mouse connected, then afterwards deciphers the meaning based on the device signature. You are right that delay is really short I might triple it actually. I'll check, once it starts fading out I don't think it turns back even if you were moving. You can always hit a non-dpad joypad button or a mouse button to skip the AI playing, I will see if there was any reason I avoided using mouse move to do so. So I really wish it was a 3 button mouse like the genesis one, but hey it was the early 90's. I did put a way for the mouse to access the menu though. You will see a small red check mark above your score and you can click that with the mouse to open it up.
One question, on your end moving the mouse on the main menu/title screen does hold off the demo mode as long as you keep moving it correct? At this point I honestly do not take anything for granted on the mouse working correctly, but on my end it seems to be so.
Edit-Crap! Clicking new hand some times corrupts things. I don't think it did this before, and it is probably a cycles thing from the mouse. SO want to get this off my mind
It might be as simple as not letting Uzenet run if the user clicked or releases something, since that's when expensive game logic happensRe: Solitaire
Ok I got a second wind on this game. "NEW HAND" bug is fixed and the deck gets shuffled a lot more as well. The check mark collide area you can click with the mouse to bring up the menu is now larger and easier to click(the coordinates were slightly off before too).
Title screen timeout value has been tripled to 12 seconds. Now pushing ANY pad or mouse button as well as moving the mouse will skip the attract mode and high score display.
Intro portion now uses a truly random seed number, and so the cards shown will be mostly different each time you play, even in Uzem. Your EEPROM preferences are still used when you get to the title screen.
The updated rom has been attached to the first post. With that, I say it is officially done!
Title screen timeout value has been tripled to 12 seconds. Now pushing ANY pad or mouse button as well as moving the mouse will skip the attract mode and high score display.
Intro portion now uses a truly random seed number, and so the cards shown will be mostly different each time you play, even in Uzem. Your EEPROM preferences are still used when you get to the title screen.
The updated rom has been attached to the first post. With that, I say it is officially done!
Re: Solitaire
It won't be easy. 
Before mouse+controller were working in any order at the same time on my hardware. Now if the controller is plugged, mouse wont move (but buttons registers). In a game even plugging the controller, I can't bring the menu, seem its buttons are not responding. I have to unplug the mouse!
Apart that, it all gold.
Before mouse+controller were working in any order at the same time on my hardware. Now if the controller is plugged, mouse wont move (but buttons registers). In a game even plugging the controller, I can't bring the menu, seem its buttons are not responding. I have to unplug the mouse!Apart that, it all gold.
Re: Solitaire
mouse+joypad is not an easy coexistance 
Eh, I'll get it right one of these times!
Eh, I'll get it right one of these times!Re: Solitaire
Ok I gutted the old method and made a new implementation the right way. I had an inaccurate view on how the bit streams lined up between a mouse and controller that lead me to attempt a simpler hack that kind of worked enough to make me think it would do everything I need. Now, every frame I read in 32 bits for both controllers into buffers. Then based on the device signature handle each separately based on whether the particular port is a mouse or a pad. It then composites it to a padstate(d-pad,pad buttons, mouse buttons get converted to pad buttons), and a mouse state(movement of the mouse if plugged, otherwise zeroed). So far it works for 2 joypads and 1 mouse and 1 joypad(or each on it's own) as well as "fighting for control" using the joypad a mouse simultaneously moving the cursor with both at the same time. The way it's handled now should also do nothing more bizarre than would be expected with 2 mice but I don't have another one to test and it's a silly case. Last thing I ran into something I can't figure out quite yet where BTN_MOUSE_LEFT/BTN_MOUSE_RIGHT are actually reversed between hardware and Uzem with the same code...so I'll post the update when that makes any sense to me. Truly blowing my mind though
Just wanted to mention this so I will remember to look into it. Normally a real controller will return 1 for every read after the 16 bits of shift register have been exhausted, but Uzem returns 0's. This could probably be fixed by changing the MSbit after the button state is read and shifted if not in SNES mouse mode.
Another thing is the way Uzem handles the mouse(the upper 16 bits after the normal 16 controller bit reads). My real SNES mouse does not unset the bits for Left movement and Up movement(only if you later move Right/Down) even if you stop moving for any length of time. It would simply continue returning Left/Up movement with a magnitude of 0 in each direction. Uzem however, currently returns 0b0000000000000000 no matter what if not moving. My real SNES mouse returns 0b1000000010000000 when not moving if the last movement was both leftwards and upwards(since those bits are used to indicate such). For example if the the last movement was Right/Up it would return 0b1000000000000000(Up flag) or if it was Left/Down it would return 0b0000000010000000(Left flag). This one can cause confusion for any game that used an "Attract Mode" and also the mouse, where the first thought would be to cancel the attract mode if the mouse moves at all. It would seem intuitive(and currently works in Uzem) to do:
On real hardware it would always cancel attract mode immediately if the last movement you made with the mouse was Left and/or Up. So you have to do this:
It might never be an issue for anyone else, but it is confusing whenever something works in Uzem but not hardware or vice versa. I think a lot of games would benefit if mouse development was easier; Zombienator in particular would be way better! The PS/2 mouse does not seem to generate much interest, but for completeness sake I might try implementing it copying Alec's keyboard implementation with a separate tiny MCU you could install in a mouse. Primarily I would want it to accurately emulate the report behavior of the SNES mouse, except that some initialization sequence(as was done for PS/2 Microsoft Intellimouse extension on PCs) would allow extra buttons and scroll wheel functionality. The sequence would cause it to change it's device signature(if it was not a real SNES mouse) and that could be used to detect if it's PS/2 or SNES without bloating out special case code for everything.
Just wanted to mention this so I will remember to look into it. Normally a real controller will return 1 for every read after the 16 bits of shift register have been exhausted, but Uzem returns 0's. This could probably be fixed by changing the MSbit after the button state is read and shifted if not in SNES mouse mode.
Another thing is the way Uzem handles the mouse(the upper 16 bits after the normal 16 controller bit reads). My real SNES mouse does not unset the bits for Left movement and Up movement(only if you later move Right/Down) even if you stop moving for any length of time. It would simply continue returning Left/Up movement with a magnitude of 0 in each direction. Uzem however, currently returns 0b0000000000000000 no matter what if not moving. My real SNES mouse returns 0b1000000010000000 when not moving if the last movement was both leftwards and upwards(since those bits are used to indicate such). For example if the the last movement was Right/Up it would return 0b1000000000000000(Up flag) or if it was Left/Down it would return 0b0000000010000000(Left flag). This one can cause confusion for any game that used an "Attract Mode" and also the mouse, where the first thought would be to cancel the attract mode if the mouse moves at all. It would seem intuitive(and currently works in Uzem) to do:
Code: Select all
if(attract_mode){
if((padstate & 0b0000111111111111) || mousestate)//ignore upper 4 bit device signature of pad/mouse
attract_mode = 0;
}
Code: Select all
if(attract_mode){
if((padstate & 0b0000111111111111) || (mousestate & 0b0111111101111111))//mask out Up/Left sign values
attract_mode = 0;
}
Re: Solitaire
Ok I am convinced that Uzem is not emulating the mouse buttons correctly. I tried Whack-a-Mole and found that the left button works but the right button does not, which is exactly the problem I am having. Both WaM and Solitaire work for the right button on hardware, it appears Uzem is encoding the bits wrong here:
I believe this should be
I'm basing this off this document and what I am observing from real hardware. Alec would you mind sanity checking that logic when you get a chance?
Code: Select all
if (pad_mode == SNES_MOUSE)
{
// http://www.repairfaq.org/REPAIR/F_SNES.html
// we always report "low sensitivity"
int mouse_dx, mouse_dy;
u8 mouse_buttons = SDL_GetRelativeMouseState(&mouse_dx,&mouse_dy);
mouse_dx >>= mouse_scale;
mouse_dy >>= mouse_scale;
// clear high bit so we know it's the mouse
buttons[0] = (encode_delta(mouse_dx) << 24)
| (encode_delta(mouse_dy) << 16) | 0x7FFF;
if (mouse_buttons & SDL_BUTTON_LMASK)
buttons[0] &= ~(1<<9);
if (mouse_buttons & SDL_BUTTON_RMASK)
buttons[0] &= ~(1<<10);
// keep mouse centered so it doesn't get stuck on edge of screen.
// ...and immediately consume the bogus motion event it generated.
if (fullscreen)
{
SDL_WarpMouse(400,300);
SDL_GetRelativeMouseState(&mouse_dx,&mouse_dy);
}
}
else
buttons[0] |= 0xFFFF8000;
Code: Select all
//...
if (mouse_buttons & SDL_BUTTON_LMASK)
buttons[0] &= ~(1<<9);
if (mouse_buttons & SDL_BUTTON_RMASK)
buttons[0] &= ~(1<<8);