Android or IOS build

[justinl1996]

Is there any reason why ioquake3 doesn't official support Android or IOS platforms?

I'm not proposing that one should host ioquake3 officially on the play or app store, or to try to make money off it. I'm just curious to know if there would be any interest in adding official support for these platforms.

[timangus]

If it can be done cleanly and with minimal disruption, with a CI build, then sure, but I think that's probably quite a challenge. There have been numerous stand alone mobile ports for what it's worth. It's obviously a much easier task if you don't have to care about the desktop operating systems still working.

(EDIT: and for what it's worth, to my mind it's always been one of those whytho? kind of things. Cool technical challenge and all that, sure, but is anyone genuinely actually playing a twitch shooter on their phone, without a mouse?)

[tomkidd]

I have a separate project, now itself years out of date, that had iOS support. It was based on the old beben3 project which I got the dude to send me and then I spruced it up for then-modern devices. It was my gateway drug to getting involved in this project, and we've had discussions about having official mobile support baked into the main project before.

Here are the challenges:

First, iOS and Android use OpenGL ES, the mobile/embedded version of OpenGL. Long story short, the renderergl1 code almost works with it, there's just this handful of places where you have to do things differently, most of them being the older, less desirable way of handling things. We once debated what would be better - having a bunch of #ifdef statements that work around the areas where the code differs, or have like a renderergles folder, with like 95% the same code. Either approach has its pros/cons.

Second, there's the UI challenges. Quake 3's menu system is designed around mouse input and relative movements since it was designed for computers with mice. Instinctively when people run the game on a touchscreen they just want to touch the screen where they want to select (mode, skill level, etc). The beben3 project I modified had actually gone through the trouble of making the engine and ui qvm changes needed to allow absolute positioning (as in, touch the screen and it's like you put your mouse there and clicked) loaded in via a pak99.pak file to ensure it wins out. It was a pretty clever solution but the problem, besides having another #ifdef situation, is that a custom ui qvm doesn't work on a "pure" server so once you get in the game if you want to hit escape and navigate the menu with touch you can't because it's fallen back to the official ui qvm.

A workaround of sorts is to do what I basically did with the Quake3-iOS project and have a series of Cocoa Touch menus that would then essentially dump you into the equivalent of launching the game with command line arguments, but that's additional work and it's arguable whether or not it should be in the base project like this or not.

Then there's the build system issues. Namely, most iOS development is done via Xcode (and I'm focusing on iOS since it's what I know but Android has similar concerns) and we just went through and ditched all our old build systems in favor of CMake. I'm sure it's possible to have CMake come up with an Xcode project for iOS or an Android Studio project for Android but that's just something to keep in mind. And there's ways I'm sure of making an iOS app bundle with Make by way of CMake (so, no Xcode needed) I've just not done it since I switched to the Mac side.

From a logistics point of view, something to consider is that last I checked Apple doesn't allow iOS apps with dynamic libraries (so, dylibs on iOS) on the App Store, so everything has to be rolled into the main executable, including the renderer and SDL code. It's technically possible to have apps load dylibs but Xcode doesn't make it easy natively. If you're just building this to run on your own device that's fine but if you're wanting to make something for the App Store (like if you're making a game with ioquake3) it's a concern.

And finally there's the mechanics of playing the game itself. I did the project above because I thought it was neat and interesting and I figured out a way to hack a little joystick and buttons onto the screen but I'm not going to lie and say it was a good way to play the game. I also had MFi controller support and that's a good way to play it with a joystick but that's not something as easy to, say, break out on the train and play. And you'll likely get steamrolled by people on M+KB situations who have been playing for 25 years anyway, but science isn't about why it's about why not.

Anyway, those are some of the reasons/challenges. And part of it is I started working on it and got sidetracked. From a pure code standpoint you could just do the GL bits and it would run and you could let the other challenges be the issues of anyone else who wants to use it.

[NuclearMonster]

I would love to be on iOS and Android, properly, in-tree.

for just the input challenge: notably, on ipados at least you can now just plug in a usb hub/dock and monitor, and mouse and keyboard... which seems like the lowest hanging fruit way to do the barest version of this that probably wouldn't ever get approved by Apple for the App Store.