Anytime. If you need help formatting, editting or translating a post before you submit it, send me a private message. Your post are looking great though. NOTE I only can speak and read english 
And, awesome job getting the project on Github. Thanks for adding to the “Official” Game List as well 
!
Wow! This is actually REALLY smooth! Impressive.
Haven’t been able to get this (or Tiny Depth) to upload on my production Arduboy using Windows 7 on a 64-bit PC. Tried two different machines with the same basic setup. Interested to hear when the tool is updated. Thanks!
Only these games? If you could record the error messages or desribe what’s happening in another thread we can for sure try to help you out but don’t wanna hijack this thread 
reset program fixed. c# popular bug.
compiler setting changed x86 from Any CPU.
ecs liva mini 64bit pc tested.
IDE is COM5. bat is VAL2=COM5, VAL4=COM6.
arudino IDE have good log.
シリアルポート「COM5」を1200bpsで開いて閉じる事によって、リセットを行っています。
PORTS {COM5, } / {} => {}
PORTS {} / {COM6, } => {COM6, }
Found upload port: COM6
avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
Using Port : COM6
but…i dont have new arduboy. this program no run. sry.
@bateske:
ty arduboy product! i enjoy many times.
im very happy. 
I’ve fixed the Arduboy 1.0 problems with this game. My pull request is currently pending Akkera102’s approval here: https://github.com/akkera102/03_tiny_2048/pull/1
Just to clarify, with the linked changes, the 2048 game now compiles for either Arduboy Devkit or Arduboy 1.0; so feel free to pull from that branch even on Arduboy Devkit.
Oh, and the same changes should also apply to Akkera102’s other games, but I haven’t tested them yet.
Just a note for both you and @akkera102. You shouldn’t be defining or using SND_PIN2 (A3), the second speaker pin, on the DevKit (It’s OK to use both on the production Arduboy 1.0).
This is because on the DevKit the two speaker pins are shorted together. If you make them both outputs, and then one goes high while the other is low, it could damage the processor chip. On the DevKit, Pin A3 should be set as an input or just not touched (It will default to input mode).
A discussion of this is here, including some of the preceding and following comments.
perfect source code and makefile!
thank you awesome request!
i will change my 2048.
and your name will add readme.txt
2048 dont use sound.
but another my game use it.
so snd.c is existence.
another my game will change your proposal too.
pls wait bit.
my country time is 23:27.
just i must sleep lol
thank you advice.
my project will edit it too.
I did see your post about doing some damage putting a signal to the wrong pins. @JO3RI might be able to explain more. The music tracker that he did comes with a disclaimer about this. There might be a way to avoid that behavior, but I haven’t looked into it.
Here is the warning from the thread.
Full thread.
http://community.arduboy.com/t/demoscene-the-first-demo-with-4-channel-tracker-music/1081
The arduboy uses 2 PINS for sound. The DEVKIT uses 2 different PINS for sound. One of Arduboys sound PINS happen to be a button PIN on the DEVKIT.
The type of PINS used on the DEVKIT are NOT capable of doing tracker music (technical limitations ). So for the Arduboy, it was decided to use other PINS.
With the demo I wanted to give people with a DEVKIT a change of hearing the tracker music too. The only option, was to output the music on the capable PINS (the one of the right button on the DEVKIT). So if you connect a speaker on the right button on the DEVKIT you hear the tracker music. BUT if you would press that button you short circuit that PIN to ground. NOT GOOD ! hence my warning.
That said, a DEVKIT will never be able to play tracker music in a game using all buttons without hacking it (which is very hard)
Many thanks comment.
my own thinking… warning dont fear. fear is nothing.
because i and many developer tested tunes.ino(old arduboy library sample).
it can hear 1ch and 2ch. but devkit not destory.
i dont hear the information that was destory in the community.
but! warning is required. one’s own risk.
future, my library will steal arduboy source code.
// fire up audio pins
#ifdef ARDUBOY_10
pinMode(PIN_SPEAKER_1, OUTPUT);
pinMode(PIN_SPEAKER_2, OUTPUT);
#else
pinMode(PIN_SPEAKER_1, OUTPUT);
#endif
SPEAKER_2 no use. only it use 1.0.
only my 2048. fix finish.
added new 1.0 hex file. bat and makefile default setting is 1.0.
define and ifdef… i changed bit my coding style.
pls dont angry. hehehe 
sound probrem result:
#if defined(ARDUBOY_10)
pinMode(SND_PIN2, OUTPUT);
Snd.ch[1].pPinPort = portOutputRegister(digitalPinToPort(SND_PIN2));
Snd.ch[1].pinMask = digitalPinToBitMask(SND_PIN2);
#endif
and
#if defined(ARDUBOY_10)
*Snd.ch[1].pPinPort ^= Snd.ch[1].pinMask;
#endif
https://github.com/akkera102/03_tiny_2048/blob/master/src/lib/snd.cpp
The information about the DevKit speaker pins being shorted is not widely reported, but it was given in the DevKit Hardware topic under Piezo Speaker:
Two pins, A2 and A3 directly drive a piezoelectric element inside of a
small black plastic housing. Caution there is no circuit protection
these pins: Theoretically there could be some problems with driving both
pins as outputs, we suggest configuring one pin to input. In practice
this has not caused any issues to date but please comment if you have
any issues!
Unfortunately, the Arduboy library and some of the included examples still have this problem. Fortunately, the ATmega32u4 processor used in the DevKit (and production Arduboy) seems to be robust enough not to be damaged by it. But in any case, it’s not a good idea to do it. Also, it’s good that this isn’t a problem with the production Arduboy.
In the next day or so, I plan to make fixes to the Arduino library V1.2 code to address this problem.
i more agree too.
after a few months. 1.0 is spread enough.
normal of development will change 1.0 from devkit.
i think modify dont need seriously level.
This is my new favorite Arduboy game. Hands down. So, thank you!
Game clear! 1540 lol I’m gunna have to dig into your code and play around with this thanks for your work!
Does that mean this should work ok on the production devices now too?