• Status Unconfirmed
  • Percent Complete
  • Task Type Patches
  • Category Applications
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by dataangel - 2008-08-17

FS#9292 - New game plugin, NBackBox

It’s still a bit rough around the edges, but I’ve written a new game plugin called NBackBox. It’s an implementation of the dual-n-back exercise, discussed in this Wired article: . In short, it’s a game that improves your brain’s working memory. I’ve tried to keep it as close to how the game was described in the original paper.

Any feedback/bug reports/code suggestions much appreciated :)


Whoops, forgot patch

no idea what that game does but some code
should be 4
havnt made it target-portable (BUTTON_POWER isnt deifned on every
only using the main screen, this could probably work on multi screen targets (use rb→screens[i]. functions)

also, please choose a better name... we really have enough rockBLAA or BLAAbox
can you please split the patch up into the actual code and the included data files? no need for us to download 2MB every time we want to check out the code :D

Updated, tabs are now converted to spaces, BUTTON_MENU or BUTTON_OFF will be used if BUTTON_POWER is not available (Does that cover all targets?), the resources are in a separate patch, and the name is changed to dualnback :) Haven’t fixed the multiscreen issues yet...

Building on ipod video: lots of gcc warnings in functions in dualnback.c that have no arguments not being declared as void (get_random_sound, line_height, etc). Also BUTTON_DOWN not defined.

BTW you should be able to try building (even sim build) for various targets and see if they compile :)

Re NBACK_QUIT - could you use the same button combo as e.g. minesweeper? e.g. BUTTON_OFF where defined, or MENU+SELECT for ipods, etc. It should be the de-facto standard for rockbox plugins [even if it currently needs to be reimplemented in each plugin predicated by target type, unfortunately]

Some more
ipod, BUTTON_DOWN is called BUTTON_PLAY (again, take a look at minesweeper etc for appropriate keymaps for other targets)

This currently does not build in non-debug/non-sim builds because of the use of rb→debugf, which is only defined in debug/sim builds. So rather than rb→debugf you should use the DEBUGF macro - which aliases to rb→debugf for debug/sim builds and aliases to thin air for non-debug/non-sim builds (where rb→debugf doesn’t actually exist)

Two more
audio arrays included should not be bare in /apps/plugins - better to have /apps/plugins/dualnback/ hierarchy containing dualnback.c and the associated files (and add dualnback to
– compiling plugin for real target also exceeds boundaries of PLUGIN_RAM section (on ipod at least) – plugin is too big to fit in memory... Would it be possible to reduce the size of the audio somewhat to fit available target ram (shorter sounds? resampled to lower sampling frequency?) and/or be played back using codec (mp3) rather than raw pcm?

I’m running into trouble trying to put everything in a subdirectory. I made a dualnback subdirectory, and added it to apps/plugins/SUBDIRS. Inside apps/plugins/dualnback/ I put all of the source files, and added a SOURCES file just containing the line ‘dualnback.c’. But if I try to make it complains there’s no Makefile. So I tried putting the line ‘dualnback/dualnback.c’ into apps/plugins/SOURCES, but then it complains that there are no make rules for the sound header files (I changed the sounds to be .h) which is odd since it didn’t complain before when everything was in apps/plugins.

So then I decided to look at what other plugins did, and they have full fledged makefiles, which seems overkill here, since I only have one real source file, dualnback.c. Also, maybe there’s a good reason for it, but it looks like what most plugins with a subfolder do now is to copy and paste the same stock Makefile (except for changing filenames), which seems like a bad practice (if you fix something in one the rest are still bugged).

Updated version, lots of
files are now 11025hz mono, so they fit under 300KB. Will now actually load on real Sansa

bug where there would be 1 too many trials per
the wrong number of matches being present in each
now has its own folder for sources

The next step to shrink its memory usage for smaller players would be to use MP3s, but I haven’t been able to get the mp3 playback functions to work and it’s slow to test since they’re not defined for the simulator (why?).

If by “smaller players” you mean “The Archoses”, those players are the “hardware codec” players. They use a dedicated MP3 decoder chip, rather than software decoding like the other players do, and I assume if they can’t playback in the simulators it’s because nobody’s adapted MP3 software to fake this. I haven’t looked myself, so I can’t say for certain, though.

Further thoughts:

On the “software codec” players, it sounds like you have enough space in the plugin buffer already. At the moment we’d want to stop playback anyway, since you can’t listen to music while the plugin plays sounds anyway (though software mixing in the future might change this situation, though I think it’s unlikely you’d want to play this game while other noises go in the background that could make hearing the numbers difficult).

On the “hardware codec” players, my guess is that mixing will be more or less impossible anyway. So you can stop playback and used the compressed audio buffer for your sounds anyway. They’ll still need to be MP3 though, unless you want to look at the wavplay plugin for what is necessary to playback uncompressed audio.

Here’s a new version. No new features or major changes, I’ve just updated the code to build against the latest rockbox since the plugin API was changed.

Whoops, here’s the real file.

Can you update this

Joseph, you are doing button handling wrong. In particular, you’re assuming BUTTON_DOWN, BUTTON_LEFT on all targets and that is hardly the case. I believe that is what Gman above is referring to. On an ipodvideo, for example, compile fails at line 703 due to undefined BUTTON_DOWN.

See how other targets handle keymaps and just copy one with the correct number of needed buttons. That should be simple enough, I think.

Keep up the great work, this is a wonderful application!

The game idea is great. I hope you keep going the
wrote a small patch, which fixes the Button problem and add 4 spaces, instead of just 2.


Available keyboard shortcuts


Task Details

Task Editing