scanff / desmumewii Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/desmumewii
License: GNU General Public License v3.0
Automatically exported from code.google.com/p/desmumewii
License: GNU General Public License v3.0
I added some basic text output to DeSmuME Wii. So when we start the
emulator, we should see text and then, based on the text, be able to
determine where and why a freeze occurs.
However, the first line of text, "Welcome to DeSmuME Wii!" is never displayed.
My speculation for the reason is that:
1)We have an error with SDL Wii not returning to main properly.
2)My environment sucks (I just reconstructed it) and is preventing the
program from being correctly built.
Could someone please compile and confirm or deny if #2 is the issue?
Original issue reported on code.google.com by [email protected]
on 5 Nov 2009 at 10:06
1. Download and compile r157
2. Run and if you don't have a /DSROMS directory you will notice that it
goes into a folder browser thing.
3. Run a game and hit the 1 (2?) button a couple times and you will notice
that Cyan's in-between screens X amount of pixels isn't there.
4. You will also notice that it won't detect a /DS/SAVES directory, it
looks in the root.
Changes for rev 152 in the comments says that /DS/ROMS and /DS/SAVES and
/DS/BIOS was left in there from the bad previous version.
Changes for rev 153 says it adds Cyan's patch which adds space between the
screens.
I don't know why it's like this.
Original issue reported on code.google.com by [email protected]
on 21 Apr 2010 at 10:22
The expected output when you compile the project should be along the lines
of: "Welcome to Desmume Wii!" and so forth.
However, this is not the case. There is only a blank screen. What is
troubling is the fact that, in the previous version (before the reboot to
Desmume 0.95), the console worked. Any ideas as to what has changed would
be greatly appreciated, since I'm more than a tad stumped at this.
This also could be a sign of a bigger problem, such as ALL video. Let's
hope that it's not.
Original issue reported on code.google.com by dancinninjac
on 18 Mar 2010 at 12:11
Most if not all the game on Desmumewii run way too slow, i don't see the point
of fixing graphical problems if you cant even play the game a full speed.
Who care if Mario looks like a blob, as long as the blob can finish and beat
the game.
Original issue reported on code.google.com by [email protected]
on 23 Nov 2010 at 10:17
Please provide here info if you got this error.
1) Your SD card vendor, size, class.
2) Your region.
3) Last revision that worked.
4) Revision that not working.
5) You compile it yourself or download it. Where you download it.
6) Any additions from you.
Original issue reported on code.google.com by AndreyLegchilin
on 5 Apr 2010 at 3:34
Purpose of code changes on this branch:
I overhauled the way that we handle matrices in gfx3d.cpp. Right now everything
comes out black, which means that the matrices are not scaling the coordinates
right (I think).
The only changes from the trunk should be in gfx3d.cpp, GXRender.cpp, and the
additional files (MtxStack and MtxMath).
When reviewing my code changes, please focus on:
- How the scaling/rotation/positioning is done for coordinates of textures and
points. I believe this is where the problems lay.
- What needs to be "cut" in order to make this work. I suspect that since in
order to get "Vanilla" to run on the Wii, we changed a few things and that is
"undoing" what the matrix overhaul has done.
Thank you very much!
Original issue reported on code.google.com by dancinninjac
on 24 Aug 2010 at 6:06
Ok, so I've tried a whole bunch of things. Here's where I'm at.
Firstly to stop the crash in gfx3d.cpp put a return in the gfx3d_execute
function. This will stop the crash and you you can play the game but there
will be NO 3D.
like :-
static void gfx3d_execute(u8 cmd, u32 param)
{
return;
......
}
I'm still suspect of the stack as there's several functions calling other
functions. It could also be the Wii does not like a certain task one of
these functions is doing, but without a gecko it will take time to identify
which.
baby.lueshi I checked lowering the VERTLIST_SIZE and POLYLIST_SIZE but
there are sanity checks in the vert functions that don't allow more than
the defined number to be added.. I'd image it would stop drawing 3D when
it reached the max.... But having said that. the count is stored as an
"int" and the SIZE's are defined as more than the max of an int (assuming
int's are 32767). If this is a bug ... It should be reported to the main
desmume project.
i.e. You can see VERTLIST_SIZE is larger than the "count" variable as it's
an int. I am allocating these the original desmume project puts them on
the stack.
#define VERTLIST_SIZE 400000
//#define VERTLIST_SIZE 10000
struct VERTLIST {
VERTLIST()
{
list = new VERT[VERTLIST_SIZE];
};
~VERTLIST()
{
delete [] list;
list = 0;
};
VERT* list;
int count;
};
Original issue reported on code.google.com by [email protected]
on 31 Mar 2010 at 7:04
We are work on a new ds emulator for psp please help :):)
http://code.google.com/p/dsonpsp/
Original issue reported on code.google.com by [email protected]
on 8 May 2010 at 8:02
What steps will reproduce the problem?
1.start game
2.try to save
3.it will freeze when saving
What is the expected output? What do you see instead?
frozen screen
What version of the product are you using? On what operating system?
r183
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 8 May 2010 at 9:22
Ah yes, the dreaded MMU. The bane of our existence. Here is what I have
gathered so far:
1) If you set DesmumeWii to exit right before calling MMU_Init (in NDS_Init
of NDSSystem.cpp), it will successfully exit to the loader.
2) If you set it to exit INSIDE of MMU_Init, it will freeze forever, and no
text will display on the screen at all.
This leads to the deduction that MMU.cpp has code that is "optimized out"
by the compiler when we exit prior to using any of its code (before
MMU_Init). This means that the compiler doesn't actually include the code
within MMU.cpp.
So something within the file MMU (or series of files) is causing the entire
program to self-destruct before it is even run.
Original issue reported on code.google.com by dancinninjac
on 20 Mar 2010 at 7:33
There's a reason that I've been so quiet lately.
These may just be the rantings of a madman, but I was thinking...
Since the esteemed Arikado worked on DOP-Mii, I figured that you would know
whether this was possible or not. At least, moreso than I. Is it possible
to get access to the starlet? Is it even doing anything when we're running
homebrew? The DS runs on an arm processor, so if we could utilize even a
fraction of Starlet's power, well... I think we all know what would happen.
I have read the crap out of the technical manuals, and I found some
striking similarities to Vanilla's Disassembler.cpp code and native
instructions for the ARM processor. I have some heavily commented files to
this effect.
Since Vanilla was not built with an ARM processor in mind, it had to
emulate everything. Consider this piece from arm_instructions.cpp:
armcp15_moveARM2CP((armcp15_t*)cpu->coproc[cpnum], ...);
//Which is defined as:
armcp15_moveARM2CP(armcp15_t *armcp15, u32 val, u8 CRn, u8 CRm, u8
opcode1, u8 opcode2)
//Now, this code is to "move from the ARM to the Co-Processor", which is
defined on the ARM architecture as:
mcr p<cpnum>, <opcode1>, Rd, CRn, CRm, <opcode2>
Notice any similarities?
So, if this is possible, we need to communicate with the Starlet. This, I'm
told is by the Hollywood's IPC engine
(http://wiibrew.org/wiki/Hardware/IPC). I don't know how to set up
communications in the first place, though.
This just scratches the surface of what I've found. I wanted to get some
feedback before I committed my commented versions of the files, seeing as
how they are even less organized than this. I have also created a header
file with ARM-specific assembly code, ready and raring to go, if I get a
green light.
Original issue reported on code.google.com by dancinninjac
on 1 Apr 2010 at 3:01
Based on r83.
Also changed type of xfb to solve compile-time error.
Original issue reported on code.google.com by AndreyLegchilin
on 1 Apr 2010 at 5:01
Attachments:
In one of my rev's I added a hack in the GPU code. (basically so we'd see
the screen)
in ::: GUP.cpp, void GPU_setVideoProp(GPU * gpu, u32 p)
....
gpu->dispMode = 2; // NOT sure if this is an option or what ... Setting it
makes the screen WORK :)))) scanff
What this is actually doing is using the frame buffer to grab pixels from.
So you're only seeing the main screen and not the sub screen. I've
checked over all the code and can't figure out what's going on. All I'm
seeing is a block of stretched pixels for both screens. Almost like a
block of 16x16 pixels is being stretched to 256x192 pixels.
I'm looking into this but thought I'd log it in case anyone has any ideas??
Original issue reported on code.google.com by [email protected]
on 28 Mar 2010 at 6:35
What steps will reproduce the problem?
1.C Stick- cursor movement abit slow
2.
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Please provide any additional information below.
If possible could the speed of the cursor possibly be sped up to maybe slightly
slower speed say for the speed used in the wii menu when using the classic
controller's left analog stick,also something else i may suggest is what about
using the right analog stick on the classic controller for the cursor and using
one of the "Z" buttons as click/tap?just thought i would see what your mind set
on some of these ideas are,i mean if there ok with you and the team and can be
implemented into the emulator without any major hassles then i would love to
see them implemented
Original issue reported on code.google.com by [email protected]
on 17 Jul 2010 at 7:59
Just throwing it out there... You guys are more than welcome to borrow
WiiDS's button maps. They should move over to this project simply with only
a few changes (removing/editing the libwiigui functions). They're located
inside input.cpp/.h and btnmaps.cpp/.h. You'll also need to add support for
wiiuse and wpad, if you haven't already.
Original issue reported on code.google.com by [email protected]
on 29 Mar 2010 at 10:46
Hi, an option to select the ingame language should be nice, cos all
european roms start only in english.
Cheers :)
Original issue reported on code.google.com by [email protected]
on 22 Apr 2010 at 11:16
What steps will reproduce the problem?
1. Run DeSMuMe r154
2. Load Super Mario 64 DS (U)
3. Walk around in the main story
What is the expected output? What do you see instead?
Expected: Walk around and have Yoshi go where I tell him to.
Real: Yoshi warps around, not paying attention to any boundaries.
What version of the product are you using? On what operating system?
r154, DeSMuMe Wii
Please provide any additional information below.
This should classify the game as "Unstable" since only the Minigames work
right.
Original issue reported on code.google.com by [email protected]
on 31 May 2010 at 10:23
[deleted issue]
I was trying to load Animal Crossing Wild World, and I pressed 1 on the wiimote
to see the status and recieved this:
Inintialszing Virtual Nintendo DS...
Found external BIOS files. Will use!
Wooooot.... MMU is here !! (<--- I think it says MMU)
Microphone successfully inited. (Weird, I don't have a microphone?)
SoftRest Initialized
Initialization successful!
Setting up for sound...
Placing rOM into virtual NDS...
DEBUG_reset: 88902978 (I think it says that number ayways)
Using CFlash directory:
ARM7 BIOS is loaded.
ARM9 BIOS is loaded.
ROM crc: 00000000
ROM serial: ANIMAL CROSS_ADME10
yikes!!!!! please report!
yikes!!!!! please report!
yikes!!!!! please report! (this one showed up near the time I was finished
typing the above^)
Also the whole screen flashes, the Virtual DS screen alternates with the
status, really hard to read. Please reply if you know what's wrong, thanks :)
p.s. What's the yikes please report all about?
Original issue reported on code.google.com by [email protected]
on 8 Jun 2010 at 9:47
I'm unsure if you guys are still looking for Glib or not, but I figured I'd
post this just in case. GLib is a library from the GTK+ Project.
Here are the Win32 Binaries, followed by the Win32 src:
http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.22/glib_2.22.4-1_win32.zip
http://ftp.gnome.org/pub/gnome/sources/glib/2.22/glib-2.22.4.tar.bz2
Original issue reported on code.google.com by [email protected]
on 3 Mar 2010 at 12:23
What steps will reproduce the problem?
1.
2.
3.
What is the expected output? What do you see instead?
all i see is a black screen after the screen that says press start.
What version of the product are you using? On what operating system?
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 6 Jun 2010 at 11:44
I have managed to trace the source of the current problem (where the screen
will freeze and do nothing) to a specific place.
The problem is actually in MMU_Init. This is the culprit:
for(i = 0x80; i<0xA0; ++i) {
MMU_struct::MMU_MEM[0][i] = MMU.CART_ROM;
MMU_struct::MMU_MEM[1][i] = MMU.CART_ROM;
}
After doing a lot more testing the problem was actually from the MMU_struct
access. I could get it to trace something to the screen up until that
point. A simple trace of "MMU_struct::MMU_MEM[0][0x80]" triggered the same
results.
I am still unsure as to WHY this is, though. Looking at the original
Desmume code, there is no difference. Of course, the original Desmume has
since updated the MMU code significantly. Trying to put in the new code
didn't work.
At least it's a bit more pinpointed, though. If that helps at all.
Original issue reported on code.google.com by dancinninjac
on 13 Feb 2010 at 12:36
Just a note to self. Remove OpenGL from project, it's not needed!
Original issue reported on code.google.com by [email protected]
on 27 Mar 2010 at 5:11
Hey i have maked a Channel for desmume wii is tihs ok? you can install the
channel ( über den HBC ) it is a Boot.dol..#
It´s all Ok and its works Very Fine.
Can this the Official Forwader?
For user the have ios 249 base 38:
http://www.mediafire.com/?pvfj32hkaq3m5wa
For User the have ios 36 Pathed:
http://www.mediafire.com/?2or95t3wf1fler0
And It is good?
Original issue reported on code.google.com by [email protected]
on 23 Aug 2010 at 7:49
It would be very convenient for me if there was an option to use the
Gamecube d-pad for movement. My classic controller broke and I've been using
a ps1/gc adapter as a substitute.
Original issue reported on code.google.com by [email protected]
on 25 May 2010 at 3:51
[deleted issue]
What steps will reproduce the problem?
1. run chrono triger in rev 154 then run it in rev 184
2.
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
184
Please provide any additional information below.
well i notice that on rev 154 when you load chrono trigger there a clock when
it first starts that moves left to right. in rev 154 when the clock moves it
seems to refresh and run properly. also the game runs normal speed. In rev 184
the clock seem to keep multiplying and doesnt refresh. its like it stacking
clocks on each other. when you play the actual game tho it seem like it's a tad
slower running than it was in 154.
Original issue reported on code.google.com by [email protected]
on 17 Jun 2010 at 6:36
hello i can´t compile r180. bevor i have compile all versions. now there a
lot of errors at compiling with defkit
Original issue reported on code.google.com by [email protected]
on 2 May 2010 at 9:02
There is a major graphical bug with NSMB in GX mode,the graphics do not show up
at all.
In M&L3 Bowser's Inside Story,the top screen appears zoomed in too far.
and...
You probably already know that SM64DS has coloring and lighting issues.
Original issue reported on code.google.com by [email protected]
on 6 Aug 2010 at 3:31
Ide just like to say great job. This does look like you worked hard and I can
see it, and I look forward to your progress! :D
and im here to help out with testing and will report when they arise!
Original issue reported on code.google.com by [email protected]
on 27 Jun 2010 at 7:12
I'm hoping that eventually this emulator has touch support so that everyone
can play super mario 64 ds because you have to touch the star first to get to
the menu.
Original issue reported on code.google.com by [email protected]
on 4 Apr 2010 at 9:43
On it's own, the DeSmuME svn compiles up to the GPU_osd.h and GPU_osd.cpp
files. These are source files of the utmost importance as they deal with
emulating the graphics processing unit of the DS. These files rather
trivially use GLib's GTimer to keep track of clock speed in order to make
sure to not overclock the emulation.
Since we dont have GLib, we get compilation errors at this point.
There are 3 things we can do:
1) Look at how other emulators handle overclocking and try to mimic their
implementation
2) Assume we shouldn't worry about overclocking on the Wii and remove the
implementation completely
3) Port GLib
Im personally leaning towards option 1 but I looked through glib and seems
it shouldn't be too bad to port as we have libogc equivalents to major
(maybe even all) win32 libraries it calls. I want to completely avoid
option 2 at all costs.
Looking for some feedback.
--Arikado
Original issue reported on code.google.com by [email protected]
on 6 Mar 2010 at 5:41
What steps will reproduce the problem?
1. Menu option
2.
3.
What is the expected output? What do you see instead?
No Option
What version of the product are you using? On what operating system?
R149
Please provide any additional information below.
The Ability to Use BIOS and Firmware.bin
Original issue reported on code.google.com by [email protected]
on 15 Apr 2010 at 5:19
What steps will reproduce the problem?
1. Load the game.
2.
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
r185. Wii
Please provide any additional information below.
The game would start up and play on r184, even though painfully slow to the
point of unplayable. Now when it is loaded it stays a white screen as soon as
its loaded. I'm not sure if its changes that have been made or just from
reworking the desmume 0.9.6 or whatver it was (the new one) into the wii. If
this issue is irrelevant then sorry for posting it.
Original issue reported on code.google.com by [email protected]
on 28 Jun 2010 at 2:21
What steps will reproduce the problem?
1.
2.
3.
What is the expected output? What do you see instead?
being able to move the DS folder which contains /roms/saves/bios that is in the
root of the sd card to USB drive
What version of the product are you using? On what operating system?
184
Please provide any additional information below.
since there my sd is full of so many apps it be nice to be able to move that
folder to the usb drive and load the roms and everything from there.
Original issue reported on code.google.com by [email protected]
on 18 Jun 2010 at 6:19
add zooming in and out
Original issue reported on code.google.com by [email protected]
on 19 Jun 2010 at 10:06
I'm working to fix these problems and I need a feedback.
Please report only if something worked fine with X-revision, but Y-revision
broke that.
It would be bad if I'll "fix" one game that I have and broke all another.
First rev. to test is r91, second r105.
Original issue reported on code.google.com by AndreyLegchilin
on 6 Apr 2010 at 5:26
When I boot up the project I'm only able to see maybe 1/2 of the bottom
screen in the top right corner. Is this normal or is everyone else
disabling the window before testing? If so how would I go about doing this?
I'm guessing I would need to uncomment "//log_console_enable_log(true);"
and set it to false. Is this correct? If not, and there isn't anyway to
disable the log just yet, may I suggest switching the display to vertical
and aligning the screens to the right side of the screen. I say this
because I'm seeing some discoloration, or rather some color mix-ups, and I
wanted to make sure it wasn't just my TV before I submitted the issue...
But, it's hard to tell when I can only see as little as I mentioned above.
Original issue reported on code.google.com by [email protected]
on 27 Mar 2010 at 7:07
What steps will reproduce the problem?
1. Run any homebrew that uses 8bit backgrounds
What is the expected output? What do you see instead?
Expected output is of course normal background that was composed in
homebrew, instead of that it's displayed like 8x8 pixels of background
multipled like tiles, it looks sometimes really uggly, in other cases
sometimes there is white background like in GIF loading, same happens in
PC 0.9.5 version of Desmume.
However if 16bit backgrounds are used, problem doesn't occur, but it can't
be said as resolve because 16bit backgrounds takes more memory if I recall
correctly.
What version of the product are you using? On what operating system?
Recently compiled Desmume revision 169 and used once previous official
release 154
Wii OS 4.0
Please provide any additional information below.
Well, outside of that problem things like keys, music, actions foreseen in
homebrew code works pretty nice (tried with one homebrew so far)
I can make video of that broken backgrounds if that's necessary
Original issue reported on code.google.com by [email protected]
on 26 Apr 2010 at 1:47
Awesome will try some roms out. Feed back to come
Original issue reported on code.google.com by [email protected]
on 5 Nov 2009 at 6:16
There is a compiling guide to WiiDS on its google.code page and I got it
successfully compiled, but was not able to compile desmume. So any further
instructions how to compile it would be much appreciated.
Original issue reported on code.google.com by [email protected]
on 29 Mar 2010 at 6:37
What steps will reproduce the problem?
1. Run emulator
2. open new super mario bros
What is the expected output? What do you see instead?
The game runs very slow and crash
What version of the product are you using? On what operating system?
r122
Please provide any additional information below.
tested on HBC 1.06 wii 4.1U
Original issue reported on code.google.com by [email protected]
on 10 Apr 2010 at 4:59
please add a folder for all save files.
maybe :
SD:/desmumewii/save/
thx
Original issue reported on code.google.com by [email protected]
on 3 Apr 2010 at 12:13
Discussion of the white screen bug.
Games know to have this issue.
==============
Super Princess Peach
castlevania series
Zelda games
Advance Wars
Pokemon games Heartgold & Soulsilver.
=============
After a few hours of debugging I'm seeing that the REG_AUXSPIDATA is never
reached and the MC commands are never processed. The problem is deeper than
just the MC commands the arm cores continue to run but it obvious they've
gone of track somewhere. Not sure if there are similarities between these
games or a certain piece of hardware they use that the other games don't.
I'm asking for suggestions as I'm really not looking forward to debugging
arm instructions one by one on the Wii.
Original issue reported on code.google.com by [email protected]
on 14 Apr 2010 at 4:35
improve the wiimote ir sensor support. its hard to point with it in other
screen modes
Original issue reported on code.google.com by [email protected]
on 21 Jun 2010 at 9:41
This is really for myself to help me keep the project on track (and myself
busy of course) as well as to let everyone working on the project or
interested in becoming involved with the project to know what most pressing
things need to be done. Listed here are everything from trivial programming
tasks to potentially major core changes.
1)Getting 3D working well
Right now, 3D renders some things but textures are for the most part
transparent. This is what I am personally working very hard on resolving.
It seems on the outside that we need to allocate more memory for the 3D
functions to use. However, it also seems that there is something going
wrong causing some textures not to show. I think it involves the palette
color conversions but I'm really not too sure at the moment. If you
couldn't tell, this is what I'm personally focusing my working around.
2)Getting homebrew and commercial ROMs to work properly
It seems we can only get homebrew ROMs to work correctly when we hardcode
in the GPU display mode as 2. But we can only get commercial ROMs to work
when we do not. At the very least, we need to setup an if() that hardocdes
the gpu display mode if "Homebrew" is detected as the ROM ID.
3)Visibly marking stylus position
We've got X and Y coordinates tracking the stylus. Now let's use GX to
render a small aquare or something to show where the stylus is positioned
at. At the moment, as you cant see where the stylus is at, it's almost
impossible to use it or tell if it even works at all.
4)Getting more ROMs to boot
It's no longer an issue of ROMs just crash the emulator because we can't
get 3D to work. While compatibility has been greatly improved, there are
many ROMs like the Castlevanias and Mario Kart that just freeze and don't
do anything. This is presumably something in the loader code. My guess
would be that there's a register we need to give memory that we stole back to.
5)Optimization
I'm noticing in the rasterizer and 3D effects that we could probably
directly use GX to get some things done more efficiently and quickly. There
are most certainly other places in the emulator where similar things can be
done to shorten code or make it more Wii friendly.
6)Removing unneeded code
We need every extra bit of memory we can get! We do not need things in
DeSmuME like code to record a video of gameplay. Or to interface with a
linux filesystem. We can also probably start getting rid of OGLRender files
now. Please, if you see code we can get rid of: Get rid of it. We need the
extra memory.
7)Using 32-Bit Variables
ekeeke suggested using 32 bit variables in lieu of smaller ones
(specifically 32 bit ints instead of the 8 bit ones we were using) in order
to speed up the emulator. I would love to look into this and see how
helpful this may be.
8)Adding frame skipping
We've got some code in main.cpp to monitor the fps rate. It shouldn't be
too hard to use it to give the user control over frame skipping to
artificially speed up emulation for themselves.
Original issue reported on code.google.com by [email protected]
on 2 Apr 2010 at 2:20
What steps will reproduce the problem?
1. Use A forwarder Channel
2.
3.
What is the expected output? What do you see instead?
Desmunewii Code Dump
What version of the product are you using? On what operating system?
Wii 3.2e cIOSX rev 19 (38 base) desmunewii r73
Forwarder channel used customizemii and NAND Loader as waninkoko although
I'm pretty sure that wouldn't change anything
Please provide any additional information below.
I do see the desmune wii screen for like 1 second then it code dumps
I know A forwarder channel is the most important thing right now but it
would be nice if it worked, Here's the one I made :
http://www.megaupload.com/?d=R50FX6Q4
Original issue reported on code.google.com by [email protected]
on 31 Mar 2010 at 4:25
Since we have a desperate need for space, I was thinking...
BOOL is defined as an unsigned int, or 4 bytes.
bool (lowercase) is defined as only one byte.
I was thinking it might be a hoot if we converted all of the BOOLs to bools
for space consideration.
If the "Vanilla" Desmume used BOOLs in the correct way, then it shouldn't
be a problem... Right?
I wanted to get some input before I start to dive in, however.
Original issue reported on code.google.com by dancinninjac
on 28 Mar 2010 at 6:26
What steps will reproduce the problem?
1. Run DeSmuMe
2. Start Super Mario 64 DS (U)
3. Start the main adventure then walk around.
What is the expected output? What do you see instead?
Expected: Walk normally in a linear fashion.
Real: You warp around. This may or may not be triggered by certain areas.
What version of the product are you using? On what operating system?
r154
Please provide any additional information below.
I have warped outside the map, and the camera could barely show me (it
showed the edge of the lake, and I was a tiny speck in the background.)
Original issue reported on code.google.com by [email protected]
on 27 Apr 2010 at 12:10
Loads fine, but does go very slow in the start screen. Stays in black
screen and does not play the game afterwards.
Original issue reported on code.google.com by [email protected]
on 11 May 2010 at 3:27
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.