Hi,
Sorry, that was not meant to disincentive you in this task. My point was that porting Dune II to DS is not something that would bring new content to the DS platform, as there is already a port to the SEGA Genesis and that could be emulated.
If you really want to go along this project, here are a few tips I can suggest you, since I got to know the Westwood RTS engine in Command & Conquer and it was heavily based on Dune II sourcecode.
The first thing you should do is get the source code to compile. You will need to edit the build scripts (CMake, Makefile, ... whichever tool they use) to use the devkitpro toolchain (compiler and linker). Here is the CMake configuration file I wrote for devkitarm:
https://github.com/giulianobelinass.../ndsi_new/cmake/devkitarm-nds-toolchain.cmake
You will probably take some time to achive this task because, as I mentined somewhere else, devkitarm doesn't provice a fully feature standard C library and you will probably have to implement some of their functions by your own or create fake functions to get it to work. Here is an example of a port of the `fnmatch` function that was used by the game. I took it from newlib and patched it to work on DS:
https://github.com/giulianobelinassi/Vanilla-Conquer/blob/ndsi_new/common/fnmatch.cpp
There will most likely be problems with the graphical and sound libraries they are using in the game. It is most likely they have a compatibility layer interfacing the original game calls with SDL2. Nintendo DS doens't support SDL2 so you will have to remove the calls to SDL2 for now, and then later understand what they are supposed to do and implement them.
Once you get it to compile and a ROM generated, then you will try to run on a real DS only to find that the game will crash, probably at some point because the filesystem was not properly initialized or they don't know where to open a file. So you will have to tell the game how to initialize the filesystem and interface it with the game.
Here is an example of what I had to do: Here I implemented which path should the game find the game files:
https://github.com/giulianobelinassi/Vanilla-Conquer/blob/ndsi_new/common/paths_nds.cpp
Here I hacked the game's Linux port of finding files to properly call the libfatfs initialization:
https://github.com/giulianobelinassi/Vanilla-Conquer/blob/ndsi_new/common/file_posix.cpp
Once you get all files to be properly found and open, you should continue to get the video engine to work.
Command & Conquer (and most likely Dune II) did not assume the hardware had many acceleration features like today games do. They just set the VGA to 320x200 pixels and 8-bit indexed paletted mode. Then it assumes that there exists an address to which when it writes bytes on that, stuff get displayed on the screen. This is easy to emulate on the Nintendo DS, as it supports 512x256 8-bit backgrounds that can be downscaled to fit the screen. You will see that on video initialization it sets up the background accordingly:
https://github.com/giulianobelinassi/Vanilla-Conquer/blob/ndsi_new/common/video_nds.cpp
You will also see that I emulate the VGA cursor support using a single DS sprite. That probably won't be needed because I think Dune II could not assume that it was supported by the card at the time. So who knows
As for the controls, I just emulate the mouse using the touchscreen and the keyboard using the keypads:
https://github.com/giulianobelinass...9aa28e64a4f2fbe512/common/wwkeyboard.cpp#L662
With this you should have a playable game, but without music. Getting music to work in the DS is troublesome and very hard. I had to rewrite the sound engine of Command & Conquer for the DS. Dune II should be even harder in this respect because it uses MIDI music playback, so you will have to emulate an OPL somehow.
LibNDS unfortunatelly do not provide too much control of the sound engine from the ARM9 side, so will probably will want to have the code to run on the ARM7. That said, you will probably have a lot of problems debugging it. And also limited amount of RAM.
Here is the interface I wrote from the ARM9 side interfacing the game:
https://github.com/giulianobelinassi/Vanilla-Conquer/blob/ndsi_new/common/soundio_nds.cpp
Here is the DS sound engine I wrote for the game running on ARM7 side:
https://github.com/giulianobelinassi/Vanilla-Conquer/blob/ndsi_new/arm7/audio.cpp
Here is an overview of how the sound engine works: It defines 5 sound trackers that will be used. I known that the Nintendo DS supports more trackers, but I can't use them because of memory usage concerns. The sounds are stored compressed in memory, and decompressed as they are being played. In order to do that, I set the trackers in repeat and divide the buffer into two parts. While one part is being played, the other is being updated. This is called double-buffering. To realize when should I update the buffers, there is a *very precise* timer counting how much time was spent since the last update. This is where things get really complicated. DirectSound (PC) allows inspecting where the sound hardware is at the current sample. Nintendo DS do not have that. There is even extra code there to load the sound samples from the Expansion Pak, but I doubt you will need to use it. Dune II will probably run fine with 4MB of RAM.
In summary, that is a long but interesting project to work on. You will learn a lot if you do it, as I did learn a lot. But don't expect to finish it on a week or two, it will probably take years. It took me one year to port both Command & Conquer games to the DS.
I fully support your proposal, hoping that some of our brainiacs will come forward to implement it. I usually prefer t-rpg games over rts games, but since it is free and concerns my beloved DS, why not give it a chance?
