Hm. Hardware copy sounds neat but without double buffering, the uses are a bit limited. I am most annoyed by the flickering - therefore I just use the scanline rendering for everything. It's fast enough to scroll all sprites/texts that I draw in any direction anyway.

It would be much more useful if the screen had

- Selectable 8bit palettes (currently it's 2-3-3)
- Double buffering
- Uploadable sprites that can be used as textures (32kb or so would suffice)

Essentially the Double buffering would make the difficult-to-use scanline renderer obsolete - which uses also quite a bit of precious ram. And it would make the hardware commands more attractive again - right now I chose not to use them.


Is there an overview what hardware commands are supported?

The good news is that hardware copy does not result in any flickering or tearing. I am using it for several smooth scrolling scenes in my game intro. I have been conveyer belting in the pixels (you do this simply using a static scanline and copying the screen over itself) and it looks great. Since the full resolution bitmap is almost 1/5 of the total available flash memory on the 328, I have been scaling up all of my full screen images by 4x.

The hardware copy is also very fast. If you do not have delays, you may not even see it.

There is a datasheet for the chip. It has a few other modes which are useful for hardware acceleration of graphics.

There are also several different color modes, including a 16 bit mode. The framebuffer on board is actually 96 x 64 x 16 bit.

One major compliant I have with this display driver is there is no way to read back the frame buffer. This makes it very difficult to efficiently draw graphics on the screen, implement sprites, and use windows. I mitigate this by using SetX() and SetY() and calculating what should be replaced.

There is a datasheet for the chip. It has a few other modes which are useful for hardware acceleration of graphics.

One major compliant I have with this display driver is there is no way to read back the frame buffer. This makes it very difficult to efficiently draw graphics on the screen, implement sprites, and use windows. I mitigate this by using SetX() and SetY() and calculating what should be replaced.

Do you have a link to the datasheet?

As I wrote earlier - right now I am solely trusting my scanline renderer with which I can do quite many sprite renderings with reasonable frame rates. It's is quite optimized so I am fine for most games I was thinking of.

Do you have a link to the datasheet?

As I wrote earlier - right now I am solely trusting my scanline renderer with which I can do quite many sprite renderings with reasonable frame rates. It's is quite optimized so I am fine for most games I was thinking of.

https://www.newhavendisplay.com/app_notes/SSD1331.pdf

Feel free to do what you want. From what I saw earlier, it is working out great for you.

My goal is to post as many details as I can about the hardware to assist others. There are probably a bunch of people asking themselves the same question.

https://www.newhavendisplay.com/app_notes/SSD1331.pdf

This is interesting. The RAM is holding either 16bits or 8bits. And the address for read out can be set. So... if I am not mistaken from the short glance I had, double buffering might be possible by using 8bit mode and doing the page flip by setting the address respectively to the left or right half. If that would work, using the hardware commands for drawing rectangles and such becomes interesting again. I hope that this really works... it might be that the driver doesn't allow doing that - which would be a shame because the memory is available for that it appears. Have to invest more time in the evening.

7.5.3 says that if you are using 8 bit color mode, the 16 bit color is generated into RAM.

In 8.1, it indicates you can read via parallel, but not in serial mode.

I really wonder how true this 'read' condition is. I guess it's worth a shot.

7.5.3 says that if you are using 8 bit color mode, the 16 bit color is generated into RAM.

In 8.1, it indicates you can read via parallel, but not in serial mode.

I really wonder how true this 'read' condition is. I guess it's worth a shot.

Ah yes, that point looks pretty clear to me. Otherwise the logic for the screen would probably be much more complicated. I've been already thinking about the possibilities - like having an offscreen sprite atlas and copying it onto the front buffer. Then however I realized that this technique would also have severe drawbacks: No transparency support. And since sending the data line by line lacks also transparency, there's no solid way to fix it. Too bad they didn't just pack twice or four times more RAM and included some transparency mode. That would make making games quite easy...

I think I'll stick to scanline rendering as it requires less fiddling.

There are btw. two things I've been thinking in the past about regarding compression: Text compression and image compression. I dropped doing an implementation since I didn't see much use (yet) with the stuff I want to do, but by mentioning full screen images, I've been wondering if you would be interested in that.

The text compression I thought of would be quite simple: A script scans a file with all strings you want to use in your game. It determines the character usage and creates a custom compression table of all used characters. Depending on the number of distinct characters it would pack the strings into 4 bit tuples where certain sequences would tell the decompressor that the character needs another 4 bit tuple for unpacking. I wrote a simple Lua script for compression and it pretty much works... it would save 50-70% of storage space for all strings and the decompressor should be rather simple since the format is quite straight forward. It wouldn't however really matter unless you have ~1k of text.
I could finish that work if you are interested.

Another thing was image compression... I didn't follow that since rendering times would decrease significantly, however again, if you are interested, I could look into that direction as well. I think it wouldn't be too much work. I'm just also not sure how "good" it would look like. The idea is similar to DXT/ETC compression - with some adaptions: I would slice an image into a 4x4 or 8x8 block. Each block would have a color palette associated. An image would have 16 color palettes to pick from, 4 colors each. Each pixel would therefore use 2bits plus 4 bits for each 8x8 or 4x4 block for the palette selection. That would mean using 16.5 bytes for each 8x8 block instead of 64 bytes or 4.5 bytes for each 4x4 block instead of 16 bytes. Depending on the image content, it might look ok (of course it's lossy compression, so quality might be problematic ). The decompressor would be still rather simple to implement (read a byte, unpack pixels, load palette colors, translate colors to line pixels). However the compressor would require some more thinking to get "good" quality.

