Git Product home page Git Product logo

Comments (23)

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
We are aware of this issue.

Original comment by [email protected] on 13 Sep 2008 at 6:44

  • Changed state: Accepted

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
Alright. Thanks for taking notice of the report though. :)

Original comment by mossj32 on 14 Sep 2008 at 7:18

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
If you need any ideas on how to get the game's mouse to work with the IR 
Properly, go
talk to The Creator of SNEmulDS for the DS. He has some code called "Memory
Following", which directly manipulates the Cursor X/Y Values in the ROM based on
where you touch the screen on the DS. Same idea could be put into play for the 
Wii
IR. Needs an external file containing info for each ROM though, containing the 
Memory
Addresses where the Mouse X/Y Values are Read from.

Original comment by mossj32 on 29 Sep 2008 at 4:00

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
That's very interesting, I'll take a look but I'm hoping we don't need anything 
that 
complicated.

Original comment by [email protected] on 29 Sep 2008 at 5:46

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
as a quick (I would imagine) fix, you could just make a buttn freeze the game, 
so you
can line up your cursor to the game's one, then unfreeze the game. would that 
work?

Original comment by [email protected] on 21 Oct 2008 at 2:52

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
What, as in Calibrate it to the game somehow?

Original comment by mossj32 on 24 Oct 2008 at 6:33

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
This is not a calibration issue, it is related to the difference in the lecture 
provided by a mouse versus the wiimote. Mouse coordinates are absolute values, 
meanwhile the wiimote provides relative values to its position.

Currently, even if you calibrated the wiimote to point where the mouse cursor 
is 
displayed, they would still move at different speeds.

In the future the only way to improve it would be a way to accurately convert 
the 
relative values to absolute values for the screen position... however this is 
beyond 
my knowledge :)

Original comment by [email protected] on 7 Nov 2008 at 2:32

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
actually, this is the contrary:

- wiimote return absolute position (X Y coordinates), based on calculation made 
by
wiiuse library from the LED detection

- SNES mouse returns relativ position (amount of movement in H and V direction )

Snes9x takes X/Y coordinates from input device (PC mouse or Wiimote) and do 
some kind
of calculation to determine quantity of movement when the EMULATED mouse need to
return some values

Apparently, the current code is not very accurate and indeed this is quite 
difficult
to do: for example, you could think that storing old position then returning the
normalized difference between old and current position would be enough, but 
it's not

I'm sure there is some kind of algorithm somewhere  to do that efficiently 

Original comment by [email protected] on 7 Nov 2008 at 4:13

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
eke-eke is correct. but the in-game mouse actually follows the in-game cursor 
pretty 
well and is acceptably accurate. 

The in-game mouse cursor is what's generated by the SNES, and the in-game 
cursor by 
snes9x - it's not visible on the snes itself - we're only using it for 
debugging. 
It'll be turned off when the mouse is fixed. It's not important that these two 
line 
up *exactly* (just approximately) - the user won't notice.

2 big problems occur:

1) there's no code for dealing with going offscreen or onscreen (when the 
wiimote is 
pointed away). What happens here is if you go back onscreen at a different 
point 
from where you left, the in game mouse doesn't "jump" to where you now are. 
This 
also occurs right at the start of the game (unless you're pointing your wiimote 
EXACTLY in the middle ;) ). Your two cursors are now far apart from each other. 
PC 
snes9x deals with this by moving your PC mouse to match up with the SNES mouse. 
We 
can't do that, we'll have to do the opposite - signal the SNES mouse to move to 
where your Wii remote is pointing (using deltas).

2) there's an inaccessible area where the snes mouse can't seem to go. No 
matter 
what you do, you can't make the snes cursor move into this area. This is at the 
top 
part of the screen and left part too, if I remember correctly. You can make the 
snes9x cursor go there, but not the snes one.

I don't know how to solve either (1) or (2) right now though. I think (2) 
should be 
solved first, if possible.

Original comment by [email protected] on 7 Nov 2008 at 4:54

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
To calibrate it, move the mouse to the corners of the screen. This is easiest 
with a
GC controller. A classic controller would probably work too. Also, there's a 
mario
paint joystick hack on the internet.

Original comment by [email protected] on 5 Feb 2009 at 9:40

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
Yeah, that hack idea is probably a good deal easier than tweaking the ir 
settings 
because the mouse wasn't designed to behave like an ir.  Might be less 
complicated to 
rom hack every mouse-based title to respond to an actual ir input like as in 
the 
superscope titles.  Wouldn't take much since there were only a handful of mouse 
titles.

Original comment by [email protected] on 16 Apr 2009 at 6:07

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
[deleted comment]

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
Agreed with trevorquinby. After messing with memory values I've found these:

-----------
MARIO PAINT
-----------

Co-Ordinates:

CONTROL     ADDRESS     MIN MAX DATASIZE    TYPE
------------------------------------------------------------------------
Mouse X     7E04DC      -16 271 2 BYTES     SIGNED
Mouse Y     7E04DE      8   215 2 BYTES     SIGNED

