Restore support for the Nokia N-Gage

[mupfdev]

As described in #11243 and #6691, support for the Nokia N-Gage has been dropped due to technical limitations that have now been resolved. The custom-built C-Compiler now supports C99. The C++ compiler is still outdated and has only been retained for compatibility reasons.

Description

• A completely new port that uses a native rendering backend instead of SDL's software renderer.
• Limited but working audio support!
• Built-in FPS display for performance control during development #.
• EKA2L1 can output messages via SDL_Log().
• A demo application is currently being developed. It can be found in the ngage-toolchain repository.
• The backlight is kept on while the SDL application is running. Edit: The behaviour can now be modified using SDL_DisableScreenSaver/SDL_EnableScreenSaver

Existing Issue(s)

• It is currently not possible to put the application that has been launched into the background. It continues to run and can then no longer be closed. This is a bug in the new rendering backend.

• If the application is put in the background while sound is playing, some of the audio is looped until the app is back in focus.

• It is recommended initialising SDLs audio sub-system even when it is not required. The backend is started at a higher level. Initialising SDLs audio sub-system ensures that the backend is properly deinitialised. Edit: Not really an issue.

[mupfdev]

Some of the more recent changes is causing an error message when I close the running SDL application. I look into this.

[ccawley2011]

I'd suggest directly using the SDL_SCANCODE_ values here rather than converting from a fixed set of SDLK_ values.

[mupfdev]

How do you mean that? I am currently translating the scan codes from the Symbian API into the identifiers used by SDL.

[ccawley2011]

Like this:

        case EStdKeyBackspace: // Clear key
            return SDL_SCANCODE_BACKSPACE;
            break;

[mupfdev]

I would rather set a variable while having a single point of return, however, I need to determine all the scan codes to make this work either way. 👍

[icculus]

What's the status on this? Are we ready to merge?

(Tweaks and additional fixes/improvements can come later, but I'd rather this not have to live in a branch if it's Good Enough at this point.)

[mupfdev]

@madebr made great progress with CI. @madebr what's your take on this?

A merge would be fine with me, but N-Gage shouldn't be the only platform without a working CI.

[madebr]

@madebr made great progress with CI. @madebr what's your take on this?

A merge would be fine with me, but N-Gage shouldn't be the only platform without a working CI.

I can't comment on the N-Gage C/C++ code, which seems to be in ok state.
I'm not so happy with the current CMake integration: N-Gage's CMake toolchain file uses hacks and does not allow to build any SDL tests or examples.
I have a wip ngage-toolchain branch in which I modified the Emscripten wrappers to let the ngage toolchain behave in a way that cmake (meson?) likes.

Short term, I can live with this but long term this needs to be fixed.

[icculus]

Let's try to get the CMake stuff up to standards and merge this, so @mupfdev doesn't have to keep working out of a branch.

[icculus]

(Whether that's @madebr or @mupfdev, or me, that needs to do that, let's figure it out.)

[mupfdev]

@madebr started working on a compile wrapper to streamline CMake support. AFAIK it's in this branch: https://github.com/madebr/SDL/tree/cmake-ngage-extra-support

If there's anything I could do to help, just let me know. I can also modify the toolchain if necessary.

[mupfdev]

I'm currently cleaning up the compiler wrapper by @madebr (which is now part of the toolchain).
Could take a few days until everything works as intended.

[mupfdev]

For whatever reason SDL_GetBasePath() stopped working at some point. This should be fixed, since it worked before.

[icculus]

Even so, 8000Hz is a very low sample rate to enforce for all applications just in case.

I agree, but that's a fix-after-merge issue, imho.

(If SDL can tell the audio device format changed for a phone call, etc, the backend should call SDL_AudioDeviceFormatChanged() when this happens. This will adjust any bound audio streams to output in the new format, so everything will continue to feed the device appropriately by default...it will also send an event to the app if it wants to do something with that information, like perhaps change the input side of the audio stream to the new format so no conversion is necessary.)