FYI: IRC log of LWJGL meeting regarding 0.9

[Matzon]

[20:56] * ErikDuijs has joined #lwjgl
[20:58] <Mazon> lo
[20:58] <vrm> lo
[20:59] <ErikDuijs> hi
[21:04] <Mazon> wonder when Cas and Spasi gets here...
[21:05] <UlfJack> wonder if .....
[21:07] <Mazon> elias: u alive?
[21:07] <elias> yep
[21:08] <Mazon> cool
[21:08] <Mazon> will give them 5 minutes more, then we'll just start
[21:08] <elias> ok
[21:13] <Middys> lum
[21:15] <Mazon> well, time's up
[21:15] <Mazon> we'll just begin
[21:16] <Mazon> first up, we plan to release around easter
[21:16] <Mazon> which would be around april the 11th
[21:16] <elias> whenis that exactly?
[21:16] <elias> too late..
[21:16] <Mazon> for what?
[21:16] <elias> asking when
[21:16] <elias> :-)
[21:16] <Mazon> ahh
[21:17] <elias> but still
[21:17] <Mazon> unless we need to do a lot of work, I don't think that
that date is unrealistic
[21:18] <Mazon> ErikDuijs: how's that date for you, to stabalize GLU and
write some tests ?
[21:18] <elias> I hope it's too pessimistic
[21:18] <elias> but it might be alright
[21:18] <ErikDuijs> I think I can manage it
[21:19] <Mazon> cool, we'll get back to GLU later
[21:19] <ErikDuijs> That is, if we would decide not to include tess &
nurbs
[21:19] <elias> fine by me
[21:19] <elias> they're not even in 0.8 anyway
[21:20] <ErikDuijs> ok :-)
[21:20] <Mazon> I still need to fix native cursor
[21:20] <Mazon> I had something going, but lost interrest - still
looking at it :/
[21:21] <Mazon> elias: no native cursor on mac, right ?
[21:21] <elias> no
[21:21] * UlfJack has quit IRC ("<[-P-]Scharlatan> bei andern
onlinegames kann man auch nich meckern ||| <[GoD]Redeemer85[Fritte]>
alle notgeil hier")
[21:21] <elias> it apparantly has 16*16 cursors anyway
[21:21] <elias> +only
[21:21] <Mazon> k
[21:21] <elias> so I didn't bother
[21:22] <Mazon> one thing that I am having some trouble with, is OAL
renaming - preferably I need to rename it to OAL10
[21:22] <Mazon> err - AL10
[21:22] <Mazon> however I need to have a -create method, and I don't
know where to place it
[21:22] <elias> SondContext.java?
[21:22] <elias> Sound
[21:23] <Mazon> well, that depends on whether we plan other engines?
[21:24] <elias> but is the naming the only trouble?
[21:24] <elias> +is
[21:24] <Mazon> no, naming isn't just where to place the create method
[21:24] <Mazon> OGL has its window
[21:24] <Mazon> oal has nothing
[21:25] <elias> not even something that resembles a context, device or
aything?
[21:25] <Mazon> well, I have contexts and devices - but they're private
[21:25] <Mazon> and will soon disapear into native code
[21:25] <elias> umm why?
[21:25] <Mazon> because they're just shell classes
[21:26] <elias> I thought the general consensus was to move stuf up into
java ...
[21:26] <elias> stuff
[21:26] <Mazon> yeah, well the device actually holds a pointer, which
I'd like to hide away in native code
[21:27] <Mazon> same goes for context
[21:27] <elias> well, Cas and I spoke about the exact opposie
[21:27] <Mazon> yeah, I know - but not for pointers ?
[21:27] <elias> indeed for pointers too
[21:28] <elias> as a long
[21:28] <elias> to accomodate 64 machines
[21:28] <Mazon> k
[21:28] <Mazon> so I actually shouldn't change anything in the oal code?
[21:28] <Mazon> only rename and move around
[21:28] <elias> I think so
[21:28] <Mazon> if at all that
[21:29] <elias> we'd like to do like swt
[21:29] <elias> where the only ative code are stubs for OS calls
[21:29] <elias> so the more code we have in java the better
[21:29] <Mazon> yes, maintanance wise
[21:29] <elias> I think renaming is still in order
[21:29] <elias> to match GL naming
[21:30] <Mazon> yeah, I am leaning towards: AL.java (which holds the
create) and AL10 which has actuall 1.0 methods (or all right now)
[21:30] <elias> sounds alright
[21:31] <Mazon> (everybody is welcome to comment on api changes...)
[21:31] <Mazon> ok, I'll work towards that then
[21:31] <Mazon> * Fix java 1.5 webstart bug | No longer relevant,
apparently Cas was just experiencing a snafu
[21:32] <Mazon> at least webstart works fine here
[21:32] <elias> yes, I think he said it worked again
[21:32] <ErikDuijs> snafu?
[21:32] <Mazon> situation normal all f*cked up
[21:33] <ErikDuijs> ah :-)
[21:33] <elias> but we need to be aware of 1.5 issues with lwjgl  - no
need to have a final 1.5 with lwjgl compatibilities
[21:33] <elias> +in
[21:33] <Mazon> ?
[21:33] <elias> incompatibilites
[21:34] <Mazon> ahh
[21:34] <Mazon> but are there any incompatibilities?
[21:34] <Mazon> I knwo of none
[21:34] <Mazon> know
[21:34] <elias> no, but I'm saying they're important
[21:34] <Mazon> agreed
[21:35] <Mazon> * Complete OGL1.5 | afaik, spasi has said it's done -
however I would like some tests to actually confirm its status
[21:35] <Mazon> I have access to glslang drivers
[21:35] <elias> isn't that hard given that no drivers has ogl 1.5 yet=?
[21:35] <elias> oh glslang
[21:35] <Mazon> and 1.5 drivers too
[21:35] <Mazon> last time I checked at least
[21:35] <elias> from ati?
[21:35] <Mazon> yes
[21:36] <elias> weird, I thought they were stuck on 1.4
[21:36] <Mazon> hang on
[21:36] <elias> 1.3 even
[21:37] <Mazon> only missing 1.5 is GL_EXT_shadow_funcs
[21:38] <elias> does spasi know that?
[21:38] <Mazon> else I have complete 1.1, 1.2, 1.3, 1.4, 2.0
[21:38] <elias> ah
[21:38] <Mazon> dunno
[21:38] <elias> from your drivers...
[21:38] <elias> sorry
[21:39] <Mazon> but still, can't really say that 1.5 is done, without
some kind of test
[21:40] <elias> sure
[21:40] <Mazon> also need tests for glslang
[21:40] <Mazon> which is 1.4 ?
[21:40] <elias> but most GL funcs are not testes in lwjgl...
[21:40] <elias> glslang is just  an extension?
[21:41] <Mazon> indeed, but they're as complex as glslang and other
programs
[21:41] <elias> not really a particular gl versin
[21:41] <elias> maybe, but doesn't make the API any more complex
[21:43] <elias> so what's next?
[21:45] * spasi has joined #lwjgl
[21:45] * ChanServ sets mode: +v spasi
[21:46] <ErikDuijs> Could we discuss GLU next? I'm sorry but I'm a bit
pressed for time...
[21:46] <elias> sure
[21:46] <elias> I have two things for GLU
[21:46] <elias> 1. gluErrorString
[21:47] <elias> needed for proper error reporting from LWJGL opengl
exceptions
[21:47] <elias> and
[21:47] <elias> 2. Can we have java arrays instead of buffers in GLU now
that it is java?
[21:48] <elias> for the fixed small data types I think arrays are
superior to buffers
[21:48] <elias> but what do others think?
[21:48] * Matzon has joined #lwjgl
[21:48] <ErikDuijs> I agree, but for the image scaling and mipmaps
buffers might be better
[21:48] * ChanServ sets mode: +v Matzon
[21:48] <Mazon> so we should deem 1.5 done, and take any bugfixes when
people actually use it ?
[21:48] <Mazon> well, I'll finish it off with spasi - no reason to hold
us up right now
[21:48] <Mazon> * Complete GLU | how much is missing from GLU ?
[21:48] <Mazon> all tests in cvs now uses erik's implementation
[21:48] <Mazon> and works fine
[21:48] * Mazon has quit IRC (Remote closed the connection)
[21:49] <Matzon> GRR
[21:49] <Matzon> f*cking BNC
[21:49] <Matzon> welcome spasi
[21:49] <Matzon> what was the last that anyone said ?
[21:49] <elias> ErikDuijs: yes for image data buffers ae better
[21:49] <elias>  < ErikDuijs> Could we discuss GLU next? I'm sorry but
I'm a bit pressed for time...
[21:49] <elias> 21:43:11 < elias> sure
[21:50] <elias> 21:45:17 < elias> but what do others think?
[21:50] <elias> 21:43:20 < elias> I have two things for GLU
[21:50] <elias> 21:43:32 < elias> 1. gluErrorString
[21:50] <elias> 21:43:58 < elias> needed for proper error reporting from
LWJGL opengl exceptions
[21:50] <spasi> hi, sorry for being late...
[21:50] <elias> 21:44:01 < elias> and
[21:50] <elias> 21:44:36 < elias> 2. Can we have java arrays instead of
buffers in GLU now that it is java?
[21:50] <elias> 21:45:08 < elias> for the fixed small data types I think
arrays are superior to buffers
[21:50] <elias> that's ok
[21:50] <elias> I think that we should consider gl15 and glslang done
tll people comlaing
[21:50] <elias> complain
[21:50] <Matzon> oki
[21:51] <elias> that's been the policy on other GL functions anyway...
[21:51] <elias> too much work in biulding tests anyway
[21:51] <elias> so, what do we think o GLU?
[21:51] <Matzon> heh
[21:51] <Matzon> well, I like the new implementation - but it needs a
good refactoring and cleanup
[21:51] <elias> arrays for small fixeddata types like viewport, matrices
and the like?
[21:52] <Matzon> well, glu isn't really about performance, but ease of

