Android port (on hold)

Game Talk The Lab
21

SDL_android_main.cpp is more like an entry to the main function (status = SDL_main(1, argv);).
The file I uploaded has some junks from previous project I ported to android in which I simulated a joystick (so I need to record all fingers). I added functions because I felt the way SDL handles touch was buggy, so I did the job in java and sent the results to c++.

They are all commented out.I’ll do some clean up later, now github is too slow for me.

Besides that, SDL is used like on windows. Check sdlcurse.cpp in jni folder. Forget video.c, is was from my previous project.

22

[quote=“utunnels, post:21, topic:1726”]SDL_android_main.cpp is more like an entry to the main function (status = SDL_main(1, argv);).
The file I uploaded has some junks from previous project I ported to android in which I simulated a joystick (so I need to record all fingers). I added functions because I felt the way SDL handles touch was buggy, so I did the job in java and sent the results to c++.

They are all commented out.I’ll do some clean up later, now github is too slow for me.

Besides that, SDL is used like on windows. Check sdlcurse.cpp in jni folder. Forget video.c, is was from my previous project.[/quote]

So the only difference is bitmap font instead of SLD_ttf. The template from that link above has SDL_tff stuff included as well.

23

Don’t you have to cross compile Cataclysm source code first into libDDA.so and manually copy it to lib/armeabi-v7a folder together with libSDL2.so, and only then run “ndk-build” command with that build.bat? I also don’t see any “make” file defines ANDROID target or paths to Android tool-chain. Where is all that defined?

24

The make file is Android.mk, the goal is to generate libsdl2.so and libDDA.so that can be used by the app.

libsdl2.a (static) is already compiled so I included it in jni/lib folder. The toolchain allows precompiled libs as source, it will link it and produce libsdl2.so (dynamic), don’t copy it manually, the toolchain will do the job for you and overwrite the result.

25

[quote=“utunnels, post:24, topic:1726”]The make file is Android.mk, the goal is to generate libsdl2.so and libDDA.so that can be used by the app.

libsdl2.a (static) is already compiled so I included it in jni/lib folder. The toolchain allows precompiled libs as source, it will link it and produce libsdl2.so (dynamic), don’t copy it manually, the toolchain will do the job for you and overwrite the result.[/quote]

I see you’ve done some kind of emulator with that template previously. Me too, I’ve done MAME port and I also emulated joysticks, and trackball and steering wheel, only not with touch screen but through tilt sensor controls:
https://play.google.com/store/apps/details?id=com.ctMAME

I didn’t really care to learn anything about the SDK other than to just get it compiled, and what I knew I forgot as soon as it worked and I didn’t need to worry about it. But I do know what I did is to have regular makefile for native part of the code, with defined path pointers to SDK folders and the tool-chain, like this:

BASE_DEV=c:/android/android-ndk-r7/platforms/android-8/arch-arm

CC = c:/android/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/arm-linux-androideabi-gcc

… and then I would compile it normally with “make” command, then manually copy the lib to libs folder and from there did the rest as you do. I had no idea all those things were defined internally somewhere within NDK and that “ndk-build” command could do it all automatically.

Anyway, I pulled that computer with Android SDK from my garage finally and it compiled your project just fine, after some 20 or so minutes, although I first had to update the project to use the targets and SDK I had already installed on that computer, by running this command:

android update project --name catDDA --target 8 --path ./

So then I enabled auto-rotation and there are problems. Rotating the screen exits the application, font size is hard coded and it doesn’t stretch properly. Beside sorting out input mechanics I’d say those would be the first things to address in order to make this port actually playable across many Android phones. Are you plaining to work on these things? Are you going to make it use SDL_ttf?

In any case you did the hardest part, from here on it’s easy. Thanks for that. Just one more thing. When I modified some files and went on to recompile it “ndk-build” command wanted to compile all the source files from scratch all over again, as it seems it had deleted object files when it moved those libs automatically after the first compilation. I had no such problems with my project since I was doing it all manually, and so funny enough I really have no idea how these SDK tools actually work and have to ask these most basic questions even after I spent almost a year working with it. So please tell me: what do you do about it, how to make it re-compile just the files that changed since the previous compile?

