Gadgeteer Mini Pacman - New Enhancements

My little toy project has a few enhancements.

Whats New?

  1. Support for multiple levels
  2. Bonus items - All the bonus items as per the original PacMan
  3. Floating bonus points when pac eats ghosts or bonus items
  4. Abstracted the input mechanism used to control Pacman
  5. Encapsulate the timeout pattern I was using for in game timeouts into a CountDownTimer

Still to come…

  1. Introduce support for mutliple screens (Intro Screen, Game play Screen etc.)
  2. High score table???
  3. And the part I am really interested in - Optimizations.

It is point 3 that interests me the most because I suspect that is where I am going to really learn a lot about .NETMF.

You can grab the code from Codeplex

Best Regards,


I want to try to make Space Invaders using your engine. I hope you don’t mind.

Should be fun. Plus I need a good demo for my Chucky module and its driver.

@ Architect, consider the code yours. I would be glad if it can be useful to someone.

I have to say, I’m very impressed with your work!

Great! I’ll give it a try tonight.

@ taylorza, I have forked your project and adjusted it to work on FEZ Cobra with 3.5" display. I could have connected the gadgeteer joystick to it using ransomhalls MakeBread module but instead I have added touch screen control of pacman. Everything works :slight_smile: There wasn’t many changes needed but please check out the difference. I suggest you extract the game logic to some core library so that you can support both devices (or more in the future).

And a proof

@ Gralin, that is super cool. I am checking the diffs now and will definitely look at how I can make this more portable.

I also want to eventually extract the “Game” namespace into a separate library so that it is more convenient to use it as a game library. This has evolved way beyond anything I initially intended it to, you guys have been a great motivation and the platform (.NETMF) is far more fun than I expected :slight_smile:

Thanks for sharing!


How hard did you have to work on perf optimization? Are you driving everything pretty much as hard as it will go, or did you have enough headroom so that you had to put in delays?


@ Pete,

I have not really done any optimization other than the “obvious” and I say obvious based on my desktop experience and anything that seemed obvious to me based on the little I know about NETMF.

  1. Typed containers - I was lazy and did not actually implement IList/ICollection so I call them containers
  2. For loops, no foreach
  3. Shifts instead of mul/div

I noticed that the casting was consuming time and that motivated me to go with the typed containers. Foreach has the overhead of casting and since there is no JIT it seemed hard to see how they could be optimized in the same way that the JIT does. And the shifts vs. mul/div, that was just an assumption and since I am working with powers of 2 the shifts are easy enough to not get concerned with readability.

I have not really benchmarked much of the code yet, I am writing a mini-profiler to tackle that and I will let the profiler guide me, hopefully, in the right direction.

In its current unoptimized state it does not seem as if the device is being pushed to the limits. The current “game loop” timer runs at 50ms, if that is dropped to 10ms the game runs faster, but I suck at playing games so 50ms it is :slight_smile:


This is so cool. You only got your spider kit at the weekend and have achieved all this!
I can’t wait to see what other projects you will cook up.

@ taylorza - I am adding new “InputProvider” to try the game with Wii controller using Chucky module. Looking at your GhiJoystickInputProvider. Have a question.

Why do you multiply each position by 2?

@ Architect - The analog input from the joystick returns a value from 0 to 1 with 0.5 being the center position. I choose you standardize the IInputProvider interface to use the range -1 to 1 with 0 being center, the calculation adjust the scale into this range.

I choose to scale the analog input this way because it firstly felt more natural to me and secondly seems to be the more standard approach when dealing with desktop analog inputs.

Thanks. Makes sense.

Wii has a range from -26(-27)(-28) to +25(+26)(+27). Different for each stick even on the same controller. Center is also different it can be (0,0) (-1,0) (0,1)and so on.

Trying to came up with the formula to normalize it.

@ Architect - Why not assume a range of say -25 to 25 then clamp the result to -1 to 1. The center does not matter too much because you always have to assume it is not 100% 0,0 so even in the pacman game I have a dead-zone.

Of course you can play around with the value, I arbitrarily choose 25, but in my albeit limited experience with controllers on the PC etc. I have never seen situation where the accuracy is important just as long as the response is the expected response for the player.

That should work.Thanks for the suggestion.

@ Architect - Here is a quick and dirty implementation (real dirty :slight_smile:

private static double Normalize(int min, int max, double value)
  double result = value / ((max - min) / 2);
  return result < -1 ? -1 : result > 1 ? 1 : result;

So you could call it like this

double X 
  get { return Normalize(-25, 25, xAxisValue); }

Wouldn’t work with assymetric ranges, but close. :wink: I have more generic formula to count for that. Thanks!

@ Architect - Of course you are correct :slight_smile: I just assumed that you would ignore the asymmetry. Of course having said that, I should in that case have just passed a single value which specified the half range ie 25, that would also have saved the divide, like I said quick and dirty… :slight_smile:

Hope you will share the generic formula…

No problem. Should be something like this:

    private static double Normalize(int min, int max, int value)
        double result = -1 + (value << 1) / (max - min);
        return result < -1 ? -1 : result > 1 ? 1 : result;