Android Version


#81

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?


#82

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. :slight_smile:

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! :slight_smile:


#83

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 :slight_smile:

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))


#84

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…))


#85

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.


#86

[quote=“Taerzik, post:85, topic:13348”]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.[/quote]

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.


#87

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. :slight_smile: 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. :slight_smile:

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”.


#88

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.


#89

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.


#90

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.


#91

On an asus zenfone with 4 gigs ram (1.8 available) I recently updated the xotto tileset and pk’s rebalance mod. During the Z loading screen I get kicked to my home screen. I also deleted un-used tile sets. Phone becomes very sluggish to respond, after closing cata it’s back to normal in about a minute of two.


#92

Hi, could you tell me when the update to last build CDDA? And can not you make a special button to clean the buttons from below, because on my phone this damn swipe does not work :smiley:


#93

a1studmuffin. Hi. Theres a bunch of new features since your last update, so, could you release a new version based on a latest experimental build? Or tell how to exactly compile it for overwriting. Thx.

By the way, i’d figure it out what’s wrong with my installation crash. You was right, it is a tiles issue. More precisely, i deleted all tiles folders, but didn’t – png’s in the /gfx. So, game didn’t find default tiles, then tried to use those garbage tile png’s and this caused the launch crash. So lame facepalm.jpg


#94

Installing on a xiaomi phone. Gonna check it out.
Edit: Damn, this is so awesome!


#95

[quote=“snow dwarf, post:94, topic:13348”]Installing on a xiaomi phone. Gonna check it out.
Edit: Damn, this is so awesome![/quote]

Snow dwarf, does it work fine on Xiaomi?
Was thinking of maybe trying a Xiaomi phone at some point, but I got a bit cautious as I understand it modifies the android skin quite a bit (I realize it might be just superficial).


#96

[quote=“Aqma, post:95, topic:13348”][quote=“snow dwarf, post:94, topic:13348”]Installing on a xiaomi phone. Gonna check it out.
Edit: Damn, this is so awesome![/quote]

Snow dwarf, does it work fine on Xiaomi?
Was thinking of maybe trying a Xiaomi phone at some point, but I got a bit cautious as I understand it modifies the android skin quite a bit (I realize it might be just superficial).[/quote]
It does worj on xiaomi. If you plan on getting the phone outside of China, you should be alright with installing apps, however it does have a total skin overhaul. I bought the phone in China and had to do a lot of digging in the memory, before I could install apss from Google.


#97

Thank you! I’ll keep it as an option when I replace my oneplus.


#98

Hey A1.

I’ve gotten the port to load with Chesthole’s standard set on a regular basis on my 1gig mem phone. Loading takes a full minute or so but I like these tiles.
I have had it crash once or twice on chesthole but that’s all.


#99

Hi Michael I created this account for showing support for your work. CDDA desserve for a while an android port ( and a new stable btw, not even feature freeze today, the process can take a long time ) and Im genetically proud a human accomplished this.
I run it with a LG-K350n ( sold under nickname LG K8 ) with no problem ( 4x1.3GHz proc and 1.5Go RAM ) and its a low end phone.
I know you read my letter to santa ( I know it ) altought I would never expect to this happened before a new stable, nor with tileset, external keyboard, mods…
I was also impressed by the “autosave on lose focus” feature, and much pleased that I can access/transfert files and folders without a rooted phone.

I encountered some problems, altought i suppose most of them come from experimental build side ( exemple : some food in box dont display properly ) but for my full day test I had zero crash !!
A problem I saw and I think is your side (is somewhat very minor but I mention it ):

  • Lose physical keyboard exept directionnals keys and escape
    To reproduce :
  • Connect a bluetooth keyboard
  • Start a game
  • While ingame, switch focus to an other app ( for me, tested with : return to desktop or switch to web navigator )
  • Return to game
    At tihis point any key exept directions and escape dont work ( shorcut modifications not impacted. EDIT : I mean the modifications done to shorcut are not reverted, but keypress dont work )
    To correct user-side :
  • Just disconect and reconnect bluetooth keyboard, thats fine
    For this minor problem i hve to mention the option “virtual keyboard” in “android” tab is set to auto .

Great work, for sure a lot of gamers will love it. Thanks really, if it was easy it would be done for a while so bravo !


#100

No, I haven’t looked in detail at other areas of the game yet. Every user I’ve spoken with who had troubles running tiles on Android (usually due to a low-spec device with < 1GB memory) was able to run the game fine in ASCII mode, so I agree that tiles are most likely the biggest culprit, but I haven’t verified that. (And if we apply Programmer’s Law, the one thing we haven’t verified which we’re certain is correct has a 99% chance of being incorrect, hehe.)

Also for anyone looking to contribute, the source code + release APKs is now permanently available on GitHub: https://github.com/a1studmuffin/Cataclysm-DDA-Android

sidav: Thanks for the report, I’ll see what can be done.

Taerzik: Yeah absolutely smaller tilesets will reduce memory overhead. As you say some people have had success with Hoder’s tileset, though it will depend on your device and available memory. Glad you got it working :slight_smile:

RipRoarinBoogerPenis: Does the same issue persist if you don’t delete the unused tilesets? I know Cata will try and revert to a few default tilesets if it can’t find the user-chosen tileset, perhaps that’s tripping it up. Awesome username btw.

Kirikman: v0.30 (latest) is using 0.C-20819-gc7f9eb7. You can now see the Cataclysm DDA version in use via the GitHub releases page: https://github.com/a1studmuffin/Cataclysm-DDA-Android/releases
Thanks for the feedback about resetting shortcuts too, duly noted.

hatcher: I will do a new experimental update soon. It does take a bit of time to do the update though as I have to merge it with my UI changes, and I’ve had some unexpected commitments lately hence the delay so far. I won’t be doing them very frequently regardless - I’ll aim for once every month or so, unless someone else is dying to help out and loves 3-way merging code! :slight_smile: I’ll also update when a major version is ticked.

zer0pol: Santa delivered the goods! Hahaha. Thanks for the kind words and bug report, I’ll see if I can repro this locally.