use
[21:52] <Matzon> so arrays are fine with me
[21:53] <ErikDuijs> Ok, I'll change things to use arrays. But what about
image data?
[21:53] <elias> direct buffer are probably worse anyway when GLU is java
code anway
[21:53] * Mazon has joined #LWJGL
[21:53] <elias> Erik: that's larger non-fixed data, so fr that, buffer
are probably better
[21:54] <elias> what do you others think?
[21:54] <Matzon> I concur
[21:54] <ErikDuijs> that's what I thought. It's more consistent with
other GL texture functions
[21:54] <Matzon> ErikDuijs: are there any parts of glu, you need a hand
with?
[21:55] <ErikDuijs> No, not really. There's not that much work left.
[21:56] <ErikDuijs> If I stumble on some troubles, I'll trouble you with
them anyway :-)
[21:57] <Matzon> cool
[21:57] <ErikDuijs> But if you guys don't mind, I'll have to leave. I'm
on somebody else's dial-up connection and all...
[21:58] <Matzon> yeah, it's ok
[21:58] <elias> ok
[21:58] <Matzon> someone will probably mail you the log
[21:58] <Matzon> I lost mine
[21:58] <Matzon> damn f*cking bnc
[21:58] <ErikDuijs> Ok, thanks everybody. Bye :-)
[21:58] <elias> bye
[21:58] <Matzon> bye
[21:58] * ErikDuijs has quit IRC
[21:58] <spasi> bye
[21:59] <Matzon> regarding static import, the plan is to use that, once
1.5 is out - right?
[21:59] <elias> in LWJGL code?
[21:59] <elias> or what?
[22:00] <Matzon> yea
[22:00] <Matzon> h
[22:00] <elias> yes
[22:00] <Matzon> cool, agreed then
[22:01] <Matzon> next up - post from spasi:
[22:01] <Matzon> We need to support render-to-texture. Currently it's
Windows only, but I
[22:01] <Matzon> think I read somewhere that support is coming for other
platforms. I
[22:01] <Matzon> remember something about platform independent p-buffer
extensions coming
[22:01] <Matzon> too. Anyway, we should make a platform independent
class, like Pbuffer.java,
[22:01] <Matzon> to handle render-to-texture. Or we can do it within
Pbuffer.java, since
[22:01] <Matzon> render-to-texture requires a p-buffer to work.
[22:01] <elias> indeed
[22:02] <elias> I was about to implemet it ages ago, but lost itnterest
sinc it was doze only :-)
[22:02] <elias> it should be a straightforward add on to the existing
pbuffer.ajava
[22:02] <elias> Pbuffer has an int capability field for that purpose
[22:03] <spasi> make it fast please! ;-)
[22:03] <elias> yeah, well...
[22:03] <elias> I'm not exactly a windoze guy...
[22:03] <elias> so it would be nice with other tkaers?
[22:03] <elias> takers
[22:04] <Matzon> I am bit swamped with cursor, oal, site, tests,
documentation
[22:04] <elias> so spasi, if you're up to it...
[22:04] <spasi> I'll see what I can do
[22:04] <Matzon> hah
[22:05] <elias> but we have to be very careful about extensins for one
platform only
[22:05] <elias> but I can see that render-to-tex is usefull
[22:05] <Matzon> lol - taking a jab at eax next?
[22:05] <Matzon> jap
[22:05] <elias> yes
[22:06] <elias> that's my next target
[22:06] <elias> unless you there's significant proof that it is on its
way to other OS'es
[22:06] <Matzon> I dont
[22:06] <elias> so
[22:06] <Matzon> however I think we should seperate it out ?
[22:06] <elias> what's the fate of it then?
[22:07] <elias> Cas had an idea of separating LWJGL into two parts
[22:07] <elias> lwjgl-core
[22:07] <Matzon> well, fwiw, I think it would be silly to remove it
entirely - by that account, we should remove all platform specific stuff
[22:07] <elias> and lwjgl-obscure
[22:07] <Matzon> lol obscure
[22:07] <elias> where we could have NV,ATI and win32 only exts
[22:07] <Matzon> lwjgl-optional would be a bit better
[22:07] <Matzon> and glu ?
[22:08] <elias> nah
[22:08] <elias> or that's maybe in lwjgl.tools
[22:08] <elias> lwjgl-tools
[22:08] <elias> the purpose of lwjgl-optioal was to mark it "use it but
don't expect t to be generally avaiabl"
[22:09] <Matzon> isn't lwjgl a bit small to seperate into 432 packages?
[22:09] <elias> that's why I'd say GLU should be in coe
[22:09] <elias> because it's always there per definition
[22:09] <Matzon> true
[22:10] <Matzon> I am open for it, but it would be something we should
define really soon, since 0.9 means api freeze
[22:10] <elias> I say remove EAX
[22:10] <Matzon> would you have multiple dll's then ?
[22:10] <elias> but that's just the penguin in me...
[22:10] <elias> yes
[22:11] <spasi> I agree separating something that is win32 only, but why
the NV,ATI ones?
[22:11] <Matzon> I wouldn't remove it - just make it into it's own
dll/jar
[22:11] <Matzon> since they're just as specific - just on hardware
[22:11] <elias> yes
[22:12] <Matzon> but by doing so, we actually make it possible to
support a lot of weird wgl stuff, by seperating to specific jar/dlls
[22:12] <spasi> but the lib user KNOWS that
[22:12] <elias> yes, but the exts does take up space...
[22:12] <elias> and it just as easy tobundle two dll as it is with one
[22:12] <elias> do
[22:13] <spasi> if it's not difficult, I'm ok then
[22:13] <elias> and as matzon says, it would make optional more open to
even more narrow exts, like WGL_NVor whatever
[22:13] <elias> and core more true to the meaning: only generally
avaiable exts and core GL
[22:14] <Matzon> any ext's at all?
[22:14] <elias> yes, arb nones
[22:14] <elias> ones
[22:14] <elias> and probably ext
[22:14] <Matzon> ahh
[22:14] <Matzon> fair enough
[22:14] <elias> and Pbuffer
[22:15] <Matzon> but it's basically a simple problem of new makefiles
and some editing to the ant script - no problem at all, as I see it ?
[22:15] <elias> a few native ones
[22:15] <elias> all exts depend on extgl now
[22:15] <elias> one dll handle and so on
[22:16] <elias> but that will be fixed in anyway because of JOGL
integration
[22:16] <Matzon> is Cas on top of that jogl stuff ?
[22:16] <elias> sort of
[22:16] <elias> I ight help out at some point
[22:16] <Matzon> k
[22:16] <Matzon> , think it's a step in the right direction
[22:17] <elias> the extgl split need a little more work for the JOGL
support to be clean
[22:17] <elias> indeed
[22:17] <Matzon> well, last item on my list is a biggie - Mac OS X
support. We *need* someone dedicated, that actually knows the ins and
outs of a mac
[22:18] <Matzon> though the current port "works", there are a lot of
stuff still to be fixed
[22:18] <elias> we will definitely buy a mac at some point
[22:18] <elias> when TT is nearing beta
[22:18] <Matzon> when is that, circa ?
[22:18] <elias> but that's is probably after 0.9
[22:18] <elias> cirka june-juli
[22:19] <Matzon> hmm
[22:19] <Matzon> bit late though
[22:19] <elias> so it's late
[22:19] <Matzon> and you would still have to learn a mac
[22:19] <elias> I did the basic port anyway
[22:19] <Matzon> especially the bundle stuff needs to be fixed
[22:19] <elias> so Im not totally n00b
[22:20] <Matzon> hehe
[22:20] <elias> and I have these wack plans of using JOGL for most f the
support
[22:20] <Matzon> my small adventure into Macs, left me banging my head
against the wall
[22:20] <elias> when the integration is donw
[22:20] <Matzon> so you'll take the path of swing ?
[22:21] <elias> yes the darkside
[22:21] <spasi>
[22:21] <elias> because java is standard that's the best way IMHO
[22:21] <elias> the same with linux and messagebox() really
[22:21] <Matzon> except, there'll be different versions of swing
deployed?
[22:22] <elias> are they incompatible?
[22:22] <Matzon> dunno - migth become it in a future version ?
[22:23] <Matzon> spasi: have you tested the 1.5 implementation ?
[22:24] <Matzon> or did you only have a nV card with 1.4 drivers?
[22:25] <spasi> no, not yet
[22:25] <spasi> the leaked 56.57 forceware has support for it
[22:25] <spasi> but I'm getting some really strange errors when using it
[22:25] <Matzon> cool - it's not critical, but would be nice
[22:25] <spasi> so, I'm still waiting for the official ones
[22:26] <Matzon> if you have a simple test, I could try and run it on my
radeon
[22:26] <spasi> well, I need to learn GLSlang first...
[22:27] <Matzon>
[22:28] <Matzon> so, last up - documentation - what to do about it?
[22:28] <Matzon> I am working on some stuff, but I've stalled lately
[22:28] <Matzon> and we really need a huge bunch of documentation
[22:28] * elias fakes away mode
[22:29] <elias> :-)
[22:29] <Matzon> heh
[22:29] <spasi> :-)
[22:29] <Matzon> the biggest problem is actually stale javadoc, which
needs to be identified (if any)
[22:29] <elias> but can we conclude that mac support is not holding 0.9
up?
[22:30] <Matzon> well, 0.9 should still work on mac - as it does today
[22:30] <elias> sure, but the "missing" features...
[22:30] <elias> ?
[22:30] <Matzon> I have access to an os 10.3 box with a setup tp compile
on
[22:30] <Matzon> yes
[22:30] <elias> ok
[22:31] <elias> docs: I wish that someone other than me did, GL refactor
is boring enough as itis :-/
[22:31] <Matzon> heh, well - docs not bad - it's just a question of
looking for motivation
[22:32] <Matzon> unfortunately - it's not right besides my PS2, with a
brand new copy of Final Fantasy X-2
[22:33] <Matzon> well, that concludes the meeting really - unless
someone else has somethiung to say?
[22:33] <Matzon> afaik, there is no unknown parts holding up 0.9 then ?
[22:33] <Middys> javadoc comments would do wonders
[22:33] <Middys> Maybe some community effort?
[22:33] <spasi> about docs, what needs to be done?
[22:34] <spasi> javadoc on every method?
[22:34] <Matzon> theoretically we need three kinds of doc:
[22:34] <Matzon> 1 - javadoc
[22:34] <Matzon> 2 - class usage
[22:34] <Matzon> 3 - tutorials
[22:34] <spasi> javadoc on -every- method?
[22:35] <Matzon> yes
[22:35] <spasi> I mean, it's still opengl...
[22:35] <Matzon> oh - not the ogl methods
[22:35] <Matzon> except
[22:35] <spasi> oh, ok
[22:35] <Matzon> we actually talked about copying man pages into java
doc
[22:35] <Matzon> would be rather neat
[22:35] <Matzon> but CRAP job to do
[22:36] <spasi>
[22:36] <vrm> I'm pretty sure nobody read lwjgl javadoc about opengl
methods
[22:36] <Optus> I do sometimes
[22:36] <elias> and I hI have one last thing to add:
[22:36] <elias> vorbis support
[22:37] <elias> simply by dropping libvorbis in the dll bundle
[22:37] <elias> need a littl e work on linux I guess
[22:37] <Matzon> well, the oal people are working on something regarding
enumeations
[22:37] <elias> but that's not strictly required for 0.9
[22:38] <Matzon> well, the whole enumeration thingy is a bit of a joke
actually - and a mess for lwjgl
[22:39] <elias> but tther than that, 0.9 is near :-)
[22:39] <Matzon> but no much I want to do about it - would get messy if
I were to fix it
[22:39] <elias> let's just wait for oal
[22:39] <elias> but why can't they jurry up already? :-)
[22:40] <elias> hurry
[22:40] <Matzon> yeah - when the guys get they're act together vorbis is
really simple to add support for
[22:40] <Matzon> rather - the cvs version actually supports it on
windows
[22:40] <Matzon> just linux (or windows) that need to agree on how to
add support
[22:40] <elias> okthen
[22:40] <Matzon> and have the god damn dame enumeration value
[22:41] <Matzon> dame = same
[22:41] <elias> I'm going afk again if we're finished
[22:41] <Matzon> yeah
[22:41] <Matzon> Thanks for joining people
[22:41] <elias> good evening then :-)