|
|
|
| Touch Screen Solution MAYBE |
|
spellcaster
Member #1,493
September 2001
 |
I changed exmouse to 640x480, 800x600, 1024x768 and 1280x1024. In all resolutions the mouse behaved exactly the same as under native windows. So, at least on my box that change is a big improvement over the old one -- |
|
Richard Phipps
Member #1,632
November 2001
 |
I think the scaling is there to speed up the mouse movement so it takes the same amount of time to move from one side of the screen to the other in any screen resolution. Taking out that scaling should make the mouse speed dependent on the windows desktop screen mode size. |
|
spellcaster
Member #1,493
September 2001
|
Um, well.... maybe. -- |
|
Richard Phipps
Member #1,632
November 2001
|
How is the mouse speed in 640 x 480 or lower then? It is slower? |
|
Marco Radaelli
Member #3,028
December 2002
 |
Phipps: after changing the sources your breakout beta does no more work Exactly I can't move the bat, while I can use the buttons to launch the ball. I restored the standard sources and after recompiling the mouse worked well. Are you doing something weird with mouse variables / functions
|
|
Richard Phipps
Member #1,632
November 2001
|
I'm just using the mouse_mickeys function with a scale factor. |
|
Marco Radaelli
Member #3,028
December 2002
|
Is that scale factor managed by your code or set with an Allegro function? You could always track mouse offsets manually.
|
|
Richard Phipps
Member #1,632
November 2001
|
The scale factor is managed by my code. Currently it's set to 0.5. Oh, I do also position the mouse after getting the mouse mickeys, and this is to stop you moving the mouse out of the window in windowed mode. What do you mean by tracking mouse offsets manually? |
|
Marco Radaelli
Member #3,028
December 2002
|
Now that you mention it, I tried windowed mode and there the mouse is really slow, maybe because I have modified the allegro sources. I'm gonna test that. I saw that mouse_mickeys() return the distance the mouse covered between two calls. Well you may old two variables for each axis, something like current_x and old_x and the calculate manually the distances. I'm suggesting this if mouse_mickeys() has problems with the modified code. [edit] Tried 1024x768 in windowed mode with the standard Allegro sources, the mouse moves really slow
|
|
Richard Phipps
Member #1,632
November 2001
|
Well I don't have any problems in windowed mode. I think your fix is a bit buggy at the moment. EDIT: As for the slow speed, that's what I expected to see. I think James Lohr's fix would be better in this case. |
|
Marco Radaelli
Member #3,028
December 2002
|
I should correct myself. It seems slow, compared to the fullscreen mode, so actually there's no problem. So the only problem is the froze mouse movement which occurs applying spellcaster patch to resolve wacom tablet fullscreen troubles. The mouse didn't freeze in windowed mode.
|
|
Richard Phipps
Member #1,632
November 2001
|
Can you try the exmouse example that prints out the mouse mickeys? See if that still works. |
|
Marco Radaelli
Member #3,028
December 2002
|
I does work. At least it prints some values for the mickeys.
|
|
spellcaster
Member #1,493
September 2001
|
Um.. since the fix doesn't change the windowed mode, but only the fullscreen mode, my guess would be that something else went wrong. Also, the fix I made was in the WIP branch, which already has new mouse functions... I don't have the old version of allegro installed, the 4.1.6 version seems to behave way better on my system anyway The OP should use 4.1.x version with the changes I've propesed. Should work nicely. Maybe it's better to leave the 4.0.x mouse functions the way they are. -- |
|
Marco Radaelli
Member #3,028
December 2002
|
I may test it, but that would be a bit of trouble, because I do not know how to keep two versions of Allegro together. You'll have to wait a bit more [edit] Does OP stand for Opener?
|
|
spellcaster
Member #1,493
September 2001
|
OP: Original Poster. -- |
|
Marco Radaelli
Member #3,028
December 2002
|
I'd like to test that on the latest WIP but I have a problem: breakout is linked (I suppose) with the stable library. I'll need a version linked against the latest WIP to see if changes will work without problems.
|
|
Richard Phipps
Member #1,632
November 2001
|
Sorry Marco, I'm not going to recompile for this. I have to much to do. I suggest you make a simple program using the mouse mickeys and then use that.. |
|
spellcaster
Member #1,493
September 2001
|
Or just use exmouse, which does exactly that. richr: Why are you using the 4.0.x branch? The 4.1.x should be even more stable, since some bugs got fixed and some code got an overhaul... -- |
|
Richard Phipps
Member #1,632
November 2001
|
Spell: You may be right, I guess the advice to use the stable branch for releases is pretty well ingrained. The 4.2.0 series should be out soon (hopefully) anyway. |
|
Specter Phoenix
Member #1,425
July 2001
 |
Spellcaster: I agree with using the newest WIP but I must let everyone know that A.CC doesn't have the file downloads updated yet. You can only get 4.0.x from A.CC (4.0.3 to be exact) right now so they must go to the sourceforge site for allegro 4.1.x -> http://alleg.sourceforge.net/. [EDIT:]
|
|
Marco Radaelli
Member #3,028
December 2002
|
I surely don't want to load you with extra-work After modifying the wmouse.c source I do "make" and "make install" which probably recompiles also the examples. In this way, as Harbringer ZERO pointed out, my exmouse test works, but Phipps' breakout does not. This way if Phipps applies the patch to his 4.0.3 copy of Allegro and then recompiles the program, it should work without any problem.
|
|
spellcaster
Member #1,493
September 2001
|
Nope. -- |
|
Marco Radaelli
Member #3,028
December 2002
|
I just suggested to test it.
|
|
spellcaster
Member #1,493
September 2001
|
I tested that already. Doesn't work. -- |
|
|
|