The "MIN" and "MAX" values are the boundaries for the cursor. There are 
different
boundaries in different parts of games and from what I've tested (the ones 
above are
for the main painting screen and the music creation screen). Not working within 
these
boundaries doesn't break the game too badly, however the fly swatting game can 
be
easily cheated though since you can go off-screen if you want. I couldn't find 
the
addresses for the boundaries.

-------------
CANNON FODDER
-------------

Co-Ordinates:

CONTROL     ADDRESS     MIN MAX DATASIZE    TYPE
------------------------------------------------------------------------
Mouse X     7EFA6B      4   252 2 BYTES     SIGNED
Mouse Y     7EFA6D      0   223 2 BYTES     SIGNED

Cannon Fodder is different in that it actually moves the mouse cursor while 
scrolling
around. I haven't been able to test it enough to see if this would actually 
matter.

--------
SIM CITY
--------

Co-Ordinates:

CONTROL     ADDRESS     MIN MAX DATASIZE    TYPE
------------------------------------------------------------------------
Mouse X     7E01EB      4   238 2 BYTES     SIGNED
Mouse Y     7E01ED      24  198 2 BYTES     SIGNED

Yup, Sim City's cursor is basically a mouse cursor and it would be trivial to 
make it
work with a wii-mote. The above values work with the main game screen, but not 
the
opening menus. I haven't tested to see if you can get a cursor on them too. All 
the
other menus work fine.

It would be interesting to find games that don't officially have mouse support 
that
could be hacked to work with the wiimote pointer.

Original comment by [email protected] on 8 Sep 2009 at 7:50

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
And another
---------
PAC MAN 2
---------

Co-Ordinates:

CONTROL     ADDRESS     MIN MAX DATASIZE    TYPE
------------------------------------------------------------------------
Mouse X     7E1062      4   239 2 BYTES     SIGNED
Mouse Y     7E1066      17  182 2 BYTES     SIGNED

Again, works just like a cursor so it shouldn't be a problem.

Original comment by [email protected] on 8 Sep 2009 at 8:03

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
What about Mario & Wario?
Does anybody know the Co-Ordinates?

Original comment by [email protected] on 3 Oct 2009 at 12:18

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
It's to much work to write a separate code for every mouse game (which are over 
70).
But maybe I got a solution concerning SNES mouse games.

The trick is a translation layer.
http://img263.imageshack.us/img263/9787/mouse1k.jpg

This layer translate the absolute coordinates from the Wiimote in relativ 
coordinates
for the SNES Mouse. The pointer of the wiimote is touching the grid cell, which 
will
return a relative position. Means, if the Mote-pointer is going left and will 
reach
the next cell, the mouse is moving one coordinate to left. So you can stroke 
over the
grid without calibrating or tracking anything. The simple calculation is done 
by the
grid.
http://img693.imageshack.us/img693/4447/mouse2t.jpg

The grid is not visible for the user.
The advantage of this translation layer/grid is:
-The size of the grid and the amount of cells can be changed (fine, medium, 
large)
So the sensitive of the wiimote can be adapted.
- No permanent tracking, calculating, calibrating of the wiimote is necessary.
- Recalculating of the relative path if the wiimote is going outside the tv 
area.
(where was the last point, where is it now)


Original comment by [email protected] on 13 Apr 2010 at 10:50

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
Wouldn't adding support to the emulator for USB Mice be a possible solution? I 
know it may seem asinine, but if the problem is with emulating the mouse on a 
non-mouse device, why not add mouse support to give the player an option to 
plug in an actual mouse? That way they can play it the EXACT way it was meant. 
^_^

Original comment by [email protected] on 30 Jun 2010 at 4:29

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
Yup! I agree with you! I own 2 SNES mice and both of them have problem with 
right and/or left button clicking... They don't worth a Logitech mouse (for 
example). It would be great to play SNES games on TV with a good mouse!

Original comment by [email protected] on 30 Jun 2010 at 7:27

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024

Original comment by [email protected] on 25 Apr 2011 at 9:54

  • Changed state: WontFix

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
Is there a reason this is WontFix? Mario and Wario is unplayable with the 
Wiimote, the cursor keeps freezing. It seems to be even worse during gameplay 
than in the character selection screen.

Original comment by [email protected] on 8 Aug 2013 at 2:09

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
There are better emulators for the Wii now, namely RetroArch, which has Snes9x 
Next

Original comment by [email protected] on 8 Aug 2013 at 2:58

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
RetroArch Wii has no SNES mouse emulation.

Original comment by [email protected] on 8 Aug 2013 at 4:36

from snes9xgx.

GoogleCodeExporter avatar GoogleCodeExporter commented on August 19, 2024
Ah, good point. Forgot about that lol. Not sure if Tantric/Dborth will pick 
this emulator up. 

Original comment by [email protected] on 8 Aug 2013 at 4:53

from snes9xgx.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.