Nintendo Wii port - teaser!

[mardy]

Hi all!
There are quite a few little things that I still need to fix up, but the game is now mostly playable on a Nintendo Wii. As you might see from the video, this is not Neverball from the master branch, but an older version from 2017 (the same one packaged in Ubuntu and Debian). I will eventually update it, I just want to fix the point rendering -- as you might notice, the little stars on the goal are missing.

out.webm

The most annoying issue now is the short freeze that happens whenever the game has to play a sound (you notice them in the video everytime the ball is about to hit a coin or a wall).

Stay tuned :-)

[parasti]

Awesome! Just to let you know, in the latest code I'm starting to move away from point sprites - they are very size limited on modern high-density displays. So I guess if you wait long enough, you will not need to do any point sprite work.

[mardy]

Yes, but actually, my goal is also to improve the OpenGL driver for the Wii, so I do want to get that part done :-)

To fix the delays when playing sounds, do you think that a small cache (say, keeping in memory the last three played sounds) is something you could accept upstream? The Wii does not have a real OS that would take care of caching files, unfortunately.

[parasti]

To be precise, all sound effects should be precached on game launch. Most-recently-used cache won't be good enough because it will still lag on the first playback and will 100% always lag on the goal-reached sound effect.

Neverball used to do sound precaching, but switched to streaming as part of an effort to reduce its memory footprint (primarily for mobile devices at the time). In retrospect that didn't really work out - I've seen plenty of reports and personally experienced instances of sounds being laggy due to slow initial I/O.

This is on my list, but I obviously won't mind if anyone beats me to it.

[mardy]

To be precise, all sound effects should be precached on game launch. Most-recently-used cache won't be good enough because it will still lag on the first playback and will 100% always lag on the goal-reached sound effect.

Right.

Neverball used to do sound precaching, but switched to streaming as part of an effort to reduce its memory footprint (primarily for mobile devices at the time). In retrospect that didn't really work out - I've seen plenty of reports and personally experienced instances of sounds being laggy due to slow initial I/O.

Unfortunately, it does not appear to be a I/O issue: I tried this

diff --git a/share/fs_physfs.c b/share/fs_physfs.c
index c8be4934..d64292aa 100644
--- a/share/fs_physfs.c
+++ b/share/fs_physfs.c
@@ -39,6 +39,18 @@ int fs_init(const char *argv0)
     if (PHYSFS_init(argv0))
     {
         PHYSFS_permitSymbolicLinks(1);
+#ifdef __WII__
+        PHYSFS_addToSearchPath(PHYSFS_getBaseDir(), 1);
+        PHYSFS_File *sounds = PHYSFS_openRead("data/sounds.zip");
+        PHYSFS_sint64 length = PHYSFS_fileLength(sounds);
+        void *sound_data = malloc(length);
+        if (!sound_data) return 0;
+        PHYSFS_sint64 read = 0;
+        while (read < length) {
+            read += PHYSFS_readBytes(sounds, sound_data + read, length - read);
+        }
+        PHYSFS_mountMemory(sound_data, length, free, "sounds.zip", "", 0);
+#endif
         return 1;
     }
 

where the sounds files were added to sounds.zip uncompressed (zip -0 ...), but it doesn't seem to do a noticeable difference. It may be that the issue is in the ogg decoding, or the mixing itself. I'll investigate.

[parasti]

We dropped PhysicsFS some years ago. Using it further or debugging it is a waste of time, iMO.

Just cache the sounds in audio_init.