@DukeZhou could you please help me o recall the name of that pretty old strategy, where you have to develop yourself, explore the world and destroy other settlements? It is called something like Rival. It was popular on Nokia hone 240*320 screens
But the old games were a lot funnier because it worried about more the gameplay rather than "hm, people need to appreciate that realistic grass, and being able to see your legs in a First Person camera"
Well, it doesn't really matter ( unless you do something really dumb in C/C++ ) The CPU can run circles around memory so in most case cutting down the CPU cycles does nothing. It's why HyperThreading actually gives any benefit. Even with C/C++ code a cpu thread ends up waiting on memory most of the time so the cpu can run the other thread "in parallel"
You can even speed up some algorithms working on a stream of data by decompressing the data from LZ78 on the fly. It'll reduce the data's memory footprint and the CPU can decompress faster than memory could provide otherwise.
The stuff I'm dealing with is game trees for an increasingly intractable set of problems, so I'm worried about every operation, and also heat. trying to avoid multiplication/division wherever possible, and I'm even thinking I should avoid simple real numbers (.5, 1.5) by doubling the values (1,3) and only dividing for humans via the GUI
We have to run on individual smartphones with no assumption of connectivity
and the math is so simple, i'm leaning toward bitwise approach when we rewrite the kernel
what I really want to do is build a data structure for the game board, a simple 3^2(3^2) grid initially (classic Sudoku config) where the coordinates are the memory addresses, and the addresses hold a simple set of integers or their inverses.
Even the ARM TDMI7 in the GBA had 1 to 4 cycles multiplication. 32bits * 32bits : if one value is < 8 bits: 1 cycle, <16bits: 2 cycles, < 24bits 3 cycles, and 4 cycles otherwise. lots of newer ARMs do the full 32*32 bits in 1 cycle or less.
I cut this image with photoshop and I obtained a png image. Then I cut this image again because there was too much png background as you can see. But when I import the image in my project, the background is excluded, right?
@Bálint I mean: does Android Studio consider part of the image the empty background too?
In LibGdx you create a Texture containing your nine-patch and then you create a NinePatch from this texture and then you create a NinePatchDrawable from this NinePatch.
An image-button can be used to represent a nine-patch since an image button uses a drawable