[02:15:17] *** sseehh has quit IRC
[02:15:34] *** sseehh has joined #sgine
[02:15:34] *** sseehh has joined #sgine
[03:23:34] *** sseehh has quit IRC
[03:23:49] *** sseehh has joined #sgine
[03:23:49] *** sseehh has joined #sgine
[14:51:15] *** sseehh has quit IRC
[14:51:33] *** sseehh has joined #sgine
[14:51:33] *** sseehh has joined #sgine
[15:11:15] *** sseehh has quit IRC
[15:11:36] *** sseehh has joined #sgine
[15:17:31] *** darkfrog has joined #sgine
[16:37:43] *** sseehh has quit IRC
[16:41:13] *** sseehh has joined #sgine
[16:41:13] *** sseehh has joined #sgine
[19:00:43] *** lexn82 has joined #sgine
[19:40:17] <lexn82> darkfrog: sup?
[20:23:11] <darkfrog> lexn82: hey...how's it going?
[20:25:50] <lexn82> darkfrog: it's good, saw your vlc post
[20:26:30] <lexn82> pretty neat
[20:40:05] <darkfrog> lexn82: yeah, surprisingly good performance
[21:01:30] <lexn82> darkfrog: do you have to bundle vlc libs with it or the system must have vlc installed?
[21:01:47] <darkfrog> lexn82: either way
[21:03:52] <lexn82> darkfrog: nice!
[21:04:30] <darkfrog> lexn82: it's more of a proof of concept at this stage since I need my scenegraph before I create the "media project" on top
[21:04:46] <darkfrog> lexn82: right now I'm working on text support
[21:05:02] <darkfrog> lexn82: creating an editable document model
[21:05:02] <lexn82> rendering strings?
[21:05:18] <lexn82> i saw it already done in jogl, have you looked
[21:05:36] <darkfrog> more than just Strings...formatted content with multiple fonts, color, etc.
[21:05:51] <darkfrog> multi-line and editable in real-time
[21:06:11] <darkfrog> my goal is to make it capable enough to display HTML
[21:06:33] <darkfrog> or probably more appropriately like RTF docs
[21:07:08] <lexn82> ic
[21:07:15] <lexn82> here is what jogl has: http://download.java.net/media/jogl/jogl-2.x-docs/com/sun/opengl/util/awt/TextRenderer.html
[21:07:27] <lexn82> pretty much all the rendering, but no document model
[21:07:52] <darkfrog> nah, that's pretty much what I had in Sgine 0.1, but found it lacking
[21:08:33] <darkfrog> oh, it doesn't support wrapping
[21:08:57] <lexn82> it seems rather low level
[21:09:49] <darkfrog> http://code.google.com/p/sgine/source/browse/src/main/scala/org/sgine/ui/TextComponent.scala?name=0.1
[21:10:10] <darkfrog> that's what I had in the previous iteration and I'm going for something far more powerful this go-around
[21:10:49] <lexn82> got it
[21:11:10] <lexn82> im working on support for various texture formats
[21:11:24] <lexn82> have you looked into all the formats and which ones to support
[21:11:46] <darkfrog> honestly I'm sort of forcing RGBA right now
[21:12:13] <darkfrog> devs can program for this or they can use the built-in conversion features that will take any image format and convert it.
[21:12:51] <darkfrog> one of the underlying goals here is combining many textures into a larger texture map for efficiency, but additionally it gives me the benefit of simplicity.
[21:13:50] <lexn82> what about precompressed textures?
[21:15:25] <darkfrog> lexn82: currently just support PNG natively....I'm sure I'll have to expand that in the future, but I'm not doing much with 3d models yet, so it's mostly just UI related stuff for now.
[21:17:27] <lexn82> makes sence... im working on it backwards: defining all the formats before even having a renderer.
[21:18:24] <darkfrog> btw, my renderer fully supports Android at this point....that abstraction is actually working out quite well.
[21:18:47] <darkfrog> I'm getting close to being finished with the render layer and about to move on to the scenegraph
[21:21:55] <lexn82> darkfrog: you mean gl wrapper layer?
[21:22:22] <darkfrog> yep
[21:23:37] <lexn82> cool, im hoping to see some demos soon
[21:35:07] <darkfrog> lexn82: specifically with Android?
[21:36:35] <lexn82> darkfrog: something with the gl wrapper
[21:36:54] <lexn82> other than tutorials
[21:37:28] <lexn82> we need to get people off java and onto scala
[21:38:08] <lexn82> then both of us will get users
[21:39:19] <lexn82> i am trying to cover a different market: im focusing on an extensive toolkit to build engines
[21:39:35] <lexn82> with a simple prototype engine
[21:42:28] <darkfrog> well, I personally don't want to emphasis the gl wrapper too much as for me it's a means to an end, not really an end of its own....part of the purpose of it though is to allow it to be used as an end if so desired though.
[21:42:39] <darkfrog> my focus is on the higher level abstraction layer
[21:43:27] <darkfrog> I'm just one person, so I'm trying to leverage my time as best I can to accomplish my goals
[21:43:46] <darkfrog> so creating a game or app just using the gl wrapper isn't really on my agenda
[21:43:53] <darkfrog> neither is it even for the rendering abstraction
[21:44:03] <darkfrog> the scenegraph is another story though
[21:45:41] <lexn82> i hear ya, same here
[21:48:01] <darkfrog> lexn82: btw, with my new mutable maths I can rotate a cube forever without any garbage creation whatsoever. :)
[21:52:01] <lexn82> darkfrog: quaternions?
[21:52:42] <darkfrog> lexn82: currently just Matrix
[21:53:21] <lexn82> matrices destabilize, so it's not forever :P
[21:55:00] <lexn82> i am curious what desgined you have settled with, do you have math in svn?
[21:55:15] <darkfrog> mercurial, but yes
[21:55:31] <darkfrog> it's still really early development and doesn't have all methods in place yet
[21:55:49] <darkfrog> I need to dedicate time to adding in all the necessary features for the math library
[21:55:56] <darkfrog> and do a lot of cleanup
[21:56:09] <darkfrog> but the first test was validating that it works and is efficient
[21:56:30] <darkfrog> I'm taking an extremely practical approach this go around
[21:56:41] <lexn82> no fancy stuff?
[21:58:36] <darkfrog> not at this stage
[21:59:28] <darkfrog> my main objective at this point is to push forward to a functional scenegraph and be operational with at least the same functionality that was in 0.1 but without excess garbage creation and support for Android.
[22:02:28] <lexn82> you should be careful with virtual calls on android
[22:02:55] <lexn82> last time ive checked, android vm doesnt like traits
[22:03:32] <darkfrog> in my testing it didn't have any trouble
[22:04:17] <lexn82> did you test on actual android or an emulator?
[22:04:24] <darkfrog> both
[22:05:34] <darkfrog> I did a prototype of an SBT plugin to deploy Android applications to both the emulator and device.
[22:06:16] <lexn82> neat
[22:14:41] <lexn82> darkfrog: how do you deal with mutable math that invlovles matrix constants?
[22:14:49] <lexn82> basically mixing mutable and immutable matrices
[22:20:27] <darkfrog> lexn82: not sure I follow?
[22:20:51] <darkfrog> lexn82: if you are multiplying a mutable against an immutable the mutable will be modified
[22:21:02] <lexn82> what about the other way around?
[22:21:12] <darkfrog> the immutable will create a new instance
[22:21:35] <lexn82> so if you have just math.Matrix, then you dont know if it will change or a new instance will be made?
[22:21:50] <darkfrog> correct
[22:21:55] <darkfrog> that's kind of the point
[22:22:07] <darkfrog> at least for the *= or +=
[22:22:25] <darkfrog> for * or + operators it would create a new instance of the left-hand type
[22:22:52] <lexn82> but then *= is just *
[22:22:55] <lexn82> for immutable
[22:22:56] <darkfrog> yep
[22:23:14] <lexn82> i dont understand the different with what i have
[22:23:17] <darkfrog> actually there wouldn't be an explicit implementation at all for *=
[22:23:26] <darkfrog> it's very similar
[22:23:33] <darkfrog> but my mutability is much cleaner
[22:23:54] <darkfrog> I can avoid any instance creation if I want to
[22:24:34] <darkfrog> perhaps Simplex3d allows that as well in a more recent version, but as of 0.1 codebase when I was using it, there were lots of places where I couldn't avoid instance creation
[22:25:15] <lexn82> it always had *= methods
[22:25:30] <lexn82> the only thing was missign was scale=, rotate=, that kind of stuff
[22:25:51] <lexn82> and then if you are using build in functions, they will create new instances
[22:26:09] <darkfrog> right
[22:26:49] <darkfrog> scale, rotate, and translate were the two primary places it was problematic
[22:26:54] <darkfrog> err, three. :p
[22:27:26] <lexn82> only because we couldnt figure out the naming
[22:27:44] <darkfrog> that's where my route conveniently solved the problem
[22:28:20] <lexn82> the problem is the virtual call, and the trait
[22:28:48] <darkfrog> performance has been incredible with it
[22:29:11] <darkfrog> I think it ends up just being an abstract class
[22:29:20] <lexn82> nop
[22:29:36] <darkfrog> well...I can always force it to be. :p
[22:29:57] <lexn82> it will help somewhat, but not 100%
[22:30:08] <lexn82> actually, it would be a major boost
[22:30:39] <darkfrog> I might do some testing to validate that, but in my tests currently I'm FAR out-performing what 0.1 was doing
[22:31:20] *** CIA-73 has quit IRC
[22:33:09] <lexn82> just math alone or the whole thing
[22:35:03] <darkfrog> whole thing
[22:35:15] <lexn82> not really a fair comparision then ;)
[22:35:30] <darkfrog> but for the most part everything else should technically be slower
[22:35:46] <darkfrog> ...since I'm doing practically the same stuff, I've just got another layer around it.
[22:37:02] <lexn82> anyway, i had reasons to settle on my current desgin. so any advice i wuold give would lead for more similarities to what i have...
[22:37:23] <lexn82> so i guess i should just shut up and let you design what you want
[22:39:02] <lexn82> so as difficult as it is to stop talking about matrix internals i wont bring it up again... :(
[22:39:54] <darkfrog> hehe
[22:40:04] <darkfrog> I don't mind
[22:41:13] <darkfrog> I would even be happy to switch back to Simplex3d if you made to concessions: 1.) Apply your efforts to the Sgine engine rather than creating your own engine, 2.) Provide a better separation of mutable and immutable as I'm doing in my math library.
[22:41:56] <darkfrog> I think your math library is great, but I think it's a bit over-complicated and does not define clear barriers between mutability and immutability
[22:42:28] <lexn82> thanx... and i agree with both points
[22:43:13] <lexn82> it is a bit overcomplicated, and mutability may be a bit non-inuitive at first
[22:44:33] <lexn82> compliexity is a result of competeness and consistency, so cant be helped...
[22:45:02] <darkfrog> I think we both have different objectives in the 3d space and different specialities...if we were to work on the same engine I think we'd be able to accomplish a broader engine much faster
[22:45:08] <lexn82> and mutability is designed to be safe from accidental errors
[22:45:39] <darkfrog> perhaps some completeness should be downplayed in an effort to simplify
[22:45:59] <lexn82> it was...
[22:46:02] <darkfrog> who cares if you can handle every single scenario in every single way if the end result is a less usable library?
[22:46:26] <lexn82> i dont see how it is less usable...
[22:46:38] <darkfrog> #1 for a math library I would think should be conciseness followed closely by simplicity
[22:47:26] <darkfrog> accomplish everything it needs to with the smallest amount of code in the most efficient way possible
[22:47:31] *** CIA-80 has joined #sgine
[22:47:47] <lexn82> from the user point of view, its pretty concise
[22:47:48] <darkfrog> simplex provides so much it's a bit daunting to consider
[22:48:04] <darkfrog> I'm a user and it does not seem very concise to me
[22:48:12] <darkfrog> powerful without a doubt, but not concise
[22:48:16] <lexn82> well, you seem to not mind GLSL
[22:48:25] <darkfrog> and very hard to dig through the code and/or docs
[22:48:42] <darkfrog> it's more complicated as an API than GLSL
[22:48:57] <lexn82> only the property part
[22:49:27] <darkfrog> AnyMat3x4d, ReadMat3x4d, .... and fifty other variations. :p
[22:49:42] <lexn82> you dont have to worry about those
[22:49:51] <darkfrog> ah, but because they are there I do
[22:50:13] <darkfrog> and because I may be digging through code or docs I have to figure out where functionality lies
[22:50:37] <lexn82> that part is the same for all my projets
[22:50:45] <lexn82> it's hard to navigate the internals
[22:50:54] <lexn82> it doesnt matter what i write, really
[22:50:58] <darkfrog> hehe
[22:51:10] <darkfrog> don't you see this as something that should be optimized?
[22:51:14] <lexn82> so if you think math is too complicated, you dont want me digging in your internals
[22:51:22] <lexn82> it is optimized
[22:51:29] <lexn82> thats why its so complicated
[22:51:37] <darkfrog> I try to focus on thinking about my frameworks from the perspective of a new user trying to develop with it.
[22:52:03] <lexn82> thats why ive made tutorials
[22:52:11] <darkfrog> if you see the forum and mailing list you'll see lots of comments from people that are in awe of how easy it is to get going because of that.
[22:52:11] <lexn82> so you dont have to dig in the internals
[22:52:35] <darkfrog> that's not acceptable to me as a developer...I don't want your tutorial, I want the docs
[22:53:12] <lexn82> im busy on the engine to write docs
[22:53:18] <lexn82> i really want to, but no time...
[22:53:22] <darkfrog> if I'm trying to figure out how to push my matrix into a buffer I don't want to search through tutorials...I want to look at the matrix class and see if there are methods to do so.
[22:53:35] <lexn82> there are no methods to do so
[22:53:46] <darkfrog> I'm not talking about documenting right now...I'm bad about that myself
[22:54:07] <lexn82> matrix stack is deprecated...
[22:54:14] <darkfrog> I'm talking about writing your API in such a way that you don't necessarily even need the text docs to understand it
[22:54:39] <lexn82> hey, it makes perfect sense to me...
[22:54:54] <lexn82> i was told my tutorials make it very easy to use
[22:54:58] <darkfrog> lexn82: the question is, is this only for you, or do you want others to use it?
[22:55:16] <lexn82> sure, that's why i have the tutorials ;)
[22:55:20] <darkfrog> just trying to help...if you disagree that's fine. :)
[22:55:41] <darkfrog> it's for these reasons that I'm writing my own math library
[22:56:00] <lexn82> that's ok
[22:56:07] <darkfrog> Sgine *should* be a prime candidate to use Simplex
[22:56:20] <darkfrog> but I have these reasons that I'm not
[22:56:25] <lexn82> i cant claim my library will work well on android until the compiler plugin is developed
[22:57:15] <lexn82> which is time...
[22:57:30] <darkfrog> I'm honestly really not focusing on Android at this point...my only objective for Android was the wrapper layer and that's done.
[22:57:47] <lexn82> i thought our primary disagreement was around the garbage
[22:57:51] <darkfrog> I know I *can* release on Android and that's good enough for me until I need to
[22:57:58] <darkfrog> yep
[22:58:11] <darkfrog> garbage is a big deal on desktop as well
[22:59:08] <lexn82> ive done lots of tests, and i just dont see it being a big deal
[22:59:19] <lexn82> on the desktop
[23:00:16] <lexn82> so there lies the root of our disagreement
[23:00:16] <lexn82> as for complexity, you will end up with something similar
[23:00:16] <lexn82> you already have 3 Matrix4 objects
[23:00:48] <lexn82> the different is i gave them distinct names: ReadMat4 for the common type, ConstMat4 for immutable, and Mat4 for mutable
[23:01:04] <darkfrog> you aren't centering around animation to the degree I am
[23:01:20] <lexn82> i dont see how having the same names makes it less complicated, if anything it's a lot more confusion
[23:01:34] <darkfrog> animations show those small gc hits that you wouldn't expect to make any visual impact
[23:01:35] <lexn82> what do you mean animation?
[23:01:46] <lexn82> there are no gc hits
[23:01:49] <darkfrog> so you think that Scala's List is confusing?
[23:02:20] <darkfrog> just rotating a bunch of cubes on the screen you can see choppiness when GC occurs
[23:02:43] <darkfrog> this was one of the big frustration points of 0.1
[23:02:58] <lexn82> when it occurs
[23:02:59] <lexn82> there is no gc if you write it right
[23:03:10] <darkfrog> GCs were happening a couple times per second in complex scenes that matrix transformations were occurring
[23:03:21] <lexn82> garbage gets eliminated by jvm, via stack allocation
[23:03:54] <lexn82> taht was due to the properties
[23:04:01] <lexn82> which consume an object
[23:04:08] <darkfrog> I shouldn't have to think about "writing it right" when all I'm trying to do is rotate and using mutability would solve my problem incredibly efficiently
[23:04:09] <lexn82> so one has to be created
[23:04:55] <lexn82> see, you dont have to worry about this under normal circumstances
[23:05:07] <lexn82> when you have to worry abou it is during api design
[23:05:22] <darkfrog> using the same name is a take from Scala's collections that I think makes it very nice to switch between mutable and immutable
[23:05:26] <lexn82> if you have virtual methods that consume objects, then those objects cannot be elimiated
[23:05:59] <lexn82> so, what im designing avoid this altogether, so you will not have to worry about garbage
[23:06:25] <darkfrog> but there's still not a clear separation between mutable and immutable
[23:06:44] <lexn82> sure there si
[23:06:55] <lexn82> ConstMat is immutable, Mat is mutable
[23:06:57] <darkfrog> how do I scale?
[23:07:09] <lexn82> mat.applyScale(2)
[23:07:29] <lexn82> will apply it to the mat
[23:07:30] <darkfrog> that doesn't create a new object?
[23:07:34] <lexn82> no
[23:07:40] <lexn82> mat scale(2) will make a new object
[23:08:06] <lexn82> math objects are not like collections
[23:08:22] <lexn82> they can be used in complex expressions, when mutability becomes very hard to track
[23:08:28] <darkfrog> well, at the end of the day you're still creating your own engine which keeps me from wanting to use Simplex. :p
[23:08:44] <lexn82> that's ok
[23:09:17] <lexn82> politics are politics, i just dont want to have misunderstanding on the technical lvel
[23:09:37] <lexn82> besides, if you saw what i have, you would trip
[23:09:43] <lexn82> if you think math is complex
[23:10:00] <lexn82> my engine stuff is not meant for people to navigate the internals
[23:10:47] <lexn82> it's easy to use, once you are shown the api
[23:10:59] <lexn82> but its probably impossible to understand the api from the code
[23:11:05] <lexn82> due to implicits and stuff
[23:11:18] <darkfrog> then a higher-level abstraction should be created to simplify
[23:11:34] <lexn82> cant, its the core
[23:11:46] <lexn82> the skeleton on which all builts
[23:11:53] <lexn82> and it's not simplifiable any more
[23:12:18] <lexn82> it does have dynamic property allocation and change tracking build in
[23:12:18] <darkfrog> I'm referring a layer on top of it, not below it
[23:12:36] <lexn82> yeah, that will be an engine
[23:12:40] <lexn82> what i have is an engine toolkit
[23:13:10] <lexn82> but yeah, change tracking and dynamic properties make the internals pretty crazy
[23:13:55] <lexn82> and its nothing like sgine... so we are making different things
[23:14:24] <lexn82> i had something very particular in mind, that's why im not working on sgine
[23:14:56] <lexn82> its not because i want to make my own engine, i just want to make something very different from what you are making
[23:21:49] <darkfrog> fair enough. :o
[23:25:06] <lexn82> i can even see people complaining its too complicated and rolling with sgine instead... and i dont really care.
[23:25:28] <lexn82> i just had it in my head and i have to write it out... its one of those things
[23:50:01] *** darkfrog has quit IRC





top