Closed GoogleCodeExporter closed 9 years ago
Yeah. Tried playing Cannon Fodder. Gets really frustrating sometimes.
Original comment by svi...@gmail.com
on 14 Sep 2009 at 6:19
[deleted comment]
Try using the classic controller instead of the wiimote.
Original comment by kev1210r...@msn.com
on 14 Sep 2009 at 7:35
Do you mean using classic controller for mouse emulation?
Original comment by erikba...@gmail.com
on 14 Sep 2009 at 7:47
Yes I did mean that... but I just fired the emu up (tried battle chess and
north &
south) and unfortunetly that doesn't work - so forget that useless peice of
information. lol
I wonder if it would be possible to bind the mouse control to one of the classic
controller analogs instead of using the wiimote though (seeing as you wouldn't
need
the ir sensors - if that is what the control prob is)?
Original comment by kev1210r...@msn.com
on 14 Sep 2009 at 8:24
I do not think that mapping the mouse to the right analog would be a better
solution
as the beauty of emulating an Amiga on a Wii is to have the chance of playing
Cannon
Fodder, Dungeon Master, Capone, Walker, Op.Wolf and the like using the Wiimote
instead of a mouse.
Original comment by erikba...@gmail.com
on 14 Sep 2009 at 8:44
Well if it was possible to bind to an analog stick making the games fully
playable on
the wii then it would be a great solution to me. I know other peeople have
previously
reported the mouse movement issues but Simon has said something like theres
nothing
he can do about it as its not an emulator issue. I guess for now stick with wii
uae
for mouse games.
Original comment by kev1210r...@msn.com
on 14 Sep 2009 at 9:01
Not an emulator issue... hard to believe as any other mouse implementation I've
seen
on the Wii works flawlessly.
Original comment by erikba...@gmail.com
on 15 Sep 2009 at 6:34
Hard to believe, yes, but probably true. I believe this is a SDL issue. See this
SDL-wii bug report:
http://code.google.com/p/sdl-wii/issues/detail?id=15
so once the upstream bug is fixed, it should work out of the box for UAE-wii as
well.
Original comment by simon.ka...@gmail.com
on 15 Sep 2009 at 6:35
Ah, it's clear now. An SDL bug that heavily affects Amiga Emulation...
Maybe I've never noticed this before because I'm not running many SDL
applications on
Wii... Thank you for the update
Original comment by erikba...@gmail.com
on 15 Sep 2009 at 7:46
Hi,
in the SDL-Wii bug report mentioned above, there is a proposal to rebuild with
the
last release version of wiiuse.a :
http://code.google.com/p/sdl-wii/issues/detail?id=15#c14
Is it worth a try? And then perhaps to release a new binary uae-wii version
with the
fixed mouse emulation?
Original comment by Holger.C...@gmail.com
on 23 Sep 2009 at 7:52
dborth has replied to the above issue asking if the latest release (which came
out
today) of devkitPPC r18 and libogc 1.8.0 fixes the mouse issue on uae? Can
anyone who
can can compile confirm this?
Original comment by kev1210r...@msn.com
on 10 Oct 2009 at 9:04
Just tested with the above and the mouse problem is still unfortunetly there.
doh!
Original comment by kev1210r...@msn.com
on 12 Oct 2009 at 5:30
Sorry to hear that, but thanks for testing!
Original comment by simon.ka...@gmail.com
on 13 Oct 2009 at 11:48
I see dobox on the wii has mouse emulation... dya think using an actual mouse on
wiiuae would also be possible in the future?
Original comment by kev1210r...@msn.com
on 13 Oct 2009 at 4:09
I've been looking into this problem a bit this weekend, and I think I now
understand
what causes it.
The problem is that the Amiga wants relative mouse motion (what it gets from
it's own
mouse). That's fine and no problem with a regular mouse - it's motion is always
relative, so that if you lift the mouse up and move it on the mouse pad it will
stay
at the same place.
Unfortunately, this is not the case with the wiimote. It's always has an
absolute
position - where you point it at on the screen. I believe this is the root of
the
problem. SDL will happily hand you relative coordinates, and with a regular
mouse
that would be fine (you can just lift it up), but with the wiimote (where you
CAN do
the same) it will feel pretty strange although it technically just emulates a
mouse.
So what we'd need to is to get UAE to accept the absolute values.
src/inputdevice.c
and src/gfx-sdl/sdlgfx.c is where to try out stuff if you want to help out.
Original comment by simon.ka...@gmail.com
on 18 Oct 2009 at 9:18
OK, after some more googling around I found this:
http://talk.maemo.org/archive/index.php/t-5298.html
So this will be very difficult to implement. You'll have to live with the
current
mouse movement and play joystick-based games.
Probably you can configure the analogue pin on the nunchuk or classic
controller as a
mouse controller in the configuration file, maybe that's the best solution. I'd
be
happy to accept a configuration file change if someone makes it work.
Original comment by simon.ka...@gmail.com
on 18 Oct 2009 at 9:33
Well, isn't it possible to create an absolute_to_relative mouse position
wrapper into
WiiSDL?
I'm a bit into coding (not C and not Linux based systems) and I do NOT know how
UAE
and WiiSDL work, but AFAIK it should not be that impossible to implement.
I mean, the good thing a Wii has above other consoles is the Wiimote, now if we
do
not support it within an Amiga emulator it stops to have a meaning. I mean, we
loose
the opportunity to play Capone, Op.Wolf, Op.Thunderbolt, Walker, Barbarian,
Obliterator, Terrorpods, Xenomorph and the like in a way they could never be
played
before the Wii existed...
Original comment by erikba...@gmail.com
on 18 Oct 2009 at 2:59
SDL already does that as good as it can, but that's not really the problem.
What we
would need to know is where the mouse pointer is *on the amiga* - then this
could
fairly easily be worked around. But UAE only emulates the Amiga hardware mouse
(which
of course can only produce relative values), so it will require giving values
like
"two vertical ticks" and so on - not "mouse has moved to 15,120".
I don't know Amiga hardware, but if the OS stores the absolute mouse position
in a
fixed position in memory (which I doubt), this would be possible to implement.
Perhaps other UAE forks have implemented this (the maemo one in particular is
interesting), but I have low hopes of getting it working.
It would certainly be an interesting addition to some games, but for now the
only
Wii-specific feature you'll get is the wheel for car-games (and that's perhaps
not
really very impressive either).
Original comment by simon.ka...@gmail.com
on 18 Oct 2009 at 3:52
I've posted your request to Amigaworld.net, maybe someone there knows if Amiga
stores
them in a fixed RAM position or in fixed registers.
Here it is the link to the discussion:
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=29802&start=0&post_id
=514646&order=0&viewmode=thread&pid=0&forum=8#514646
Original comment by erikba...@gmail.com
on 19 Oct 2009 at 7:26
[deleted comment]
Are you sure that is not into SDL the problem ?
DOSBox Wii had the same problem with mouse emulation and it is written using
SDL too.
See here
http://code.google.com/p/dosbox-wii/updates/list
(issue17 and issue18 for example)
Now this issues are 'fixed' but maybe you can talk with dborth, the owner of
DosBox
wii project to have some hint.
Matteo
Original comment by matteo.p...@gmail.com
on 19 Oct 2009 at 2:38
Yes, I'm pretty sure this is the issue.
There are probably ways of improving how it behaves, but most likely not
possible to
get it behaving wii-like (point to where you want the pointer to be). One thing
that
can be tried is to play around with the mouse sensitivity (to increase it), so
that
you can at least use a larger area of the screen to move the mouse on.
There are some config options related to the mouse, see inputdevice.c. I've
tried a
bit with a few of them, but not got any real improvement.
Original comment by simon.ka...@gmail.com
on 19 Oct 2009 at 4:04
This is a common issue, it's the longest-standing issue with Snes9x GX, for
example.
Original comment by dborth@gmail.com
on 23 Oct 2009 at 4:06
As I understand the topic correctly, the problem is, that during passing the
information from an absolute Wiimote position to a relative change in Amiga
mouse
emulation, that this delta information might have some "data loss", which leads
to
that the mouse is not moved so far in Amiga as actually the Wiimote has been
moved,
making the window where to move the mouse virtually smaller.
So, if it is so difficult to pass the correct delta information to the Amiga
mouse
emulation, what about simulating a relative movement of the Wiimote:
With the libraries available for Wii, is it possible to set the Wiimote pointer
to a
specific position? If yes, each time, when the Amiga emulator reads the absolute
position, the emulator only reads the difference between this absolute position
and
the middle of the screen. Then, it resets the absolute Wiimote pointer to the
middle
of the screen. In the next interval, when reading the absolute Wiimote
position, the
emulator does the same as above (difference between absolute position and
middle of
the screen, then resetting the position again to the middle of the screen).
-> you get a "relative" movement of the Wiimote, what may be directly passed to
the
Amiga mouse emulation. With that, the problem could be fully solved (if
positioning
the Wiimote pointer by software is possible)
Any comment?
Original comment by Holger.C...@gmail.com
on 25 Oct 2009 at 1:09
Seems a smart solution... maybe it'll have a small cursor flickering as a side
effect, but if viable would be a good one indeed.
Original comment by erikba...@gmail.com
on 25 Oct 2009 at 4:05
No, it won't help. Getting relative movement from SDL is no problem, the UAE
code
already works that way. The problem is simply that the Amiga mouse (emulated by
UAE)
generates vertical or horizontal ticks - moving the pointer horizontally or
vertically. What you would need is to be able to set the *absolute* position of
the
Amiga mouse.
I don't believe that is possible other than through the method hinted at for
snes9x:
http://code.google.com/p/snes9x-gx/issues/detail?id=13
but as you can see, this is application specific.
Original comment by simon.ka...@gmail.com
on 25 Oct 2009 at 7:40
Hi Simon, it's actually about making the Wiimote motion relatively by keeping it
always at the center of the screen and only reading the delta values (which is
already done by SDL, and also by uae-wii, as you say). So the solution is
already
half in place there.
Yesterday, I downloaded, compiled SDL-Wii and uae-wii-4 and had a look into the
code.
Actually, the idea I do have, is already fully implemented for Windows (and
also for
Linux according to some comment).
Original comment by Holger.C...@gmail.com
on 26 Oct 2009 at 12:23
I understand your idea, but I don't think it will improve the situation (thanks
for
looking into it!). It won't fix the general Wii mouse emulation issue: When you
point
the wiimote at the lower right corner, you'd expect the mouse to be placed
there -
not in the top left corner, the middle or somewhere else depending on where the
Amiga
mouse pointer was before.
With a normal mouse, this is not strange - you will just pick it up and move it
to
the other end of the pad when you need to. With the wiimote, you can't do that
even
if you place the wiimote pointer at the center of the screen.
Original comment by simon.ka...@gmail.com
on 26 Oct 2009 at 12:29
Good point, but even with that disadvantage the mouse would be at least usable
(which
it is not currently..), right? And instead of picking the mouse up and move
somewhere
else on the pad, you could anytime move the Wiimote further outside the screen
in
order to get back to a normal area of movement (e.g. moving it far to the right
if
having hold the Wiimote somehow far too left).
Additionally, perhaps by introducing some Wiimote/mouse sensivity in the
options menu
could workaround this additional issue? (if assuming, that the "data loss" of
delta
values is similar in all four directions).
Original comment by Holger.C...@gmail.com
on 26 Oct 2009 at 1:56
Yesterday, I tried out what I mentioned above, it is much better than before,
can
move the mouse everywhere I like to, but it is not sufficient, as you
mentioned. Very
often, I move the Wiimote "out" of the window, and the mouse then only continues
moving if I move the Wiimote back into the invisible window area..
Especially when playing games (tried it out with Pirates!), this is annoying as
the
area where you are allowed to point at with the wiimote seems to be very small.
Original comment by Holger.C...@gmail.com
on 27 Oct 2009 at 4:43
Sounds good. If you have a clean patch for it, I can apply it.
Original comment by simon.ka...@gmail.com
on 28 Oct 2009 at 6:13
Here is another generic hack that could work for many games;
Each frame, check the sprite coordinates of each emulated Amiga sprite on the
screen.
Compare the delta changes of the sprite position with the delta change of the
WiiMote. This should indicate which sprite is actually used as mouse pointer.
Now you can compensate the delta of the Mouse Tick registers until that sprite
ends
up where the Wiimote is pointing...
This will only work for games that uses a hardware sprite as a mouse pointer,
but I
believe that is pretty common (the system pointer is a sprite so it should at
least
work for all games that uses Amiga OS).
Original comment by jonas.mi...@gmail.com
on 8 Dec 2009 at 12:58
Mouse control with the nunchuck control would be nice, it also has two buttons
you
can use.
Original comment by e5f...@gmail.com
on 6 Mar 2010 at 8:20
hmmm, sorry to say v5 is still jerky. It tends to feel that you loose
connectivity
with he remote for minor second every now and then. Happening with most games.
Original comment by vio...@gmail.com
on 27 Mar 2010 at 3:20
@viopej: See above for the reason why this can't be fixed.
Original comment by simon.ka...@gmail.com
on 27 Mar 2010 at 5:17
how does apps in windows accepting touchscreens deal with this?
Original comment by svi...@gmail.com
on 28 Mar 2010 at 7:29
@svin83: What do you mean? In your *own* applications (or the OS itself for
that
matter), you can always set the pointer to absolute coordinates somewhere. For
the
Amiga, you emulate a hardware device (the mouse) that generates ticks when it's
moved
- pure relative in other words.
The only thing we can really do about it is tricks like the one jonas.minnberg
suggested above, or game-specific changes.
Original comment by simon.ka...@gmail.com
on 29 Mar 2010 at 5:11
aaahh. sorry. I was remembering it all wrong:P
But what about WinUAE? they haven't had any trouble with mouse emulation for
years as
I recall...
Original comment by svi...@gmail.com
on 30 Mar 2010 at 6:56
@svin83: That's because they use an actual mouse :-)
If SDL-wii supports an USB mouse (does it?), it should work fine on the Wii as
well.
The Wiimote works as well, it's just that it doesn't work like the user
intuitively
thinks it should. I.e., by pointing to an absolute position on the screen,
you'd
expect the pointer to move there. What actually happens is that you drag the
wiimote
across the screen, and the mouse pointer moves relatively to that.
I'm marking this as WontFix now.
Original comment by simon.ka...@gmail.com
on 30 Mar 2010 at 7:16
It's a real pity... Wiimote controlled mouse is one of the main reasons to
emulate an
Amiga through Wii instead of using WinUAE.
Original comment by erikba...@gmail.com
on 30 Mar 2010 at 7:28
To fix the mouse getting stuck part way across the screen when the wiimote is
still within the screen boundary:
Edit the uaerc.saved file on the SD card, and ensure:
gfx_fullscreen_amiga=true
I mentioned more details here:
http://code.google.com/p/uae-wii/issues/detail?id=10#c5
Original comment by g.a.stew...@gmail.com
on 18 Oct 2010 at 10:16
Original issue reported on code.google.com by
erikba...@gmail.com
on 28 Jul 2009 at 9:07