Modules that are need to be developed

[devolonter]

List of non-existing modules that you think are basic and they need to be developed for inclusion in the future.

[skn3]

collision checking functions eg RectsOverlap, CircleOverlaps, PointInRect, etc

[swoolcock]

There's some non-frameworky utility stuff in Diddy and in my own personal projects that might be useful too:
Colorspace conversion (in Diddy). HSL, RGB, more could be added.
Matrix/Vector classes (mine are based heavily on the libGDX ones and have a lot of optimisations).
Array manipulation utilities (in Diddy)
String.format / sprintf-style formatting (in Diddy)
Internationalization (in Diddy)

There's also a side-project in Diddy for multithreading, but that might be out of scope.

[maffl-dev]

I would definetely vote for these modules you mentioned.
Vector
Matrix
Color
ArrayUtil

For the color, there could be a class for each color space?
RgbColor, HslColor, etc. and then you can convert between these.

[swoolcock]

I think it would be better to have a single Color class, then use getters
or properties to access each component per colorspace. As for the other
modules, I'll look at cleaning up the Diddy ones and removing dependencies.

[devolonter]

I also vote for the inclusion of classes: Vector, Matrix, Color and ArrayUtil. Please, look at the collection’s scheme in wiki, are there any questions or objections?

[skn3]

Seems nice to me 👍

[swoolcock]

I was actually about to post my own structure proposal, but then I realised it's almost identical to that one anyway. :)
A couple of suggestions though:

pub.native: Any externed stuff goes in here and is not referenced anywhere else in the library. Anything that's not supported by a particular platform should have a NOP stub method or a pure Monkey implementation (as mentioned before).

pub.math: Have separate classes for matrix/vector dimensions. ie. Matrix3, Matrix4, Vector2, Vector3.

Might be nice to have a MathUtil class there somewhere too that can handle easing and interpolation. Easing/interpolation aren't really restricted to graphics, so I think they belong in the math module. It'd also be a nice place to put things like clamping, and possibly a better pseudorandom number generator.

[maffl-dev]

I have an interpolation only module (no dependencies on mojo).
Maybe on top of that we could integrate it with our vector class? Then you would have:
math.Tween(Float)
math.Tween(Vector)

[swoolcock]

Sounds good. To be honest I think it would be useful for Color too. Tweening RGB is just horrid, but tweening HSL is lovely.
Reason why RGB is fail: Tweening between red and yellow won't give you orange as you'd expect. (255,0,0) to (0,255,255) passes through grey (128,128,128) instead. With HSL you'd leave saturation and luminance alone, and just tween the hue.

Rather than restricting tweening to these kinds of data types, I propose we make Vector/Color implement an ITweenable interface that allows you to tween as many different components as you like. You could do 1000 components if you want! ;)

[maffl-dev]

Yeah, you can't really tween rgb values - I agree on that.

The problem with an ITweenable interface is the following:
A vector has 2 values(x,y) and color has 3(h, s, l). So the challenge is to boil that down into a common interface.
You could return arrays or use reflection but then you have unnecessary overhead.

So maybe there is an obvious solution to that? It's because I tried to do exactly that (ITweenable interface) and failed because every class has a different amount of values which it returns.

EDIT: Oh, you mean the vector and color class have to implement the tweening themselves? That's a possibility.

[swoolcock]

Haven't tested, probably has compilation errors:

Interface ITweenable
Method GetComponentCount:Int()
Method SetComponent:Void(component:Int, value:Float)
Method GetComponent:Float(component:Int)
End

Class Vector2 Implements ITweenable
Field x:Float, y:Float

 Method GetComponentCount:Int()
     Return 2
 End

 Method SetComponent:Void(component:Int, value:Float)
     Select component
         Case 0
             x = value
         Case 1
             y = value
     End
 End

 Method GetComponent:Float(component:Int)
     Select component
         Case 0
             Return x
         Case 1
             Return y
     End
     Return 0
 End

End

Class Color Implements ITweenable
Field hue:Float, saturation:Float, luminance:Float, alpha:Float

 Method GetComponentCount:Int()
     Return 4
 End

 Method SetComponent:Void(component:Int, value:Float)
     Select component
         Case 0
             hue = value
         Case 1
             saturation = value
         Case 2
             luminance = value
         Case 3
             alpha = value
     End
 End

 Method GetComponent:Float(component:Int)
     Select component
         Case 0
             Return hue
         Case 1
             Return saturation
         Case 2
             Return luminance
         Case 3
             Return alpha
     End
     Return 0
 End

End

Function Tween:Void(target:ITweenable, startValue:ITweenable,
endValue:ITweenable, progress:Float)
For Local i:Int = 0 Until target.GetComponentCount()
Local startComp:Float = startValue.GetComponent(i)
Local endComp:Float = endValue.GetComponent(i)
target.SetComponent(i, startComp + (endComp-startComp)*progress)
Next
End

[maffl-dev]

Well, that's great :)
That would mean we only need 2 interfaces/functions:

Tween:Float(...) ' for normal Interpolation
Tween:Void(...) ' for custom classes which implement ITweenable

I think handling when something is finished should be left to the user.
Regarding event handling. Is a general event system out of scope for pub?

[skn3]

Looks good but maybe not the I______ class names ;) ? I think we should try and keep things verbose.

Although I dont think its sensible to require that if you want a vector in your app that you then have to import the tween lib? We have to be careful that we don't turn pub into a framework.

[swoolcock]

Hmm... you'd want to make an event system very extendable and generic, which leaves a lot of work up to the developer, defeating the purpose of the module.

[skn3]

You could do a basic callback system?
https://bitbucket.org/skn3/monkeymodules/src/master/skn3/callbacks