Since NDS_Init takes no arguments, it should not hurt to call it early
in the gtk frontend, too.
This fixes the segfault in issue #415, although I could not get it to
run a r4 kernel in a quick test.
According to RFC 2396, the single quote character (') is allowed in uri
strings and is not escaped by gtk, so the action string constructed for
the recent files menu must be quoted with " instead of '.
This fixes issue #437
The data returned by Mic_ReadSample() must be transfered in 2 parts.
This must be done by every microphone driver.
I did test with Lunar: Dragon Song which values are considered loud,
since you can run away by screaming/blowing into the microphone. Values
from 33-223 don't trigger the escape, values from 0-32 and from 224-255
trigger an escape attempt. Thus 128 would be considered silence.
the offsets in the dump file are as follows (code snippet taken
from the dump function and annotated with locations from gbatek:
0x2000000
fp.fseek(0x000000,SEEK_SET); fp.fwrite(MMU.MAIN_MEM,0x800000); //arm9 main mem (8192K)
4 DTCM 027C0000h 16KB - - - R/W
or 0x800000 or 0xb000000 . DTCM location in real NDS varies, as the program can select where
it's mapped to, apparently.
fp.fseek(0x900000,SEEK_SET); fp.fwrite(MMU.ARM9_DTCM,0x4000); //arm9 DTCM (16K)
fp.fseek(0xA00000,SEEK_SET); fp.fwrite(MMU.ARM9_ITCM,0x8000); //arm9 ITCM (32K)
fp.fseek(0xB00000,SEEK_SET); fp.fwrite(MMU.ARM9_LCD,0xA4000); //LCD mem 656K
0 I/O and VRAM 04000000h 64MB - - R/W R/W
fp.fseek(0xC00000,SEEK_SET); fp.fwrite(MMU.ARM9_VMEM,0x800); //OAM
0xc000bc
fp.fseek(0xD00000,SEEK_SET); fp.fwrite(MMU.ARM7_ERAM,0x10000); //arm7 WRAM (64K)
fp.fseek(0xE00000,SEEK_SET); fp.fwrite(MMU.ARM7_WIRAM,0x10000); //arm7 wifi RAM ?
fp.fseek(0xF00000,SEEK_SET); fp.fwrite(MMU.SWIRAM,0x8000); //arm9/arm7 shared WRAM (32KB)
this is necessary to load saves from other devices or emulators,
as desmume uses its own incompatible format.
it works for importing .sav files from flashcarts, but only if the
file extension is .sav or .SAV - if using .dsv desmume guesses it's
of its own type and looks for a specific string, then fails.
the right code was taken from windows/importSave.cpp - it might make
sense to add the export item at some point too, however that will
probably require some more effort.
A call to the `SDL_DestroyTexture` method was forgotten, resulting in all the textures created to render the game's frames being stored indefinitely until running out of memory
This is a temporary fix so anyone using the interface (mainly `py-desmume` users) can have it working correctly again. Next step is to mirror the changes from POSIX CLI's main.cpp `Draw` method, if stable
- simplified ring-buffer mechanism
- added proper locking for all variables accessed by 2 different threads
- fixed oob writes that occassionally crashed SDL's "Alsa Hotplug thread"
- make buffer sufficiently large to prebuffer enough samples to survive
the occassional SDL_Delay(1) in the frontend.
- fixed ignoring volume set by the SPU.
- improved speed and robustness by not calling malloc over and over in
SDL callback, and copying directly to the SDL buffer if volume is max
(no need to use mixer to lower the volume in that case).
the new command line parameter --scale allows to scale the window by
a floating point factor. SDL2 stretches it in hardware to the desired
size, which makes the scaled window run at almost identical speed to
1x scale.
1) the float format displayed like 50.123456789123456 wouldn't fit
into the window title bar, and
2) most likely not into the char buffer of length 20, of which half
was already used for the desmume string.
additionally:
- don't allocate memory for surfaces and textures over and over
- use one texture for each NDS screen - this allows to easily
add support for horizontal screen layout.
the command line option existed once, but was turned off when a
new generic commandline parser class was introduced. the entire
array in main.cpp using custom commandline options is currently
unused.
there were 2 logical issues which caused reproducible misbehaviour.
for example when starting up pokemon soulsilver, one can click away
the intro, but it's not possible to click on the "load savegame"
icon.
the issues were:
1) failure to record whether the down event has been
passed to the emulator before abandoning it and turning it into
a click event (on a fast click, both events would happen during
the same SDL_Pollevent loop), and
2) mouse coordinates were discarded and unless the mouse down
event was registered. that means if the down and up events happen
on the exact same coordinate, the .x and .y of the mouse weren't
updated at all.
this is probably helpful for frontends other than cli that have to repaint
and react on events in the user interface, so they can set a timeout like
100 ms, or simply poll whether the stub is active using timeout 0.
the emulator thread was consuming 100% cpu even when the debugger was
active and execution paused.
a second pipe was added to gdb stub, which allows communication in
direction stub -> emulator/frontend, and also to infinitely block
in the frontend until the debugger returns control, for example
by typing "c" (continue) in gdb.
the other frontends use an inefficient method of running usleep(1000)
or similar in a loop, which will cause high cpu usage too, albeit not
a full 100% but more like 10-20%.
in order not to fill up the pipe with data for frontends that don't use
this mechanism, the functionality needs to be explicitly enabled.
(see functions added to gdbstub.h)
the functions added could in theory also be used to communicate
other data to the frontend, and optimally even replace all the locking
between the 2 sides.
zeromus