Author Topic: Android Version  (Read 4313 times)

Offline Taerzik

  • Zombie Food
  • *
  • Posts: 6
    • View Profile
    • I'm fixing the world. Would you like to help?
Re: Android Version
« Reply #75 on: February 27, 2017, 05:36:05 AM »
A1,

I solved my own problem, sort of.

Going on a hunch from others' issues here, I removed the graphics folder from my tablet and that allowed the app to launch fairly quicky.

That doesn't quite explain what's going on though.
My phone's CDDA instillation seems to be loading with graphics now, while it was initially hanging at the Z screen.
But the tablet's installation won't load unless I remove or rename the graphics files.

I've tried launching CDDA with GFX file present and then looking at memory usage but it doesn't appear to be going over a few MB during startup.
This makes me think that the problem isn't the tiles themselves but some kind of problem with the loading process... unless there's a corrupt file in there that is simply causing the launch to hang.

I would really like to be able to have graphics on my tablet, preferrably iso.,  but it's only got a gig of memory total and I haven't figured out how to get a swap file working yet to work around what might be a memory shortage.
Ask me about:
Machine Intelligence
Robotics
3D Printing
Threat Analysis & Preparation

Offline a1studmuffin

  • Zombie Food
  • *
  • Posts: 32
    • View Profile
Re: Android Version
« Reply #76 on: February 28, 2017, 08:02:14 AM »
Heya, glad you've sort-of worked around it. I'm pretty sure this is an out-of-memory issue if you've only got 1GB RAM on your devices. What are the models + specs + android versions of your phone + tablet?

(Also, note to self - try and detect out of memory and display a proper message!)

On first run, after it installs the game data, the game will sit on the Z screen for a good 10-30 seconds (depending on how slow your device is) before launching. Could you have mistaken that for a freeze on your phone perhaps? That would explain why it worked on successive loads. (I should probably put a "LOADING" indicator on that screen as well as the Z.)

The game uses around 350-450MB (it might peak slightly higher than this too during load), and most Android devices use at least half a gig for the OS and other bits and pieces, so it's definitely a squeeze and is probably failing to load tiles during startup... that's why renaming the gfx folder fixes the issue, as it forces the game to skip loading tiles, thus reducing overall memory needed to start the game.

I was chatting with someone over email and they managed to get the Hoder's tileset working when ChestHole wouldn't, so perhaps that's worth a shot. This was on a 2GB device too, so I'm wondering if some Android devices have issues loading the large tileset textures into memory... perhaps there's a 4096/8192 limit on some of them...

Offline danabnormal

  • Zombie Food
  • *
  • Posts: 2
    • View Profile
Re: Android Version
« Reply #77 on: March 02, 2017, 03:14:17 AM »
Awesome work! I'm interested though on whether you're able to use tilesets on your HTC One M8, as I've had to rename the graphics folder to get the game to launch.

Also, how feasible would it be to be able to repoint the world and character folders to another location? I have CDDA as a folder in Google Drive, so the thought of being able to continue games both on the move and on my PC makes me giddy!

Offline Taerzik

  • Zombie Food
  • *
  • Posts: 6
    • View Profile
    • I'm fixing the world. Would you like to help?
Re: Android Version
« Reply #78 on: March 03, 2017, 03:27:52 AM »
Dan that's a really sharp idea there! I love it!
Ask me about:
Machine Intelligence
Robotics
3D Printing
Threat Analysis & Preparation

Offline a1studmuffin

  • Zombie Food
  • *
  • Posts: 32
    • View Profile
Re: Android Version
« Reply #79 on: March 06, 2017, 05:17:31 AM »
danabnormal: That's interesting you're unable to run with tiles on an HTC One M8. Perhaps you're running some software that's taking up more memory than I am? I'm running Cyanongenmod 14.1 (Android 7) which might also make a difference.

I'm wondering if I should default the game to not using tiles at all, since Android devices tend to have way less memory than PCs. This would mean more people would be able to launch the game on low-spec devices. They could try turning tiles on, but if it fails, they can just clear program data and relaunch again, try a different tileset etc. Might be a simpler flow for users than messing with the gfx folder?