26

Well if the screen is rotated SDL must destroy the old window and build a new one, not sure how to do that right now, but it is easer to rotate the backbuffer by 90 degree in SDL without changing the app window.

A quick answer about your last question. It will recompile if Android.mk is modified.
If only a cpp file is changed, it will only compile the cpp. But if a header is changed, it will recompile all files that uses the header.

Also you can force it to recompile using ndk-build -B

27

I don’t think I had to do anything to make it work in my app. It’s handled by the OS, it destroys the old window and onCreate() function is called where the application window is normally initialised and so also re-initialised, if I remember correctly.

Doesn’t that SDL package where you found that template contain some demo app that can be rotated to both portrait and landscape? That’s pretty important and basic feature for Android devices, it should already be taken into account in their template. Maybe it’s just those hard-coded dimensions that causes new window to fail initialisation, I’m guessing that stuff would need to be re-initialised for the new window as well.

A quick answer about your last question. It will recompile if Android.mk is modified. If only a cpp file is changed, it will only compile the cpp. But if a header is changed, it will recompile all files that uses the header.

Also you can force it to recompile using ndk-build -B

I didn’t change Android.mk or any header files, only sdlcurse.cpp. I’ll try “ndk-build -B” next time, thanks.

Are you planning to work on this some more? Are you going to make it use SDL_ttf like desktop builds?

28

I can’t find a demo.
It is more convinient to render the DDA window on a backbuffer though, after that you can render the buffer to your window in any way you want.

There is no official port of SDL_ttf based on SDL 2.0, as far as I know.

29

Hi all first time poster long time player.

I thought I would give this a go and it will not work

I have a Nexus 7 where would one put the Cataclysm-DDA folder?.

I have placed it in a few folders with no luck though in one folder

android/ I get a keyboard show up and scrambled image of the title screen but its all messed up :frowning:

Please help

30

The folder should be in your sdcard.

/mnt/sdcard/Cataclysm-DDA/
/mnt/sdcard/Cataclysm-DDA/data
/mnt/sdcard/Cataclysm-DDA/data/raw
/mnt/sdcard/Cataclysm-DDA/data/raw/font
etc…

If it runs it should create a save folder.

/mnt/sdcard/Cataclysm-DDA/save

I don’t know if your file browser shows the full directory, but /mnt/sdcard should be your original sd, not the ext one (if any).

31

hi thanks for replying

The nexus 7 does not have an SD card it only has internal storage

I have placed the folder in

Nexus 7\Internal storage and it did create a save folder but as said above the graphics are all corrupt :frowning:

Ok took a pic of what I mean by corrupt graphics

32

Hi stk2008stk, it seems your screenshot is just fine. The internal storage is actually called sdcard (the external is extsdcard), so it’s OK. :slight_smile:
The corrupted graphics is not part of the game screen, maybe I forgot to clear the outside area. Check my screenshot in this topic, the game screen is really small…

I wonder if you can see the keyboard? I can’t see clearly from your screenshot.

33

[quote=“utunnels, post:28, topic:1726”]I can’t find a demo.
It is more convinient to render the DDA window on a backbuffer though, after that you can render the buffer to your window in any way you want.[/quote]

You would only be re-doing what is already done. You would need to monitor sensor input and calculate all the window properties at application level which would give you less compatibility because specific hardware and different drivers on different devices can make quite a difference and give different values for the same sensor reading function. On the other hand automatic rotation through OS is guaranteed to work as is part of vendor provided custom support for any particular model.

You draw graphics on “backbuffer” image/texture in either way. Then you simply give it to OpenGL in whatever size/resolution it is and if the window initialisation is done properly auto-rotate function will be able to scale it and even perform anti-aliasing/screen smoothing for you. That way the application makes the best of whatever device, with whatever display resolution and orientation it is running on, without you having to worry about any of those specifics. It is the same thing as “onWindowResise” event on desktop platforms, when done in general terms rather than with hard-coded aspect ration and tile size, it doesn’t matter how you resize the window it should always be able to adapt and scale/stretch accordingly. You should only define font image for the best resolution, say 800x600, and let SDL/OpenGL scale the whole screen/back-buffer image down for any lesser resolutions. The game would run even on small 320x200 screen displays, but it doesn’t have to scale all the way down to fit the screen, zooming and panning could be used to show larger than screen resolution game window and make the game playable even on the smallest of screens.

