Mouse emulation problem about sdl-wii HOT 22 CLOSED

I don't have this issue. The mouse moves perfectly with the wiimote.

Tantric, I can verify this issue.  The left and top of the screen cause the 
mouse to
lag and stop. 

If you need code for a repro then it happens on WiiRadio.
http://code.google.com/p/wiiradio/  I'm unsure what's causing it.  

I'm wondering if this has anything to do with windowed vs full-screen mode. Not 
that
the Wii will ever be windowed, but I guess you could check if SDL_SetVideoMode 
is
called with SDL_FULLSCREEN.

I'm calling with SDL_FULLSCREEN.  The only thing I can think is it could be an 
issue
in 24bit mode. Or maybe a flag.

Here's my init 

BITDEPTH = 24, fullscreen = 1, SCREEN_WIDTH = 640, SCREEN_HEIGHT = 480

SDL_SetVideoMode( SCREEN_WIDTH, SCREEN_HEIGHT, BITDEPTH,
             (fullscreen ? SDL_FULLSCREEN : 0) | SDL_HWSURFACE | SDL_DOUBLEBUF );

It can stops moving in left or right side, but its like if I move away and come 
back,
the wiimote can reconnect some times. 
If can be useful I have a wii in 480p mode.

[deleted comment]

If you stuck to the left/right/top/bottom and you cover the ir sensor and you 
point 
to the middle of the screen, than (after uncovering the sensor again ;-) you 
can 
move to you wanted direction again and the mousepointer moves till the end of 
the 
screen!

IT's almost like the pointer "thinks" it is alredy on the edge ... 

OK ... here's what's happening.

The cursor x,y is clipping to the the surface size and it's causing this 
behavior. 
So if SDL thinks the cursor is at 0,0 it really could be at -100,0 this causes 
the
cursor to stick until you shake the controller and the wii ir value comes back 
in range.

It's really doing what it should but the problem is this behavior does not 
suite the
wiimote.

Here's the clipping code in SDL_mouse.c

    /* Mouse coordinates range from 0 - width-1 and 0 - height-1 */
    if ( x < 0 )
        X = 0;
    else
    if ( x >= SDL_VideoSurface->w )
        X = SDL_VideoSurface->w-1;
    else
        X = (Uint16)x;

    if ( y < 0 )
        Y = 0;
    else
    if ( y >= SDL_VideoSurface->h )
        Y = SDL_VideoSurface->h-1;
    else
        Y = (Uint16)y;

... the cursor stops too early ... :-(

Yes, I'm looking into it.  I need this feature too :)

Hum, Well I updated libogc to the latest SVN but it seems to have broken the 
Wiimote.
All I'm getting is a cursor that will go up or down on the left of the screen.  
Is
anyone else seeing this? 

definitely a problem with the SVN version of wiiuse.a and not SDL. 

Hi, what's the progress about this issue? As I have read on the uae-wii page, 
this
issue may be the reason why mouse emulation in Amiga emulator is not working 
properly.
I'd like to play good old games like Rock'n'Roll etc. on the Wii :)

I believe it's a compatibility issue with wiiuse.a in the libogc SVN.  This 
problem
goes away if you use the last release version of wiiuse.a, I think it's libogc 
1.7.1a.

Here's what I did.  Get the SVN libogc build it then copy everything but 
wiiuse.a to
your lib dir.  Or if you have already copied over wiiuse.a download libogc 
1.7.1a and
replace your wiiuse.a with the released one.

Also any app will need to be re-built with this config.

scanff, does this still happen on r18 / 1.8.0 / latest SDL?

remember to use the portlibs available here:
http://sourceforge.net/projects/devkitpro/files/portlibs

I just tested uae (r118) r18 with 1.80 and newest sdl and the mouse problem is 
still
there.

I'm not near a Wii right now ... Kev1210rose can you try replacing lib 
wiiuse.a, from
libogc 1.7.1a. to see if that fixes the problem.  I'll try it myself when I get 
a chance.

hmm I don't see how it could be wiiuse. I tested, and wiiuse reports values 
back 
between (0,0) and (480,640), like I ask it to. It's almost like SDL isn't 
moving the 
mouse as far as it should, and if it reaches a boundary (eg: 480, 0), but isn't 
at 
the proper place yet (bottom of the screen) then it won't move any further of 
course, since the max wiiuse value reported is 480, and 480-480 = 0 = no 
movement.

What I've done work around the issue - switched to relative movement, and 
doubled 
the movement values (by doubling the vres). the result is pretty good, I think.

Very strange uae is still broken with the mouse issues still then? :(

So it's caused by some other problem then. That's nice, we now know at least 
that! I
still think it's a Wii/SDL issue though, since it works well when compiling for 
the host.

For more information on the UAE mouse problems, see here:

  http://code.google.com/p/uae-wii/issues/detail?id=23#c17

it's not related to this bug report.