Dosbox 0.72-1 For Gp2x


Pickle said:
Eclipse said:
oh also, when clicking with the stick the emu slow down a lot :(


Thats strange, the only thing i can think is that the SDL is running a lot more code once you use the touchscreen.
Yes I got this too, if you click and hold, the emu slows down a lot, I tried in a test program and it didn't happened, must be some problem with dosbox receiving a lot (100+/s) events when cursor is held. I am aware of this problem, and looking for a solution.

Senor Quack said:
Also: please, when adding the right-click modifier, also add an option to never register clicks at all with the touchscreen taps, let them only move the cursor itself and have any and all clicking solely done with GP2X buttons. (Sometimes, like with the ScummVM GP2X port, it gets annoying wanting to float your cursor over something but not click on it)
Wow that is a GREAT idea! I found it annoying that the mouse autoclicks when using touchscreen devices.
 
Last edited by a moderator:
Hitnrun said:
Pickle said:
Eclipse said:
oh also, when clicking with the stick the emu slow down a lot :(


Thats strange, the only thing i can think is that the SDL is running a lot more code once you use the touchscreen.
Yes I got this too, if you click and hold, the emu slows down a lot, I tried in a test program and it didn't happened, must be some problem with dosbox receiving a lot (100+/s) events when cursor is held. I am aware of this problem, and looking for a solution.


Im pretty sure this problem is in the SDL code

Hitnrun said:
Senor Quack said:
Also: please, when adding the right-click modifier, also add an option to never register clicks at all with the touchscreen taps, let them only move the cursor itself and have any and all clicking solely done with GP2X buttons. (Sometimes, like with the ScummVM GP2X port, it gets annoying wanting to float your cursor over something but not click on it)
Wow that is a GREAT idea! I found it annoying that the mouse autoclicks when using touchscreen devices.

[whisper] (does it work yet?) [/whisper]
 
Last edited by a moderator:
Pickle said:
Hitnrun said:
Senor Quack said:
Also: please, when adding the right-click modifier, also add an option to never register clicks at all with the touchscreen taps, let them only move the cursor itself and have any and all clicking solely done with GP2X buttons. (Sometimes, like with the ScummVM GP2X port, it gets annoying wanting to float your cursor over something but not click on it)
Wow that is a GREAT idea! I found it annoying that the mouse autoclicks when using touchscreen devices.

[whisper] (does it work yet?) [/whisper]


Yet. B)
 
Last edited by a moderator:
Pickle said:
Senor Quack said:
Do a search on google site:gp32x.de EVENTTHREAD and you'll find a mention of a halfway fix for this in this thread several posts down:
http://www.gp32x.de/board/index.php?showt...3819&st=480



I assume your refering to this: add SDL_INIT_EVENTTHREAD to SDL_Init()
Has this worked for you? The person with the problem in the thread says later it didnt work for him.


Yes, it worked for me in TTD2X when I encountered the same problem and I think it's worth a shot. Don't kill me if it doesn't work though, that was a few months ago and my first time working with mouse events in SDL at all ;)
 
Last edited by a moderator:
Hitnrun said:
Wow that is a GREAT idea! I found it annoying that the mouse autoclicks when using touchscreen devices.
also making the touchscreen only moves the mouse and NEVER clicking would fix that slowdown problem, because you can do the clicks using the buttons and please, make the mouse clicks only once per button press, or it will slow down too if you keep pressed the button more than a millisecond :)
Don't make the click on the button release, this will be laggy with games that aren't adventures, you can use something (like a bool) that turns to true when the button is released so you can inject the mouse click only when this bool is true and the button is pressed, then make the bool false and... it will work for sure ;)

about the OSD, simply put the ttf in the release, why not?
 
Last edited by a moderator:
Eclipse said:
also making the touchscreen only moves the mouse and NEVER clicking would fix that slowdown problem,
how do you know that? Its an easy thing to do, but you seem confident it would work, so im curious...

Eclipse said:
because you can do the clicks using the buttons and please, make the mouse clicks only once per button press, or it will slow down too if you keep pressed the button more than a millisecond :)
I have added map items for the mapper file to map any GP2X button to a left click/right click. I also have an item to turn off and on clicks from the touchscreen.
I have added code to do mouse motion emulation with the direction buttons.
The left/right clicks are working well, the other 2 need some work yet.
 
Last edited by a moderator:
Eclipse said:
Hitnrun said:
Wow that is a GREAT idea! I found it annoying that the mouse autoclicks when using touchscreen devices.
also making the touchscreen only moves the mouse and NEVER clicking would fix that slowdown problem, because you can do the clicks using the buttons and please, make the mouse clicks only once per button press,
I don't think so, the problem seems that when the mouse is held, the gp2x is flooded with mouse movement events, not mouse click, so this may not fix it. What should fix this is some kind of mouse filtering, as event helding the pen on the same spot, we receive a lot of events in different positions, the touchscreen device is not very precise.
 
Last edited by a moderator:
Hitnrun said:
Eclipse said:
Hitnrun said:
Wow that is a GREAT idea! I found it annoying that the mouse autoclicks when using touchscreen devices.
also making the touchscreen only moves the mouse and NEVER clicking would fix that slowdown problem, because you can do the clicks using the buttons and please, make the mouse clicks only once per button press,
I don't think so, the problem seems that when the mouse is held, the gp2x is flooded with mouse movement events, not mouse click, so this may not fix it. What should fix this is some kind of mouse filtering, as event helding the pen on the same spot, we receive a lot of events in different positions, the touchscreen device is not very precise.

I agree with that. I believe the problem is in the SDL code itself. DJwillis is getting a F200 soon, lets give him some time to work on it.
 
Last edited by a moderator:
Due to popular demand and cause it really isnt that hard.

Ive added mappable items to emulate left and right mouse clicks
Ive added stick/dpad mouse cursor emulation control
Ive added mappable item to turn a touchscreen no click.

Which is better holding a button or a button toggle for the no click? Right now I have it a hold.
 
Excellent. :)

I think the "hold" method is ok if the process is:

-- Hold button -> move cursor -> release button to "autoclick" on selected item

But not if it's:

-- Hold button -> move cursor -> release button -> manually click on selected item

I can see the former being a smooth action once you get used to it, but the latter being a little convoluted.

If toggle were used, you might need an indicator on screen so you'd know if touching the screen was going to result in a click.

To be honest though, if I've got the option to disable touchscreen-clicking all together I'll use that.
 
Gruso said:
Excellent. :)
-- Hold button -> move cursor -> release button -> manually click on selected item
.
right now it this method. But you could either click with the touchscreen or you could map a button to left click and trigger it that way.

With your autotrigger idea, i thought the noclick option was so that the cursor could be moved without any clicks. Wouldnt triggering a click at the end be doing that?
 
Last edited by a moderator:
Im also thinking about the virtual keyboard idea im having.

Is it enough to be able to send alphabet/numeric values and is they are in a list?.

What im thinking is to use something like our OSD feature and have it browse from left to right through the number keys and alphabet keys
Look something like this where 8 is the selected key:
<-1234567890ABCD->

Is not a pretty thing, but it could open up some mappings.
I could do things like up/down move 10 chars, left/right moves 1 char, the start key selects the key and sends it. select(or some other mappable button) turns the feature on and off.
 
Pickle said:
Im also thinking about the virtual keyboard idea im having.
Have you looked into UAE4All's method? Maybe there is some source code there you can lift, and then see how that will work in DOSBox?
 
Last edited by a moderator:
BadAstronaut said:
Pickle said:
Im also thinking about the virtual keyboard idea im having.
Have you looked into UAE4All's method? Maybe there is some source code there you can lift, and then see how that will work in DOSBox?

I think so they might be possible, its has all of the keys layed out in a qwerty format right? That could be possible.
 
Last edited by a moderator:
Pickle said:
BadAstronaut said:
Pickle said:
Im also thinking about the virtual keyboard idea im having.
Have you looked into UAE4All's method? Maybe there is some source code there you can lift, and then see how that will work in DOSBox?

I think so they might be possible, its has all of the keys layed out in a qwerty format right? That could be possible.

Maybe for this feature we could use the pause feature of dosbox, to avoid the terrible flickering of the OSD.
 
Last edited by a moderator:
Hitnrun said:
Pickle said:
BadAstronaut said:
Pickle said:
Im also thinking about the virtual keyboard idea im having.
Have you looked into UAE4All's method? Maybe there is some source code there you can lift, and then see how that will work in DOSBox?

I think so they might be possible, its has all of the keys layed out in a qwerty format right? That could be possible.

Maybe for this feature we could use the pause feature of dosbox, to avoid the terrible flickering of the OSD.

I dont know how we can avoid the flickering aside from stopping dosbox cold while in the virtual keyboard, that or fixing the problem.
Anything we blit onto the screen is going to flicker.
 
Last edited by a moderator:
I have a working virtual keyboard. Its not pretty but it works.
There is although a side effect, we may have to readjust the button's to start at a lower/higher number rather than at 97.
 
Things are looking good, I was able to improve the flicker problem with the OSD's.
Hitnrun has a fix for the touchscreen at 320x200 so no more scaling.

So we have mouse emulation, virtual keyboard, fixed touchscreen. There are a couple more things to add but I think we come up with another release in the weeks to come.

I would like to add backspace/shift to the keyboard, auto scaling for the OSD's (640x480 res).

The virtual keyboard is laid out in a table format:

123445678090
QWERTYUIOP
ASDFGHJKL
ZXCVBNM

All of the area around char's are transparent, expect the char selected is has a back color to highlight it.
Right now I a QWERTY setup, but I may change to ABCDEFG format
 
Pickle, you're making me wish I had a F200 for touchscreen support!

As for virtual keyboard, are you including all the keys or just the ones listed? I think it would be pretty important to include keys like space, esc, etc. in the virtual keyboard layout.
 
Back
Top