There is no official port of SDL_ttf based on SDL 2.0, as far as I know.

I don’t see why would there need to be a port at all. SDL_ttf is based on SDL only, and not on any platform specific APIs or libraries, if SDL works so it must SDL_ttf. In that link I posted there is SDL_ttf support in that SDL 2.0 template for Android.

Why SDL 2.0 anyway? Why not SDL 1.2 you used for desktop version? Shouldn’t 1.2 be more stable, proven and tested?

34

hi utunnels a keyboard does come up its the std android one but as I said the graphics are all corrupted :frowning:

35

[quote=“LazyCat, post:33, topic:1726”]I don’t see why would there need to be a port at all. SDL_ttf is based on SDL only, and not on any platform specific APIs or libraries, if SDL works so it must SDL_ttf. In that link I posted there is SDL_ttf support in that SDL 2.0 template for Android.

Why SDL 2.0 anyway? Why not SDL 1.2 you used for desktop version? Shouldn’t 1.2 be more stable, proven and tested?[/quote]

SDL 2.0 has better android support (and I have a habit to use official libs). But I don’t think it is a big drawback to use bmp font, haven’t you suggested me to use bmp in another thread? :slight_smile: I just want to make it simple.

I think the biggest problem is a playable layout with touch screen only. I tried landscape view before, standard DDA size (640x400) leaves only a strip at the bottom, which can be used to place a menu. There are also some spaces on left or right side of the screen, which can be used to add buttons or just extend the display area to 800x400.

I’ve tried to place a keyboard (semi-transparent) on top of the playable area in photoshop, unfortuantely, it is very disturbing because the game interface is text based. I think I’ll abandon this idea.


36

Bitmap font is fine, but if you were already going to use SDL_ttf I wouldn’t bother with it in order to support flexible screen aspect ratio and arbitrary screen sizes (square fonts/resizeable play window), as it seems that stuff would be simpler to handle with SDL_ttf and it’s already in the desktop build so it would make things easier to maintain and test I suppose.

I think the biggest problem is a playable layout with touch screen only. I tried landscape view before, standard DDA size (640x400) leaves only a strip at the bottom, which can be used to place a menu. There are also some spaces on left or right side of the screen, which can be used to add buttons or just extend the display area to 800x400.

I’ve tried to place a keyboard (semi-transparent) on top of the playable area in photoshop, unfortuantely, it is very disturbing because the game interface is text based. I think I’ll abandon this idea.

You have the whole screen in an image before it actually goes to screen, just split it in half and show one side below the other, where you stretch each half to fit the screen horizontally, whatever the screen size is:

… that way the application will be exclusively portrait to avoid any auto-rotate issues, it will provide for the biggest possible tile size on any given screen, and conveniently the only wasted or less important area of the screen gets to be on the bottom without altering any code in the game itself. Ideally to make everything visible there should be a custom keyboard, or menu even, that uses only one or two rows of letters, scrolling left and right if necessary.

Actually, using Android built in menu system (menu button) seems pretty simple and easy way to present to the player only letters/commands necessary for the game instead of whole keyboard.

In any case as many as possible actions should be accessible with some touch screen gestures. Walking for sure, panning the view, targeting and shooting as well, the more the merrier. Driving will need special attention since touch screen would make those controls even much more awkward when driving to the south than it is on a PC with a keyboard. I’m thinking to make driving use tilt sensor, that could be fun and provide some additional challenge. Volume up/down buttons are also very handy and should be able to be mapped, for say smash, reload, drop or use actions, and when in vehicle those two are perfect match for speed up and speed down controls.

37

Well, updated the post and download link.

38

Hmm, for some reason when i attempt to install the .apk, i get an error that states that there was an error in parsing the package. i’m using the tf201 transformer prime on the latest firmware, any ideas? i am using the compiled binary provided.

39

I’m not familiar with that device. What android version is it running?

40

4.1.1