Porting source ports to Android 4.0

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Source Ports > Porting source ports to Android 4.0

Pages (2): [1] 2 »

Author

All times are GMT. The time now is 20:24.

Csonicgo

Posts: 4304
Registered: 03-04

Hey! I have a really interesting proposition. thanks for scrolling to the right.

I have been playing prboom+ for android recently with an external keyboard, and I'm impressed at the performance. This makes it very possible to play doom on the go, and when plugged to a television and paired with keyboard/mouse, makes a very interesting "console".

Any other ports/port authors thought about this? with the amount of working android emulators out there (even one for Commodore 64!) I think it'd be very possible.

08-23-12 23:39 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

entryway
Forum Staple

Posts: 2666
Registered: 01-04

Csonicgo said:
thanks for scrolling to the right.

thanks for stylish.

code:
@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain("doomworld.com")
{
  div
  {
    width: auto !important;
    min-width: 0px !important;
  }
}

Last edited by entryway on 08-24-12 at 03:51

08-24-12 03:21 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Use3D
Forum Legend

Posts: 4638
Registered: 04-02

Maes was just talking about porting his work to android, a few topics down from here.

08-24-12 03:48 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 9138
Registered: 07-07

I've never seen a reason to allow Doomworld's javascript (does it do anything beyond make Post Hell annoying) so I don't see anything wrong with Csonicgo's posts.

08-24-12 09:17 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10163
Registered: 07-06

Use3D said:
Maes was just talking about porting his work to android, a few topics down from here.

That was more of a "pie in the sky" thread I had made more than a year ago, though there have been some progresses that would make such a task more possible than when I first wrote it (e.g. using input streams for resource handling, direct HiColor/TrueColor COLORMAPs getting around the lack of an indexed display etc.)

However my approach was referring exclusively to making a pure Java port to Android (and obviously basing it on Mocha), there were (and still are) hybrid ports (Java frontends with a JNI "doom library") as well as entirely native ports in C/C++ for Android.

What Csonicgo was wishing for was just the usual thread we see once in a while about porting tools, editors and ports to Android, there are several of those.

The answer is always the same:

"Clean" command-line based utilities (MIDI2MUS, DEUTEX etc.) could be ported as-is, but of course those would offer no bells and whistles, they'd only be useful as unseen parts of the toolchain.
Some of the "cleanest" C-based stuff like DEU/Yadex might be possible to port if direct plug-in substitutes for the Allegro/X graphic libraries they are using can be found.
Stuff like Slade3 however would be vexing because it depends on C++ libraries like WxWidgets, which are not ported to mobile OSes as of yet (update?), and the code depends too much on them to simply replace them with plug-in substitutes.
Stuff like Doombuilder (1 and 2) would be nearly impossible to port without a major rewrite, as the toolchains required simply don't exist for Android (Visual Basic, .NET, DirectDraw).
Stuff like ZDoom is too Windows-oriented too, despite there being a Mac port. Too much work for some poor sod to port to yet another platform.
Stuff like the existing prBoom+ port for Android use the "binary blob" approach: a Java wrapper for controls/screen/sound, but the core functionality is done by a C "doom library". Still, that must have required some extensive modification to emulate some of the external dependencies.

08-24-12 10:23 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 8137
Registered: 06-06

What about Eternity what about Eternity?

__________________
Available for download: Automatic Wolfen s tein - Wolfenstein 3D bot
MBF configuration for WHackEd2

08-24-12 10:34 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10163
Registered: 07-06

printz said:
What about Eternity what about Eternity?

I'm not the most avid fan of that port, but if I'm not severely out-of-date, the C++ codebase and the Direct3D dependencies shouldn't make it pretty.

08-24-12 10:52 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5139
Registered: 08-00

Maes said:

I'm not the most avid fan of that port, but if I'm not severely out-of-date, the C++ codebase and the Direct3D dependencies shouldn't make it pretty.

EE does not use Direct3D.

It has an OpenGL 2D-in-3D backend, however.

How/why is C++ such a liability on this platform? Sounds like a broken system if it can't run code in what is still one of the most prominent languages.

08-24-12 14:45 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

chungy
Doomworld is so about bullshit excuses

Posts: 1691
Registered: 06-05

You just use GCC to build architecture-native programs for Android anyway. Which, surprise surprise, supports C++ just fine.

08-24-12 17:29 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5139
Registered: 08-00

chungy said:
You just use GCC to build architecture-native programs for Android anyway. Which, surprise surprise, supports C++ just fine.

