#jogamp @ irc.freenode.net - 20140629 05:05:28 (UTC)

20140629 05:05:28 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20140628050528.html
20140629 05:05:28 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20140629050528.html
20140629 06:43:31 <sgothel> ^^ Nirei: You simply put the module's LICENSE.txt file i.e. like LICENSE-JOGL.txt LICENSE-GLUEGEN.txt into your source and/or binary distribution - thats it. Sure it would be nice if you reference us on your webpage, like 'Using Jogamp http://jogamp.org ...'
20140629 07:03:07 * monsieur_max (~maxime@anon) has joined #jogamp
20140629 07:47:46 * ___m___ (~Mike]@anon) Quit ()
20140629 08:19:52 * hija (~hija@anon) Quit (Quit: hija)
20140629 09:45:23 * Guest30096 (~Odin@anon) Quit (*.net *.split)
20140629 09:51:49 * odin_ (~Odin@anon) has joined #jogamp
20140629 09:52:12 * odin_ is now known as Guest72647
20140629 10:25:46 <rmk0> sgothel: nice catch on 1027
20140629 10:25:56 <rmk0> \o/
20140629 10:26:48 <sgothel> all a bit messy in package com.jogamp.opengl.util - i.e. should have clear jar/package separation .. next time
20140629 10:28:23 <sgothel> hope the FloatUtil unroll changes won't harm some low profile cpus .. hmm
20140629 10:48:03 * Nirei (~nirei@anon) has joined #jogamp
20140629 10:50:10 <Nirei> Hey, sgothel, thanks for the answer! That's what I'll do. :D
20140629 10:50:56 <sgothel> great
20140629 10:51:25 <sgothel> since our license files cover all user 3rd party licenses as well, e.g. jogl uses
20140629 10:51:41 <sgothel> hence including our license files is most appropriate ..
20140629 11:46:47 * Guest72647 (~Odin@anon) Quit (*.net *.split)
20140629 11:55:01 * odin_ (~Odin@anon) has joined #jogamp
20140629 11:55:41 * odin_ is now known as Guest78960
20140629 13:04:49 <Nirei> Uuh... I'm having a hard time making 2.1.5 work in Eclipse... 2.1.4 was working allright now I keep getting this:
20140629 13:05:15 <Nirei> Catched FileNotFoundException: /home/nirei/Documentos/Codigo/Java/tobacco/jogamp/jar/gluegen-rt-android-natives-linux-amd64.jar (No existe el fichero o el directorio), while addNativeJarLibsImpl(classFromJavaJar class com.jogamp.common.os.Platform, classJarURI jar:file:/home/nirei/Documentos/Codigo/Java/tobacco/jogamp/jar/gluegen-rt-android.jar!/com/jogamp/common/os/Platform.class, nativeJarBaseName gluegen-rt-android-natives-linux-am
20140629 13:05:15 <Nirei> Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /home/nirei/git/Tobacco/tobacco-game-test/libgluegen-rt.so
20140629 13:05:47 <Nirei> Thing is I'm not even importing gluegen-rt-android-natives...
20140629 13:06:29 <Nirei> There's probably something wrong with my build path but I don't know what it is... I'm trying to use auto-natives as I did before.
20140629 13:07:42 <sgothel> don't use android jar files in your classpath, then such a android native lookup shall not happen
20140629 13:08:51 <sgothel> at least not 'upfront' .. i.e. they should be in the end .. so that the loading gluegen base class (i.e. Platform) comes from non-android
20140629 13:10:28 <sgothel> gluegen-rt-android.jar <- Platform was loaded from here !
20140629 13:20:06 <Nirei> : )) Fixed!
20140629 13:21:11 <Nirei> Thanks so much
20140629 13:22:22 <Nirei> That was weird, the files were in the build path but they were unchecked, I though that was enough to make eclipse ignore them
20140629 13:22:30 <Nirei> But obv. it's not
20140629 15:41:43 * zzuegg (zzuegg@anon) has joined #jogamp
20140629 16:10:47 * Nirei (~nirei@anon) has left #jogamp
20140629 16:12:19 * zaphos (~Matthew@anon) has joined #jogamp
20140629 16:37:17 * magaio (~magaio@anon) Quit (Ping timeout: 245 seconds)
20140629 16:37:28 * magaio (~magaio@anon) has joined #jogamp
20140629 17:06:09 * Guest78960 (~Odin@anon) Quit (Quit: Leaving)
20140629 17:10:48 * kermyt (~kermyt@anon) Quit (Ping timeout: 248 seconds)
20140629 17:16:03 * kermyt (~kermyt@anon) has joined #jogamp
20140629 17:37:51 * bgroenks (~chatzilla@anon) has joined #jogamp
20140629 17:38:32 * bgroenks (~chatzilla@anon) Quit (Client Quit)
20140629 20:05:48 * zaphos1 (~Matthew@anon) has joined #jogamp
20140629 20:09:18 * kermyt_ (~kermyt@anon) has joined #jogamp
20140629 20:14:40 * zaphos (~Matthew@anon) Quit (*.net *.split)
20140629 20:17:42 * kermyt (~kermyt@anon) Quit (Ping timeout: 255 seconds)
20140629 20:17:43 * kermyt_ is now known as kermyt
20140629 20:23:41 * magaio (~magaio@anon) Quit (Ping timeout: 260 seconds)
20140629 20:23:48 * magaio_ (~magaio@anon) has joined #jogamp
20140629 20:24:12 * magaio_ is now known as magaio
20140629 20:32:49 * bgroenks (~chatzilla@anon) has joined #jogamp
20140629 20:33:11 * bgroenks (~chatzilla@anon) Quit (Client Quit)
20140629 20:42:52 * hharrison (~chatzilla@anon) has joined #jogamp
20140629 20:43:52 <hharrison> just looking at bug 1027, maybe that points to how jogl src/ could be organized
20140629 20:43:58 <hharrison> src/jogl-util/
20140629 20:44:03 <hharrison> etc
20140629 20:44:35 <sgothel> too many packages / jar - plus we may change packaging
20140629 20:45:17 <sgothel> however, the content / packages should be able to be sealed .. i.e. unique packages .. can't do it now though
20140629 20:45:54 <sgothel> when all that is cleaned up .. then we might be able to do unique source -> package locations :)
20140629 21:01:51 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20140629 21:39:08 <rmk0> i've toyed with the idea of sneakily getting everything into a maven project setup
20140629 21:39:20 <rmk0> mainly just to see if it's even possible
20140629 21:39:38 <rmk0> find it quite hard to work on gluegen/jogl due to how much has to be rebuilt each time, as it's one big monolithic piece
20140629 21:40:00 <rmk0> point would be to separate everything into maven modules, with the correct interdependencies
20140629 21:40:10 <rmk0> i might surprise you lot with it one day, we'll see how it goes...
20140629 22:00:34 * zaphos1 (~Matthew@anon) Quit (Quit: Leaving.)
20140629 22:24:24 <hharrison> rmk0: feel free to fire me any work in progress stuff, that's kind of what I was headed for with the recent gluegen patches to separate out the antlr stuff
20140629 22:25:34 <hharrison> commit e8bc9edd3c39170af038ab23b8cdca9ffd6f2d56
20140629 22:26:14 * bgroenks (~chatzilla@anon) has joined #jogamp
20140629 22:26:20 <rmk0> hharrison: will do!
20140629 22:28:12 <bgroenks> anyone from JogAmp here?
20140629 22:28:37 <rmk0> bgroenks: almost everyone
20140629 22:28:57 <bgroenks> I figured. Perhaps more specifically, anyone who knows JOGL well?
20140629 22:29:05 <rmk0> .. almost everyone!
20140629 22:29:08 <bgroenks> :D
20140629 22:29:47 <bgroenks> rmk0: Just checking! Do you know if GL2GL3 is available from a GL2 profile?
20140629 22:30:21 <rmk0> hm...
20140629 22:31:15 <rmk0> think it should be
20140629 22:31:47 <rmk0> http://jogamp.org/jogl/doc/uml/html/
20140629 22:32:13 <rmk0> is intended to be the common subset of GL3 and GL2
20140629 22:32:23 <rmk0> the core profile of GL3, that is
20140629 22:32:35 <bgroenks> Right.
20140629 22:32:55 <bgroenks> so then GLContext.getGL().getGL2GL3() should work from a GL2 profile
20140629 22:33:10 <rmk0> yep
20140629 22:34:16 <bgroenks> hmm but then why are VAO methods available? won't those fail under GL2?
20140629 22:35:03 <rmk0> interesting...
20140629 22:35:20 * rmk0 prods sgothel
20140629 22:36:32 <bgroenks> I'm pretty sure the GLContext/GLProfile docs say that GL2 goes up to OpenGL 3.0
20140629 22:37:03 <bgroenks> which is when VAOs were added, but this causes problems on systems that only support, say, OpenGL 2.1
20140629 22:39:25 <rmk0> this looks like a mistake... they're inherited from the GL2ES3 interface
20140629 22:41:12 <rmk0> obviously the vertex array functions aren't in the common subset of GL2 and ES3
20140629 22:42:02 <bgroenks> and GL2 inherits from GL2GL3
20140629 22:42:28 <bgroenks> a GL2 object actually has the methods for VAOs, i.e. glGenVertexArrays, glBindVertexArray, etc
20140629 22:42:31 <bgroenks> which is odd to me
20140629 22:43:22 <rmk0> it is a bit
20140629 22:43:51 <rmk0> thing is, the GL2 interface also covers things like framebuffers
20140629 22:44:06 <rmk0> which obviously didn't exist in 2.1 without extensions (jogl will quietly use the extensions if they're there)
20140629 22:44:24 <rmk0> so i'm not sure the interfaces are perfect guides to compatibility (at least when it comes to these olde versions of opengl)
20140629 22:44:38 <bgroenks> maybe not
20140629 22:44:45 <bgroenks> From the GL2 javadoc: "This interface contains all OpenGL [ 1.0 .. 3.0 ] methods, as well as most of it's extensions defined at the time of this specification. "
20140629 22:44:59 <bgroenks> so it looks like it includes GL 3.0 stuff
20140629 22:45:22 <rmk0> it may be that sgothel saw this and thought it wasn't worth the extra complexity to make them invisible (and split the interfaces)
20140629 22:45:42 <rmk0> he's the one that decided what went where the last time things changed (when ES3 appeared)
20140629 22:45:56 <bgroenks> so if you're writing in compatibility for GL 2.1, what would you use?
20140629 22:46:55 <rmk0> is a tough question
20140629 22:47:19 <bgroenks> GL2ES1?
20140629 22:47:44 <rmk0> think it probably depends what you're writing
20140629 22:47:52 <rmk0> are you using the fixed function pipeline?
20140629 22:48:14 <bgroenks> for the backwards compatible part, yes. for the core profile stuff no (obviously)
20140629 22:48:49 <rmk0> i mean, personally, i stick to the core profile and target >= 3.0
20140629 22:49:01 <rmk0> only the programmable pipeline
20140629 22:49:19 <rmk0> in my case, supporting 2.1 is a few bits of conditional code
20140629 22:49:33 <rmk0> if you have large divergent code paths though...
20140629 22:49:41 <bgroenks> yes, I would. but this is a 2D graphics library, so I figured it might be expected for simpler projects that are perfectly doable on lower end hardware
20140629 22:49:56 <rmk0> right
20140629 22:50:16 <rmk0> i still have some hardware from 2008 here that can only do 2.1 and ES2
20140629 22:50:37 <bgroenks> My laptop, for example, is brand new, and the integrated graphics (it has dedicated too, but that's besides the point) can only do up to 3.0
20140629 22:50:49 <rmk0> ow... you sure?
20140629 22:50:54 <rmk0> what's the gpu?
20140629 22:50:55 <bgroenks> according to JOGL at least
20140629 22:51:04 <bgroenks> GTX760M
20140629 22:51:25 <rmk0> you should be able to get better than 3.0 on that... may be that you're asking JOGL the wrong way
20140629 22:51:34 <rmk0> it'll pick a safe default
20140629 22:51:47 <rmk0> would that be with GLProfile.getDefault()?
20140629 22:51:47 <bgroenks> GLContext.getGLVersion()
20140629 22:51:59 <bgroenks> GLProfile.getDefault() gives a GL2 profile
20140629 22:52:07 <rmk0> hrm... which OS?
20140629 22:52:23 <bgroenks> getGLVersion() prints out OpenGL 3.0 GLSL #version 130
20140629 22:52:39 <bgroenks> Hmm I think that was on Linux actually, which might explain it :D
20140629 22:52:49 <rmk0> is that with the open driver or the binary driver?
20140629 22:52:57 <bgroenks> nvidia's
20140629 22:53:00 <rmk0> right
20140629 22:53:04 <bgroenks> 331.something
20140629 22:53:13 <rmk0> might be worth trying GLProfile.get(GL3)
20140629 22:53:30 <bgroenks> hmm but that doesn't change what getGLVersion prints right?
20140629 22:53:51 <rmk0> well if you're calling getGLVersion(), it means you've already opened a context
20140629 22:54:10 <rmk0> but requesting a different profile before opening a context can give you a more modern context
20140629 22:54:15 <bgroenks> fair enough
20140629 22:54:23 <rmk0> if i ask for the default context here, i get 3.0
20140629 22:54:29 <rmk0> if i ask for a core GL3 context, i get 3.3
20140629 22:54:35 <bgroenks> what if you ask for default?
20140629 22:54:54 <rmk0> ^^ 3.0
20140629 22:56:05 <rmk0> you certainly shouldn't be stuck with 3.0 on modern hardware, regardless of the driver
20140629 22:56:16 <rmk0> and i'd expect an even higher context with binary drivers
20140629 22:56:44 <rmk0> almost certainly 4.3+ on that hardware
20140629 22:57:15 <bgroenks> with integrated?
20140629 22:57:22 <bgroenks> I get 4.4 on the graphics card
20140629 22:58:12 <rmk0> yeah, even with integrated
20140629 22:58:14 <bgroenks> I just switched to Windows to test it. getDefault is giving me 4.0 for integrated graphics
20140629 22:58:34 <bgroenks> also why doesn't Windows let you widen the command prompt >:(
20140629 22:58:43 <rmk0> hehe
20140629 22:58:59 <rmk0> have to set the number of columns manually in the window settings, for some reason
20140629 22:59:07 <rmk0> doubt cmd.exe has been updated since 2001
20140629 22:59:56 <rmk0> i'm not actually sure how JOGL decides what the default profile is
20140629 23:00:08 <rmk0> i tend to ask for GL2, GL3, GLES2, etc, specifically
20140629 23:00:59 <bgroenks> do you ask for GLES2 on desktop hardware?
20140629 23:01:47 <rmk0> the choice is usually made by the program... so the end-user configures it
20140629 23:01:55 <rmk0> what i mean is that i don't usually let jogl decide
20140629 23:02:23 <bgroenks> how do you know what hardware the user has without a context?
20140629 23:03:03 <rmk0> jogl does profile discovery by trying to open contexts behind the scenes, to learn what's available
20140629 23:03:19 <rmk0> so then it knows what's actually available when you ask it for a usable context
20140629 23:03:44 <rmk0> er... not sure if that's what you asked
20140629 23:04:00 <bgroenks> yeah I mean how do you which one to ask for?
20140629 23:04:06 <bgroenks> do you know*
20140629 23:05:44 <rmk0> ok, two things... i ask for the one that the user tells my program to ask for (because i make it a configuration option), but i also tell them what possible versions are available with the GLProfile functions
20140629 23:06:12 <rmk0> can call GLProfile.isAvailable() for each profile name, and so on
20140629 23:06:58 <bgroenks> hmm
20140629 23:07:00 <bgroenks> ok
20140629 23:07:28 <rmk0> i think in your case, if you're writing a general purpose library
20140629 23:07:31 <bgroenks> My main check (after I have the context) is for GLSL version 150
20140629 23:07:47 <rmk0> right
20140629 23:08:01 <bgroenks> I resort to FFP/GL2 without it
20140629 23:08:08 <rmk0> ... i'd probably have your code just accept a GLContext and do the right thing based on whatever context you're given
20140629 23:08:09 <bgroenks> because I hate pre-core shaders
20140629 23:08:19 <rmk0> and possibly reject contexts you can't support
20140629 23:08:25 <rmk0> rather than ask for any profiles yourself, i mean
20140629 23:08:53 <bgroenks> GLProfile.getDefault(), check for supported shaders, but then how do I know which GL interface to use?
20140629 23:10:07 <rmk0> if you've got a GL2 context, it'll always be safe to use GL2GL3 or GL2ES3 (with the caveat that you have to manually avoid the vertex array functions)
20140629 23:10:24 <rmk0> if you've got GL3 or above, it's always safe to use GL3ES3, as nothing has been deprecated since 3.1
20140629 23:11:08 <bgroenks> Or just always use GL2GL3 :S
20140629 23:11:14 <rmk0> or that!
20140629 23:11:27 <bgroenks> I'm not currently using anything added post 3.2
20140629 23:11:29 <bgroenks> I don't think
20140629 23:11:40 <rmk0> can get a lot done with 3.1
20140629 23:12:02 <rmk0> obviously possible to implement something roughly equivalent to the source engine with just the functionality of 3.1
20140629 23:12:09 <bgroenks> especially in 2D, no tessellation or anything to go modern for
20140629 23:12:18 <rmk0> yeah
20140629 23:12:45 <bgroenks> source engine is great lol
20140629 23:13:08 <rmk0> 3.0 is okish, but they obviously didn't rip out the guts until 3.1
20140629 23:13:26 <rmk0> 3.1 is a sort of sane baseline
20140629 23:13:35 <bgroenks> did they ever fix the sound loading glitch?
20140629 23:13:53 <rmk0> no idea!
20140629 23:14:22 <bgroenks> do they still use DirectX on Windows?
20140629 23:14:29 <bgroenks> or did they switch to 100% OpenGL?
20140629 23:14:50 <rmk0> pretty sure it's still directx on windows
20140629 23:15:03 <bgroenks> Hmmm. I wish that would stop happening.
20140629 23:15:17 <rmk0> it might
20140629 23:15:43 <bgroenks> DirectX just makes life harder for everyone else.
20140629 23:15:55 <rmk0> yeah, i can't be bothered with it
20140629 23:16:07 <rmk0> i can target everything with opengl, or one platform with directx
20140629 23:16:18 <rmk0> doesn't make sense for me to do otherwise
20140629 23:16:41 <bgroenks> yep
20140629 23:17:17 <bgroenks> I also find it odd that EVERY DirectX application has to install DirectX every time they are installed.
20140629 23:17:29 <rmk0> yeah, not sure what's going on there
20140629 23:17:36 <bgroenks> OpenGL is just there
20140629 23:19:20 <bgroenks> Ok so with the dedicated card on Linux, I'm getting GLVersion=4.4, GLSL 440
20140629 23:20:43 <rmk0> that's more like it
20140629 23:22:08 <bgroenks> Hmm but on the PRIME "power saving" profile AKA integrated graphics, I'm still getting GLVersion=3.0 GLSL 130
20140629 23:22:22 <bgroenks> maybe intel just doesn't like updating linux drivers lol
20140629 23:22:26 <rmk0> is that when asking for a GL3 profile?
20140629 23:22:39 <bgroenks> hmm no that's with default, let me try asking for GL3
20140629 23:23:08 <rmk0> with an intel gpu on linux, i'd expect 3.3
20140629 23:23:20 <rmk0> at least with reasonably recent drivers and mesa
20140629 23:24:13 <bgroenks> asking for GL3 I get 3.3
20140629 23:24:19 <bgroenks> you are correct
20140629 23:24:21 <rmk0> \o/
20140629 23:24:46 <rmk0> they probably give 3.0 by default for backwards compatibility
20140629 23:25:28 <bgroenks> would it be too ambitious to ask for GL4?
20140629 23:25:37 <rmk0> think so
20140629 23:25:53 <rmk0> not sure the hardware is capable of it
20140629 23:27:18 <bgroenks> is gl_FragColor still reserved by the driver?
20140629 23:27:28 <bgroenks> as in, can you not use it as an out variable?
20140629 23:27:45 <bgroenks> hmm sorry let me rephrase that
20140629 23:27:48 <rmk0> the spec says you can't use anything beginning with gl_ yourself
20140629 23:27:55 <bgroenks> ^ fair enough
20140629 23:28:32 <bgroenks> but I guess they still have gl_FragColor initialized internally in 3.3 because the compiler fails with a "gl_FragColor" redeclared error
20140629 23:28:46 <rmk0> hm!
20140629 23:29:04 <rmk0> ... did you add a #version directive?
20140629 23:29:10 <bgroenks> yesir
20140629 23:29:14 <rmk0> weird
20140629 23:29:21 <bgroenks> yeah #version 150
20140629 23:29:47 <rmk0> sounds like an accident on their part
20140629 23:30:17 <bgroenks> I wonder if it prints that error for anything starting with gl_
20140629 23:30:22 <rmk0> they're not known for their excellent drivers, although i've not had problems personally
20140629 23:30:37 <bgroenks> well it worked on LInux
20140629 23:30:38 <rmk0> had a friend submit patches to them repeatedly for basic things like checking the return value of malloc()
20140629 23:30:41 <bgroenks> sorry
20140629 23:30:45 <bgroenks> didn't work on linux
20140629 23:30:50 <bgroenks> worked on Windows
20140629 23:30:57 <bgroenks> wait submit patches to Nvidia?
20140629 23:31:02 <rmk0> intel
20140629 23:31:06 <bgroenks> oh haha
20140629 23:31:20 <bgroenks> they probably just spend all their time on the hardware
20140629 23:31:49 <rmk0> it seems like they have two small teams working furiously on completely separate linux and windows drivers, and not really listening to bug reports
20140629 23:32:34 <bgroenks> do they at least open source their linux drivers?
20140629 23:32:43 <bgroenks> because Nvidia can't even do that >_>
20140629 23:32:45 <rmk0> yeah
20140629 23:33:05 <rmk0> the windows drivers are open source too, i seem to remember
20140629 23:33:13 <rmk0> just nobody bothering to build them from source
20140629 23:33:55 <bgroenks> well it appears that the integrated graphics driver on Windows didn't care about the gl_FragColor thing, but on Linux it did
20140629 23:33:59 <bgroenks> so take that as you will
20140629 23:34:13 <rmk0> hehe
20140629 23:34:22 <bgroenks> everything is always allowed on Windows
20140629 23:34:26 <bgroenks> imperative from Microsoft
20140629 23:34:46 <rmk0> be GRATUITOUS in what you accept
20140629 23:35:00 <bgroenks> And never do error checking.
20140629 23:35:11 <bgroenks> That's for <80% market people.
20140630 00:29:30 * [Mike] (~Mike]@anon) has joined #jogamp
20140630 00:35:02 <bgroenks> rmk0: you still here?
20140630 03:45:29 * bgroenks (~chatzilla@anon) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131206145537])
20140630 03:51:56 * kermyt (~kermyt@anon) Quit (Ping timeout: 240 seconds)
20140630 03:56:23 * kermyt (~kermyt@anon) has joined #jogamp
20140630 03:57:56 <sgothel> good morning. @Mark 'mavenizing' everything .. oh well :)
20140630 04:01:42 <sgothel> VAO in GL2, e.g. glGenVertexArray(..), it's GL2 extension 'ARB_vertex_array_object', our API docs mentions all sources of things
20140630 04:22:45 * hharrison (~chatzilla@anon) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140611055721])
20140630 05:05:29 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20140630050529.html