Clone of clones. My first game! :D

Game/Demo Showcase
#1

My first release! Not as fancy as I wanted it to be; but hey, it’s my first game and certainly won’t be the last. Will put it up on the AppStore once I’ve saved up for the hefty dev fee.

Let me know what you think! :smiley:

https://play.google.com/store/apps/details?id=com.jonah1nine.ColourGame

1 Like
#2

congrats on the release!!

#3

This could seriously be an interesting game. UI looks simple and good.
I feel colors mixing is intuitive but not for many people. Anyways, this game can be good time pass :smile:

Congrats

#4

I was just thinking of writing a three’s inspired colour mixing game. Good idea :smile:

#5

Thanks guys! Hope you score a point. :stuck_out_tongue:

@JonB You can always improve on the idea. Go for it! :wink:

#6

Your listing looks beautiful. How did you get the binary down to just 2.4M? Even my first builds were about 7M.
I’ll pass on improving it. Been done, hard to beat etc. Plenty more things for me to match one day.

#7

Actually it is 4.5MBytes. 2.4MB is just the compressed APK.

Did you (dead) stripped all your binaries and libs you linked with? Linking with non stripped libs can result in a fat binary.

#8

I’m not sure how I ended up with that size and I did not do anything special really. I developed my game in cocos2d-x v3.0 using Visual Studio and export my project using Eclipse to produce the APK.

#9

Could you post about it? I am also very interested how to compress and link stripped binaries to the project!

#10

Compression is done by the APK packager. APK is just an archive with compression, like a zip archive.

The compiler and linker flags differ a lot between compilers/linker. E.g. on gcc you have to use special flags and procedures. There are also the binutils, which can be used to strip symbols and dead code.

Different flags for optimizing your code are available. E.g. optimizing for size, instead for speed.

Read about the different options for different compilers here(it’s a little dated, but you can still apply it to new compiler versions). To get the best out of it, you have to read the compiler/linker manuals.

There is also a discussion about common used compiler flags here:
https://news.ycombinator.com/item?id=7371806

Especially this post:
https://news.ycombinator.com/item?id=7374911

Basically you optimize for size with the option -Os and stripping all symbols and dead code form your binaries to get the smallest binary possible.
clang is used in combination with LLVM to analyze code and strip dead code.
http://llvm.org/docs/LinkTimeOptimization.html

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options

http://clang.llvm.org/docs/UsersManual.html
http://llvm.org/docs/CommandGuide/opt.html

You really have to dig into compilers and linkers to get the most out of it.

2 Likes
#11

I’ve tried putting

LOCAL_CPPFLAGS += -Os -fdata-sections -ffunction-sections
LOCAL_LDFLAGS += -Wl,–gc-sections -dead_strip

in Android.mk and shaved a massive 200kb off a 14.7MB apk! Apparently local linker flags have no effect on static units. So I subbed gnustl shared in which made 100kb bigger than 14.7MB. I didn’t get as far as making cocos2d-x recompile as shared unit. I’d better off hacking away at my original content vs library boiler plate ratio, I think.

#12

You could also strip the symbols with -Wl,-s. You only strip dead code, and maybe there was no such code. The 200kb are cause of -Os.

Don’t compare the .apk file, as it is just a zip archive. Compare the .so file inside it, which is your binary.

What is your binary/asset ratio? When assets take >100MB, it does not matter, if your binary is 7MB or 2MB.

If you want speed and tiny binaries, there is no way around ASM. The problem is, the OS, kernels, binary formats for executable files and software are just bloatware. It contains legacy stuff from the 70s. Even the hardware is carrying a lot it.

Compare the sizes(from here http://supp.iar.com/Support/?Note=11872), to true bare metal programming and software:

Hello World - Plain C
  8 858 bytes of readonly  code memory
     54 bytes of readonly  data memory
  8 712 bytes of readwrite data memory

Hello World - Embedded C++
   8 928 bytes of readonly  code memory
     252 bytes of readonly  data memory
  42 644 bytes of readwrite data memory

Hello World - Full C++ with exceptions
  21 963 bytes of readonly  code memory
   2 637 bytes of readonly  data memory
  42 680 bytes of readwrite data memory

If you code a “Hello World” in ASM for a true 64Bit OS written entirely in ASM, you will get this numbers:

30 byte binary. The actual code compiles to 18 bytes and the string is 12 bytes.

Yes, 30bytes vs. at least 17kBytes.

So you may see, that caring for binary size may not be worth it, if the system you are using/targeting is just bloatware itself.

1 Like