jPCT-AE - a 3d engine for Android > Support

compatibility with desktop version

(1/3) > >>

raft:
hi,

i'm a developing a game for android. as i dont have a device at the moment, it seemed natural to develop game logic in desktop version and port to android. however there are some practical difficulties in this approach. there are some minor differences in api's and that forces me to either duplicate the code or abstract the actions with interfaces or so. a bit overkill or performance killer for such simple tasks.

i believe making both api's as identical as possible is highly beneficial. in theory android version can be a subset of desktop version. AE is still in alpha state so i suppose it wont be problem for anyone.

the differences i've noticed and my two cents:
* Light class moved from util package to regular package. i guess this is for hiding world.addLight method. deprecating desktop's old Lights and Light class may be an option. or the other way around
* As android doesnt have awt color, AE uses a seperate RGB color class. same can be added to desktop version.
* desktop doesn't have Texture.keepPixelData() method. it doesnt make sense in desktop version but a method can still be added. indeed desktop version can have false as default and android can have true

just my two cents
r a f t

EgonOlsen:
I'm not very happy with the current situation myself. However, i don't like the idea of adding too much stuff from AE back to jPCT either. Anyway, please give this jar a try: http://www.jpct.net/download/beta/jpct.jar. It adds the keepPixelData()-method (which isn't completely pointless in desktop jPCT if you set Config.glAvoidTextureCopies to true, so that's just fine) as well as the RGBColor-class (which simply extends awt's color class). Regarding Light, i'm not going to change that one. Afterall, it's just a different import.

Another thing that you might come across are methods with "filler objects" that i've introduced in AE. I.e. instead of writing sv=Object3D.getTranslation() you can now write sv=Object3D.getTranslation(toFill), which will fill the "toFill"-SimpleVector and return it in addition. Android's garbage collection is so bad, that it's mandatory to avoid creation of short lived objects at almost all costs. However, this somehow clutters the desktop API, because it's simply not needed there. I've tried to back port these methods anyway.

I agree that it would be best if AE is a strict subset of jPCT, but i don't think that i can ensure this all the time. If you stumble upon other stuff that's missing, please let me know. Maybe it's not intentionally and i just forgot to back port it.
 

raft:
cool, thanks :)

so for moving a light around i need to abstract it but that's ok, i can live with it.

for the filler objects, maybe instead of using filler methods, making AE methods always return the same instance can be an option. a static one or an instance one. fill in the object and return it. i believe this will be ok if this behaviour is properly documented

EgonOlsen:
I think i'll stick with the filler methods. That instance option is more error prone IMHO. And you'll most likely end up constantly setting these instances before calling the actual method anyway, so it's cheaper to do it in one method call instead of two.
 

raft:
i'm having difficulty to setup eclipse with new RGBColor in desktop version. maybe you can help.

i need a base project which contains my game logic and other projects (GL and Android gui's) should depend on. if my base project uses AE in classpath, GL (desktop) client fails in runtime with NoSuchMethodError Object3D.setAdditionalColor(RGBColor). if i do the inverse and make my base project use desktop jPCT in classpath, Android client fails with a VerifyError (rejects Object3D.setAdditionalColor(awt.Color)) method

Navigation

[0] Message Index

[#] Next page