compatibility with desktop version

[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

[paulscode]

Would another option be to get rid of RGBColor and instead create a faux java.awt.Color for the AE version (and any other awt-related classes used in the desktop version)?  That way the compiler wouldn't generate NoSuchMethodError's.

[EgonOlsen]

The idea was to make it portable on the source code level, not on the binary level. And i don't want to bind myself to the state of awt.Color. Once it changes, i would have to decide with which version to go...
Can't you simply create two projects (one desktop, one Android) and one additional source folder with the shared stuff that is linked into both, i.e. that will be compiled in both environments? That way, it's also easier to detect version mismatches at compile time instead of running into runtime errors.

[raft]

i dont think adding java.awt.Color to AE is a good idea. if i remember correctly applications are not allowed to use java package name. it may work for now but may result in other problems in the future.

@egon, i can do that but if i dont miss anything, that will either result in duplicating code or abstracting such unshared actions via interfaces or so. it takes me where this thread started.

if i were you, i would add RGBColor to desktop, duplicate awt.Color methods and deprecate the old ones. i would do a similar thing for light and others if any. i agree that will clutter desktop api, but that's how api's evolve i suppose.

i found this a fairly big decisision. but for years you had struggled to keep SW and HW renderers aligned. this is something similar i suppose.

just my two cents..

[EgonOlsen]

Maybe i'm a bit confused now, but how does adding a second source-directory with the shared source code to both of your projects differ from linking to the project in that aspect?

[EgonOlsen]

This is what i mean:



...where the Hurgel.java is the one that comes from a shared src-directory somewhere but both projects are using it.

[raft]

mm ok, i had misunderstood you indeed i wasnt aware of that feature in eclipse.
that will work (and worked indeed) for RGBColor, thanks but for the rest my two cents still remains. it's your call of course

[EgonOlsen]

For the Light class, you can solve this by doing imports with wildcards only IMHO. I.e. import com.threed.jpct.* and com.threed.jpct.util.* in all classes that are using Light. The worst thing that may happen in the Android project is a warning about an unused import.

[raft]

that should work but come on, that's only a hack. that's not the right way to do it. i may prefer abstracting light to it.
anyway it's your decision

[EgonOlsen]

Yes, it's a bit hacky... However, i'm really not sure what would be best here...maybe moving jPCT's Light class from util to the main package is the best option. Moving the AE-version into util is worse, because it would hide the only way to work with lights in AE in a package where nobody would search for it. But moving it into the main package leaves me with Lights and Light in the same package which can be even more confusing than the current state.

The idea behind moving and cutting some stuff for AE was to keep the APIs as similar as possible to ease porting while still taking the opportunity to clean up some things and to tailor the API to the platform. I didn't really expected people (and that includes me) to use both APIs for one project very often. The target audience is just too different IMHO.

[raft]

moving Light from util to main package sounds to be the best option. besides it breaks backward compatibility. i dont agree having two classes called Lights and Light will create confusion. it's like Collections and Collection. you can even change the name if dont care about backward compatibility. or deprecate one and remove a few releases later

personally i think cutting some functionality off from AE makes sense as they are not supported there. but moving functionality does not.

I didn't really expected people (and that includes me) to use both APIs for one project very often. The target audience is just too different IMHO.

arguable. even if this is the case, different applications may share some libraries. for example i use some of karga classes in my game. luckily you didnt change SimpleVector's name to Vector3 or so

anyway, your call