Hm, something to think about. Assembly is my weakest area programming though; perhaps @ Wouter could lend a hand there? Assembly flipping of the pins is bound to be even faster than RLP/C.
Maybe if I asked really nicely he’d give me a sample of pushing a 16x16 indexed image to the FEZ Touch in RLP/Assembly. 
But you may not need assembly all together!
This is not assembly…it is C pointers.
byte * p = RAM_ADDRESS;
*p = 5;
I’m thinking for pushing to the FEZ Touch. I know Panda II is only running the 100 pin USBizi but you’re out of Rhino’s at the moment and I’d rather get something on an existing board before designing a whole new one.
Spiral can push a full screen image from uSD in about 2 sec (managed). Just going off other tests I’ve done previously I’m thinking I’d only see 1 or 2 FPS in RLP with 16x16 indexed tiles.
Skewworks, I would like to help you. Just keep in mind I only have a FEZ Cobra with 320x240 screen, so I won’t be able to debug it.
But, I suggest you write the stuff in RLP/C and then let me take a look at the source. Then I can see where it can be optimised. (I have tried 2 compilers: Yagarto and sourcery, and they really s*ck in optimalisation, maybe they just don’t because they are free…)
Try to reduce the number of calls from managed to rlp.
F.e.: one command to load a sprite to RLP memory,
second command to do a move of the sprite with a given movement speed (instead of moving the sprite from managed code with several calls)
In RLP you can run a timer interrupt (GHI seems to only use one hardware timer…) to process the movements…
Thanks Wouter I appreciate it!
I already have RLP code for everything on the Panda II (at home) so I can send it tonight for you to have a look at.
Personally I still think EMX is the way to go. If you could rework your RLP Bitmap sample to render a byte array (height/width passed) to a given X/Y on the screen that’d be a great help towards seeing what the best way to proceed is.
I already make pretty limited calls to the render engine. For example when I move a sprite I only re-render the source tile, the new affected tile (if not the same as source) and the foreground sprite to limit my render calls since the LCD already persists the image for me.
If you want to email me directly it’s thom at my screenname . com; which I think you already have. 
I’ll put you down for a free copy of the IDE for all your help; heck maybe even a device too.
Maybe 565 RGB will be an overkill for this. I’ve seen in the datasheet of the LPC24XX that you can use palettized (1, 2, 4 or 8 BPP) graphics on color TFT’s. There is a 256 entry palette RAM area.
When I think on the old 64K demo times, by using a palette, you can let area’s of the screen fade very fast by just updating the color palette, instead of redrawing the image data. Could be a nice feature 
I’ve run my tests and as I suspected FEZ Touch doesn’t even come close to being fast enough; so I stick with EMX for now.
I’ve thrown together what will be my demo board for now: FEZ Cobra w/ 480x272 LCD & enclosure + Wii Nunchuck & Easy Remote.
This will simulate my board pretty well: Nunchuck provides Joystick & Select/Start buttons while the EasyRemote provides access to 4 additional game buttons. I must say it works rather well too. I have the IR Receive mounted inside the enclosure w/ a small hole drilled on the side and the remote signal gets picked up from the front easily.
FACEPALM So anti-aliased fonts have been supported by NETMF since they released 3.0. You’ll see them in Game Slate; they look fantastic!
New video of Game Slate in action. See the screen saver, RPG/Pacman Hybrid, and Brick Breaker. Everything running of a FEZ Cobra with Wii Nunchuck and EZRemote (we take a bit of a CPU hit using them but it still works well!)
Nice work so far!
Keeps getting better and better…I am still not sure what you mean by “IDE” and would love to see some demo if it.
Impressive!
I’m wondering how you do that scrolling effect between the two games… It looks pretty smooth!
Thanks guys!
@ Wouter the scroll is pretty simple. Paused the engine and created a second BMP w the anti-aliased text. Used a 3rd BMP and looped through X values placing the images accordingly and flushing the 3rd one. I actually had to slow it down a bit w sleeps.
@ Gus it’s a development program like you have for Glide. I’ll throw together a video in the next few days; maybe show off how to make a Brick Breaker in under 5min.
Audio Jack, 2000mAh LiPo, Thumb Joystick, SPDT Slide Switch, LiPo charger, Tactile Buttons w/ Colored Caps, Rechargable Coin Cell Battery, Coin Cell Battery Holder, VS1033D MP3 Decoder, RGB LEDs and ShapeLock are on their way.
I smell a prototype board in the making.
Looks like he had this plan for a very log time but now it is actually happening.
Haha yes! Can’t wait to get the components and make this thing happen!
Looking forward to seeing this happen!
Thanks Mark, I’m really excited about it. And if I can get a decent add-on board design going I’ll send it off to you for production.