Do you have any delay for the mouse release event?

are you saying I should be sending a PRESSED, then wait some time, then send the release? The actual code is pressed, send it to handlemousebutton, then release, and handlemousebutton again, so the "click hold length" is extremely small i would image.

Ive tried a SDL_Delay in between the pressed and released (which is obv wrong, as it freezes everything), but that doesnt help. Is there a threads command or something I can use to sleep properly?

If you mean something else, then I am welcome to suggestions.

You have to effectively model what happens in GFX_Events (SDL_MOUSEBUTTON stuff) and not sure if
some games would freak out because they get rapid mouse callbacks.

Are you feeding a complete SDL_MouseButtonEvent?

Ive tried a SDL_Delay

That pauses the host, doesn't add a delay to the game. PIC_AddEvent and the likes can be used to schedule delayed execution.

Yeah, I knew sdl_delay was wrong. 🤣

Now it might be getting over my head until I look at the code more.

Like i said the logic of it is follows:

mousemotion:
move cursor to x,y

button down event:
get current time
and *thats* it, nothing else is done.

button up event:
calculate difference of time since the down event
send pressed and released events (right after another) of the correct button (left if a quick tap, right if time difference > 1000ms)

aka

event.button.button = SDL_BUTTON_LEFT;
event.button.state = SDL_PRESSED;
HandleMouseButton(&event.button);

event.button.state = SDL_RELEASED;
event.button.button = SDL_BUTTON_LEFT;
HandleMouseButton(&event.button);

Ive also set MOUSE_DELAY higher than 5.0, doesnt help xcom. 🙁 (although is that even the right var to delay? if not, im really going to have to look at those PIC events more carefully, and might be over my head)

I would say its something with my logic, but a lot of the games work perfect. 😒

Oh well, time to look more at the code, good learning expereince if nothing else. And thanks for the help. btw dosbox rocks!

Can you post a diff of sdlmain.cpp and others if necessary?

Just my 2 cents but doesn't SDL 1.3 provide better touch stuff? Probably porting disbox via the compatibility header to sdl 1.3 might be more fruitfull.

The compatibility stuff was really awful (windows) when I last tried but that may certainly be interesting to try.

Hmm, maybe it needs to be fully ported then. The iOS port should have some pointers to it already.

I have attached the full sdlmain.cpp

note, I am compiling with HPTOUCHPAD *not* defined (these are future improvements, that involve multitouching, note this exhibit the exact same problem, some games work perfectly, some do not receive any clicks)

Ignore ALL opengl stuff, its being compiled with opengl disabled, and its currently broken anyways (opengles stuff)

mouse.cpp also attached, thats where MouseCursorMoved2 is (moving mouse to absolute position)

I dont think webos has support for sdl1.3, and to be honest, using .which for events isnt turning out to be that bad...

And I hope Ive attached the right ones. 🤣

Don't know if your case SDL_MOUSEBUTTONUP is intended like that (the button type depending on mousediff).

Is there anything in common int33-wise for the non-working games? Like they all use Read Motion Data or similar.

grazzt wrote:

I dont think webos has support for sdl1.3

a quick look seems to say that the webos "pdk" has sdl 1.3 in it. Didn't look further though...

thats exactly what i want for button up, generate a click (aka send a pressed followed by a release) depending on how long the finger is held down. if its held long enough, do a right click, if not, do a left click (the other option is a really long hold, in which case bring up the virtual keyboard)

Im not sure about int33, how do I go about testing that? Should I build a debug build and play around?

Almost at the point of saying screw it, a lot of games work, and to be honest, playing dos games on a touchscreen is difficult at best. (touchpad has no available hardware buttons)

now what i might work on next is adding a virtual joystick for games that only require a joystick+buttons.

Once again, thanks for the help.

as for sdl1.3, like i said, using .which hasnt been too bad, as I have gotten multitouch working in dosbox (aka, two finger tough for right click, but same as before, only works in certain games), and have also added swipe gestures, etc.

Im not sure about int33, how do I go about testing that? Should I build a debug build and play around?

You can use something like

1LOG_MSG("int33 %x",reg_ax);

at the start of INT33_Handler to output data in release and debug builds.

Sorry for being daft, but with . you mean "tip" the actual development branch of SDL? That is generally refered to as SDL 1.3 since there hasn't yet been a release of this. Just asking to clarify this for me. I'm butting out after this since I can't productively help 😉

Ok, that logging seems to be showing something.

for example, a game that "works" doesnt generate much logging traffic,but when xcom (a broken game), a lot of logging is generated

aka, saving the outputs to a txt file, running master of magic for about 30 seconds and doing about 10 clicks generates a txt file of about 8k, yet, for about the same 30 seconds, and same amount of clicks, the xcom log file is 58k

I have attached both, it looks like in xcom, a ton of the data is being repeated, repeated.

So it almost looks like something is 'stuck' in xcom? (or at least xcom is thinking something is stuck)

Don't think it's stuck, more looks like the first part is accounted to the initialization and the rest
(ie. int33/ax=3 calls) is what's happening during the game, constant readout of the mouse pos
and button states.

Remove the current logging and add it to the subfunction (case 3) where you can also monitor
the button states and similar (so you can check if your button-presses should be visible to
the game at some point or don't go through for some reason, like they are "too fast").

I have attached two files again, this time with debugging only printing out in the 0x03 case (also printed out mouse.buttons, which is always 0?)

both programs were sent 5 touches (so left clicks) and one "hold" (which should generate a right click).

Do the values for reg_bx make any sense?

also printed out mouse.buttons, which is always 0?

Those games most likely wait for a button press during their readout, which doesn't happen
since you immediately release them (at least that's how it looks like to the game since there is
no delay at that level).