Merging LibGDX utilities from Ore Infinium about ktx HOT 14 CLOSED

I like the idea of "translating" clunky interfaces to Kotlin to add the missing nullability data. InputListener could go directly to the ktx-app module; not sure about InputProcessor though - doesn't it work on primitives, which are already assumed to be non-null?

ShaderProgram and TextureRegion extensions are nice, but I'm honestly not sure where to put them right now. (A similar use method could be added to Batch as well.) ktx-app, maybe? If we can think of enough extensions and utilities to justify this, we could start a new KTX module - ktx-graphics. For 3-4 methods it seems like an overkill. ; )

Sprite extensions create a new object on each call, which kind of goes against LibGDX policy (if there is one).

Rectangle, Vector2 and Random extensions would be great in ktx-math.

I did a similar thing with the alignment enum in gdx-lml, so I could parse alignment values in sort-of-HTML files - basically handling the string-to-int conversion. Without extensions methods that could consume the enum instances in Scene2D API, I don't see the use case for this in KTX - either way you're stuck with calling methods with ints.

Methods from KotlinExtensions.kt seem either too generic or too specific to your game needs.

Thank you for considering contributions. Please, keep merge requests to each module separate.

from ktx.

As far as Artemis utilities go, you can propose your solutions in #23 issue.

from ktx.

not sure about InputProcessor though - doesn't it work on primitives, which are already assumed to be non-null?

it's not just about nullability as my terrible comments neglect to mention...in my game for instance, i only actually want to implement a couple of those methods of the interface.

because libgdx targets java 6, doesn't have the default interface keyword..so you're forced to implement all functions even if they do nothing. so still a big benefit as far as cleaning it up goes.

from ktx.

in my game for instance, i only actually want to implement a couple of those methods of the interface.

An "adapter" of sorts then (Java libs seem to misuse the term, imho) - empty implementation to cut down the boilerplate. Yeah, I like that - since it's still an interface, I can see that it could be more useful than abstract classes with empty implementations that LibGDX provides.

from ktx.

yep. if libgdx targeted java 7 (actually i think..maybe 8 they arrived in), they could define their interfaces methods as eg 'public default void' and the method would be optional, and we wouldn't need this, but here we are 😄

from ktx.

Java 8. Yeah, Java is well known for its boilerplate ceremony.

Anyway, may I ask if you plan on using KTX in Ore Infinitum eventually? ; )

from ktx.

haha yes, been working on past few days (in a diff branch), been playing with the skin stuff and moving that over(and writing a new skin style), in between playing with coroutines for multithreaded world gen

from ktx.

Great. I already used KTX in game jams and the overall experience was, well, pleasant - no KTX bugs encountered, fortunately. But without some feedback from more developers and usage of KTX in a bigger project, I don't want to publish a non-beta release just yet. Don't hesitate to create an issue with some simple comments on the project if some part of it just doesn't "feel right".

from ktx.

yep, sounds good.

we should probably also have a 'uses ktx' list of projects in the readme or something so people can have real examples of it in action to take ideas from

from ktx.

I'm not comfortable linking to my dirty game jam code and empty "uses KTX" list wouldn't be so impressive, I'm afraid. Judging from the downloads from Maven Central, there are some KTX users out there, but none shared their story yet. But yeah, I'd like to create such list eventually.

from ktx.

If you don't mind, I can port some of your utilities to KTX (especially the math-related ones), so you can focus on ktx-tools.

from ktx.

Sure, if you want, you can steal whatever you find useful.

from ktx.

@sreich I think we moved all common utilities to KTX. I found the rest of the stuff too specific to your project or unlikely to be widely used. If you think something else should be added as well, please create a pull request. Thanks.

from ktx.

Yep, sounds good. My Artemis stuff I'll sit on for a while, see what changes I want for it etc.

from ktx.