From rogerman:
The RomBanner struct requires UTF-16 strings for the six different ROM titles.
Currently, we use wchar_t buffers to define the memory blocks where the title
strings are supposed to go. Using wchar_t is fine for compilers that assume a
2-byte wchar_t. But compilers that use a 4-byte wchar_t will misalign
the memory blocks.
I've submitted a new patch that changes all the wchar_t in RomBanner titles
to u16 for all ports. It took me a while to research the dependencies on
titles, and to make sure I didn't accidentally break something in the
Windows port.
As for the wcscpy() deal in the RomBanner constructor, it's an arbitrary
default init value that we don't actually use in practice, so I removed it.
If a particular port wants to know what to display for the titles when a
ROM isn't loaded, there are plenty of ways to figure this out. Or they can
just check the titles for an empty string, which the constructor inits the
titles to before the wcscpy() call.
For CHEATS::save(), I removed the dependency on using titles. The ROM name
we write to file is also an arbitrary value which we don't actually
reference in practice. I changed it to use gameInfo.ROMname, since we're
already using gameInfo.ROMserial.
Anthony J. Bentley reports that desmume does not compile
on OpenBSD when the hud is enabled in bug #3148356.
After a few he reports that Stuart Henderson of OpenBSD
found the problem. The macro definition of ALIGN() conflicts
with a definition in /usr/include/machine/param.h.
So rename ALIGN macro to DS_ALIGN.
When the user uses an external firmware image, there is a
call to getpathnoext() in firmware.cpp:571 in order to
generate a file name for the saved firmware config file.
The size of the MMU.fw.userfile char buffer is only 260,
as declared in mc.h:73. However, getpathnoext() expects
the buffer size to be MAX_PATH, which is declared as 1024
in types.h:77. The buffer overflow occurs in path.h:293
with the call to strncpy(), which copies 1024 chars into
MMU.fw.userfile, which is only 260 chars.
This patch fixes this bug by setting the MMU.fw.userfile
char buffer to a size of MAX_PATH. This is consistent with
the char buffers used for the other file names.
From rogerman, #3328686
NSMB gets one step further. When Luigi receives Mario's data frames, he tries to use port 094 (REPLY1) to respond, but only writes zero there for whatever reason.
user heftig says that he can't find Agg_init() at link time when he uses
--enable-hud. Fix AM_CONDITIONAL to check for the proper variable and to
set in true only if --enable-hud was set.
Relayed by zeromus in a comment in #3250391
satelight reports the menu item position for savestates does
not match the slots they are saved.
As zeromus explains the pattern should be:
F1 saves to ds1
F2 saves to ds2
F10 saves to ds0
recent savestates list looks like:
1 myfile.ds1 F1
2 myfile.ds2 F2
...
0 myfile.ds0 F10
Based on a patch from satelight.
Jan reports that if you call reset when a game is paused
the statusbar would wrongly report the game as playing
when it is actually paused. Jan's attached patch removes
the call to desmume_resume() and the status bar update.
I think the intent here is different and the plan was to
reload the game so just call Launch directly as already
Jan noticed it would do the right thing.
Based on a patch from Jan Bücken (nooris), #3288654
xrmx: kept only the hunk that pause and not the one
that reenable the previous state, i think we should
stay paused and the user should act to continue
playing.
Based on a patch from: Jan Bücken (nooris), #3301520
This is not portable on windows and actually it's not even
working here. Anyway it should be working for Jan
otherwise it wouldn't have posted the patch right? :)
From: Jan Bücken (nooris), #3301520
Spring cleanup:
After this patch the file wxMain.cpp is ordered as follows:
1) header
2) includes
3) vars (and defines)
4) the wx oninit function that every wx project needs
5) the desmume class functions
5a) for functionality and events (e.g. for clicks on buttons, etc...)
5b) to load the menu
6) the wx event table
[xrmx: i hate these labels before code :)]
From: Jan Bücken (nooris), #3301520
We have a fair chunk of duplicated code to build the GUI
menus, remove the monolithic one in favour of the one
splitted in smaller functions.
From: Jan Bücken (nooris), #3301520
zeromus