I'm really not surprised at all, mainly because I already knew there's a version of GCC for it. Which is why I can't figure out how Maes can be considering C++ a liability against a program being ported to the platform. Maybe it would be in the sense that a lot of platform libraries are in Java or some other language. Is there not an equivalent of JNI there to bridge to native code?

EDIT:
https://developer.android.com/guide/practices/jni.html

Heh. Well there goes that "minus" against C++ I guess.

08-24-12 17:58 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

Some people seem to have the mistaken impression that mere use of C++ makes porting code problematic.

This, of course, is utter nonsense. I programmed the Playstation 1 in C++ 10 years ago. The whole bloat thing only comes from using inappropriate classes from the runtime library.

Nobody should use iostream and other heavy baggage stuff if code size is an important factor. These things easily add a few 100k just for sitting there and doing nothing.

BTW, ZDoom doesn't use any of those, so they wouldn't be a factor.

Since both SDL and FMod appear to be available for Android I think the biggest issues are already out of the way.

08-24-12 18:06 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5139
Registered: 08-00

In my job I've moved C++ code from Linux to Windows, and between different compilers on Windows. You can't tell me it's not portable :) If anything, most C++ code ends up being more portable than C code, as classes can be created that abstract away any system-specific nonsense behind pImpls or under the auspices of an abstract base class. In C programs from days yore, and even now depending on the code's purpose and target, you just have all this stuff thrown into the mainline program code more often than not.

08-24-12 18:45 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Ladna
Junior Member

Posts: 233
Registered: 04-10

Maes just considers the JNI thing "impure", compared to a "pure" Java-only port. I say we bombard him with some stuff about how the Dalvik and Hotspot VMs JIT compile Java bytecode into platform-specific instructions, and that it would be way more "pure" to write your application in those instructions in the first place ;).

Android has an NDK (Native Development Kit), and SDL 1.2 and 1.3 both have Android ports. The 1.3 README says it uses a JNI shim, and I assume 1.2 does as well.

Anyway, I would guess it's not that difficult. One of the things we talked about for EE's C/S branch was a "viewer" that would play demos, connect to live servers, notify about games, etc. We specifically tried to not talk about a full client, because playing Doom on a cellphone is deeply unsatisfying and it's probably impossible to get the controls right. I assume that's why it hasn't really caught on for single player.

I think if there were a compelling "console" installation of Android (Ouya, Nexus Q, tablet docks + bluetooth controllers) you'd see a lot more of this stuff in general. I seriously don't know anyone who plays cellphone FPS games, and I know a lot of nerds/geeks/gamers. In fact, I really just don't know why this didn't happen sooner.

08-24-12 19:19 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10163
Registered: 07-06

As I said, I might have been a bit out of date on Eternity :-p

As for C++, sure, porting "clean" (HA!) code should not be a burden, but wait a minute, what flavor of C++ are we talking about? Borland? Microsoft? GNU? And with what OS-specific assumptions, headers and libraries? If the situation with plain C is just "ugly" when it comes to cross-platform support, with C++ it escalates to downright "fugly". How many #ifdefs will be needed to save the day?

Ladna said:
Maes just considers the JNI thing "impure", compared to a "pure" Java-only port.

Well, it *is* impure. In the case of Doom ports on Android, all the real "doom" work is done on the native library's side (almost like a doom-on-a-stick), and Java is just there to avoid writing the UI in NDK :-p

Writing stuff with JNI wrappers is also a hideously non-portable option, much more than even a native executable, effectively tying you to not only a specific CPU, but also a specific OS and JVM, depending on how "clean" (an oxymoron, in this case) a JNI app you write. You can make certain very nasty things happen if you try sharing structured data between the two "worlds" during runtime, and rely on memory layout assumptions. These might change even between different JVMs, thus making any JNI app a one-time hack. "But it worked on my computer" squared and cubed.

Ladna said:
I say we bombard him with some stuff about how the Dalvik and Hotspot VMs JIT compile Java bytecode into platform-specific instructions, and that it would be way more "pure" to write your application in those instructions in the first place ;).

Why would I be upset about those? I am counting on them to do just that ;-) I have a colleague who tried to write his own class loader with real-time bytecode manipulation for some extremely convoluted task, though. It was not pretty. However, a pure Java port of Wolfenstein 3D with real-time, generated-bytecode, optimized column drawer functions would be a tantalizing idea ;-)

Last edited by Maes on 08-24-12 at 20:03

08-24-12 19:52 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Ladna
Junior Member

Posts: 233
Registered: 04-10

There are lots of definitions of "portable". You said yourself that in Mocha Doom you have to do different things with input handling on different platforms (iirc), that's a platform-specific issue even platform-independent languages have to deal with.

Plus, under the hood, VMs have to do different things depending on which platform they're running on. Just because the #ifdef or whatever isn't in your code doesn't mean it's not there. And if we're not counting #ifdef's in VMs because they're not in our code, shouldn't we also not count #ifdef's in library code such as SDL or the STL? Hardware platforms differ, and abstraction layers are necessary in order to provide a uniform interface.

Finally, there's been a huge cross-section of "compatible C++" on the major platforms for years. Unless you're using super-new stuff, you really don't have a lot to worry about.

08-24-12 20:01 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10163
Registered: 07-06

In those cases you mentioned, you're running near the "convenience horizon" of a particular runtime environment or VM. VMs are usually used to abstract all or most of those implicit #ifdefs, as you said, and they are only convenient to use as long as they do a good job masking them. If they don't, you consider moving to a better platform, unless you like getting your hands dirty. The hacks I've had to do, so far, are limited to runtime checks (e.g. if method #1 to get audio fails, try method #2, or give the user the option to use mouse grabbing method #1 or #2).

That being said, the support for those aspects has been much more flaky on Linux (between distros/window managers/audio subsystems), and more consistent on Windows and Mac OS :-/

08-24-12 20:10 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

Maes said:
As I said, I might have been a bit out of date on Eternity :-p

As for C++, sure, porting "clean" (HA!) code should not be a burden, but wait a minute, what flavor of C++ are we talking about? Borland? Microsoft? GNU? And with what OS-specific assumptions, headers and libraries? If the situation with plain C is just "ugly" when it comes to cross-platform support, with C++ it escalates to downright "fugly". How many #ifdefs will be needed to save the day?

Strangly enough, even a very complex program like ZDoom manages to do it quite well.

I still declare most of what you say in the post I quote bullshit. As I said before, using C++ doesn't necessarily mean you have to use all the baggage that comes with a common C++ runtime library. In fact, in most situations you are way better off ignoring all the crap in there and stick to the C RTL.

08-24-12 22:08 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 8137
Registered: 06-06

Graf Zahl said:
In fact, in most situations you are way better off ignoring all the crap in there and stick to the C RTL.

Not even the standard templates (map, vector etc.)?

__________________
Available for download: Automatic Wolfen s tein - Wolfenstein 3D bot
MBF configuration for WHackEd2

08-24-12 22:41 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10163
Registered: 07-06

I've come to take "kind" comments like those of Graf with philosophy: IT is an incredibly varied, unpredictable and largely empirical field, so much that no single man can claim to "have it all laid down", he and none else: there's always more than one way to achieve a certain goal, and no matter how bright your solution or approach might appear to you, somewhere, sometime, there will be someone whose approach will be just a tad brighter than yours.

Same goes for user experiences with software X, hardware Y or toolchain Z: someone might be able to point out all of their flaws, someone else might notice none, and both be 100% right and in the true from their own perspective. IT is a patchwork of 1.000.000.000 "my neck of the woods" situations, and those necks that are the same for more than one person are few and far between.

08-24-12 22:57 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Blzut3
Member

Posts: 375
Registered: 06-04

printz said:
Not even the standard templates (map, vector etc.)?

When I converted ECWolf from std::vector, etc to ZDoom's containers. The size of the binary went from several MB to less than a MB IIRC. The std containers are quite bloated.

It's nice since it provides a minimal standard library to work with, but it is definitely not lightweight.

08-24-12 23:17 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

... which is one of the reasons I prefer using the ZDoom classes whenever possible.

Not only are they far more lightweight, they are also much easier to debug.

And they don't behave differently based on the compiler being used.

08-24-12 23:49 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

chungy
Doomworld is so about bullshit excuses

Posts: 1691
Registered: 06-05

Maes said:
That being said, the support for those aspects has been much more flaky on Linux (between distros/window managers/audio subsystems)

The distros/audio subsystems thing has a tiny bit of credibility, but you pretty blew all of it out of the water by claiming that a window manager would be affecting your program.

I lol'd.

08-25-12 00:06 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Csonicgo

Posts: 4304
Registered: 03-04

chungy said:

The distros/audio subsystems thing has a tiny bit of credibility, but you pretty blew all of it out of the water by claiming that a window manager would be affecting your program.

I lol'd.

I've actually heard reports of certain versions of metacity could, in fact, destroy flash applets that wanted the video overlay. not sure how much "fact" was in that.

08-25-12 00:10 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10163
Registered: 07-06

chungy said:
claiming that a window manager would be affecting your program.

Yup. It does affect the pesky Java Robot class (mouse grabbing/forcing), especially when you have extended desktops. With some methods, it can still get a grab on the correct desktop, with others, it just can't get a steady lock and "jumps" on the wrong desktop. I could name other aspects like e.g. what part of the window is considered "the top corner", whether borders and titles count or not to the total height property of a window etc. you name it. The only way to make everyone happy is to check and recheck for known screwups and infer what the underlying windowing subsystem actually does. If a window manager isn't a platform-specific aspect that needs to be adapted by Swing/AWT, then I don't know what is. It's pretty much a cause c�l�bre of why it's hard to design good cross-OS GUIs with Java.

chungy said:
I lol'd.

I lol'd more :-)

But take it with philosophy (see my previous post).

Last edited by Maes on 08-25-12 at 00:29

08-25-12 00:24 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 9138
Registered: 07-07

Graf Zahl said:
... which is one of the reasons I prefer using the ZDoom classes whenever possible.

Not only are they far more lightweight, they are also much easier to debug.

And they don't behave differently based on the compiler being used.

And they're also capable of supporting larger collections. Or at least, I believe this is the explanation for this.

08-25-12 00:59 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10163
Registered: 07-06

ZDoom: the future of C++? *scratchchin*

08-25-12 01:00 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Blzut3
Member

Posts: 375
Registered: 06-04

Maes said:
ZDoom: the future of C++? *scratchchin*

That's not exactly what we're trying to imply here. We're just pointing out that, for a majority of use cases, there are better ways to do collections than the way the standard library does them if you're looking for efficiency. I believe this has a lot to do the stl having templates which implicitly utilize other templates for things most don't care about.

The ZDoom containers are just one example of this and I've actually converted a program from one to the other with a dramatic difference. There are plenty of other C++ libraries that provide similarly efficient containers.

08-25-12 01:24 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5139
Registered: 08-00

Blzut3 said:

That's not exactly what we're trying to imply here. We're just pointing out that, for a majority of use cases, there are better ways to do collections than the way the standard library does them if you're looking for efficiency. I believe this has a lot to do the stl having templates which implicitly utilize other templates for things most don't care about.

The ZDoom containers are just one example of this and I've actually converted a program from one to the other with a dramatic difference. There are plenty of other C++ libraries that provide similarly efficient containers.

That's pretty much right on. As a perfect example, take std::map, which is still the closest thing to a hash table you can get in STL. It's implemented on top of a red-black tree, which has zero cache coherency, only guarantees O(log N) access time, and worst of all, wraps everything put into it into instances of std::pair which get passed by value everywhere, invoking copy constructors and destructors.

For a small investment you can write your own hash table using chains, for better coherency, O(1) access guarantee, and no stupid intermediate structures (ex., bind to hash keys via a pointer-to-member argument in the template like EE does).

It's not much more difficult to exceed the STL for other data structures in similar ways. I look at the STL as being a blessing for RAD and office-type database-accessing crap. I would never use it somewhere that efficiency is the top concern (ie., in a game engine).

08-25-12 07:53 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

entryway
Forum Staple

Posts: 2666
Registered: 01-04

std::unordered_map?

08-25-12 08:16 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10163
Registered: 07-06

Blzut3 said:
That's not exactly what we're trying to imply here. We're just pointing out that, for a majority of use cases, there are better ways to do collections than the way the standard library does them if you're looking for efficiency. I believe this has a lot to do the stl having templates which implicitly utilize other templates for things most don't care about.

I think that is true of other languages as well -while many modern languages do offer their own containers/lists/data structures and thus the programmer is exonerated from the burden and responsability of developing his own from scratch, they often come with a ton of crap that one could do without.

It's not unusual to be able to make a more lightweight version of e.g. a Stack or ArrayList class than the built-in one, even for a novice programmer, especially if limited to a single data type. What such re-implementations often "lose" are some frills like thread safety, generics (but not always), implementation of some exotic interfaces, serialization, etc. and of course having to prove from the ground up that they are correct.

08-25-12 10:44 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 20:24.

Pages (2): [1] 2 »

Doomworld Forums > Classic Doom > Source Ports > Porting source ports to Android 4.0

Show Printable Version |

Email this Page |

Subscribe to this Thread

Forum Rules:

You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON

< Contact Us - Doomworld >