Android Doom ports and editors?

So, I've ordered an Android computer. The Asus Eee Transformer to be exact. Now I didn't really get it to use for things like art or anything, though I would love it if there were some art program like Photoshop made available to Android tablets/notebooks like the Transformer (I looked around a bit and it appears there may be a version of Gimp available for Android, not sure before I've tried it when my Asus arrived). Though I don't expect it in the immideate future.

However, I came to think of Doom. I've been doing some editing on the road with my previous lap tops. Though the touch pad never been a good tool for the job. But with tablets and the Transformer in particular, I'd say this becomes a non issue. So I got curious, would it be feasible to port an editor like Slade and a port like Eternity or PrBoom for instance to Android? Is there any interest other than mine in seeing this done?

I would love to see this happen.

It's times like these that I regret not getting into programming.

Well, there is a slightly infamous Doom port for Android for some time now, based on some unspecified version of prBoom. It has some drawbacks though -it's hard to find because of some warez controversy, it's awkward to install (relies on a natively compiled library, it's not pure Java, so it might not be possible to run if the Android CPU architecture is ever changed, etc).

Performance is nothing special either: it uses a software renderer projected on an OpenGL surface from what I gathered, and so achieves an unimpressive 15-20 fps on 600 MHz devices. Most important of all, it's an unsupported, closed source binary blob which hasn't been updated for some time now (and yet it featured in a professional Android game programming book).

Of course, since "Java" and "Android" are somewhat related...I've flirted with the idea of porting Mocha Doom to Android. I know that 2.1 would have performance issues (the slowest part is simulating an indexed 8-bit display, rather than running the logic), but 2.2 would be feasible. The good news is that the codebase is mostly "digested" by the Android SDK, so it's technically possible to reuse my work to base a port or even partial tools on it ;-)

Perhaps you want to check my oldest thread about cross platform tools (not particularly warmly received though, so I take that people are happy with using Yadex or trying to get Slade to compile), and a link to the Android port.

But is Java the only language for Android? I mean, for instance this tablet/notebook hybrid is using Android 3.0, aka Honeycomb. I seem to recall from somewhere that later Android versions doesn't limit itself to Java. Though I might have misunderstood that.

Well, the official Android SDK is based on a subset of Java, which however is far less restrictive than the one used for older MIDP Java phones. Designing UIs etc. should only be done (as in, "officially endorsed by Google") by using the provided tools, XML scripting, button designers etc. and preferably through the only fully supported IDE for the task, Eclipse.

kristus said:

But is Java the only language for Android? I mean, for instance this tablet/notebook hybrid is using Android 3.0, aka Honeycomb. I seem to recall from somewhere that later Android versions doesn't limit itself to Java. Though I might have misunderstood that.

Not totally misunderstood:

http://stackoverflow.com/questions/2671871/can-i-develop-for-android-in-something-other-than-java

however all of the examples cited are at an even higher level of virtualization/abstraction (e.g. JavaScript, HTML 5, Ruby etc.), and would fall even more behind than Java in terms of performance. Which, let's not forget, is fully JIT-ed from 2.2 and onwards, so it's quite a different beast than 2.1 and previous.

Of course you can stick to the command line if you want, and you can develop Android applications in C or any language that can interface with the (C-based) Android Native interface (NDK) through the usual means, but that carries the risk that if in the future Android implementations that are not ARM-CPU based pop out, you'll have a useless binary blob, so only system-specific stuff or really critical portions of an app's code are made into native .so blobs.

In theory, anything that produces either straight .so executables (binary apps) or .apk packages with .dex bytecode could be used, so the source language needs not be Java. But it's the one Google actively supports, and the one which defines the high-level API, so there ;-)

Even the prBoom-based Android Doom uses "normal" Android code (aka Java) for the interface and menus, and it uses Java Native Interface to delegate the actual doomesque stuff like game logic to the binary blob (so you can think it of a C-Java hybrid). It's essentially one large huge-ass JNI binding ;-) Works wonders if you just want to get a running blob quickly and -relatively- effortlessly, but maintainability sure sucks.

I must admit, I don't quite understand all this. But essentially, there's no easy yet "reasonable" way to port Linux or Windows programs to Android?

Though for Honeycomb Java is considerably faster than it is for Gingerbread or Froyo?

But it all boils down to we'll probably be seeing completely different tools and ports for Android in the long run, if we see any at all. Though since you've made some serious headway with Mocha Doom, I suppose there will at the very least be that?

kristus said:

I must admit, I don't quite understand all this. But essentially, there's no easy yet "reasonable" way to port Linux or Windows programs to Android?

It depends to a great extent on the libraries they use. Sure, if you have a "Hello world" type of program or one that has no visual output and only does number crunching (e.g. LAME MP3 encoder in the form of a library), there's no reason why you can't use the official Android C compiler and make a library or executable out of it straight ahead.

But take something like Slade3, which uses the wxWidgets library for its GUI: that library is not (yet) available for Android, so any part of the code using it would have to be commented out/replaced with something else, so a "straight" port would not be possible. It would make more sense to keep only the "non visual" parts of it, and build a Java UI around them, gluing everything together with JNI (personally, I'd go one step further and cross the language barrier once and for all, by translating the C/C++ code to Java by hand, but maybe that's just me).

For Windows stuff, it wouldn't be much easier, and ports which rely on stuff like SDL, FMOD etc. would either have to use a port of said libraries (e.g. there's a mod player that uses a cross-compiled FMOD) or yank them out and wrap around them with alternatives.

kristus said:

Though for Honeycomb Java is considerably faster than it is for Gingerbread or Froyo?

From what I've seen, no: there were major differences when going from 2.1 (Eclaire) to 2.2 (Froyo) and onwards, because that's when the JIT mechanism was introduced (BTW, that was standard on the desktop since at least Java2 aka HotSpot), but not from there onwards: at most minor optimizations.

kristus said:

Though since you've made some serious headway with Mocha Doom, I suppose there will at the very least be that?

Depends on the tastes and time of individual developers. I personally prefer having a pure codebase and translating stuff (as Mocha Doom demonstrates), others may prefer mixing external libraries or postponing until they are available. As for Mocha Doom, once I release v1.6 on the desktop, I will try getting a working sample on Android, just for demonstration's sake.

XWE is another issue altogether: its source code is unmaintainable for a variety of reasons. Doombuilder (especially DB2) has a better chance of being ported at the core logic level, since they are written in VB and C# respectively.

Various classic utilities like DMAUD, MUS2MIDI etc. could be compiled to native Android libraries or ported to Java (e.g. Mocha Doom contains a full port of MUS2MIDI as of now), while some of the most complex ones like node builders would probably be easier to just cross-compile and invoke externally (maybe by wrapping them in a casual use Android GUI).

Maes said:

that if in the future Android implementations that are not ARM-CPU based pop out, you'll have a useless binary blob, so only system-specific stuff or really critical portions of an app's code are made into native .so blobs.

Question is, how many high performance apps are 100% Java code.

I wouldn't be surprised if some apps that were co-developed for Android and iOS share large parts of C/C++ code. It makes little sense from an economic standpoint to recode all this in Java if it can be made to work as it is.

I think with mobile phones we have reached the same situation as with PCs. The CPU architecture is pretty much set in stone with very little chance of an outsider being able to break up the monopoly...

Well, the CPU architecture is a bit of a grey area at the moment, and it's not really easy to get a clear "yes" or "no" about it being set in stone.

Yeah, de-facto, all current Android platforms use the ARM architecture, and the reference compilers by the Android design team target the reference development platform which is ARM-based.

But AFAIK it's not written in stone anywhere that it has to be ARM. A company could release an Intel-based or otherwise different architecture tomorrow, have the base OS all compiled and ready for it, and it would work with most stuff from the market (but not all).

And yeah, in the case of complex stuff which is implementation/interface neutral, I'd be all pro-reusing them as well (e.g. it would be crazy to rewrite ZenNode in Java, since it can just work at the pipeline level. Not that I haven't considered it...ya know, node building self-reliance and all that ;-).

Maes said:

But take something like Slade3, which uses the wxWidgets library for its GUI: that library is not (yet) available for Android, so any part of the code using it would have to be commented out/replaced with something else, so a "straight" port would not be possible.

Slade doesn't use wxWidgets just for the GUI: it's a wxApp. You'd have to entirely rewrite the architecture and translate it to something with equivalent features (e.g., Qt). It also use SFML, FluidSynth, FreeImage and, depending on platform, GLEW and FTGL...

Porting to a system other than the big three desktop OS seems difficult.

Questions: Java isn't compiled to binary is it? Is it text based like Doom3's scripting? Or possibly compiled at loading like in ETQW? You mentioned the CPU's architecture. So does that mean it works quite differently from an x86 processor?

Anyway. it seem to me from this discussion that there are ways to get things like the basic infrastucture of Doom and it's editings tools working in Android. But at the expense of unreliability when it comes to future versions. It reminds me of how DLL files in Quake and Doom 3 engine games work. When you get a new version, the old DLLs are useless and needs to be recompiled for the new version.
Though that might become a smaller issue as long as sources are preserved and people care enough to warrant new versions to be compiled. (not a very reliable system, I know)

I'm surprised that DB2 should be easier to port than Slade as I thought Slade was the one that was most compatible with different OSes.

Java is compiled to bytecode, which is then interpreted by a virtual machine. Just like ACS, if you want.

As for porting DB2 being easier; I suppose it would be if .NET and SlimDX existed for Android OS...

kristus said:

Questions: Java isn't compiled to binary is it? Is it text based like Doom3's scripting? Or possibly compiled at loading like in ETQW?

Java is compiled to bytecode which is then either ran as a pure interpreted language like e.g. BASIC or partially compiled to actual machine code "Just in time" like modern JVMs do, including android >= 2.2 There are some static compilers like GCJ but that's far behind the curve in terms of features. Actual JVMs run a mixture of interpreted, dynamically compiled and native code, while e.g. .NET uses static compilation of bytecodes during program start.

kristus said:

You mentioned the CPU's architecture. So does that mean it works quite differently from an x86 processor?

Yes, it's totally different at the binary (ones and zeroes) level. The ARM architecture is nothing exotic though -it's been around since the early 90s, and is what powers most cell phones, portable game consoles and in general almost everything even remotely "digital" that is more more complex than a microwave oven with a timer.

kristus said:

But at the expense of unreliability when it comes to future versions.

If there ever are alternative CPU architectures for Android devices (the idea behind making Java the language of choice was exactly to make at least end-user apps architecture-independent), then anything which was optimized for speed by using native binaries, will likely have issues.

kristus said:

Anyway. it seem to me from this discussion that there are ways to get things like the basic infrastucture of Doom and it's editings tools working in Android.

Sure, if they are simple programs that operate at the console/pipeline level are which are not tied to specific frameworks (like node builders, mus2midi etc.). Those are VERY easy to port (just compile them into blobs, like on any other platform).

kristus said:

I'm surprised that DB2 should be easier to port than Slade as I thought Slade was the one that was most compatible with different OSes.

Yes and no. As Gez said, it's "easy" only on the three major OSes for which the libraries it depends upon are fully supported. Remove that condition from the equation, and you are essentially better off rewriting the whole thing from scratch, or severely modifying it. Let alone that doing Android UI design in anything other than Eclipse would be a fucking headache, so you'd still end up writing mixed code.

A "clean slate" solution built around the Android UI but copying elements of logic (e.g. WAD management, graphics lump drawing etc.) from existing libraries, function by function if necessary, would lead to a more streamlined development cycle IMO.

Now as for DB2: it's written in C#, which is quite close to Java just as if it was just a dialect of it for Microsoft Windows, to the point that you can reuse most source code with relatively minor adaptations (the hardest ones would be the UI stuff, so it depends on how well UI concerns are separated from the underlying logic).

Anyway the real problem with mobile development is that every industry player pimps its own SDK and language: Google pimps their own version of Java for Android, Apple pimps Objective-C for iOS and Microsoft pimps C# and .NET for their Windows Phones. Even much more "bare to the metal" platforms like Symbian OS use such a restricted subset of C that straight ports of much existing software is made harder.

Anyway, even with the most high-level SDKs available for any given platform you can revert to plain C/C++ in most cases but you usually lose the convenience of whatever rapid development tools were included in the SDK, so it's only something you do sparingly.

Well, all I guess I can do right now is wait and hope that someone with actual knowledge and skill will find something like this interesting enough to shoulder the task. I will be looking forwar to possibly seeing Mocha Doom running on Android though.

To elaborate and offer some friendly clarifications/corrections:

A long time ago, some guy ported PrBoom to Android but made a very sloppy job of it - screen ratio badly skewed, no PWAD selection, etc. As per the GPL he made his code available. Someone else came along and fixed what the original guy did with a pretty frontend and released it whilst giving full credit to the original porter. The original porter had a huge cry about it on usenet and made an idiot out of himself. He then took this fixed code and started selling it as Doom games complete with IWADs on Android Market. I reported him to Zenimax legal team and anything with the word "Doom" in it got cleaned off Market the next week.

There is currently at least one port of Doom on Market, being sold for $1 (which isn't a violation of the GPL). He doesn't seem to distribute IWADs so that's not breach of copyright either. The same author also appears to have ported Wolf3D and Quake, I'll have to check these out :)

