Raw input in taito type x lightgun games
Window hooker to run fullscreen programs in window and much more...
Status: Beta
Brought to you by:
ghotik
Menu
▾
▴
Hi, Ihave read the supermodelemu topic, and I'm having similar problems with taito type x lightgun games:
IN Gaiaattack4 for example seems to display properly at1280x768, butI need to run 640x480. Dxwnd does it right, but I'm using demulshooter, aprogram that provides dual gunsupport using rawinput.
without demulshooterI can check "correct mouse poition" and the aiming gets aligned.
But using demulahooter the aiming dont reaches the full axis. I tested the latest built with the rawinput option but no luck. Any idea? Thanks
Well, I don't know how exactly demulshooter works, first idea is to try it and see. Is is a free program or licensed? I see a downloadable release 7.6, does it correspond to yours?
If you have some additional configuration info, please send.
Last question: does your configuration include two normal USB mouses or is it necessary some special hardware?
Demulshooter is free, yes, release 7.6 is the last release that supports gaia attack 4.
But I think it wont work with regular mice, I think it only works with absolute devices, like lightguns and maybe wiimotes.
The problem seems to be the "same" than in supermodel, if I dont use rawinput I can correct the aiming with correct mouse position, but I cant using rawinput. The new rawinput option in dxwnd doesnt seem to work in this case.
I have this same problem with Fright fear land, Let's go island, Haunted museum, and maybe some other.
In some games like Aliens extermination I could change the resolution editing the exe with an hex editor, but in those, I don't know which offset should I change.
In effect, the DxWnd raw input option is not fixing coordinates in the way you need because the problem was resolved by hacking (and later fixing by the program's author) the supermodel directly, so I stopped the development of a not useful feature.
If you need something different, we could add a sort of "custom coordinate translator" to DxWnd so that you can remap the coordinates as you like, some sort of linear transformation like this by setting 4 custom parameters cx, cy, offx and offy.
But the first step is looking at what's going on. You should start a very short gaming session and collect input traces also describing me the experiment and providing some screenshot. To identify the situation in a very verbose log you should terminate the game session with Alt-F4 so that the last log lines tell where the cursor was left. So, summarizing, you could do the following:
1) set DxWnd the best you can, including DirectInput / XInput hooking
2) set DxWnd log options including "Input" and "Debug" flags
3) Run a short game session moving (or trying to move) the lightgun in a critical position
4) while the cursor is still in place, press Alt-F4 to stop the program
5) check that the dxwnd.log file has some meaningful information and post it here
6) post here the description and a screenshot, like "I tried to move to upper-right corner but the gun pointed just halfway to where it should be". If necessary, you could edit the screenshot to mark where the cursor was and where it ought to be.
What about it? The only alternative is you buying and shipping me a pair of lightguns, but I think my proposal is simpler and cheaper ;)
Last edit: gho 2018-06-09
Many thanks, here it is:
in gaiaAttack640x480.png, I launched the game without dxwnd, as you see, some graphics get not scaled, but yes the 3d rendering. The aiming here its ok.
in gaiaAttack640x480.png, I launched the game at 1280x768 which looks the best, I suppose the native one, and I use dxwnd to resize to 640x480. As you see the resize is nice, but the coordenates gets wrong. I'm aiming near the same position as the other screenshoot, but the coords seems blocked to the proportional area for 640x480 if we suppose the resolution is 1280x678. Its what I indicated
Last edit: phasermaniac 2018-06-09
Weird, the DxWnd log flags seem ok, you checked both INPUT and DEBUG options and the log shows the creation of a DirectInput8 session, bt then there is no trace of attempts to read mouse (or keyboard) data. Of course, if you set the screen size to 640x480 and fit the game inside it, unless DxWnd scales the coordinates you'll never get a coordinate value outside the 0,0 - 640,480 range, that corresponds to the square you draw.
So, it seems that DxWnd is not intercepting the data from the lightguns, that's odd!
Maybe you configured the supermodelemu to use XInput: in that case you should also set the "Input / Hook Xinput" flag to intercept the lightguns. Please, repeat the experiment with Xinput hook set, and this time add also the "Logs / DxWnd hacks" flag to get even more information.
This is not supermodel, they are taito type x games I only use demulshooter to provide them rawinput I think it uses rawinput, not Xinput, but not sure.
My mistake, if the emulator uses RawInput you should set also the "Input / Fix mouse rawinput" flag. Can yo repeat he experiment & send log, please?
Ok, I got to unset "correct mouse position", else setting "Input / Fix mouse rawinput" seemed to cause the gun not moving the crosshair
I need to see the log with also the "correct mouse position" flag set. It doesn't matter if the gun crosshair is not moving, the log could tell me what's going on. But it seems that RawInput is definitely the problem: the RawInput calls are found in the executable (see the log) and the RawInput flag is changing something (currently for worse, but it doesn't matter). The RawInput logic would scale all input from mouse devices, maybe demulshooter is sending input data as coming from some other device type, or maybe there's simply some bug in the DxWnd logic.
Another interesting thing would be having a copy of the emulator program. Either it's a dedicated program or a console emulator, sharing the program alone (with no game ROMs) is relatively legal, so there should be no harm in posting the (zipped) exe here.
there's not emulator. Taito type x games works directly on windows pc. I only use demulshooter for playing with 2 guns.
To run demulshooter youll have to open Demulshooter.exe and adquire one or two devices, then save.
Next run via commandline with :
Demulshooter.exe -target=ttx -rom=gattack4
Gaia attack 4 only needs some options on the ini to be changed to run fine with demulshooter. It is detailed on its readme. I attach my ini file.
I still see no input traces in the DxWnd log. I think I'd better replicate some of your situation here. It will take a while, do not despair ....
I apologize, maybe it was necessary to add a further trace flag. To avoid possible errors, I'm attaching here the screenshot of the log panel and input panel as they should be set to provide the maximum possible information.
P.s. could you post the zipped game.exe alone? I would like to check what sort of input methods are called.
Last edit: gho 2018-06-10
this is only the exe, the whole game is about 3gb
please, see my post update above with directions to grab a (hopefully) better log ...
Very strange, I'm noticing that the game.exe has no whatsoever input method connected. It doesn't link DirectInput or DirectInput8, nor Xinput, it doesn't load these modules dynamically through LoadLibrary and doesn't have CoCreateInstance calls that may create a input session otherwise. All the traces in the logs related to DirectInput and RawInput could be simply caused by DxWnd hooks and not being made really by the game.
It looks as if the input to game.exe is coming from some other way - some interprocess channel with another executable or whatever. Maybe I'm wrong, but if I'm right game.exe is not the executable to hook for input scaling!
Last edit: gho 2018-06-10
here it is
actually the game have before_run.bat:
REGSVR32 /s ir50_32.dll
dont think it has something to do with this
and codec_install.exe, that seems to fix some video parts.
Last edit: phasermaniac 2018-06-10
I read some doc about demulshooter, it is quite curious. According to that, the tool reads two input devices and then multiplexes their position coordinates by repeatedly moving the mouse single-cursor alternating the positions of each device, probably by means of a SetCursorPos system call or something similar. But this doesn't explain why the game.exe should work this way.
I'm also wondering if it could be possible to cheat the game by changing the values in MINIGUN.INI, where there are screen size values in two places and these could be replaced by the real 640, 480 values ...
P.s. Could you name some smaller game (anything lesser than 3GB) that could be **hem** searched for testing? Please, feel free to use also PM channel, just in case ....
Last edit: gho 2018-06-11
if I set 640x480 in MINIGUN.INI the guns aiming is right but it doesn't resize properly (gaiaAttack640x480).
What I do to resize it properly is to set 1280x768 in MINIGUN.INI and udse dxwind to show at 640x480 (gaiaAttack1280x768_dxwnd640x480), but I have the coordinates problem descrived above.
Haunted Museum is about 500 Mb, better for testing.
Last edit: phasermaniac 2018-06-11
Wow, impressing.
I got perfect results this way, try to follow these directions:
These settings were perfect with 1 mouse / gun, hopefully they will be good also with 2 to 4. It should be the "Position message processing" flag that makes the difference.
Please, let me know ....
Last edit: gho 2018-06-11
No luck, sameas before, but did you use it with demulshooter? Using it, correctmouse positionnor position message precessing seems to work
No, I first tried without. Tomorrow I will try again with it, though I will have to emulate two lightguns (maybe two USM mouses?). Too bad, I hoped in some luck.
Reading more about DemulShooter I got some scary words about coordinates "injection": if the tool doesn't send regular input but uses code injection techniques, it may easily conflict (or bypass) DxWnd processing.
I wrote a post (now waiting for moderator's approval) to the http://forum.arcadecontrols.com/ board. Hopefully I will get some help.
Hi, so let's explain what's happenning in this case.
Let's start with the easiest part : Yes, DemulShooter is directly injecting values in emulator/game's process memory. That's why there is no mouse log or anything like that in DxWnd
Now a little bit of technical stuff, and how it's working :
1) I'm getting the raw location of the device. As for example, for Aimtraks, it's in a range [0x0000 - 0xFFFF], in absolute positionning
2) I'm getting the desktop resolution and then translate raw coordinates to desktop location so we have now [DesktopX; DesktopY]
3) I'm getting the process main window's size and location, then thanks to the ScreenToClient Win32 API I'm translation desktop coordinates to window coordinates. We have now [WindowX; WindowY]
4) Now there is the issue : usually games in Arcade have fixed range for gun coordinates, so another translation step is needed, but not for HauntedMuseum and GaiaAttack (and others from this game engine) that are waiting for data according to their resolution
So this means that for these users with DxWnd the screen is 640x480, the desktop is 640x480, the game's window is 640x480 but with the MINIGUN.INI the game's engine is waiting for 1280x768 values..... this is why they can't move past the upperleft part of the screen as they won't get anything more than 640x480
One solution would be for me to find a way in the game's memory to get the engine resolution and scale accordingly, I'll have a look
But I don't think you can do something else with DxWnd, it's not really your fault
I hope I've been clear enough to be understandable :)
@argonlefou: First of all, thank you very much for paying us a visit here and for giving such a clear explaination. It corresponds pretty much to what I feared it could be going on.
Given that DxWnd seems to grow in popularity to manage weird situations, I hope you could consider a possible (and I believe cheap) extension to your tool where the desktop resolution is not (by default) determined by direct measure, but rather configured as additional (and optional) parameters.
That would manage this situation perfectly: on a 640x480 desktop, DxWnd would run the emulator at 1280x768 and resizing its video output, while DemulShooter would get the device input and mapping it to the configured 1280x768 coordinate range before injecting it to the emulator.
In addition (I don't know if you ever considered this possibility) this feature would be useful when you would extend your tool for networked interface, where the input could be read from a host whose resolution doesn't correspond to the desktop size of the target networked host where the emulator is running. But it's only a weird idea.
P.s. I found no trace of source code and I got the impression that DemulShooter is NOT open source. If I was mistaken, my apologies and if sources are available I could consider to make the patch by myself.