Donny Viszneki <smirk thebuicksix.com> writes:
But notice that I don’t only want to change the cursor, but the
movement, so
that x axis becomes the y and the other way around.
What operating system are you using? Are you as of yet doing anything
special when capturing mouse movements?
To my understanding, your graphical working environment (ie XFree86,
Apple Quartz) is responsible for mouse movement. Please describe your
working environment a bit more.
Hi,
Right now my app runs only under windows since I wrote code to select
the
monitor in a multi-display sytem.
Are you running in full screen or windowed mode? Running in a
pseudo-full screen environment may be a plausible solution (in other
words, creating a window that occupies the whole screen, but is in fact
not full-screen mode.)
This is still in my opinion a bug in Windows (though you may still want
to work around it, perhaps you should report it to Microsoft? I don’t
know how good they are about fixing bugs, and I doubt any commercial
game has been developed for pivoting displays.)
The software will run in 3D stereo, and the
monitor is in portrait format (it has to be).
Stereoscopy is so cool, as a matter of fact I have been spending a lot
of time trying to figure out a game design that makes stereoscopy more
than just eye candy, and actually an important strategic element to the
game. But I digress…
Out of curiosity, why does it have to be in portrait format?
Unfortunatelly I cannot rely on the graphic card or any other pivot
software
because it’s my experience that everything becomes too slow.
Could you provide some links to “pivot software?” Again, this is the OS
vendor’s responsibility, but it’s your choice if you wish to try and
find a work-around until they’ve addressed the problem.
So, now i have my OpenGL/SDL scene rotated 90 degrees, everything is
fine, but
the mouse movements are still running as the display would be in
landscape, so
if I move the mouse left, for my app it’s moving down. That’s why i
need to
convert the x->y and then shown my custom cursor.
I can’t stress enough that this is the responsibility of the Operating
System Vendor, in this case, Microsoft.
The best workaround you can probably use (and for all intents and
purposes, it’s a pretty good one,) would simply be to translate the
position coordinates for the mouse at the beginning of your mouse
message handling.
This is probably better than the solution I mentioned above, running in
pseudo-full-screen. The theory I’m working with here is that when
Windows is in control of video (not a full screen application) the
mouse cursor MUST be working fine in portrait mode (meaning, that
Windows DOES translate the cursor in this case.) Not even Microsoft
could have missed a bug like that. However it is quite likely that they
never tested a video game in portrait mode.
The resson I’m using SDL is basically because I want to port it later
to Linux
and also because of the current audio and image loading support.
The application also supports video, only under windows using
directshow. I
need to implement that also under Linux… later.
Kudos to you.
So, should I modify SDL, I was lokking inside the code and I found a
method
called something private mouse (can’t remember now) and warpMouse
something. I
usually don’t like to modify the library but it seems to me the best
solution.
Your best solution is probably just to have a binary value that tells
the game whether or not it needs to translate mouse position
coordinates! Like I said earlier, begin your loop by translating the
coordinates. This simply means swapping the X and Y values, plus
performing some polarity inversion depending on which way the screen
rotates (I guess.)
In your case, you said moving the cursor left (negative movement along
the X axis) moves down on your screen (positive movement along the Y
axis.) Which suggests that your screen rotates 90 degrees counter
clockwise for portrait mode. So to perform the translation, do
something like this:
if (PortraitModeEnabled && event->type == SDL_MOUSEMOTION)
{
int x = event->motion.x;
int y = event->motion.y;
// Which direction are we rotating?
if (CounterClockWisePortraitMode) x = - x;
else y = - y;
// Assign switched values!
event->motion.x = y;
event->motion.y = x;
}
}
Depending on your program, you may want to catch more event types than
mouse motion events. Perhaps you could catch mouse button events as
well this way.
I can’t really help you determine the value of
CounterClockWisePortraitMode or PortraitModeEnabled (although the
latter may be an easy one since you did say that it MUST be in
portrait mode, I’m still quite curious about that!) However it might be
best for it to be an option the first time you run the game. A message
could appear and a mouse cursor saying “move your mouse! is it working
alright?” And if the answer is no, perhaps they can hit the letter N on
the keyboard or something to invert the value of
CounterClockWisePortaitMode, thereby fixing the mouse rotation.
Hope this helps you get your project underway…
ps. please tell me more about your project, I’m very curious to hear
about this stereoscopic portrait-mode only application!On Jul 23, 2004, at 5:08 PM, wpr wrote:
On Jul 23, 2004, at 7:08 AM, wpr wrote:
TIA
wpr
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl