Just a quick message to report that the sideloaded version works fine on my phone (beta isn’t available in Australia on the playstore yet). Someone from Bay12 threw me onto the port.
Only tried it with ascii and the Hodor tileset (as recommended for low spec phones), but they work fine. Standard tileset locks up as expected due to lack of memory. It “might” have worked, but I didn’t wait 30-45 seconds. I’ll try it out. (nope, it doesn’t)
Phone is a Huawei G526-L22, 1.2ghz dual core, 1gb ram, 960x540 res screen, Android version 4.1.2. So really entry level stuff these days. Was when I bought it a couple of years ago too 
Basically, if this will run it with Hodor’s tileset, anything will. I’ll try out a few more 24x24 and 32x32 sets and report on what works and what doesn’t. Might be better to just use Hodor’s as the default set, considering it works on low end phones, but still gives graphics. Saves people saying “it doesn’t work” when it probably does, so you can focus on actual port issues, rather than just tileset memory issues (which many users probably won’t be bothered working out, they’ll just uninstall). Easy is good, and requires no coding. Unless you want to code a tileset manager before launch?
Thanks for porting this. The interface is pretty good considering how fiddly it could be. The only three suggestions I have is to include an escape key on many menus (I’m using hacker’s keyboard, but it would be good for quality of life to just be able to click esc), make touch input menus considerably more transparent (it’s hard to read some things on a low res screen when they’re behind the touch input interface), and to maybe make tileset changes easier for noobs, because this seems to be the only thing holding it back from widespread use (not everyone has a decent file manager/can use one on android phones).
Other than that, great work! Cheers.
though train stuff
((I’m pretty sure it would be a coding issue in loading the tilesets that’s causing the large memory differences. 24x24 and 32x32 shouldn’t cause that big of a difference considering there’s only 1000-2000 fairly small tiles to be loaded. It should be about 1.7mb compared to 3mb for the different resolutions, assuming 1000 tiles with 3 byte (24bit) colour per pixel, doubled if there’s 2000 tiles. But a max of 6mb difference at most, assuming a fair bit o overhead for stuff that’s not just in the pixel data. Maybe it is just hitting the not-sweet-spot for low end 1gb ram phones though, with all the other stuff that has to happen and be loaded to play. Are you sure you’re not throwing the bigger tiles into far too bigger objects/pointers/arrays in code? You’re not using the base tileset image “tile.png” x/y amounts to allocate memory for the 32x32/24x24 tiles themselves or anything are you (I have done this, I’m not accusing you or anything)? Or allocating bit data to bytes, giving an 8x memory allowance to it? That almost perfectly amounts to the memory discrepancies you’ve described between small and large tiles, tens or hundreds of megs instead of a few, which is why I mentioned it, and I did it myself once on a project ages ago. Anyway, as a quick fix, making 24x24 the standard tileset would work, until you get around to something more elegant. ** Totally disregard the base figures given, the standard tileset is huge compared to Hodor’s **))
((it probably can’t be a memory block issue, because a 32x32x4byte tile is 4096. Unless array/pointer headers bounce that just over, so you get 8kb memory blocks allocated to 32x32 tiles, and only 4kb to 24x24 tiles. Depends on what size android memory blocks are. Are smaller tiles halve what bigger tiles are in memory, proportionate to the tileset image’s x/y’s, 8x the expected use, or something completely different? Just trying to nail down where the problem lays.))
((24,576,000 bytes to load the “standard” huge tileset in memory, assuming 4 bytes per pixel in memory (32 bits: 16mil colour RGB (3 bytes, 1 each of 8 bit colour) with alpha channel (1 byte), standard .png file in memory, decompressed). 1,785,856 bytes for Hodor’s 24x24 (which is missing heaps of tiles, it’s not just a down-rezzed replacement set). 38,584,832 bytes for the standard isometric set. So yeah, you’re probably right, it’s just a not-sweet-spot thing. I didn’t realize how uncomprehensive other tilesets were compared to the standard full set. 4000+ 32x32 tiles compared to 1500’ish 24x24 ones. If there’s massively different discrepencies from those figures in memory use, way bigger than pointing to a larger tileset needs, there’s a problem. 5-10mb max difference is normal probably. 8x implies dropping bits into bytes. Double is 4k memory blocks just going over to 8kb allocation. Higher means the array allocation is way off 32x32 or 24x24 or base tile.png x/y’s. Otherwise, it’s fine, just an “Android takes up too much memory and runs too much bloatware on 1gb devices” thing, which you can’t do anything about.))
((just on my table-napkin math, the standard Chesthole 16x16 tileset is only about 6mb in memory, so should load. Especially considering Blockhead’s 32x32 at 11mb in memory does load. So it’s not to do with graphic file x/y dimensions, it’s all to do with the number of tiles. I think.
ps. not talking down to you, just trying to discover the root cause of this problem. 4200’ish 16x16 tiles hangs the game, but a smaller set of tiles that should take up more actual memory for the graphics data doesn’t. In this might lay the solution))
((there’s no memblock.size things in the code is there? Like, you’re not setting minimum file sizes to 64kb in memory or anything are you? Because that’d do it as well, especially with heaps of 1-8kb (in memory, supposedly) tiles. But you might need that for the port considering you’re working with legacy code. You might not either, considering 64x64x4byte (16kb) graphic data is the biggest you’ll probably ever be throwing around at one time, ever. Unless it’s not, because there’s heaps of world generation and memory paging stuff towards it happening. Or you can redefine it as a separate thingy for the graphics only portions of the code that are pointing to it (entirely separate and smaller, but similar to the original). You’d be surprised how much heavy lifting Android will do on the memory end of things, until you explicitly ask for 4180 64kb chunks of memory it doesn’t have (for tiny amounts of actual graphics data), and it just says stop. My pages end here, snap, break… it says))
((Wait…It’s not just something as silly as setting memory management to dynamic, rather than simple or fixed is it? Just thinking… I don’t know the code base. Everything in these double brackets is a train of thought anyway. And if it’s a one or two line code fix for memory management, a couple of checkboxes at compile time, or even a find/find the actual instances you want of it/replace memblock fix, then great. At worst, some tilesets work, at several (more than one) resolutions anyway))
