Baron of Hell
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Investigating the possibility of an Android Mocha Doom branch.
 
Author
All times are GMT. The time now is 04:39. Post New Thread    Post A Reply
Maes
I like big butts!


Posts: 12395
Registered: 07-06


I was currently investigating Android's raw bitmap rendering performance, to see if a Mocha Doom for Android branch would be feasible. Yeah I know someone already made a prBoom-derivative port for it, but good luck getting that closed-source binary blob to run on an unrooted phone, or getting it updated.

The good news is that the current Mocha Doom codebase is "digested" by the Android API, so if someone wanted to use the Mocha Doom logic to create a Doom-like game, it would be definitively possible, provided my "AWTDoom" app is replaced by one suitable for Android's system events.

Android's canvas drawing functions can be very fast, provided you use line, circle, filling etc. drawing primitives, and even pre-loaded bitmaps can be draw with scaling and clipping at a reasonable speed, even on pre-2.2 devices (hence, with no JIT). We're easily talking hundreds of updates per second, when using Canvas.drawxxx(...) functions.

As for max. screen update frequency, my Sony Xperia 8 (Android 2.1)is able to update a 320 x 400 pixel area more than 60 times per second, using a raw int[] array as a screen buffer and filling it manually each time using a modified arrayfill function, and that's without using OpenGL. If the array is already stored somewhere in memory (e.g. uncompressed animation), the time to draw it to screen is really negligible. These are the good news.

However, it goes downhill from here: Android doesn't support any form of indexed display, and even 16-bit bitmaps are treated as hicolor RGB and are forcibly blown to a full 32-bit Canvas before being drawn.

The problem is that Doom is a game that relies on indexed palette manipulation for its lighting and colormap tricks, and on the ability to set an arbitrary palette of colors for some of its visual effects, so if I keep the inner working intacts.

I benchmarked how long it takes for Android to copy the contents of an int[] array to another and then display that to the screen, and usining an optimized array fill operation resulted in a 60 fps update at 320x480 resolution. However, converting a byte[] array to an int[] one using a palette table (which is what a Doom source port will need to do at the end of each frame.some point) was SHIT SLOW. It doesn't help that there's no native function to do that, and no JIT in 2.1.

So slow in fact, that it can't be performed faster than 10-12 fps at vanilla resolution, at least on a JIT-less Android implementation (still stuck with 2.1, sigh). Even the existing mixed-code Doom for Android that uses a prBoom binary blob is quite slow to update, and I think that one actually uses a GL surface to force hardware palette conversion, which means creating a new GL texture each frame. Unsurprisingly, that one doesn't run very smooth either.

So, either I wait and see if 2.2 will definitively solve this bottleneck on the same hardware, if Google decides to add native support for indexed 8-bit or even 16-bit images (which is why Mocha Doom works so quickly on the desktop), or if there is a way to implement a 32-bit renderer without using colormaps. Another way would be to write a special primitive-based renderer for Doom e.g. draw sprites as clipped and scaled bitmaps, which are generally hardware accelerated even without using OpenGL. If this could be extended to textures too, it would make an awesome novel implementation of Doom's renderer (at least some pure 2D elements like the menus, automap and sprites could be def. drawn this way).

Old Post 02-23-11 10:52 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
AlexMax
Senior Member


Posts: 1114
Registered: 01-03


Nice investigative work.

Has there been any recent progression on the codebase proper? Is it any more or less playable at this point than the last public betas you went through with?

Old Post 02-26-11 21:04 #
AlexMax is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 12395
Registered: 07-06



AlexMax said:
Has there been any recent progression on the codebase proper? Is it any more or less playable at this point than the last public betas you went through with?


The version currently in the CVS has some extra features like support for DEUTEX flats in PWADs, and definitive removal of the SSEGs limit, and also a fix that allows it to work on OS X, along with some overflow fixes, but it's not more playable, sorry. I have a priority to finish my MSc within March, so I will resume work on it after that date. At most I could release a 1.3 beta so that OS X users could try it too (works just like on Linux).

Old Post 02-26-11 23:39 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
chungy
Senior Member


Posts: 1835
Registered: 06-05


I have a Droid currently running Android 2.3.2 and I can downgrade to 2.2 for testing as well if you'd like to start making public alphas/betas/whatever :p

Old Post 02-27-11 04:49 #
chungy is online now Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
sheeple
Warming Up


Posts: 22
Registered: 07-10


Android 2.2 Motorola FLIPSIDE user here, would love to test.

Old Post 08-22-12 05:57 #
sheeple is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6006
Registered: 08-00


What if you created specialized versions of R_DrawColumn and R_DrawSpan that blow up the memory addresses to int[] and remap the colors while doing the original drawing pass, so that you end up with a pre-expanded framebuffer?

Seems like it should in theory be less expensive than doing the normal drawing and then converting the entire buffer to int.

Old Post 08-22-12 18:22 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 2079
Registered: 08-03


I'm no expert on DOOM software renders but I would have thought that would indeed be quicker because you'd be able to write the three-value pre-computed BGR value set for a given palette index in one. Thus avoiding the potentially expensive 8 => 24-bit whole frame processing entirely.

The only potential drawback is repeated processing of a given pixel but as DOOM's software renderer already goes to some lengths to avoid overdraw - its probably not going to be an issue.

Good idea.

Old Post 08-22-12 19:02 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 12395
Registered: 07-06


Wow, I had almost forgotten about this thread...in any case, the HiColor branch development is quite close to what Quasar has suggested: all drawing functions are specialized and write 16-bit (565 RGB) values directly to a screen buffer, while an expansion to 24-bit or 32-bit truecolour would be trivial. The "palettes" are actually extended COLORMAPs.

There's no frame post-processing required, so if I even move on and try this, it will be based off the HiColor branch, the very least.

Old Post 08-22-12 21:49 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
tempun
Member


Posts: 597
Registered: 08-09



Maes said:
but good luck getting that closed-source binary blob to run on an unrooted phone, or getting it updated.
My phone is unrooted and runs it fine. There're lots of apps using native code now; Firefox and VLC, for example.

Old Post 08-23-12 14:18 #
tempun is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 12395
Registered: 07-06



tempun said:
My phone is unrooted and runs it fine. There're lots of apps using native code now; Firefox and VLC, for example.


That comment was made over a year ago, and now things have changed. The Android NDK itself can now target multiple CPU architectures (including MIPS and Intel) with a sort of "fat binary", but for older stuff, there was the implicit assumption that the underlying hardware would always be ARM-based, and I wondered whether this could break things in the future, eventually. We're also talking about older releases of the Android OS, and 2.1 was still king just about a year ago.

Old Post 08-23-12 15:48 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 04:39. Post New Thread    Post A Reply
 
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Investigating the possibility of an Android Mocha Doom branch.

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 >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.