But it's been mostly just ideas. It would be more interesting to make use of that

Yeah - I've been going down the scanline render route exclusively.. I think as long as your scanline renderer is optimised - it seems to be the best bet. I've got tiles & sprites working with this (sprites layered on top of the tiles) - I've also got it working with my Outrun style game.

I'm going to add optional SD card writing in to my renderer, so I can occasionally save "screenshots" to the SD card - could even save multiple screenshots to make little animated gifs for uploading/showing.

I thought about palette based sprite storage, too - perhaps using a palette of 16 colours per sprite/tile (4-bits per pixel)..but I might come to that later, if I feel I'm going to run out of program memory.

Really cool to see some other projects coming together! I'll post my progress after the weekend

Hey all!

I recently bought one of the Tinyduino video game kits at the makers faire in the Bay Area, and I've got to say that everyone here and on CodeBender has given me quite a bit to play with! This is awesome!

I noticed that there was a FlappyBird port for the TinyScreen on CodeBender which had a counter for how many tubes you had flown through, but couldn't find a code for FlappyBird that was TinyJoystick compatible which also had a counter.

So - I merged the two codes

Here is what I ended up with: It loads just fine on what I (and I believe most of us) are using.

https://codebender.cc/sketch:115301

I hope it helps for you guys as well!

Also - a few questions.

I have been unable to get a few programs to run for some unknown reason. I figure most of you are the creators of these games, so maybe you will be able to point me in the right direction I have been able to get most things (flappy bird, mario, ect..) to run fine on the joystick and screen tinyduino package.

The games which I cant get to work are:

Asteroids: https://codebender.cc/sketch:107161#Asteroids%201.ino
Stellar Explorer: https://codebender.cc/sketch:98686#Stellar%20explorer.ino

Asteroids returns: "Could not connect to your device. Make sure that you have connected it properly, that you have selected the correct settings (device type and port) and try again" even though other programs are being uploaded successfully without this problem. Has anyone had this issue?

Stellar Explorer returns: "There was an error compiling." and I can't seem to figure out where it's going wrong.

Thanks for your help in advance!

Asteroids: https://codebender.cc/sketch:107161#Asteroids%201.ino
Stellar Explorer: https://codebender.cc/sketch:98686#Stellar%20explorer.ino

Asteroids returns: "Could not connect to your device. Make sure that you have connected it properly, that you have selected the correct settings (device type and port) and try again" even though other programs are being uploaded successfully without this problem. Has anyone had this issue?

Stellar Explorer returns: "There was an error compiling." and I can't seem to figure out where it's going wrong.

Thanks for your help in advance!

Both are games I've uploaded. Interesting that they don't work for you  - both compile and upload for me without problems. Do they also report errors when you "verify code"?

