Closed GoogleCodeExporter closed 8 years ago
The reason this occurs is because the interpreter is relying on a hack to set
the rounding mode, using the set_floor macro. This does not work because gcc
sets the rounding mode back to truncate.
Don't rely on hacks like this. Either use the libm floor() function, or use
__asm__ to output exactly the instructions that you want.
Original comment by a8033...@gmail.com
on 27 Aug 2010 at 3:39
Very interesting, thanks for report. Maybe it could be easely change in the
repo.
If you have time, it could be good that you look at the project:
http://bitbucket.org/richard42/mupen64plus-core/overview
And prupose a patch.
Thanks in advance. =)
Original comment by dorian.f...@gmail.com
on 27 Aug 2010 at 9:57
It's more than just the floor instruction, many of the floating point
conversions are incorrect.
There is a similar problem in the Goldeneye intro, where the in-game sequences
do not finish. It doesn't crash, just restarts.
Original comment by a8033...@gmail.com
on 8 Sep 2010 at 11:44
Thanks! This prob is important indeed... What do you suggest to do with it?
You seem to be right about the conversion prob (even if it doesn't solve the
prob).
When you said that "many of the floating point conversions are incorrect", are
they easely identifiable?
Don't hesitate to go on the #mupen64plus IRC on freenode, maybe there will be
people that will understand the problem and help you. :)
Original comment by dorian.f...@gmail.com
on 14 Sep 2010 at 2:44
Original comment by richard...@gmail.com
on 22 May 2011 at 4:00
Just pushed fd0d64765ec6 (currently only in
https://bitbucket.org/lazhur/mupen64plus-core/ ). Can you please test if it
works for you?
Original comment by sven@narfation.org
on 10 Jul 2011 at 8:29
It is now merged in https://bitbucket.org/richard42
Original comment by s...@narfation.org
on 15 Jul 2011 at 12:13
Original comment by s...@narfation.org
on 29 Aug 2011 at 2:43
Original issue reported on code.google.com by
a8033...@gmail.com
on 8 Feb 2010 at 1:07