RE: CDDA synced over Google Drive/Dropbox, I see no reason why it wouldn't work, and I've been quietly waiting for someone to try it! :D I think you would have good luck with something like Autosync Dropbox/Google Drive, assuming they work reliably (I haven't tested either of them, but all the reviews seem positive):

Autosync Dropbox: https://play.google.com/store/apps/details?id=com.ttxapps.dropsync&hl=en
Autosync Drive: https://play.google.com/store/apps/details?id=com.ttxapps.drivesync&hl=en

The only thing to be aware of is that CDDA Android adds some extra json data to the save games to remember the touch shortcuts for various screens. These will be ignored (and overwritten) by the desktop version, so it means if you played on Android, then on desktop, then on Android again, the touch shortcuts would reset. It's probably not a huge deal, but worth noting. If this becomes a heavily used flow by players, I could look at moving the shortcuts into their own separate json file to avoid this issue.

Offline danabnormal

  • Zombie Food
  • *
  • Posts: 2
    • View Profile
Re: Android Version
« Reply #80 on: March 07, 2017, 10:55:22 AM »
Yeah I'm running the 'normal' HTC OS (Android 6) on mine. If you want anything specific let me know. Also tried it on the Nexus 7, same thing.

Could you do a brute force check? On startup 'if (freemem < 500mb) {doascii();} else {dotiles();}' or something like that? Would make it a bit more fluid for people who sometimes have lots open and sometimes don't, although ofcourse that could also be toggleable in the android settings menu.

I'll have a crack with the PC sync thing then! Should prove '!FUN!'.

Interesting you mention the shortcuts in the save file - any chance they could NOT be stored there?! I'm a noob to the game and remembering the shortcuts is a pain. As I die extremely often having the shortcuts persist across games means I could bring the old muscle memory in to play!

Awesome work though, I've not had a single issue with it (and the better half is hooked now as well!) - any plans on releasing the source yet?

Offline a1studmuffin

  • Zombie Food
  • *
  • Posts: 32
    • View Profile
Re: Android Version
« Reply #81 on: March 07, 2017, 11:19:25 AM »
Not sure how reliable the brute force thing would be since I don't know the exact amount of memory it would use, but someone on reddit suggested simply asking the user on startup if it's a first run.

RE: shortcuts, yeah fair enough - I'll make a note to move them into another file, probably should have done that in the first place. :)

Source code will eventually appear on GitHub, though I'm waiting to release the first official version before doing that. I've had less time than I expected in the past few weeks but will eventually get around to it, promise! :)

Offline sambojin

  • Zombie Food
  • *
  • Posts: 2
    • View Profile
Re: Android Version
« Reply #82 on: March 12, 2017, 11:14:52 PM »
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.






((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))
« Last Edit: March 13, 2017, 09:59:45 AM by sambojin »

Offline sambojin

  • Zombie Food
  • *
  • Posts: 2
    • View Profile
