Android Implementation

3 views
Skip to first unread message

Dori

unread,
Sep 23, 2009, 11:38:25 AM9/23/09
to PulpCore
Hello, thought i would ask this in another thread as it's not about
the cost issues of the port.

Was just looking through the anodroid api's and was trying to see
where pulpcore would meet android dev wise. Would you be calling this
method

public void drawBitmap (int[] colors, int offset, int stride, float
x, float y, int width, int height, boolean hasAlpha, Paint paint)

from android.graphics class to draw sprites, groups, scenes etc to the
screen, as the methods which take bitmaps use unpremultiplied colors
and would lose some of the speed that pulpcore gains.

I imagine that it wouldnt be a case of being able to select either
compile for applet or compile for android in a pulpcore build file as
there is so much extra stuff that has to be in place for android apps,
is this what you are aiming for?

Exciting stuff!

Dori

David Brackeen

unread,
Sep 24, 2009, 12:43:55 AM9/24/09
to pulp...@googlegroups.com
Yes, I think that's why PulpCore might need to use OpenGL. Also, better graphics chipsets are supposed to be coming in newer Android devices, so I think OpenGL is the way to go.

I worry about the lack of a JIT in Android, but perhaps that will be fixed in the future. Hopefully sooner rather than later.

In regards to porting, there's also audio and other issues to work with. Also I want to upgrade all the source to Java 5 (generics, varargs and such).

As for compiling, yes, you'd have to select either "applet" or "android" at build-time. However, I think this can be done with zero source changes - so you'd have the same source code for both applets and android.

Dori

unread,
Sep 24, 2009, 3:35:43 AM9/24/09
to PulpCore
Hiya, thanks for replying.

The method that i posted above takes an int[] which represents the
pixels values for an image, instead of the android.graphics.Bitmap
object which is stated uses unpremulitplied colors. Im new to a lot of
this, and underdtand that an ARGB color can be stored as an 32-bit
int, with each 8-bit sections representing an ARGB channel, does this
work for both unpremultiplied & premulitplied colors (would
premultiplied not only need 24 bits to represent (AR AG AB) where the
alpha is 0 >= A <= 1 and any color componants between 0 -255?). I
imagine the int[] in the above method only takes one format, (pre or
unpre) but it doesent state what one, how do we find out?

sorry for all the questions, are there any good resources you could
point me too about this (apart from the pulpcore wiki?)

Thanks

Dori

On Sep 24, 5:43 am, David Brackeen <brack...@gmail.com> wrote:
> Yes, I think that's why PulpCore might need to use OpenGL. Also, better
> graphics chipsets are supposed to be coming in newer Android devices, so I
> think OpenGL is the way to go.
> I worry about the lack of a JIT in Android, but perhaps that will be fixed
> in the future. Hopefully sooner rather than later.
>
> In regards to porting, there's also audio and other issues to work with.
> Also I want to upgrade all the source to Java 5 (generics, varargs and
> such).
>
> As for compiling, yes, you'd have to select either "applet" or "android" at
> build-time. However, I think this can be done with zero source changes - so
> you'd have the same source code for both applets and android.
>

David Brackeen

unread,
Sep 24, 2009, 12:58:50 PM9/24/09
to pulp...@googlegroups.com
It looks like that method takes 8888 ARGB, unpremultiplied colors. It docs say "array of colors" and a "color" is defined here:

Dorian Cussen

unread,
Sep 24, 2009, 1:29:38 PM9/24/09
to pulp...@googlegroups.com
So using openGL draw methods instead would allow pulpcore to keep the premulitplied colors speed advantage?

2009/9/24 David Brackeen <brac...@gmail.com>

David Brackeen

unread,
Sep 24, 2009, 1:51:49 PM9/24/09
to pulp...@googlegroups.com
Yes.
Reply all
Reply to author
Forward
0 new messages