I sometimes also have trouble with the serial connection. Most often it simply works by unplugging the device and plugging it in again.

Asteroids: https://codebender.cc/sketch:107161#Asteroids%201.ino
Stellar Explorer: https://codebender.cc/sketch:98686#Stellar%20explorer.ino

Asteroids returns: "Could not connect to your device. Make sure that you have connected it properly, that you have selected the correct settings (device type and port) and try again" even though other programs are being uploaded successfully without this problem. Has anyone had this issue?

Stellar Explorer returns: "There was an error compiling." and I can't seem to figure out where it's going wrong.

Thanks for your help in advance!

Both are games I've uploaded. Interesting that they don't work for you  - both compile and upload for me without problems. Do they also report errors when you "verify code"?

I sometimes also have trouble with the serial connection. Most often it simply works by unplugging the device and plugging it in again.

Thanks for the quick response!

I've "Clone and Edit"ed both games and they both return "Verification Successful!" when clicking the Verify Code button; but, for some reason I get the same response every time when trying to run on the arduino. Even after restarting my computer and unplugging/replugging everything back in, it still wont run. Hmm..

I'm running it on Google Chrome; what browser are you using to compile it?

Asteroids: https://codebender.cc/sketch:107161#Asteroids%201.ino
Stellar Explorer: https://codebender.cc/sketch:98686#Stellar%20explorer.ino

Asteroids returns: "Could not connect to your device. Make sure that you have connected it properly, that you have selected the correct settings (device type and port) and try again" even though other programs are being uploaded successfully without this problem. Has anyone had this issue?

Stellar Explorer returns: "There was an error compiling." and I can't seem to figure out where it's going wrong.

Thanks for your help in advance!

Both are games I've uploaded. Interesting that they don't work for you  - both compile and upload for me without problems. Do they also report errors when you "verify code"?

I sometimes also have trouble with the serial connection. Most often it simply works by unplugging the device and plugging it in again.

Thanks for the quick response!

I've "Clone and Edit"ed both games and they both return "Verification Successful!" when clicking the Verify Code button; but, for some reason I get the same response every time when trying to run on the arduino. Even after restarting my computer and unplugging/replugging everything back in, it still wont run. Hmm..

I'm running it on Google Chrome; what browser are you using to compile it?

Ah - it had to do with using Chrome. I switched to Firefox and got them running no problem

Thanks for your help nonetheless, and for writing these awesome games!

I had noticed that someone (maybe on youtube?) had mentioned wanting the left stick to be used to steer and the right stick to be used to shoot. I went ahead and modified your original code to switch these.

The code is posted on: https://codebender.cc/sketch:115627

Hope this is of some use to someone!

I've "Clone and Edit"ed both games and they both return "Verification Successful!" when clicking the Verify Code button; but, for some reason I get the same response every time when trying to run on the arduino. Even after restarting my computer and unplugging/replugging everything back in, it still wont run. Hmm..

I'm running it on Google Chrome; what browser are you using to compile it?

I use firefox. If the verification is successful, it means that the program was created and that it's merely the upload the fails.

Have you checked the com port settings? I used com1 for my device, maybe it's different for yours?

I've "Clone and Edit"ed both games and they both return "Verification Successful!" when clicking the Verify Code button; but, for some reason I get the same response every time when trying to run on the arduino. Even after restarting my computer and unplugging/replugging everything back in, it still wont run. Hmm..

I'm running it on Google Chrome; what browser are you using to compile it?

I use firefox. If the verification is successful, it means that the program was created and that it's merely the upload the fails.

Have you checked the com port settings? I used com1 for my device, maybe it's different for yours?

Ah - it had to do with using Chrome. I switched to Firefox and got them running no problem

Thanks for your help nonetheless, and for writing these awesome games!

I had noticed that someone (maybe on youtube?) had mentioned wanting the left stick to be used to steer and the right stick to be used to shoot. I went ahead and modified your original code to switch these.

The code is posted on: https://codebender.cc/sketch:115627

Hope this is of some use to someone!

Wow, it's been a while since anyone has posted here.

Anyway, I am working on the graphics for a -Tiny Four- game.
I still need to make more sprites and like 2 more background sets. Then maybe we can just re-skin an existing game and call it done

here is some art shots of what the game should look like: