Yeah, time to start figuring out the wire harness...
Turns out it's a little trickier than I thought it would be.
As you can see, quite a bit to do before the wire harness is completed - We'll see how it'll turn out once finished!
Thursday, September 20, 2012
Sunday, September 9, 2012
Blazing Saddles!
Sometimes the simplest things are the best.
By doing a few simple changes to the SD card library, I've managed to squeeze out a whopping 3x performance out of the SD card reading! I learned that once the card has been initialized into SPI mode it's possible to raise the clock speed A LOT.
Currently I'm setting the clock speed after init to ten times the speed before init. This means a full frame loading in just 2.5 ms and by doing this, I've increased the overall refresh rate by 15 Hz! The card is now reading approximately 614KB/sec!
The card functions with higher speeds, but data gets corrupted along the way. This is probably because the rise/fall times of the resistors in the SD card circuit needs time to switch. With a faster circuit I'm pretty sure I could squeeze out more!
Nice!
By doing a few simple changes to the SD card library, I've managed to squeeze out a whopping 3x performance out of the SD card reading! I learned that once the card has been initialized into SPI mode it's possible to raise the clock speed A LOT.
Currently I'm setting the clock speed after init to ten times the speed before init. This means a full frame loading in just 2.5 ms and by doing this, I've increased the overall refresh rate by 15 Hz! The card is now reading approximately 614KB/sec!
The card functions with higher speeds, but data gets corrupted along the way. This is probably because the rise/fall times of the resistors in the SD card circuit needs time to switch. With a faster circuit I'm pretty sure I could squeeze out more!
Nice!
Friday, September 7, 2012
That "behind the scenes" stuff...
Been focusing on getting the codebase up to date and functioning as I would like.
Slowly getting there.
For one -
I've redesigned almost the entire code bank from scratch.
So what I've got now is a state machines for each player state along with separate states for the various maintenance views and idle loops. Works like a charm and VERY flexible. I've got most (if not all) of the player states pinned down including bonus, highscore, ball saved, match sequence etc. And of course - multiplayer.
It is at the moment entirely possible to "play" a complete single- or multiplayer game from inserted credit to game over (or highscore), but the actual gameplay logic is not yet started. I've still got some electrics and hardware things to do...
Here's a teaser pic of the current state -
Animated streamed video, multiple layers of text/images, transparency, transitions, effects...
In my humble opinion, I believe this easily matches the quality of commercial pinball DMD rendering!
One guideline I'm following is that there should never be a time where the graphics is just switched on and off - each transition should be handled fluently and text should not just pop into place, but rather fade (but fast) into place. That particular effect creates a modern feel to it and I hope that the overall impression will surpass most peoples expectations!
If there's RAM and flash available when logic is complete, I'm think about inserted some realtime generated water effects onto the display as well - staying true to the Bioshock realm.
I've also spent time creating the tools to burn and generate my SD disc image.
My tool simply recursively loops through all files in a folder and packs the DMD files together into one big file with a reserved 51200 byte space in front for machine settings and highscores. An "anims.h" header file is created and updated so all I need to do is to run a recompile of the Chipkit program and reseat the SD card and the animations are updated.
If only the actual data has changed and not the start/stop sectors no reprogram is needed. This allows for quick and easy previewing in the pinball machine since the SD card library has been recreated to support hot-swapping of cards as well.
I've also written a readdmd.py script that can read directly from the packed image (or a regular DMD file) and show the frame at that position. Really handy when debugging and developing.
Pretty neat!
To compare an older image with the current, you can see that it's much closer to the expected output compared to the old image - which I also commented on in the older entry.
Slowly getting there.
For one -
I've redesigned almost the entire code bank from scratch.
So what I've got now is a state machines for each player state along with separate states for the various maintenance views and idle loops. Works like a charm and VERY flexible. I've got most (if not all) of the player states pinned down including bonus, highscore, ball saved, match sequence etc. And of course - multiplayer.
It is at the moment entirely possible to "play" a complete single- or multiplayer game from inserted credit to game over (or highscore), but the actual gameplay logic is not yet started. I've still got some electrics and hardware things to do...
Here's a teaser pic of the current state -
Animated streamed video, multiple layers of text/images, transparency, transitions, effects...
In my humble opinion, I believe this easily matches the quality of commercial pinball DMD rendering!
One guideline I'm following is that there should never be a time where the graphics is just switched on and off - each transition should be handled fluently and text should not just pop into place, but rather fade (but fast) into place. That particular effect creates a modern feel to it and I hope that the overall impression will surpass most peoples expectations!
If there's RAM and flash available when logic is complete, I'm think about inserted some realtime generated water effects onto the display as well - staying true to the Bioshock realm.
I've also spent time creating the tools to burn and generate my SD disc image.
My tool simply recursively loops through all files in a folder and packs the DMD files together into one big file with a reserved 51200 byte space in front for machine settings and highscores. An "anims.h" header file is created and updated so all I need to do is to run a recompile of the Chipkit program and reseat the SD card and the animations are updated.
If only the actual data has changed and not the start/stop sectors no reprogram is needed. This allows for quick and easy previewing in the pinball machine since the SD card library has been recreated to support hot-swapping of cards as well.
I've also written a readdmd.py script that can read directly from the packed image (or a regular DMD file) and show the frame at that position. Really handy when debugging and developing.
Pretty neat!
To compare an older image with the current, you can see that it's much closer to the expected output compared to the old image - which I also commented on in the older entry.
2) Old version: All colors were to washed out, not enough contrast. |
3) New version: Nice contrast between high and lows. Taken at an angle, but with a nice red color and... |
4) ...when compared to the source image, pretty close. This means I get more or less an accurate preview on the file before 'burning' the SD-image. |
Saturday, September 1, 2012
Shaven Even!
I managed to shave off additional time from the rendering today.
Took a full rewrite of the display code, but nevertheless it gained a 13% increase in speed.
Now I'm down to almost exactly 7 ms per frame which gives us roughly 1 ms per color and around 4 microseconds per pixel.
For comparison - just toggling a pin with the Chipkit core library function digitalWrite() takes almost 16 microseconds!
If I could live with a less vivid display I could shave of an additional 3 ms per frame, but I need that time to allow the pixels to fully illuminate (exponential delay ranging from 0 to 42 microseconds between each row). So I think I've come as far as I can get without sacrificing quality!
Unless.... interrupts to the rescue?
I guess now's a good time to mention that the rendering is also looking better than ever with a nice big contrast between the different shades? I even avoided the recommended "1 microsecond delay" between the two row clock updates without adding any ghosting. Sweet!
Took a full rewrite of the display code, but nevertheless it gained a 13% increase in speed.
Now I'm down to almost exactly 7 ms per frame which gives us roughly 1 ms per color and around 4 microseconds per pixel.
For comparison - just toggling a pin with the Chipkit core library function digitalWrite() takes almost 16 microseconds!
If I could live with a less vivid display I could shave of an additional 3 ms per frame, but I need that time to allow the pixels to fully illuminate (exponential delay ranging from 0 to 42 microseconds between each row). So I think I've come as far as I can get without sacrificing quality!
Unless.... interrupts to the rescue?
I guess now's a good time to mention that the rendering is also looking better than ever with a nice big contrast between the different shades? I even avoided the recommended "1 microsecond delay" between the two row clock updates without adding any ghosting. Sweet!
Subscribe to:
Posts (Atom)