Sega Model 2 Emulator Full Screen Shooter fix - RamjetM2Borderless - App

[BadMouth]

New rawtest:

Interesting thing was that if I kept the guns aimed in the extreme upper lefthand corner, the x and y coordinates would stay low enough to have the red box on-screen and tracking.

Aim-Trak on 1440x900 LCD


Act Labs on 800x600 CRT TV over S-Video

(After the video I restarted the PC, re-calibrated gun #2 and it behaved the same as the first and I was able to get the red cursor back on screen with it)

I know this is just a test app, but one thing bugs me.
When we use real mice or track pads, each one control a different cursor(red and blue) independently.
But when we use guns or guns in combination with a single mouse, they both control the red cursor.
What's going on?

[Howard_Casto]

Ok this is all good stuff. 

It's hard to read numbers from videos but am I to assume that the values you get at the bottom right corner are in the ballpark of 65535 ?

Because this is the magic constant conversion number for mickeys according to microsoft.  So I have the right info, I just didn't understand how it's supposed to be used. 

Apparently the absolute position is a field of mickeys.  In other words 0 to 65535 for the width and 0 to 65535 for the height.  Extremely confusing considering monitors aren't square, but whatever. 

So to get the pixel position I would divide the numbers by 65535 and then multiply by the screen width or height respectively. 

I"ll whip that up in a second and post it. 

[Howard_Casto]

Here you go.  P2 wasn't coded properly last version btw... sorry about that. 

As for why the dual act-labs guns show up as one mouse... well they were designed that way.  If I remember my ancient history correctly the pc guns came out first, and they were for... well pc games.  Since pc games didn't support two mice it was assumed that people would only want one gun.  MAME changed all of that and by the time the svid guns came out they had did a hardware cludge to detect the different guns by giving player 2 buttons that fired mouse buttons 3 and 4.  The original troubleshooter used the hardware id to detect different button presses, not position changes of the indiviual mice.    Anyway I'm not sure what it's all about, but basically they acted as one mouse. 

Now if the aimtrack guns are behaving this way we are in trouble, but if it's true lightguns then it's no big deal, I can code for that. 

[BadMouth]

Here you go.  P2 wasn't coded properly last version btw... sorry about that. 

As for why the dual act-labs guns show up as one mouse... well they were designed that way.  If I remember my ancient history correctly the pc guns came out first, and they were for... well pc games.  Since pc games didn't support two mice it was assumed that people would only want one gun.  MAME changed all of that and by the time the svid guns came out they had did a hardware cludge to detect the different guns by giving player 2 buttons that fired mouse buttons 3 and 4.  The original troubleshooter used the hardware id to detect different button presses, not position changes of the indiviual mice.    Anyway I'm not sure what it's all about, but basically they acted as one mouse. 

Now if the aimtrack guns are behaving this way we are in trouble, but if it's true lightguns then it's no big deal, I can code for that.

AimTrak gun and mouse were hooked up in the first test.  Both controlled the red cursor. 

will test this version with the aim-trak right now.

[BadMouth]

Ok, most of the time both mice control the red pointer, but twice in about five launches, it worked at it should with the aim-track controlling the red and the mouse controlling the blue.  I'll do some more testing and see if I can find any rhyme or reason.

To keep the red pointer on the screen, I need to keep the x coordinate under around 4400 and the y under 4000.
It's hard to get exact numbers because it's so jumpy.  Uploading pics shortly since youtube was taking so long to upload vids earlier.

[BadMouth]

pic attached

I'll mess with this for a bit longer and see if I can figure out the difference between the times that the mouse countrols the blue cursor and when it controls the red one that the AIM Trak is already controlling.

The S-Video and newer act labs guns do show up as separate mice BTW.
It was only the first generation VGA guns that made P2's trigger and button show up as buttons 3 and 4 on the same mouse.
Doubt I'll have time tonight, but I suspect if I did more than a couple rounds of testing, they would each control a different pointer about the same percentage of time as the aim-trak and mouse on the other computer.

[BadMouth]

If I use the real mouse to click the command button, then it controls the red and the Aim-Trak also controls the red.  Neither moves the blue.

If I use the Aim-Trak to click the command button,  then it controls the red and the real mouse controls the blue.

If I just press Enter to click the command button, then the Aim-Track controls the red and the real mouse controls the blue.

When I was working with the Act Labs guns, I used gun 1 to move the mouse pointer to the command button, then pressed enter (and they both controlled red).  Maybe if I switch guns around?...

At any rate, it's predictable and it does work properly if certain conditions are met.

[Howard_Casto]

Ok I had a Senior moment... did the math backwards in that last one and that's why the cursor was still going off the screen. 

This one should fix that give or take a few pixels because there isn't a calibration routine. 

If you've got another mouse hooked up that's the issue right there. 

I'm just controlling the first two mice found... not the first two lightguns or any special conditions.  Later on I'll look for the actual hardware names and do it properly, but I'd have to KNOW the proper hardware names first... thus the reason I just did the first two mice. I know the act labs guns in particular do some rather funky stuff to the system mouse.

[Howard_Casto]

Oh btw, the mysterous "command 2" is just a math test with a hypothetical mickey value.  If you press it you'll get a message box that shows roughly half the pixel width of your screen. 

[BadMouth]

There are only two mice hooked up to this PC.  A USB wireless one and the Aim-Trak.  No others.

 I think we went too far in the other direction.   

The cursor doesn't move more than a couple inches away from the top left corner.
In the attached pic, the gun was moved all the way off the bottom right of the screen.
The cursor moves in relation to the gun, just not very far.

BYOAC is pitching a fit about the pic sizes (even though the last one should have been the same size)
I'll edit this post and attach them after I get them resized.

[Howard_Casto]

Yeah two message boxes should pop up.  The first shows what you showed, which is basically 32767 / 65535 or roughly half the screen in mickeys.  After you press ok, a second box will show up, which is half the screen in pixels or in your case about 720. 

I can try one more thing, namely to remove the vb twips mode, which eliminates one of the conversions.  Hold on a sec....

[Howard_Casto]

Ok, last one for tonight.  This hopefully should do it .....stupid twips ruin everything. 

[BadMouth]

Ok, last one for tonight.  This hopefully should do it .....stupid twips ruin everything.

Tracks perfect! (as good as it gets for IR guns)

One odd behavior, but it may be hardware, IR LED reflecting off of something.
When I move the gun off the right side of the screen, the cursor will jump back onto the screen a few inches from the edge.
I can still control it, even though the gun is pointed off-screen.  If I continue moving the gun right, it goes off the screen again (and doesn't jump back).

Someone needs to try this with two Aim-Traks and no mice hooked up.
If both guns control the same cursor, relaunch the program and just use enter to push the command button,
or try using the other gun to click the command button.

Actually relieved it's the last one....need sleep.
I will test it with the act labs guns tomorrow, but probably won't have time to do any more.

[Howard_Casto]

Excellent!  And with that I can put this code into the troubleshooter. 

I wouldn't worry about the ID thing.  In the real app you'll get a drop-down box with a list of the mice on your system you can select from.  We might still have some strange issues with the act-labs guns due to the things I discussed before, but as I said, they are fixable. 


Thanks for all the work man... I know it's a pain in the butt to play the back and forth game like this. 

[Endprodukt]

This is so exciting... feels like you're almost there

[BadMouth]

Last rawtest with Act Labs guns:

Red pointer snaps to where the gun is pointed when the trigger is pulled.
Pretty close to dead on perfect when firing centered or to the left,
but seems to start going right as I move toward the right side of the screen.
(not something that concerns us now)

Unfortuneately both guns only control the red pointer no matter what I do.
Neither one moves the blue pointer.
No other mice are hooked up.

The device ID at the top does change depending on which trigger is pulled.
If there are any more tests I can do that would be helpful, let me know.
It will probably be tomorrow morning before I can get to it though.

[Howard_Casto]

Well the device id being different when the trigger is pulled is all I need for true lightguns.  I can read the sysmouse position when the trigger is pulled and apply it to that particular gun's position.... easy as cake.  Even if by some odd chance both users pressed the triggers at the same time, both individual "event fired" messages would come into the function, so I'd read for p1, then read for p2. 

Not M2 related, but I wanted to see if  the values in the original troubleshooter's ini would be useful to me.  The only game I have on the list (on this pc anyway) is HOTD3 and I plugged in the values for p1x and they tracked as expected!  I looked through the ini to see how the various games are tracked and the only one that looks like it might be an issue would be die hard.  With all due respect to the die hard fans, I'm not wasting my time supporting that cruddy game considering it looks like you have to do a full on dx dll hook. 

[Howard_Casto]

Something I just wanted to point out, because it confused me a bit but I hadn't really looked into this. 

For all gun games in model 2, p1 trigger is mapped to player 1 button 1 in the cfg menu.  Player 2's trigger is mapped to PLAYER1 button 2. 

Now we will be hacking in the input status but I just thought I would put it out there. 

[Endprodukt]

What about demul support ? That would be nice.

[RamjetR]

Demul are still in active development aren't they?? Surely they can add their own support easier than what we're trying to do...

[Howard_Casto]

Yeah this is for dead emus (like m2) or emus that have such a restrictive liscense agreement that they won't allow me to add proper windows message code (like daphne). 

It'll have other uses as well.

[Howard_Casto]

Minor progress today.  Lua is kind of poorly documented imho, so I have to kind of poke around to get it what I want it to do. 

Figured out how to write to a specific path today.  The slashes are backwards to what windows users are used to, probably due to lua's multi-platform support. 

so 'c:\test\output.txt' becomes 'c:/test/output.txt'

I can use this to have the scripts write the dynamic memory addresses directly to my troubleshooter.  That's just the easiest way atm. 


I need to find out if the same trick works for the shell command.  The idea is upon init I'll have the script first write the text file containing the addresses, then I'll shell troubleshooter itself with the proper command line.  Since the text file is written first, it assures me that the file is up to date and eliminates the need to constantly check it. 

**update**

I wrote a test app to see what method lua uses to launch exes.  Fortunately it DOES set the working path when an exe outside of the current path is launched, which means that the method I described above will work just fine. 

[Endprodukt]

I don't understand anything but it sounds like your methods could work. That's what matters. Thanks for doing this work to all who are involved.

[Howard_Casto]

Spent a minute or two tonight teaching myself a little more lua. 

This time I learned how to read lines from a text file and apply them to a script.  Since the lua scritps will be launching the troubleshooter and not the other way around, I thought it might be useful to a a user configurable file to set the path where the troubleshooter is instead of forcing them to rummage through the scripts.  On  a somewhat related note, string contatination in LUA is *almost* as bad is it is in straight C. 

And people wonder why most of my stuff is in vb. 

[Endprodukt]

if you need someone for testing I'm in!

[BadMouth]

if you need someone for testing I'm in!

Do you have two aim-traks?
Give Howard's last rawtest will work with two aim-traks.
I only had a single aim-trak and mouse connected.

There was an issue in my testing where if I used the real mouse to click the command button, both would control the red cursor and neither would control the blue.  If I used the gun or the enter key, each would control a different color.

It would be good to know that they control the two cursors independently.
Might not be of as much use to Howard at this point, but I'm curious and it will only take a couple minutes to test.
If they both control the same cursor, try using the other gun to click command the next time.

[Endprodukt]

Will do that today.

[Endprodukt]

here are my results:

pressing return: gun 1 moves red, mouse moves blue

pressing command with gun 1: red will disappear, blue can't be moved with gun 1/2 or mouse

pressing command with gun 2: mouse will move blue, gun 1 and gun 2 will move two flickering red squares (seperate from each other.)

pressing command with mouse: same as pressing with gun 2.

pressing command with trackballs mouse: same as pressing with gun 2.

[Howard_Casto]

This is how it should behave according to my code.  You will be able to manually select the mouse devices in the actual app so this is NOT an issue. 

Thanks for testing!

[Endprodukt]

Great! Want to help as much as I can for something I'm so much looking forward to!

Is there any chance of estimating a first release? I have no idea how much work it takes to code this. Are we talking about days/weeks/moths?

Thanks again for doing this.

[ArcadeBliss]

Thanks guys! I am so looking forward to this. let me know if you need any more tests. I have two Aimtraks and an Opti-pac

[Howard_Casto]

Is there any chance of estimating a first release? I have no idea how much work it takes to code this. Are we talking about days/weeks/moths?

Well back in the day I would automatically delay a release by one day every time somebody asked that. 

Seriously though It'll be done when it's done.  I'm working on it at least a little every day. 

[Endprodukt]

haha, I guess that's the answer I deserved... sorry for beeing so impatient. Please don't delay the release because I was so stupid and asked  

[RamjetR]

Heya, Sorry I haven't been much help lately. If your not up with international news, Australia has been ravaged with 56degreeC heat and bush fires one week and now cyclone and severe flooding this week. I've spent the last 4 days rectifying power outages and restoring radio and microwave communications in 110kph+ winds and rain the likes I've never seen before. I'm still on call till Thursday and I'm sure it won't ease till then...

I'll try to get the M2 X/Y inhibit code operational globally for all the shooters this weekend provided I get power restored to my own house. Here's hoping my new house doesn't go underwater either... apparently the water was lapping the bottom of the driveway yesterday... which scares the buggery out of me as I planned to by my arcade machines in that garage... :S The rest of the town I currently live in was evactuated last night and I'm just watching water swallow the houses below me... it's pretty wild stuff...

Ramjet

[Howard_Casto]

Sorry to hear that man. 

I've been cleaning up the code and it's become apparent that if we don't find a way to properly hook these addresses instead of simply writing to them this isn't going to work.  Upon cleaning up my code the crosshair manipulation suddenly stopped working.  It became apparent that the reason is the new code is *slighty* slower and this decrease in speed made the function to slow to overwrite the values even though the function is an infinate loop that CONSTANTLY overwrites the values.  My machine is a beast btw... it probably wouldn't run even with the old code on a lesser machine. 


I found some vb code for an app that does some low-level hooking.... I would say it looks promising, but I've yet to get it to actually hook anything yet (it does show me the addresses of all the api calls from m2, such as getcursorposition). 

[RamjetR]

You were hooking in with writeprocessmemory weren't you? How about we take more of a closer look doing this inside the Model 2 emulator itself. What I've been doing in the rare 20mins I have spare here and there as part of reverse engineering the emulator writing the code to the in game axis, is analyzing the code from other ROMs which are accessing joystick inputs and where it's pulling the data from and using parts of that code to inject into the running process of the shooters. Now there is a bit to isolate but with it running in the current process as a trainer, I can do the mouse update halt and code jump to joystick code and return. Thats how I got the code reference for stopping the x/y updates to enable your code injection to work without being hindered by the emulator. I suppose you could call it working on the otherside of the API calls from the emulator side rather than the OS side lol?

[Howard_Casto]

All I really need to know is the addresses to the functions in m2 where it goes to set the variables we want to change so I can disable them. 

Maybe you sent me the wrong cheat file before, but turning it into a nop didn't have any effect nor did "freezing" it.  So I don't think we are on the same page as to what you are doing. 

I can set the memory to read only, but that could crash m2 depending upon it's error handling.  I have other options on my end that I can do, but the more low-level I go, the more chance of a massive crash or memory leak. 

[vandale]

Heya, Sorry I haven't been much help lately. If your not up with international news, Australia has been ravaged with 56degreeC heat and bush fires one week and now cyclone and severe flooding this week. I've spent the last 4 days rectifying power outages and restoring radio and microwave communications in 110kph+ winds and rain the likes I've never seen before. I'm still on call till Thursday and I'm sure it won't ease till then...

I'll try to get the M2 X/Y inhibit code operational globally for all the shooters this weekend provided I get power restored to my own house. Here's hoping my new house doesn't go underwater either... apparently the water was lapping the bottom of the driveway yesterday... which scares the buggery out of me as I planned to by my arcade machines in that garage... :S The rest of the town I currently live in was evactuated last night and I'm just watching water swallow the houses below me... it's pretty wild stuff...

Ramjet

wow! Sorry to hear. Ive been watching the news here in NZ. Reminds me of the horrific time we had in the Christchurch earth quakes a few years back, moved the hell away from there in a hurry!

Bring on Thursday

[Howard_Casto]

You were looking for stuff via emulator.exe.... I was looking for stuff via emulator_multicpu.exe, apparently there is a difference. 

I did find some more locations for NOP insertion that worked for me. Once NOPed my app did work as it should.  Now If I could only figure out how the heck to manually make a trainer from the cheat engine... or figure out WTF their addresses are. 

[Howard_Casto]

Well it's time for me to take a break as well.  It's been 70 degrees here one day and 20 the next.  My pipes decided they didn't like that so I've been fighting them all day.  And it's supposed to be below freezing by tomorrow night (even though it's 72 now) and I've got a bunch of exposed pipes with no insulation on them.  Looks like we are going to get some of those crazy winds you were talking about over here in the States as well.  Weather, as a whole, seems to be screwed up anymore. 

I hope things get better in your neck of the woods Ramjet.  I realized this evening that my posts make it seem like I'm disinterested, it's just that's the types of posts you'll get from me at 4am when I'm having trouble sleeping.