Re: Android Version
« Reply #83 on: March 13, 2017, 05:18:51 AM »
On my device, a cheap 1gb Huawei:
(these are all being run in "clear" memory, shutting down everything with android's task killer, and running ES Task Manager to clear memory straight afterwards. About 280-380mb free reported memory usually, depending on the alignment of the stars apparently. All that get to the initial menu screen are run with a "Play Now!" scenario, and a few steps of running around, just to make sure it actually works)

Chesthole 32, no.
Chesthole 16, no. (? good to see scope of problem. Is it number of tiles, not overall size?)
Chesthole, no.
Deon's, Yes! (fairly nice large tiles on a small screen, 32x32?)
Mshocks 24, no.
Hodor, Yes! (our "standard" for crap phones I guess)
Hitbutton_iso, no.
Tsutiles, Yes! (weird, my phone reported 180mb free before I ran it, but whatever android does in the background, it still worked. Simple set, but functional)
Blockhead, YES! (another cut down 32x32 set. Nice. Even more complete than Deon's too! But not as pretty)
Thuztor, Yes! (very simplified 24x24?)


((I'll keep editing this post))

((I'll finish 'em off later, but there's some 24's and 32's that work, so all good. Blockhead is looking like a good 32x32 standard, just because it loads, and is relatively complete, even if it isn't that pretty. I'm a big fan of Deon's work from Dwarf Fortress though, because it looks good.....))
« Last Edit: March 13, 2017, 06:52:21 AM by sambojin »

Offline Taerzik

  • Zombie Food
  • *
  • Posts: 6
    • View Profile
    • I'm fixing the world. Would you like to help?
Re: Android Version
« Reply #84 on: March 14, 2017, 05:19:18 AM »
A1,

I've been poking at my android installs off and on, hoping to get chesthole_iso to work. That hasn't happened yet but here is what has:

After uninstalling and reinstalling on my 1GB phone, CDDA launched with the Hoder's tiles. I was able to 'Play Now' but after a restart the app refuses to go past the Z screen, though I'm sure disabling that gfx folder would get going again.
I tried the same thing with my 1GB tablet but I can't get it past the Z screen at all. Memory shortage again, I'm sure.

Now, here's the wierd part...
The phone is low on memory usually, yet it launch CDDA with tiles on the first try, without me having to persuade it to do so by force closing services.
The tablet however has alot more free memory, over 300 MB, yet it refuses to launch with tiles entirely.

Ask me about:
Machine Intelligence
Robotics
3D Printing
Threat Analysis & Preparation

Offline hatcher

  • Zombie Food
  • *
  • Posts: 15
    • View Profile
Re: Android Version
« Reply #85 on: March 20, 2017, 03:56:13 PM »
Memory shortage again, I'm sure.

Now, here's the wierd part...
The phone is low on memory usually, yet it launch CDDA with tiles on the first try, without me having to persuade it to do so by force closing services.
The tablet however has alot more free memory, over 300 MB, yet it refuses to launch with tiles entirely.

It isn't a out of memory crash, unless you tried to launch Cata on unrooted device drowned under tons of active processes and Google shit. Because its working pretty well on my <500mb rooted budget smartphone.

Offline a1studmuffin

  • Zombie Food
  • *
  • Posts: 32
    • View Profile
Re: Android Version
« Reply #86 on: March 21, 2017, 05:44:53 AM »
sambojin: Thanks for the info. Regarding your 3 suggestions:

- You can simulate ESC with a double-tap at any time. I could also add a shortcut for ESC, but I was trying to avoid the amount of on-screen buttons since there's so many already. (Take a look at the advanced inventory for example, haha.) If you find this useful though I'm happy to add it as an option.
- You can adjust the shortcuts background transparency under the Android options. There's also a setting to prevent it from overlapping with the game screen.
- I'm going to turn "Use tiles" off by default in the next version, so people can at least get into the game on the widest range of devices and can start experimenting with tilesets. At the moment it's a bit crazy as so many bug reports I'm getting are just out of memory issues. This way people can experiment with tilesets, but if it all goes bad they can just uninstall + reinstall or clear game data and it will run again by default.

Also RE: memory spikes, I've looked into it briefly and the way the tiles are created is not optimised for low memory scenarios, which is completely unsurprising considering this is primarily a modern desktop PC game. As you mention tilesets can be rather large, and the game will load in the tileset as an SDL surface, then duplicate it for shadow, night vision and overexposed variations. It then create even more textures for the 4 variations of each individual tile by slicing from these large surfaces into smaller ones (32x32 etc), then throws the huge surfaces away. Also I think SDL does even more allocations when creating textures from surfaces. So you can see how it will spike quite a bit higher than that temporarily. :) I don't believe there are any minimum memory block allocation/alignment issues going on, though it's possible - the NDK is a fun beast to play with. :)

Some quick back of the napkin math: Chesthole32's tiles.png is 512x12000 @ 4 bytes per pixel in memory = 23.4MB. Multiply that by 4 for the shadow/nightvision/overexposed variations = 93.8MB. Multiply that by 2 for the SDL surface to texture conversion (not 100% sure about this though) = 187.5MB. Multiply that by 2 for the creation of individual tile textures from the large textures in memory = 375MB. After that, it will throw away the large textures so will drop down to 187.5MB again. Roughly. When you're dealing with such large allocations it's tricky to pin down exactly how much memory is available on the heap, since while enough memory might be free in total, there's no guarantees a sequential block of 23.4MB is available, especially if you're starting to get low on memory and lots of other processes are running. So it's all a bit fuzzy on Android, especially since so many people have custom apps/services running in the background, so I don't think it's possible to ever say "if you have XMB of memory free, it will run on the device".

Offline Kevin Granade

  • Administrator
  • Survivor
  • *****
  • Posts: 5235
  • I code dead people.
    • View Profile
Re: Android Version
« Reply #87 on: March 21, 2017, 04:37:59 PM »
Aah yes the natural enemies caching and memory meet at last.  We just keep layering caching on everything (as you say, typical for desktop), so it's no surprise we hit some limits.  There are a number of areas where we can reduce memory footprint in general, and some of those graphics caches could be made optional, so there are some things we can do to head this off.

Have you looked at anything outside the tilesset overhead?  It sounds like that's going to dominate (quick check, run with and without tiles and compare), but there may be some significant bits in the main game code as well.
Its like a fun family cookout, except your family is burning in flames while trying to eat you. -secretfire
I'm more excited than a survivor on meth and toast'ems. -Nighthawk
The the giant wasp is slammed through the zombie brute!

Offline sidav

  • Zombie Food
  • *
  • Posts: 1
    • View Profile
Re: Android Version
« Reply #88 on: March 24, 2017, 07:45:11 AM »
Thanks for the great port!
I've got only one issue so far: my phone gets noticeably warmer when I'm ingame. It occurs even in main menu (I've spent some time in settings on the first launch), so I assume it is somewhat related to the video/rendering part. It there any way to enable the FPS cap or something? It would be great in terms of battery consumption too...
Are there any other ways to make the game less energy-demanding? I'm playing in ASCII only, if that matters.

Offline Taerzik

  • Zombie Food
  • *
  • Posts: 6
    • View Profile
    • I'm fixing the world. Would you like to help?
Re: Android Version
« Reply #89 on: March 25, 2017, 09:09:28 PM »
So, question, would a lightweight tile set help us load with tiles more reliably?
Sometimes I can get it to work with Hoder's, others, not so much.
If it would help, I'm thinking of an isometric set with fewer overall tiles and probably eliminate layering for the player.

I've read that the CDDA Tile Set Studio is a great tool but the link in first thread of the post is broken so if anyone has a link to a working download, I'd love to get a copy.
Ask me about:
Machine Intelligence
Robotics
3D Printing
Threat Analysis & Preparation