Performance of games on Android was crap back in the days of the original Android 1.0 and into Cupcake (1.5) and Donut (1.6) when the only devices out were 528MHz phones with poor 3D acceleration, such as the T-Mobile G1 aka HTC Dream. Nowadays the standard Android handset is 1GHz with a very competent SoC GPU, look at the specs for the Samsung Galaxy S for example. These current phones are so good Sony has started backporting PSX games to their purpose-built Xperia Play phone so 3D gaming on Android is definitely a possibility. For example, Minecraft runs beautifully on a phone of this spec. Newer 2011 Android handsets are now coming out with 1.2GHz dual core CPUs (Samsung Galaxy S2) which are so amazingly fast it's not funny. Manufacturers are now talking 3D capabilities of 70fps with HDMI output.

Android uses the Dalvik Java VM to run its code. This isn't quite "write once, run anywhere" like a true Java (supposedly) is, but it seems moderately easy to port existing Java apps to Android/Dalvik (probably why Minecraft has come about so quickly) compared to say a typical Windows 3D game.

A PrBoom port would be fairly easy, as Maes said just compile it for ARM using NDK, you get a framebuffer and audio device, you'd just have to write your own input method and work out some way of playing the music (the aforementioned ports required OGGs). A level editor would be a whole different story as has been covered. Not only because of libraries but because of the restrictive input method. I think it would be easier just to write one from scratch than try and fuff around getting SLade/DB code to work.

The biggest issues with developing any Android app I can see are:
a) Underlying system calls changing across Android versions. For example when Android version changes (from 1.6 to 2.0 or even 2.0 to 2.1) apps are required to update to the offerings in the updated Android SDK. Some apps are fairly basic and simply recompile on any version, some require a fair bit of work to be updated. This would require any Android-based Doom app to be actively maintained.
b) Writing support for the many different screen sizes, form factors and hardware controls that Android devices come in. There is plenty of provision for this in the SDK (after all, it is a mobile phone OS) but it would be a big pain in the ass.

To my knowledge, AOSP (the Google team who now develop Android) have never said they intend to primarily support or develop for any architecture. In fact, Intel were a founding member of the Open Handset Alliance who originally released Android. There are open-source projects producing Android for EEEPC and similar x86 netbooks and tablets, the biggest hurdle these projects face is drivers for the diverse range of PC hardware. Intel have very recently made press releases stating they will be putting more effort into making Android just as good on their arch as it is on ARM.

Android Honeycomb (3.0) should be faster than Froyo (2.2) and Gingerbread (2.3) *on the right device* as effort is being put into "hardware acceleration" (I haven't looked into what this means, whether it's GPU-assisted or what) and multi-core support. Froyo was a HUGE speed increase over earlier versions, not just because of JIT (which requires a decent amount of RAM so isn't feasible on earlier handsets anyway) but because of kernel and other optimisations made by AOSP and the Android community as a whole (most notably the team who develop the CyanogenMod mobile phone firmware).

tl;dr - Port possible and there's one on Market right now. Don't hold your breath for an editor, it'll probably never happen.

Super Jamie said:

tl;dr - Port possible and there's one on Market right now. Don't hold your breath for an editor, it'll probably never happen.

To the best of my understanding that's just the same prBoom derivative that has been around since forever (and the same that has always been mentioned in the Android game programming book), no matter if it's repacked/legalized/non-free anymore. If it's indeed kept up to date and not just abandoned, the better, but nobody quite held his breath about it.

As for source code, I think only the Java source code and the JNI bindings have ever been released, not any modifications to the underlying prBoom C code itself.

So since I am excited about getting my new toy I've been digging around for information on it. And what I've learned is that you can use it as a remote control over the internet to manage your computer at home.

Basically, what you get is something a kin to the what you would get with OnLive. (as olpposed to how you can use your Phone as a remote control for your computer as more of an actual remote)

Found this video of a guy sitting at work skrewing with SC2 on his computer at home. http://www.youtube.com/watch?v=PJQ3yj5mKSM&feature=related

Even seem like it works nice enough. Anyway. Point being. By simply setting this up with my home computer, I could work on crap on my desktop from my android as long as I got a decent internet connection. Which I got almost everywhere. Though I doubt trains and busses internet connections are good enough, I don't think the stress would be that serious when working in DB2 for instance since there's so little information to stream.

Anyway, this is a possibility. Will be exciting to test it out.