| Name: | Viobyte |
|---|---|
| Version: | 0.0.0 |
| Author: | Dennis Payne |
| License: | GPLv3 |
| Operating System: | Linux and TinyScreen/TinyDuino and TinyArcade |
| Website: | http://identicalsoftware.com/viobyte/ |
TinyArcade
I learned of the TinyArcade when it was launched on kickstarter. It looked interesting but not enough to convince me to back it. Since playing with the TinyScreen Video Game Kit, I debated picking up the TinyArcade. To my surprise, TinyCircuits played my viobyte game and liked it. They offered to send me a TinyArcade if I would port it to that platform.
The TinyArcade came as a DIY kit. The assembly was pretty easy. The one thing that slowed me down was the stickers. There was no indication of which stickers go where. Some of the stickers seemed a little big for the pieces. Eventually I decided to forgo the stickers for the time being. The product looked great either way. Work on porting Viobyte started the next day.
Quick and Dirty Port
The Arduino IDE included with Feodra 26 didn't support the TinyArcade device. Fedora 27 did but it failed to compile for the TinyScreen Video Game Kit. Rather than fight with it, I ran Fedora 27 in a virtual machine and compiled viobyte to a binary file which I could then transfer to the SD card.
TinyCurcuits had a TinyArcade.h header file which they recommend using. The file included three functions, arcadeInit, checkButton, and checkJoystick. There were two versions of the hardware so far. The first interation had an analog joystick. The checkJoystick function handles the difference between the two versions. While this is great, I suspected they wanted to keep the code to a single file. Unfortunately this meant you can only include the file once. Not a big deal most of the time as you often have only have the initialization and input code in a single place.
The initial port of Viobyte wasn't checked into git. I decided to simply hack the code to support the TinyArcade. It was changed to call the arcadeInit function and use the two functions to get input. By the end of one night, viobyte started eating dots on the TinyArcade. The game worked but wasn't as easy as TinyScreen Video Kit.
Joystick Problem
The TinyArcade's viobyte had difficulty making a turn if it didn't hit a wall. The problem was due to how the joystick worked. The TinyScreen Video Game Kit detected the diagonal easily. TinyArcade did not. To make a turn when you didn't hit a wall, viobyte allowed you push diagonally and turn when it was available.
Pacman worked slightly differently than viobyte. If you pushed in a direction, it would continue in that direction until you push in a different direction and it was possible to go that way.
It wasn't hard to implement a similar control scheme for viobyte. I needed to track current direction viobyte is traveling. If the player pushes the joystick in the opposite direction immediately change direction. If the player pushes to either perpendicular direction, check to see if it is possible to go that way. After the player's direction is determined, viobyte is moved.
The Real Port
For a maintainable port, I initially modified the TinyArcade.h to include support for the TinyScreen Video Game Kit. I introduced a new TinyConfig.h which would specify the desired system. I didn't get very far before I decided it was the wrong approach. It complicated the code and would require me to update it for any future change made by TinyCircuits.
Instead I settled with keeping the TinyArcade.h in it original form. I created TinyConfig.h and TinyGameKit.h. The first had a define to determine which platform you are targeting plus some additional defines. The second implemented the same functions as TinyArcade.h.
The functions provided for input provided a bit of a question for the older platform. The TinyScreen Video Game Kit retrieved joystick and button information in a single call. I didn't really want to check the once when checkButton is called and again with checkJoystick. I settled on reading it once and recording what data was used. If you called checkJoystick, it would see if it had joystick data already. If not it would call readJoystickButtons to retrieve all the input data. It then returned the data and marked the joystick as used. Two calls to checkJoystick would cause the data to be read twice but a call to checkJoystick and checkButtons would only cause one read. It's possible with this setup to get out of synch where each frame get one input from the last frame and new input for the second call. To prevent this always call the same one first. If you only need data from the function you call second, you need to call the other one first and ignore it's results.
Video
The game selection program on the TinyArcade displays a tsv file for the game if it is found in the same directory with the same name. The tsv format is simply the screen written to a file using 16 bit pixels. There is no audio, no compression, and no framerate control. This made sense for the original TinyScreen as the CPU was slow and audio was not common.
zet23t's simulator from which tinyscreensim forked had the ability to record a tsv file. It was commented out by default. I enabled it and recorded viobyte. The TinyArcade selection program showed a black screen still. I thought maybe the file size might be a problem but smaller files didn't make a difference.
When I looked into the simulator I discovered the true cause. The simulator wrote the content of the rawFrameBuffer to the tsv file. The rawFrameBuffer was populated correctly when using 16 bit pixels but 8 bit pixels just put zero in the buffer.
The tsv file generated correctly after the fix. The TinyArcade showed a very slow moving game. I halved the number of frame generated to create a more active video. Now anyone looking at viobyte should be able to recognize the type of game.
Comments
No comments yet.