[00:11:19] *** Cultz has quit IRC
[00:12:33] *** Spkka has quit IRC
[00:16:34] *** itewsh has quit IRC
[00:23:46] *** scai has left ##opengl
[00:30:06] *** Jophish has quit IRC
[00:48:37] *** Entelin has joined ##OpenGL
[00:49:44] *** tokemonstah has quit IRC
[00:50:30] <HideousNashimoto> Does anyone have experience with "oglconsole" I can't seem to get input when I compiled it for windows, I seen on irc logs that this guy roxlu, fixed it by modifying code on line 737, but that was long time ago in 2006, and source code changed in the meantime http://echelog.matzon.dk/logs/browse/opengl/1160258400
[00:50:59] <HideousNashimoto> no in file oglconsole.h on line 737 is whitespace
[00:51:06] <HideousNashimoto> *now
[00:57:30] *** Yustme has quit IRC
[00:57:56] *** XT95___ has quit IRC
[01:02:27] *** pist0l-fish has joined ##OpenGL
[01:03:40] <pist0l-fish> hello all. I would like to import a png file to use as a texture with gluBuild2DMipmaps, but would like a parser that reads the png file into GL_RGBA format. Does anyone know anything like that? Thanks in advance.
[01:06:44] <Weiss> pist0l-fish: here is my implementation: http://pastebin.com/da897e0f - should do almost exactly what you want (using libPNG)
[01:07:34] <pist0l-fish> :) thanks!
[01:07:54] <HideousNashimoto> Weiss, why you don't use C++?
[01:09:24] <Weiss> HideousNashimoto: various reasons. i like being a little closer to the metal sometimes. i use a lot of OO concepts in my code even though i write in C. i guess most of all i just prefer the very clean syntax
[01:09:32] <tmccrary> lol
[01:09:36] <tmccrary> C is close to the metal
[01:09:39] <tmccrary> nice
[01:09:45] <Weiss> closeR
[01:10:13] <pist0l-fish> Weiss: I think I'll have to port some of your mallocs and frees in that case
[01:10:17] <HideousNashimoto> has anyone worked with oglconsole?
[01:10:33] <HideousNashimoto> I can't get any input when I compile it on winblows
[01:12:13] <pist0l-fish> Weiss: sorry to bother you, but could you please http://codepad.org/ your code? I keep attempting to copy and paste but I end up copying more than the source (the line numbers)
[01:12:30] <Weiss> pist0l-fish: should all be dead easy. there's nothing there that's anything much more than what's in the libpng manual and the GL manual
[01:12:50] <Weiss> pist0l-fish: hmm.. copy it from the white scrolly box at the bottom instead?
[01:14:32] <pist0l-fish> Weiss: oh, good point :)
[01:15:09] *** iion has joined ##OpenGL
[01:15:27] *** eu-prleu-peupeu1 has joined ##OpenGL
[01:17:43] *** eu-prleu-peupeu1 has left ##OpenGL
[01:20:32] *** Jophish has joined ##OpenGL
[01:22:48] *** eu-prleu-peupeu has quit IRC
[01:26:22] *** korff_home has quit IRC
[01:27:22] *** rabbit- has joined ##OpenGL
[01:31:23] *** Eforen has joined ##opengl
[01:31:38] *** elite01 has quit IRC
[01:34:01] *** povman has joined ##OpenGL
[01:34:07] *** dv_ has quit IRC
[01:34:09] *** xp_prg has joined ##OpenGL
[01:36:19] <JoshDreamland> Hola again, tacos
[01:36:29] <JoshDreamland> I wanted to ask about the best way to draw a bitmap.
[01:36:31] <JoshDreamland> Right now,
[01:36:36] <JoshDreamland> I load it into memory myself,
[01:36:39] <JoshDreamland> then load as a texture,
[01:36:48] <JoshDreamland> then just draw a quad with that texture bound.
[01:36:52] <JoshDreamland> Is there a better way?
[01:37:19] <MatthiasM> you could allocate a PBO, map the PBO, load the image into that mapped PBO, unmap, upload
[01:37:42] <JoshDreamland> PBO being that really fast extension whose name I can't remember?
[01:37:58] <JoshDreamland> Something Buffer Object...
[01:38:07] <JoshDreamland> Pixel, right?
[01:38:14] <JoshDreamland> yeah
[01:38:19] *** iion has quit IRC
[01:38:32] <JoshDreamland> do you know how widely supported that extension is?
[01:38:37] *** iion has joined ##OpenGL
[01:38:44] <JoshDreamland> because I kinda got screwed over with FBO
[01:38:56] *** gaffa has quit IRC
[01:38:57] <JoshDreamland> because not even 10% of my userbase could use them XD
[01:39:05] <MatthiasM> well - doing a fallbackl when no PBOP is available is very easy
[01:39:19] <MatthiasM> as you could just abstract it as memory manager
[01:39:22] <JoshDreamland> how big's the overhead?
[01:39:27] <JoshDreamland> ooh, you know,
[01:39:30] <JoshDreamland> could I, say,
[01:39:42] <JoshDreamland> make a pointer-to for a function,
[01:39:47] <JoshDreamland> then if PBO is available,
[01:39:55] <JoshDreamland> make it point to something that calls PBO,
[01:39:59] *** Bollinger has quit IRC
[01:40:03] <MatthiasM> if you load an image - you need to allocate memory anyway
[01:40:04] <JoshDreamland> otherwise fall back to quad nastiness?
[01:40:14] <JoshDreamland> yeah
[01:40:37] <JoshDreamland> I'm looking at the cost of having PBO should it not be supported
[01:40:44] <MatthiasM> PBO only allows you to let OGL allocate memory for texture up/down load - it does not change how you load the image or how you display it
[01:40:57] <MatthiasM> if you don't have PBO you allocate a buffer using new
[01:41:15] <JoshDreamland> does texturing work the same way if I do?
[01:41:20] <MatthiasM> yep
[01:41:30] <JoshDreamland> but it'll just make thing's faster?
[01:41:42] <JoshDreamland> I shoulda asked a long time ago. Thanks much!
[01:41:51] <MatthiasM> the only difference is if a PBO is bound then the data pointer of gltexImage2D is interpreted as offset into the PBO
[01:42:14] <JoshDreamland> But I don't notice, because I make the same call, right?
[01:42:15] <MatthiasM> it reduces the number of required buffer copies
[01:42:27] <JoshDreamland> that's excellent
[01:42:45] <MatthiasM> and it may allow gltexImage2D to be executed in the background without blocking your app - because the buffer is owned by GL not by your app
[01:43:14] <JoshDreamland> ^_^
[01:43:33] <JoshDreamland> Now I'll just implement those and lie to my users that I mysteriously overlooked those.
[01:43:56] *** pist0l-fish has quit IRC
[01:47:22] *** m4ggus has quit IRC
[01:47:23] *** m4ggus_ has joined ##opengl
[01:47:31] *** m4ggus_ is now known as m4ggus
[01:48:21] <RTFM_FTW> think of PBO (concerning texture uplaods) as the poor man's APPLE_texture_range, APPLE_client_storage path for vendors outside of Apple :P
[01:48:49] <RTFM_FTW> PBO is much more of a win when it comes to reading data back from the server
[01:49:05] <JoshDreamland> server?
[01:49:06] <MatthiasM> or when you can fill the mapped buffer in another thread
[01:49:09] <JoshDreamland> like X server?
[01:49:19] *** x0rx0r has quit IRC
[01:49:21] <JoshDreamland> th...
[01:49:23] <tmccrary> like the GPU
[01:49:26] <MatthiasM> glX in this case
[01:49:27] <JoshDreamland> ah
[01:49:33] <JoshDreamland> okay
[01:49:35] *** povman has quit IRC
[01:49:49] *** tmccrary has quit IRC
[01:49:58] <RTFM_FTW> MatthiasM while that is better its still significantly worse that the APPLE specific path I mentioned above
[01:50:06] <RTFM_FTW> since you still have to copy the data
[01:50:21] <MatthiasM> yep - but as Apple is not my main target - meh
[01:50:38] <RTFM_FTW> its really unfortunate that you cannot allow the GL to *directly* operate on a client side pointer to data
[01:50:52] <RTFM_FTW> through this path
[01:51:04] <MatthiasM> yeah - could have a lot of useful usages
[01:51:11] <RTFM_FTW> indeed it does :D
[01:51:14] <RTFM_FTW> heh
[01:51:19] <JoshDreamland> er, wouldn't that be slower than molasses uphill?
[01:51:27] <MatthiasM> but it requires HW support to read from arbitary memory
[01:51:33] <RTFM_FTW> not really
[01:51:50] <JoshDreamland> you're talking about Mac; it is, you just don't notice
[01:51:55] <RTFM_FTW> it requires HW support for GART texturing
[01:52:05] <JoshDreamland> sounds scary
[01:52:10] <RTFM_FTW> which we have had for *many* generations now
[01:52:16] <RTFM_FTW> all vendors have had this
[01:52:39] <RTFM_FTW> as long as you get the alignment right its hella fast
[01:52:58] <JoshDreamland> I just managed to make something to save the screen as a bitmap
[01:53:02] <JoshDreamland> I'm happy for the day
[01:53:10] <RTFM_FTW> i.e. this path should come *very* close to the PCIe / AGP interface limits
[01:53:31] <JoshDreamland> I have no idea what a path is in graphics, sorry.
[01:53:32] <RTFM_FTW> (for the STREAM update case)
[01:53:57] <MatthiasM> I'm not sure if every GART implementation is able to access 64bit memoyr ranges
[01:54:07] *** tmccrary has joined ##OpenGL
[01:54:10] <MatthiasM> and it would require locking of user space memory
[01:54:22] <MatthiasM> which might be an issue for some OSes
[01:54:39] <RTFM_FTW> believe it or not every OS ultimately needs to do this :)
[01:54:44] <MatthiasM> but a workaround could be to allow a PBO be read as texture while it's mapped
[01:54:47] <RTFM_FTW> at least any of the ones we care about here
[01:54:56] <RTFM_FTW> i.e. Windows, Linux, Mac OS X etc.
[01:55:14] <JoshDreamland> well, I'll add PBO to my todo list
[01:55:25] <RTFM_FTW> since they all currently use GPU accelerated compositing window servers
[01:55:29] <JoshDreamland> but I'ma steer clear of whatever you're talking about now
[01:55:41] <JoshDreamland> it scares me ._.
[01:55:42] <RTFM_FTW> and a quick path for texture submission / updating is a requirement for those workloads
[01:55:50] <MatthiasM> yep
[01:55:52] <RTFM_FTW> the same goes for video
[01:56:31] <RTFM_FTW> the only matter here is whether or not that vendor specific *magic* is exposed to the client :P
[01:56:47] <MatthiasM> btw - I discovered "poor" PCIe memory read performance on many MB chips (the card reads from main memory) - mostly related to small read completion block sizes (most use only 64byte)
[01:56:58] <RTFM_FTW> yep
[01:57:27] <MatthiasM> this basicly limits PCIe reads to 75%-80% bandwidth
[01:58:11] <MatthiasM> do you know of any MB chipsets which support a larger read completion ?
[01:59:01] *** mm765^away is now known as mm765
[02:02:05] *** Xmas| has quit IRC
[02:02:33] *** sparky has quit IRC
[02:05:22] *** AlastairLynn has quit IRC
[02:05:41] *** sparky has joined ##OpenGL
[02:05:49] *** tmccrary has quit IRC
[02:06:25] *** dennda has quit IRC
[02:06:30] *** tmccrary1 has quit IRC
[02:06:31] *** dennda has joined ##opengl
[02:10:26] *** tmccrary has joined ##OpenGL
[02:12:36] *** HideousNashimoto has quit IRC
[02:12:47] <JoshDreamland> okay
[02:12:53] <JoshDreamland> so on closer inspection
[02:12:55] <JoshDreamland> it turns out
[02:12:58] <JoshDreamland> my image should be blue
[02:13:03] <JoshDreamland> but it's purple
[02:13:07] <JoshDreamland> woops.
[02:17:17] *** Jophish has quit IRC
[02:21:38] <JoshDreamland> This doesn't actually make sense.
[02:21:43] <JoshDreamland> Whites are coming out gray...
[02:21:52] <JoshDreamland> everything's darker
[02:21:55] <JoshDreamland> and the blue color
[02:22:00] <JoshDreamland> is now brown
[02:22:07] <MatthiasM> JoshDreamland: maybe using GL_BYTE instead of GL_UNSIGNED_BYTE ?
[02:22:20] *** sparky_ has joined ##OpenGL
[02:22:21] <JoshDreamland> oh right, I'm using byte
[02:22:25] <MatthiasM> or not setting glPixelStore values correctly ?
[02:22:50] <JoshDreamland> we'll try byte
[02:22:57] <JoshDreamland> er
[02:22:59] <JoshDreamland> unsigned
[02:23:40] <JoshDreamland> much better, thanks
[02:23:50] <JoshDreamland> now it's at least the right tint
[02:23:58] <MatthiasM> :)
[02:25:09] <JoshDreamland> Funny though, it's still amber
[02:26:21] <JoshDreamland> I never set the pixel storage, I don't believe
[02:26:26] <JoshDreamland> I'm just using default
[02:26:41] <JoshDreamland> but shouldn't it work regardless, since I specified the new format?
[02:27:04] <MatthiasM> you should set atleast GL_UNPACK_ALIGNMENT
[02:27:49] <MatthiasM> esp if you want to upload RGB instead of RGBA data (which is slow but does work nicely with 4 byte alignment if your data is tightly packed)
[02:29:17] <JoshDreamland> If I set GL_UNPACK_ALIGNMENT to four, will it give me basically the guts of a bitmap when I call readPixels?
[02:29:21] <RTFM_FTW> well set GL_UNPACK_ALIGNMENT if you need something other than the default (which is 4)
[02:29:33] <RTFM_FTW> JoshDreamland see above
[02:29:39] <JoshDreamland> ah
[02:29:41] <RTFM_FTW> the default for GL_UNPACK_ALIGNMENT is 4
[02:29:42] <JoshDreamland> default is four
[02:29:45] * sparky_ slaps JoshDreamland around a bit with a large trout
[02:29:49] <JoshDreamland> so I was being an idiot by padding it myself
[02:29:55] <RTFM_FTW> hey sparky
[02:29:55] *** sparky is now known as Guest84391
[02:30:02] *** sparky_ is now known as sparky
[02:30:09] <JoshDreamland> I feel I've been fished
[02:30:11] <sparky> RTFM_FTW: good evening :)
[02:30:14] <JoshDreamland> what was that for?
[02:30:28] <RTFM_FTW> man glPixelStorei
[02:30:28] <sparky> I find it amuses me
[02:30:40] <JoshDreamland> oh, I forgive you, then
[02:30:40] <RTFM_FTW> or man glPixelStore
[02:30:52] <JoshDreamland> I'm reading it now
[02:31:04] <JoshDreamland> and I'm on Windoze at the moment, so no man for me
[02:31:14] *** Guest84391 has quit IRC
[02:32:12] <JoshDreamland> I'ma try not padding it then, since default is already four
[02:32:23] <JoshDreamland> though,
[02:32:27] <JoshDreamland> I said width & 4
[02:32:32] <JoshDreamland> %, rather
[02:32:44] <JoshDreamland> though & is same thing in this case
[02:32:48] <JoshDreamland> so I may as well use it
[02:33:03] <JoshDreamland> ...except that has to go. I must be off it today
[02:34:27] <JoshDreamland> then again, I'd need to know what the padding was so I could read it, too
[02:35:47] <JoshDreamland> Okay, nope, still amber where blue goes
[02:36:02] <JoshDreamland> Bitmap is RGB, right?
[02:36:07] <JoshDreamland> I know something was backwards
[02:36:09] <JoshDreamland> and it's funny
[02:36:15] <JoshDreamland> because when I wrote it upside-down,
[02:36:20] <JoshDreamland> it was in fact, upside down
[02:36:30] <JoshDreamland> Is there a GL_BGR?
[02:36:48] <JoshDreamland> :P
[02:37:40] <MatthiasM> JoshDreamland: &3 and %4 are the same for unsigned values
[02:37:53] <JoshDreamland> yeah
[02:38:02] <JoshDreamland> What'd I say?
[02:38:08] <JoshDreamland> oh, don't mind me
[02:38:12] <JoshDreamland> I'm an idiot ^_^
[02:38:13] <MatthiasM> and a BMP file can store various color formats - you have to check the header
[02:38:30] <JoshDreamland> I wrote the header
[02:38:37] <MatthiasM> there is a GL_BGRA format
[02:38:47] <JoshDreamland> one would think I would know what I wrote, but one would think incorrectly I guess
[02:38:52] <JoshDreamland> I'ma check my bitmap docs again
[02:39:06] <MatthiasM> which header ? if you wrote the file then you should know what format you wrote :P
[02:39:40] <MatthiasM> btw - I was talking about file header - not C header
[02:39:51] <JoshDreamland> I know :P
[02:40:09] <JoshDreamland> I'm exporting screen as a bitmap
[02:40:16] <JoshDreamland> So I had to write the header
[02:40:21] <JoshDreamland> both of em
[02:40:57] <MatthiasM> lol
[02:43:55] <JoshDreamland> mmm, yknow
[02:44:09] <JoshDreamland> I'ma printscreen the thing as wekk, and save it in paint
[02:44:10] <JoshDreamland> well*
[02:44:18] <JoshDreamland> we'll see how they compare
[02:44:52] *** qeed has quit IRC
[02:47:04] <JoshDreamland> the headers are identical...
[02:47:47] <JoshDreamland> but then the one from paint has three extra symbols right before the bitmap data
[02:48:46] *** kalopsian has quit IRC
[02:49:06] <JoshDreamland> I'ma just assume I'm writing the thing in BGR format
[02:49:11] <JoshDreamland> I'll reverse the pixels...
[02:49:34] <MatthiasM> JoshDreamland: http://www.matthiasmann.de/content/view/23/26/
[02:50:38] <JoshDreamland> lol, rub it in
[02:50:41] <JoshDreamland> I'm using C++
[02:51:01] <JoshDreamland> I guess I can read a little Java
[02:51:03] <MatthiasM> that doesn't matter - file formats and OpenGL is still the same
[02:51:22] <MatthiasM> ok - writing a PNG is much harder in C then in Java :)
[02:51:51] <JoshDreamland> yeah
[02:51:58] <JoshDreamland> I have Zlib, though
[02:52:08] <JoshDreamland> But the problem is, my pixels are just reversed
[02:52:10] <JoshDreamland> magically
[02:52:17] <JoshDreamland> So I'ma write them backwards
[02:52:20] <JoshDreamland> and all will be well
[02:52:29] <MatthiasM> nothing happens "magically"
[02:52:52] <MatthiasM> don't change the order if you don't know where is the error is
[02:54:54] <JoshDreamland> you're a java programmer, magic was divided up and given exception names in your language
[02:55:21] <MatthiasM> lol - C++ also has exception - but most people don't use them
[02:55:26] <JoshDreamland> I know xD
[02:55:33] <JoshDreamland> Guilty as charged
[02:55:49] <JoshDreamland> but no, I'm used to nothing being explainable
[02:55:57] <MatthiasM> because a) they think they are slow b) the compiler support is not good c) the libraries are not exception save
[02:56:00] <JoshDreamland> the explanation is that you can fix it by reversing the pixel order
[02:56:22] <JoshDreamland> hey
[02:56:29] <JoshDreamland> you forgot D)
[02:56:32] <JoshDreamland> I'm lazy
[02:56:50] <MatthiasM> then D will prevent you from getting a job :P
[02:57:04] <JoshDreamland> the employer just doesn't have to know
[02:57:09] <JoshDreamland> *drops smoke pellet*
[02:57:16] <MatthiasM> heh
[02:57:16] <JoshDreamland> *jumps out window*
[02:58:08] <JoshDreamland> it's actually because every time I call get_last_error() or get_extended_information() or use try{}catch(){}
[02:58:11] <JoshDreamland> I end up getting nothing
[02:58:18] <JoshDreamland> and then hours later,
[02:58:18] *** Morphous has quit IRC
[02:58:26] <JoshDreamland> it turns out there's a manifest file with my name on it
[02:58:31] <JoshDreamland> because I pressed the wrong button
[02:58:52] <JoshDreamland> or something similar
[02:58:52] <MatthiasM> ?
[02:59:03] <JoshDreamland> Java does manifest, right?
[02:59:27] <JoshDreamland> if not, that's too bad, because I don't know enough about them to explain them
[02:59:39] <JoshDreamland> they've never done me any good
[02:59:47] <MatthiasM> JAR files have a manifest - but that is used to specify main class and library dependencies
[03:00:27] <MatthiasM> it's called META-INF/MANIFEST.MF
[03:00:46] <MatthiasM> but how should this be related to an exception ?
[03:01:24] *** Morphous has joined ##opengl
[03:01:43] <JoshDreamland> it doesn't throw one
[03:01:56] <JoshDreamland> because it seems like it's behaving normall
[03:01:57] <JoshDreamland> y
[03:02:06] <JoshDreamland> so when I'm trying to catch an exception,
[03:02:09] <JoshDreamland> or find an error,
[03:02:11] <JoshDreamland> I get nothing
[03:02:55] <MatthiasM> well - every exception gives you atleast a stack trace from where it is comming
[03:03:15] <MatthiasM> but an exception must be throws - like a FileNotFound exception
[03:03:22] <JoshDreamland> but there was no exception, since it was behaving "normally"
[03:03:31] <JoshDreamland> the manifest file just overwrote some winapi behavior
[03:03:36] <MatthiasM> then there is nothing to catch
[03:03:42] <MatthiasM> lol - no
[03:03:46] <JoshDreamland> yeah.
[03:03:52] <JoshDreamland> no what?
[03:04:04] <JoshDreamland> the overwrote thing?
[03:04:33] <JoshDreamland> also,
[03:04:39] <JoshDreamland> I don't notice any bluring at all
[03:05:17] <MatthiasM> bluring ?
[03:05:39] <JoshDreamland> antialiasing*
[03:05:49] <JoshDreamland> er
[03:05:59] <JoshDreamland> it looks fine to me. >_<
[03:06:14] <MatthiasM> did you get vertical lines in the graph at all - something like "blips" on an EKG ?
[03:06:32] *** dvoid_ has quit IRC
[03:06:41] <MatthiasM> if your system does not show any frame time variation the you get a horizontal line
[03:06:49] <MatthiasM> with maybe a little noise
[03:06:57] <JoshDreamland> I got s pretty deep hill,
[03:07:03] <JoshDreamland> but nothing perfectly vertical
[03:07:05] <MatthiasM> ohh
[03:07:24] <MatthiasM> yeah - should not be vertical - as no 2 points share the same x coordinate :DD
[03:07:28] <JoshDreamland> the only problem was that it was cut off under a certain point
[03:07:40] <JoshDreamland> but yeah, it looks fine
[03:07:47] <MatthiasM> good
[03:07:48] <JoshDreamland> it's not pixely, and it's not too blurry
[03:08:00] <JoshDreamland> But man, I hate that
[03:08:01] <MatthiasM> what GPU do you have ?
[03:08:10] <JoshDreamland> some nasty intel chipset, atm
[03:08:18] <JoshDreamland> because Linux isn't compatible with my Nvidia
[03:08:29] <MatthiasM> so it's running SW mode ?
[03:08:29] <JoshDreamland> which is an artifact itself, but it's still better than this
[03:08:38] <JoshDreamland> SW...
[03:08:49] <MatthiasM> software
[03:08:53] <JoshDreamland> I ah, yes
[03:08:59] <JoshDreamland> s/I/
[03:09:12] <MatthiasM> hmm - let me try in my ubuntu VM
[03:13:30] *** Entelin has quit IRC
[03:13:47] <JoshDreamland> HA!
[03:13:49] <JoshDreamland> I was right!
[03:13:58] <JoshDreamland> writing the pixels backwards fixed it
[03:14:04] <JoshDreamland> but that makes me angry
[03:14:08] <JoshDreamland> Now I must find out why <_<
[03:14:18] *** Entelin has joined ##OpenGL
[03:15:34] <JoshDreamland> for (int i=0;i<sz;i+=w+pad)
[03:15:36] <JoshDreamland>    for (int ii=0;ii<w;ii+=3)
[03:15:37] <JoshDreamland>      for (int iii=2;iii>=0;iii--)
[03:15:39] <JoshDreamland>       fwrite(&(scrbuf[i+ii+iii]),1,1,bmp);
[03:15:43] <JoshDreamland> that's the code now
[03:15:51] <MatthiasM> that's horrible
[03:15:54] <JoshDreamland> I know
[03:15:58] <JoshDreamland> quite a cheap hack
[03:16:07] <JoshDreamland> and my code is notoriously nausiating
[03:16:15] <MatthiasM> lol
[03:16:22] <JoshDreamland> but it works
[03:16:27] <JoshDreamland> and I need to know why
[03:16:46] <JoshDreamland> oh, I should say
[03:16:48] <MatthiasM> do you use GL_RGB to read from frame buffer ?
[03:16:57] <JoshDreamland> yeah
[03:17:07] <MatthiasM> then that's the reason
[03:17:11] <JoshDreamland> char *scrbuf=new char[sz];
[03:17:13] <JoshDreamland>   glReadPixels(0,0,w,h,GL_RGB,GL_UNSIGNED_BYTE,scrbuf);
[03:17:14] <JoshDreamland>   char pad=(w*3)&3;
[03:17:22] <JoshDreamland> what should I have read as?
[03:17:28] <JoshDreamland> I want to write as RGB
[03:17:33] <MatthiasM> that pad value is wrong
[03:17:35] <JoshDreamland> why do I have to write backwards?
[03:17:43] <JoshDreamland> why is it?
[03:17:50] <MatthiasM> BMP stores BGR last time I checked
[03:17:57] <JoshDreamland> darn
[03:18:04] <JoshDreamland> I knew something was backwards. =\
[03:18:12] <JoshDreamland> Is there a way to read BGR instead?
[03:18:15] <JoshDreamland> without reading an A, too?
[03:18:22] <MatthiasM> pad should be (4 - ((w*3)&3))&3
[03:18:32] <JoshDreamland> O_O?
[03:18:34] <MatthiasM> no - but just create a BGRA file
[03:18:46] <JoshDreamland> (4 - ((w*3)&3))&3?
[03:19:09] <JoshDreamland> oh, right
[03:19:47] <MatthiasM> but normaly I do ALIGN(w*3, 4) - w*3
[03:20:40] <JoshDreamland> oh well, screen_save() works now
[03:20:48] <JoshDreamland> thanks for the padding fix
[03:20:59] <JoshDreamland> I don't wanna read RGBA
[03:21:03] <JoshDreamland> rather
[03:21:05] <JoshDreamland> GBRA
[03:21:10] <MatthiasM> why ? reading BGRA is way faster
[03:21:11] <JoshDreamland> because that only wastes space
[03:21:15] <RTFM_FTW> you should *never* read the FB with RGB
[03:21:16] <JoshDreamland> than what?
[03:21:19] <RTFM_FTW> use ARGB
[03:21:23] <MatthiasM> GL only copies it for you into an RGB buffer
[03:21:32] <JoshDreamland> yeah
[03:21:37] <JoshDreamland> Okay, wait
[03:21:49] <JoshDreamland> Should I use ARGB or BGRA?
[03:21:50] <RTFM_FTW> 32-bit ARGB (i.e. something like: GL_RGBA8 GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV for example) specifically
[03:21:58] <RTFM_FTW> and see above
[03:22:00] <RTFM_FTW> heh
[03:22:08] <JoshDreamland> well, you said ARGB
[03:22:18] <JoshDreamland> but he said BGRA
[03:22:24] <JoshDreamland> and I need BGR
[03:22:28] <RTFM_FTW> yes and what I specified above does exactly what I said
[03:22:41] <RTFM_FTW> this is native to the HW
[03:22:49] <RTFM_FTW> BGR isn't
[03:22:59] <JoshDreamland> fine
[03:23:04] <JoshDreamland> ARGB it is
[03:23:23] <JoshDreamland> GL_ARGB?
[03:23:37] <RTFM_FTW> read exactly what I said above
[03:23:42] <JoshDreamland> not GL_ARGB_2_2_2_2_whatever_whatever?
[03:23:53] <RTFM_FTW> GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV
[03:23:57] <RTFM_FTW> note that
[03:24:05] <JoshDreamland> yes, does it matter which?
[03:24:24] <JoshDreamland> I'll take that as a no
[03:24:47] <RTFM_FTW> does what matter? ...only one thing has been suggested here :P
[03:25:15] <RTFM_FTW> using the non-_REV format is a option as well although that isn't necessarily as fast and _REV itself is
[03:25:40] <JoshDreamland> now hang on.
[03:25:43] <RTFM_FTW> in any case being that those are packed pixel type(s) they are also { big, little } endian specific
[03:25:49] <JoshDreamland> because it is in BGRA format now,
[03:25:58] <JoshDreamland> I must add the padding manually, right?
[03:26:07] <JoshDreamland> since it'll always have a padding of zero
[03:26:08] <RTFM_FTW> actually what I said above isn't in BGRA
[03:26:18] <RTFM_FTW> its ARGB actually :P
[03:27:25] *** ol1veira_ has quit IRC
[03:28:22] <JoshDreamland> because there's no such thing as BGRA?
[03:28:43] <RTFM_FTW> I'd suggest reading the GL API specification here
[03:28:57] <RTFM_FTW> and noting what internalFormat, format, type imply
[03:29:15] <RTFM_FTW> WRT pixel processing
[03:30:26] <JoshDreamland> okay, hang on
[03:30:35] <JoshDreamland> I have something here that's working just fine, slow or not
[03:30:45] <JoshDreamland> and you want me to pick up a book on it?
[03:31:03] <JoshDreamland> I'd just as soon leave it working
[03:31:07] *** kbotnen has quit IRC
[03:32:01] <JoshDreamland> because the last time I checked
[03:32:06] <JoshDreamland> there's no BGRA
[03:32:12] <JoshDreamland> there's no ARGB
[03:32:19] <JoshDreamland> it's RGBA
[03:32:34] <JoshDreamland> Or, as I've been using, just RGB
[03:32:50] *** HuntsMan has quit IRC
[03:33:41] <JoshDreamland> I made it GL_RGBA now
[03:34:04] <RTFM_FTW> again format = GL_BGRA, type = GL_UNSIGNED_INT_8_8_8_8_REV is the OpenGL packed pixel equivalent to "ARGB"
[03:34:05] <JoshDreamland> and I feel grimy for wasting another 300 Kilobytes on it
[03:34:24] <JoshDreamland> geordi << "I'm here"
[03:34:27] <JoshDreamland> damn
[03:35:14] <JoshDreamland> geordi doesn't have GL anyway, apparently
[03:35:22] <JoshDreamland> but none of those fun things you keep posting are constants
[03:35:41] *** MatthiasM has quit IRC
[03:35:47] *** MatthiasM has joined ##opengl
[03:36:46] <JoshDreamland> GL_ARGB is undefined, GL_BGRA is undefined,
[03:36:55] <JoshDreamland> and even GL_UNSIGNED_INT_8_8_8_8_REV, which is too long to be made up
[03:36:57] <JoshDreamland> is undefined
[03:37:03] <RTFM_FTW> well if you had bothered to read what I've written so far you would have realized that GL_UNSIGNED_INT_8_8_8_8_REV is a packed pixel type... and such packed pixel types are exposed though an extension like: GL_EXT_packed_pixels (i.e. http://www.opengl.org/registry/specs/EXT/packed_pixels.txt )
[03:37:13] <RTFM_FTW> or GL_APPLE_packed_pixels
[03:37:25] <RTFM_FTW> which would be the vendor specific variant
[03:37:34] <JoshDreamland> I don't know what a packed pixel type is
[03:37:47] <JoshDreamland> so I had no clue
[03:37:57] <RTFM_FTW> yeah I'd suggest learning how to use Google
[03:38:00] <RTFM_FTW> trust me... it isn't difficult :P
[03:38:06] <RTFM_FTW> and its well worth your time :P
[03:38:09] <JoshDreamland> either way, I'm not learning 800 new specifications for something that works already
[03:38:23] *** xp_prg has quit IRC
[03:38:29] <RTFM_FTW> and GL_ARGB as I told you earlier doesn't exist
[03:38:32] <JoshDreamland> especially if one's an extension
[03:38:40] <JoshDreamland> I got that
[03:38:40] <RTFM_FTW> I did specifically tell you how to achieve this though
[03:38:47] <JoshDreamland> I don't want it
[03:38:55] *** xp_prg has joined ##OpenGL
[03:38:57] <JoshDreamland> I'll stick with GL_RGB
[03:39:13] <JoshDreamland> or maybe GL_RGBA, if it bothers you any less
[03:39:36] <RTFM_FTW> heh its not my code :P
[03:39:50] <JoshDreamland> well, thank you for trying to hel,p
[03:40:05] <JoshDreamland> I just don't feel in the mood for reading long things to do something I've already done
[03:42:53] <JoshDreamland> Also, I'm sorry I'm a bit pushy about that. I'm just sick of extensions that work for 2 of the 50 people I give them to.
[03:43:14] <JoshDreamland> So I'm pretty much scarred from them. The less, the better.
[03:43:54] <RTFM_FTW> LOL EXT_packed_pixels is extremely well supported but whatever :P
[03:44:23] <RTFM_FTW> same with the MESA and APPLE variants for that matter
[03:44:26] <JoshDreamland> That's what I heard about EXT_Framebuffer or whatever the hell it was
[03:44:46] <JoshDreamland> that's the one that's like, okay, I'm disabling that, thank you for your patronage
[03:44:53] <RTFM_FTW> funny that is reasonably supported as well
[03:45:09] <JoshDreamland> tell that to my bug report page
[03:45:10] <RTFM_FTW> but in all honestly if you are extension paranoid I'd suggest sticking with GL 1.0 :P
[03:45:21] <JoshDreamland> that's pretty much what I've done
[03:45:32] <RTFM_FTW> wise move
[03:45:34] <RTFM_FTW> heheh
[03:45:41] <JoshDreamland> when Matt suggested PBO, I was like,
[03:45:50] <JoshDreamland> ehhhh, that sounds too close to FBO
[03:46:12] <JoshDreamland> but then he showed me how easy it was to roll back from that one, and I'm like lol okay
[03:46:22] <JoshDreamland> I never do
[03:46:35] <JoshDreamland> I tell them that they can feel free to do it better
[03:46:39] *** iion_ has joined ##OpenGL
[03:46:40] <RTFM_FTW> and BTW this is why we query for the necessary support
[03:46:45] <JoshDreamland> and no one ever does because they're lazier than I am
[03:46:48] <RTFM_FTW> i.e. gluCheckExtension and friends
[03:46:51] <JoshDreamland> yes, I know
[03:47:06] <JoshDreamland> It was the error message I show that everyone was complaining about
[03:47:07] <RTFM_FTW> and code multiple paths if we *really* need a fallback
[03:47:23] <JoshDreamland> one feature didn't work, and everyone reports ZOMG IT R BORKED
[03:47:43] <JoshDreamland> and I haven't supported any extensions since
[03:47:43] *** iion has quit IRC
[03:47:44] <RTFM_FTW> and doing (A) and (B) properly resolves that issue quite well
[03:48:12] *** iion has joined ##OpenGL
[03:48:12] <JoshDreamland> (A) and (B)?
[03:48:31] <RTFM_FTW> its pretty fucking trivial to degrade nicely on the basis of decreasing extension support in a well designed system
[03:48:50] <JoshDreamland> what's the well designed system?
[03:49:16] <JoshDreamland> lemme tell you, it's not the common graphics card
[03:49:17] <RTFM_FTW> if (has_FBO) ... do FBO shit ... else (has pbuffers) ... do pbuffer shit ... else (has offscreen window + glCopyTex) ... fallback to this path ... and so on
[03:49:20] <RTFM_FTW> for example
[03:49:26] *** clrtxt has quit IRC
[03:49:41] <JoshDreamland> except the fallback is so slow
[03:49:45] <RTFM_FTW> the same can be done for any number of other path(s)
[03:49:48] <JoshDreamland> I just dropped the feature entirely
[03:50:06] <RTFM_FTW> unfortunately then you proceed to *fuck* those with the necessary support
[03:50:12] <RTFM_FTW> and the cost of a few w/o such support
[03:50:24] <JoshDreamland> other way around, dearie
[03:50:28] <RTFM_FTW> personally I'd rather make both sets happy
[03:50:35] <RTFM_FTW> and I don't think so :P
[03:50:59] <phrosty> just create a function at runtime with no ifs :P
[03:51:06] <RTFM_FTW> you are *fucking* those w/ necessary support because you have effectively refused to code a more optimal path for them'
[03:51:24] <RTFM_FTW> i.e. you are using the lowest common denominator for *everyone*
[03:52:07] <JoshDreamland> Fine,
[03:52:16] <JoshDreamland> what do you recommend in place of FrameBuffers?
[03:52:29] <RTFM_FTW> I think I made that pretty clear
[03:52:44] <RTFM_FTW> FBO -> pbuffer -> offscreen window + glCopyTex[Sub]Image
[03:52:46] <JoshDreamland> you mentioned pbuffers
[03:52:47] <RTFM_FTW> in that order
[03:52:50] <MatthiasM> JoshDreamland: use FBO when available - otherwise pbuffer
[03:52:55] <RTFM_FTW> three total paths
[03:52:59] <RTFM_FTW> from best to worst
[03:53:00] <JoshDreamland> how often will pbuffers fail?
[03:53:08] <RTFM_FTW> and that covers *every-fucking-thing*
[03:53:20] <JoshDreamland> haha
[03:53:23] <JoshDreamland> fine, you win
[03:53:29] <RTFM_FTW> damn right :D
[03:53:35] <JoshDreamland> if I look into your packed pixel extension,
[03:53:48] <JoshDreamland> how much code is it going to take before I get to use GL_BGRA?
[03:54:26] <RTFM_FTW> hey whether or not this is worthwhile is up to you :P
[03:54:31] <JoshDreamland> or your equivalent with the incredibly long name.
[03:54:39] <MatthiasM> JoshDreamland: you need the right GL headers
[03:54:40] <RTFM_FTW> heh in any case the code for that should be trivial enough since on the GL side only the format(s) and type(s) change
[03:54:41] <JoshDreamland> which is why I'm asking
[03:55:00] <JoshDreamland> so just the code to initialize it?
[03:55:17] <RTFM_FTW> the setup code for swizzling the buffers on the client side before upload will be slightly more complex
[03:55:42] <JoshDreamland> right then
[03:55:56] <JoshDreamland> someday, when I'm so bored I begin counting holes in the ceiling
[03:56:00] <JoshDreamland> I'll remember the extension
[03:56:15] <JoshDreamland> until then, I'll piss with framebuffer backup some more
[03:58:02] *** amz has joined ##opengl
[04:04:45] *** iion_ has quit IRC
[04:15:00] *** Suprano has quit IRC
[04:21:25] *** iion_ has joined ##OpenGL
[04:28:21] *** HuntsMan has joined ##opengl
[04:38:06] *** iion has quit IRC
[04:44:48] *** Entelin has quit IRC
[04:54:02] *** tmccrary has quit IRC
[04:55:28] *** tmccrary has joined ##OpenGL
[05:06:27] *** djork has joined ##opengl
[05:07:47] *** catadoxas_ has joined ##OpenGL
[05:09:25] <catadoxas_> for simple gui's (changing parameters, colors etc) would you reccomend. A: writing you own ui. B using something like gtk+/gtkmm/qt or C something I couldnt come up with?
[05:09:36] *** b0000 has joined ##OpenGL
[05:09:58] <b0000> has anyone tried out GL_EXT_direct_state yet? do you get much performance boost or not?
[05:10:31] <b0000> also i assume it will be available on all opengl drivers soon enough? (i see no reason for it not to be)
[05:11:40] <MatthiasM> b0000: one issue is to get it into drivers of all vendors etc - the other is to get the users to upgrade
[05:12:17] *** Entelin has joined ##OpenGL
[05:12:59] <b0000> MatthiasM: when i say all drivers i mean nv and amd... i know nv support my card so im assuming all nv cards are supported
[05:13:15] <b0000> MatthiasM: this extension is merely a different codepath to old functionality
[05:13:19] <catadoxas_> MatthiasM, nice:) what am I looking at here?
[05:13:38] <MatthiasM> catadoxas_: that is my UI system - it's full themable
[05:14:09] <MatthiasM> the theme is XML while the UI structure is in the code
[05:14:50] <RTFM_FTW> I wouldn't expect GL_EXT_direct_state_access to take a huge dent out of  statement management overhead in a well structured application and driver
[05:15:42] <RTFM_FTW> then again some platforms are *much* better than others in that regard
[05:19:41] *** pierrelux has left ##OpenGL
[05:20:10] <b0000> RTFM_FTW: i cant see it giving massive performance gains in a well written renderer sadly...and if its not widely spread i dont think i want to use it for now...i dont know what nv or amd cards support it yet
[05:21:09] <MatthiasM> b0000: the main issues is to get the users to upgrade - some might not even update the driver at all
[05:21:41] <RTFM_FTW> heheh
[05:21:55] <b0000> MatthiasM: its a small project...that wont be a problem for now
[05:22:45] <MatthiasM> well - you could just assume that you have the extension - and if not use your own functions to emulate it the old way
[05:24:23] <b0000> MatthiasM: that sounds like a fair policy...but to be honest i think ill just wait for a rainy day, i dont think it will help much at all
[05:25:02] <MatthiasM> or you could just generate your rendering code at runtime based on the available extensions :)
[05:25:15] <b0000> its gonna save very few clock cycles i expect...i dont have many state changes at all since i sort by pass and mesh within pass
[05:26:13] <b0000> so basically my render loop is... set program state...set vertex buffer...draw draw draw...change vert buffer...draw....change program...change vert buffer...draw draw draw etc
[05:27:31] <b0000> and the functions have weird naming and EXT on the end...so no seems like a crap idea really :D
[05:27:35] <RTFM_FTW> well if you are using VBO (multiple VBOs is even better here) you can get a much bigger win by looking at VAO
[05:28:04] <b0000> i use only 1 VBO per mesh
[05:28:05] <RTFM_FTW> and using that to consolidate your client side vertex state
[05:28:13] <RTFM_FTW> so?
[05:28:30] <b0000> is VAO well supported?
[05:28:33] <RTFM_FTW> this can still be a slight win in that case
[05:28:39] <b0000> that will set up the vert buffer in 1 call right?
[05:28:43] <RTFM_FTW> since you can reduce subroutine (API) overhead
[05:28:50] <b0000> so i dont need to keep setting the offsets yeah?
[05:28:55] <RTFM_FTW> correct
[05:29:04] <b0000> i guess its well supported?
[05:29:22] <RTFM_FTW> you can do this via GL_ARB_vertex_array_object or GL_APPLE_vertex_array_object
[05:29:47] <b0000> cheers ill look into that...i can generate it when i do my initial sanity check on vert buffer vs program in a mesh
[05:30:06] <RTFM_FTW> well the APPLE variant has been supported *forever* on Mac OS X... the ARB one is pretty new on the scene
[05:30:17] <b0000> if its sane create VAO or rendering...thanks thats a widespread optimisation i can use
[05:30:36] <b0000> im aiming at windows and linux only...since mac cant do physx yet
[05:30:46] <RTFM_FTW> in any case just query for it and make use of it when it exists
[05:30:57] <b0000> when it does the code should work fine on it anyway taking the posix codepath rather than windows
[05:31:13] <b0000> to be honest id rather not query, id rather keep my codebase clean for now
[05:31:29] <b0000> sure when its nearing completion i dont mind adding a few codepaths
[05:31:34] <RTFM_FTW> LOL a few gluCheckExtension calls aren't going to clutter up your code
[05:32:02] <b0000> RTFM_FTW: i just want one codepath to support though...not 2
[05:32:40] <b0000> sure in one case it wont matter much, but id rather just avoid it until the codebase matures a bit
[05:32:45] <RTFM_FTW> modular code FTW here
[05:33:04] *** servus has quit IRC
[05:34:15] *** reprore_ has joined ##OpenGL
[05:34:16] *** servus has joined ##opengl
[05:34:25] *** batbrat has joined ##opengl
[05:34:33] <b0000> i agree but i just dont want to have to fix bugs in stale codepaths anytime soon...id rather stick to the lowest common denominator (my renderer is already running at well over 2000fps on my machine) very hard to get it below 60fps
[05:35:22] *** djork has quit IRC
[05:36:16] <b0000> thats 2000fps on shit slow vista opengl...it takes a fair amount to drop it below 2k fps too
[05:37:06] *** catadoxas_ has quit IRC
[05:38:17] <batbrat> IrisGL was a predecessor to OpenGL. Can someone tell me what its relation to AIX is? I've been poking around some old code (IrisGL) and found an AIX manual which explains some function calls.Are they the same?
[05:38:22] <batbrat> b0000: Cool
[05:43:37] <rnx> aix is just ibm's unix
[05:44:54] <MatthiasM> batbrat: you should look at the more current documentation - like the SDK, red book, and the spec
[05:45:23] <batbrat> Thanks rnx , MatthiasM
[05:46:00] *** Burga has quit IRC
[05:46:15] <batbrat> I am reading some IrisGL code. Its relevant to a project I am working on.
[05:47:08] <batbrat> Is using the OpenGL spec + porting guide a better idea?
[05:47:28] <MatthiasM> well - depends on what you want to do
[05:47:58] <MatthiasM> getting it to compile is one thing - but getting the code to use the new APIs and concepts like VBO is a lot more effort
[05:48:59] <batbrat> Ok. I'm actually just trying to figure out a few details which I can adapt to my project. I'm not doing exactly the same thing. So just getting it to compile should be good.
[05:49:46] <batbrat> I don't think I am going to get that far though. I have a number of things to port in there, including I/O so I am going to stick with reading and understanding it.
[05:51:10] <batbrat> On an unrelated note, I found a polarview call in IrisGL :). That ports to OpenGL as -twist,-elevation,-azimuth :-)
[05:51:49] <MatthiasM> :)
[05:51:56] <batbrat> I have one question on that though. Normally, would I be measuring azimuth clockwise or counter-clockwise?
[05:52:12] <MatthiasM> no idea :)
[05:53:12] <batbrat> Ok MatthiasM thanks. Once I figure this out, I am going to post it on my blog :).
[05:56:54] *** iion_ is now known as iion
[05:57:09] *** Burga has joined ##OpenGL
[05:59:51] <b0000> wow i always suspected glut source would blow, but never in a million years did i consider it to blow this badly
[06:11:06] *** m4ggus has quit IRC
[06:23:05] *** JoshDreamland has quit IRC
[06:34:41] <sparky> batbrat: counterclockwise
[06:35:03] <batbrat> Thanks sparky.
[06:36:36] <batbrat> sparky: I am confused about it because IrisGL porting says - Translate , Rotate -twist,Rot - elevation,Rotate -azimuth whereas Redbook says Trans,Rotate -twist,-elevation,+azimuth
[06:37:21] <batbrat> I am not sure why azimuth rotation would be +ve. After all if the camera moves, we move the world in the opposite direction.
[06:38:52] *** mm765 is now known as mm765^sleep
[06:40:25] <sparky> the world is the highest node
[06:40:27] <sparky> it doesn't move
[06:40:29] <sparky> the camera moves
[06:40:42] *** GuShH has joined ##OpenGL
[06:41:17] <batbrat> 1 moment please sparky. I am re-reading your posts.
[06:42:46] <batbrat> Ok, what you're saying is that I should view the world as fixed at the origin and the camera being positioned to see it.
[06:43:07] <batbrat> I still don't get why the Rotation sign would vary for the azimuth alone.
[06:43:16] <batbrat> Could you please explain?
[06:48:47] <sparky> it's a generally accepted standard that rotation is given counterclockwise
[06:49:10] <sparky> whether it's spherical coordinates, euler angles, rotation around a vector etc
[06:49:25] <sparky> polygons are defined counterclockwise and the list goes on
[06:49:34] <sparky> counterclockwise is the generally accepted standard
[06:49:49] <sparky> and yes the world is the top node in the transformation hierarchy
[06:50:50] <batbrat> One moment... I am processing that :)
[06:51:20] <batbrat> Ok I followed it.
[06:53:06] <batbrat> But then all rotation calls would have the same sign right? If all are counterclockwise, then the signs in the calls would be matching but in the redbook excersise, they aren't.I am still not getting why there is a difference in sign. I am really new, so I'm sorry if it's a dumb question.
[07:01:52] *** iion has quit IRC
[07:03:27] *** GuShH_ has joined ##OpenGL
[07:03:53] *** GuShH has quit IRC
[07:09:11] *** korff_home has joined ##OpenGL
[07:19:09] <batbrat> I was just re-reading my own posts.It just strikes me that, that has to be the sorriest excuse for a dumb question :-) Haha.
[07:22:05] *** reprore_ has quit IRC
[07:37:00] *** HuntsMan has quit IRC
[07:49:04] *** Burga has quit IRC
[07:51:29] *** dusted has joined ##OpenGL
[07:55:24] *** Burga has joined ##OpenGL
[07:56:20] *** dmh has joined ##opengl
[08:01:35] <sparky> :)
[08:02:12] <sparky> batbrat: it's all goo
[08:02:14] <sparky> good
[08:03:29] <batbrat> Thanks.Just saw your post
[08:04:33] *** xp_prg has quit IRC
[08:05:11] *** xp_prg has joined ##OpenGL
[08:12:10] *** Kasu has quit IRC
[08:13:31] *** walt has joined ##OpenGL
[08:31:29] *** jfroy has joined ##OpenGL
[08:32:19] *** PsiOmegaDelta has quit IRC
[08:32:35] *** PsiOmega has joined ##OpenGL
[08:41:35] *** PsiOmega has quit IRC
[08:42:11] *** PsiOmega has joined ##OpenGL
[08:48:17] *** PsiOmegaDelta has joined ##OpenGL
[08:56:56] <batbrat> I have been doing a little more research and found that the azimuthal angle is specified clockwise from the +ve y axis at least for the IrisGL polarview call. I don't disagree with sparky's assesment that most everything is specified counterclockwise. In fact, if the azimuth is specified counterclockwise::
[08:57:15] <batbrat> ::then we'd have to flip its sign in the rotate call
[08:57:41] *** uster has joined ##OpenGL
[08:57:59] <batbrat> I think that is a reasonable explanation. I would be glad if someone could verify whether I am right. Once again thanks sparky.
[08:58:15] *** rnx has left ##opengl
[08:58:27] <batbrat> Btw, here's a nice link showing azimuth and elevation: http://blake.ism.u-bordeaux1.fr/doc_link/C/a_doc_lib/aixprggd/gl32prgd/figures/gl32p7.jpg
[08:59:08] <batbrat> sparky: If you are free, could you please take a look as well?
[08:59:45] *** mccbaka has joined ##OpenGL
[09:00:06] <b0000> batbrat: why not try both ways and see what works?
[09:00:21] <b0000> its not hard to change the sign of a rotation in c/c++
[09:01:12] *** povman has joined ##OpenGL
[09:02:31] <mccbaka> Hi... I am trying to use glAccum() and it appears that when I do so nothing happens. I'm not sure if this is because I'm using it wrong, I configured something wrong, or there is an interaction I don't understand with SDL
[09:02:39] <batbrat> b0000: I'll do that. I will write a script to see what works right away. I'm doing it in python though. I like c/c++. But at the moment, I am going for Python.
[09:02:55] <mccbaka> The code I'm trying to run right now is just : glClear(GL_ACCUM_BUFFER_BIT); glAccum(GL_LOAD, 0.5); glClear(GL_COLOR_BUFFER_BIT); glAccum(GL_RETURN, 0.5);
[09:03:05] *** PsiOmega has quit IRC
[09:03:20] <mccbaka> I put that before I swap buffers. I expect it will just darken whatever I just drew. Instead it winds up blanking the screen.
[09:03:58] <mccbaka> I'm using SDL and I use SDL_GL_SetAttribute to set 5-8 bits for each of the red, green, blue and a accum buffers. It seems to make no difference.
[09:04:01] <mccbaka> Any idea what maybe I'm missing?
[09:04:47] <b0000> mccbaka: shouldnt GL_RETURN arg be 1.0?
[09:05:10] <mccbaka> b000: it could be, but shouldn't the only difference if it's 0.5 be that everything is darker?
[09:05:55] <b0000> the only other suggestion i have is GL_ACCUM instead of load
[09:06:11] <b0000> you are correct to use load in this case, but perhaps its a bug
[09:06:27] <mccbaka> i've tried it with GL_ACCUM
[09:06:29] <b0000> but really your code looks fine
[09:06:37] <mccbaka> okay. and i shouldn't need to configure anything?
[09:06:45] <mccbaka> i mean, do i need to enable the accumualtion buffer or something to use it?
[09:06:51] <b0000> do you request an ACCUM buffer at starup?
[09:07:36] <b0000> 	glutInitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA | GLUT_ACCUM );
[09:07:49] <mccbaka> hm, okay
[09:07:52] <b0000> something like that in glut...dont know about SDL
[09:08:04] <b0000> other than that ur code looks perfect
[09:08:05] <mccbaka> right... i've seen code like that for glut
[09:08:11] <mccbaka> but, unfortunately i'm not using glut :( hmm
[09:09:19] <b0000> SDL will have equivelent
[09:09:34] <b0000> how do you create your framebuffer?
[09:09:58] *** Eforen has quit IRC
[09:09:59] <mccbaka> by the framebuffer you mean, like, the back buffer for double buffering?
[09:10:25] <mccbaka> I actually don't, I just call a function called SDL_GL_SwapBuffers() and it does some kind of magic
[09:10:34] <mccbaka> It's actually kind of bothersome, SDL has an attribute to turn on or off to enable or disable double buffering
[09:10:39] <mccbaka> but i can't get it to disable double buffering even if i want it to
[09:11:47] <mccbaka> the docs for sdl i find indicate that you don't have to specifically request anythuing, but you do have to set bit sizes for the accumulation buffer
[09:11:47] <mccbaka> odd
[09:11:52] *** PsiOmegaDelta has quit IRC
[09:14:20] *** groton has joined ##OpenGL
[09:17:56] <b0000> maybe it has an accum buffer by default?
[09:18:04] <b0000> sorry ive never used SDL, ever
[09:19:18] *** autonomy has quit IRC
[09:20:49] <mccbaka> *nod* well thank you
[09:22:03] *** braden has joined ##OpenGL
[09:22:48] <b0000> SDL_GL_SetAttribute(SDL_GL_ACCUM_RED_SIZE,8); <--- you try this for RGB ?
[09:24:20] *** amz has quit IRC
[09:24:25] <b0000> and make sure you do it before you init the window
[09:24:49] <mccbaka> yup
[09:24:55] <mccbaka> oh, before i init the window?
[09:25:00] *** autonomy has joined ##OpenGL
[09:25:06] <b0000> yeah thats important!
[09:25:13] <mccbaka> yikes! well that's probably the problem then
[09:25:14] <mccbaka> one sec
[09:25:23] <b0000> im sure of it
[09:26:24] <batbrat> b0000: I wrote that script. It rotates around an Icosahedron (the one I drew a couple of days back). It looks weird.
[09:26:45] <batbrat> Weird - Not what I expected. No errors.
[09:27:03] <batbrat> *the one = one
[09:27:10] <mccbaka> yup, that was it
[09:27:33] <mccbaka> ...though, now it seems quite slow
[09:27:33] <mccbaka> but, that's probably just opengl
[09:27:33] <mccbaka> thanks!
[09:27:38] <b0000> batbrat: i kind of suck at maths and stuff on paper, but i can certainly work in a compiler, i usually go for trial and error :p
[09:27:46] <b0000> mccbaka: accum buffer is quite slow
[09:27:53] <mccbaka> really?
[09:28:05] <mccbaka> i'm talking like... what looks like hundreds of milliseconds just to read into one and out the other
[09:28:11] <mccbaka> is that normal?
[09:28:21] <b0000> hm not that slow
[09:28:30] <batbrat> b0000: I'm like that usually, but I am making a concerted effort to get it right on paper these days.
[09:28:35] <b0000> have you set it to the same spec as the fb?
[09:29:04] <b0000> batbrat: that probably helps form a solid understanding better :)
[09:30:04] <batbrat> Ok, I got why it looks weird. The Icosahedron is rotating about the right axis, only it isn't oriented about the axis I expected :).
[09:30:35] <mccbaka> well what i originally was trying to do was read the values for the fb and set those for the ab
[09:30:44] <mccbaka> but i started just tooling with other things when i couldn't get anything to work
[09:31:15] <mccbaka> is it possible for the accumulation buffer to slow things down if i'm not using it?
[09:31:33] *** Bollinger has joined ##OpenGL
[09:31:40] <b0000> i dont think so, i have one enabled that i dont use and get 2500fps initially
[09:32:46] *** povman has quit IRC
[09:33:20] <b0000> mccbaka: i pasted some code to you in query, if it doesnt help your performance nothing will
[09:33:50] <mccbaka> ok thanks so much
[09:35:04] *** Jupp3- has quit IRC
[09:35:23] <b0000> im guessing ur accum buffer may be a different format than the window frame buffer...that might explain the slowdown
[09:38:35] <b0000> is your desktop 32-bit colour?
[09:42:24] <b0000> mccbaka: 9am here, id better catch a few hours sleep, hope you get that working dude
[09:43:07] *** walt has quit IRC
[09:43:31] <mccbaka> thanks for all the help
[09:43:52] *** Unnamed4Life has joined ##OpenGL
[09:43:56] *** walt has joined ##OpenGL
[09:43:58] <Unnamed4Life> anyone familiar with MD3 format?
[09:44:27] <b0000> Unnamed4Life: ive parsed a few in my time...a while ago now
[09:44:42] <Unnamed4Life> do you still remember the Tag thing?
[09:45:20] <b0000> i prefer md2 or md4, those tag things were just a bit hacky
[09:46:23] <b0000> are you trying to attach another md3?
[09:46:55] <Unnamed4Life> no, i have done MD2 already, actually i understood almost everything from the doc i am reading from, which is basically the same as MD2
[09:46:59] *** predaeus has joined ##opengl
[09:47:07] <Unnamed4Life> the only two things which werent clear for me was the Tag and the Shader
[09:47:30] <Unnamed4Life> which is basically whats new from MD2 to MD3
[09:47:31] <Unnamed4Life> :D
[09:47:58] <b0000> yeah im reviewing the docs, md3 isnt as bad as i remember...must have been a noob back then
[09:48:10] <b0000> the tag stuff is just to attach another md3
[09:48:50] <Unnamed4Life> yeah i read somewhere about "attach" but its still not clear for me
[09:49:13] <Unnamed4Life> like its the initial "another model" position relative to the main model?
[09:50:49] <b0000> yeah...for example set identity matrix, rotate the tag mesh, then translate to that position
[09:51:38] <b0000> that would be assuming your model origin is 0,0,0 of course, otherwise translate by the model origin too
[09:51:45] <Unnamed4Life> yeah
[09:51:46] <Unnamed4Life> gotcha
[09:52:02] <Unnamed4Life> what a headache for such nothing
[09:52:08] <Unnamed4Life> i was wondering what the hell was that
[09:52:52] *** sohail has quit IRC
[09:53:04] <b0000> http://en.wikipedia.org/wiki/Md3#Shader
[09:53:24] <Unnamed4Life> wikipedia
[09:53:25] <b0000> the specs are infinitely clearer since the release of the source code
[09:53:33] <Unnamed4Life> i was reading from this site http://icculus.org/homepages/phaethon/q3a/formats/md3format.html
[09:53:44] <Unnamed4Life> but it doesnt even bother to explain the Shader nor wikipedia
[09:53:48] <Unnamed4Life> its a pathname for a file
[09:54:59] <Unnamed4Life> i am not too much into source reading, you have a clue about this Shader file?
[09:55:21] <b0000> i looked at them in there day
[09:56:42] <Unnamed4Life> the file format is .PK3?
[09:57:01] <b0000> dude, you should move directly on to md4 imo...its a nicer format in modern times
[09:57:05] <b0000> pk3 is just a zip
[09:57:13] <Unnamed4Life> yeah
[09:57:18] <Unnamed4Life> its the equivalent of .PAK of quake1
[09:57:22] <Unnamed4Life> lol, i never played q3
[09:58:01] <b0000> http://toolz.nexuizninjaz.com/shader/shader/section1.htm#1
[09:58:05] <Unnamed4Life> is there documentation for MD4?
[09:58:48] <b0000> erm yeah...but maybe not as good docs
[09:58:48] <batbrat> Thanks for your help b0000.
[09:59:05] <b0000> batbrat: i didnt really help :p
[09:59:21] <b0000> just suggested trial and error
[09:59:33] <batbrat> That helped :)
[09:59:49] <batbrat> I Anyway I nearly have it now.
[09:59:50] <b0000> http://tfc.duke.free.fr/coding/md5-specs-en.html
[10:00:08] <batbrat> *Anyway
[10:00:50] <b0000> md5 - doom 3 model format is plain text and a pretty standard model format
[10:00:51] *** batbrat has left ##opengl
[10:01:40] *** _THEGOD__ has joined ##OpenGL
[10:01:52] *** Renderwahn has joined ##OpenGL
[10:01:59] <Unnamed4Life> plain text is more work :(
[10:02:35] <b0000> not really, easy to verify you can read all the data correctly
[10:03:39] <Unnamed4Life> yeah but do the string parser can be annoying
[10:04:15] <b0000> http://forum.xentax.com/viewtopic.php?f=16&t=2802
[10:04:28] <b0000> try the quake wars binary format then :D
[10:07:03] <Unnamed4Life> youre rushing me :D
[10:07:10] <Unnamed4Life> gonna do the MD3 , then try MD4
[10:11:42] *** scai has joined ##opengl
[10:21:10] <Unnamed4Life> hey b0000 you got any link for MD4 documentation?
[10:21:15] <Unnamed4Life> doesnt matter if its bad
[10:21:16] <Unnamed4Life> :p
[10:22:22] <Unnamed4Life> oh finding those documents are crazy stuff
[10:22:44] <Unnamed4Life> i am just digging various and various old gamedev topics, mostly links i find are broken
[10:30:47] *** echelon3 has joined ##OpenGL
[10:31:49] *** rabbit- has quit IRC
[10:31:49] *** echelon3 has quit IRC
[10:32:09] *** rabbit- has joined ##OpenGL
[10:33:01] *** Yustme has joined ##OpenGL
[10:33:02] *** batbrat has joined ##opengl
[10:33:29] *** groton has quit IRC
[10:35:43] <predaeus> Unnamed4Life, try Collada, it's xml and standardized by the Khronos group (same organization that maintains OpenGL)
[10:36:33] *** dmh- has joined ##opengl
[10:37:25] *** dmh has quit IRC
[10:37:48] <predaeus> there is also 2 successful implementations ColladaDOM and FCollada. So you shouldn't have to fiddle with xml yourself.
[10:38:03] *** UUncia has joined ##OpenGL
[10:38:06] *** dmh- has quit IRC
[10:41:22] <Unnamed4Life> predaeus: i am more into the learning experience, and i prefer Quake formats cause i simpatize more with it, since i played it alot
[10:42:05] *** Entelin has quit IRC
[10:43:22] *** Entelin has joined ##OpenGL
[10:43:35] *** mccbaka has quit IRC
[10:44:28] *** Unnamed4Life has quit IRC
[10:44:54] *** groton has joined ##OpenGL
[10:47:43] *** _THEGOD__ has left ##OpenGL
[10:47:50] *** UUncia has quit IRC
[10:49:17] *** elite01 has joined ##opengl
[10:52:45] *** Entelin has quit IRC
[10:54:02] *** autonomy has quit IRC
[10:56:53] *** walt_ has joined ##OpenGL
[10:58:01] *** autonomy has joined ##OpenGL
[11:00:15] *** Entelin has joined ##OpenGL
[11:04:35] *** UUncia has joined ##OpenGL
[11:06:06] *** walt_ has quit IRC
[11:06:14] *** HideousNashimoto has joined ##OpenGL
[11:06:16] <HideousNashimoto> The GLUT library (see the section "GLUT" later in this chapter) provides platform-independent support for this functionality and is sufficient for most small-application and demo-program needs.
[11:06:26] <HideousNashimoto> ?!?!??!
[11:06:26] *** walt_ has joined ##OpenGL
[11:07:43] *** walt has quit IRC
[11:07:49] *** walt_ is now known as walt
[11:09:17] *** Entelin has quit IRC
[11:09:17] *** dmh has joined ##opengl
[11:11:17] *** dmh has quit IRC
[11:11:25] *** dmh has joined ##opengl
[11:16:04] *** Entelin has joined ##OpenGL
[11:16:06] *** kbotnen has joined ##OpenGL
[11:25:16] *** tokemonstah has joined ##OpenGL
[11:25:32] *** Iraimbilanja has joined ##OpenGL
[11:27:42] *** kig has quit IRC
[11:29:09] *** Spkka has joined ##OpenGL
[11:29:56] *** synchris has quit IRC
[11:32:27] *** LordMetroid has joined ##OpenGL
[11:42:37] *** uster has quit IRC
[11:46:30] <batbrat> I am back to square one. I thought I had gotten the polarView example at last but my grandfather(who is good at 3D geometry) just blew holes right through my argument :(.
[11:47:08] <batbrat> I'm doing more research. Then I'll post a solution, if any.
[12:01:28] *** geocalc has quit IRC
[12:02:08] *** geocalc has joined ##opengl
[12:08:35] *** pietia_ has joined ##OpenGL
[12:13:08] *** AlastairLynn has joined ##opengl
[12:23:46] *** dv_ has joined ##opengl
[12:24:17] *** MouseCrazy has joined ##OpenGL
[12:25:46] *** DrGonzo has joined ##OpenGL
[12:29:18] *** Spkka` has joined ##OpenGL
[12:30:31] <walt> BLT Breakfast!
[12:31:18] *** Spkka has quit IRC
[12:31:31] *** Spkka` is now known as Spkka
[12:32:26] *** dvoid_ has joined ##OpenGL
[12:55:48] *** phrosty has quit IRC
[12:58:05] <batbrat> Ok. I've gotten a better understanding now. I just confused myself, thats why my argument was blown full of holes :). On the other hand I still have the problem with the azimuthal angle. I'm still thinking on it. I'll post a question on it + references if I fail to figure it out. :)
[13:07:24] *** cplusplus has joined ##OpenGL
[13:07:30] *** batbrat has left ##opengl
[13:08:30] *** neoneye has joined ##OpenGL
[13:11:40] *** itouch has joined ##OpenGL
[13:19:00] *** calav3ra has joined ##opengl
[13:19:59] *** DrGonzo is now known as Gonzo
[13:20:33] *** NightVisio has joined ##OpenGL
[13:20:45] <NightVisio> hi
[13:24:33] *** Stevethepirate has joined ##OpenGL
[13:28:48] *** Eforen has joined ##opengl
[13:31:28] *** kurt has joined ##OpenGL
[13:32:04] *** rutski_ has quit IRC
[13:32:07] *** kurt has quit IRC
[13:35:07] *** NightVisio has quit IRC
[13:35:19] *** NightVisio has joined ##OpenGL
[13:38:27] *** geocalc has quit IRC
[13:39:06] *** geocalc has joined ##opengl
[13:40:40] *** dolphin has joined ##OpenGL
[13:40:41] *** kurt has joined ##OpenGL
[13:41:00] *** plee has joined ##OpenGL
[13:43:54] *** echelon3 has joined ##OpenGL
[13:50:54] *** NightVisio has quit IRC
[13:53:04] *** UUncia has quit IRC
[13:53:23] *** rabbit- has quit IRC
[13:55:21] *** mm765^sleep is now known as mm765
[13:59:43] *** LordMetroid has quit IRC
[14:00:02] *** jcazevedo has quit IRC
[14:18:25] *** MouseCrazy has quit IRC
[14:20:57] *** eXtronuS has joined ##OpenGL
[14:22:56] *** groton has quit IRC
[14:23:43] *** japanfred has joined ##OpenGL
[14:24:01] <japanfred> hey peeps
[14:33:43] *** japanfred has quit IRC
[14:34:07] *** kurt_ has quit IRC
[14:34:59] *** xp_prg has quit IRC
[14:36:24] *** X-Scale has quit IRC
[14:36:45] *** calav3ra has quit IRC
[14:37:48] *** johndoe has joined ##opengl
[14:40:57] *** Yustme_ has joined ##OpenGL
[14:43:45] *** JoshDreamland has joined ##opengl
[14:45:13] <JoshDreamland> Which is more costly, keeping track yourself, and doing a check each time to see what texture is bound, or just binding to the texture you want each time?
[14:46:21] <MatthiasM> if you do the check then you can save the method call - but you should first know how likly it is that you would set the state again
[14:46:43] <JoshDreamland> I can't know that, which is the problem
[14:46:51] <Iraimbilanja> yes and not only the method call. you save a potential round trip to the hardware
[14:46:52] <MatthiasM> eg if you can gurantee from your code that 99.9% of the calls change the state then you may not need to check
[14:47:12] <MatthiasM> Iraimbilanja: the driver will take care of that
[14:47:37] <Iraimbilanja> ah, nice
[14:48:02] <JoshDreamland> hmm...
[14:49:23] <JoshDreamland> I have three options. 1) Check each time I draw anything, 2)  Bind to what I want each time I draw anything, or 3) bind in texture functions, unbind at end
[14:49:40] <MatthiasM> there is no unbind for a texture
[14:50:14] <JoshDreamland> there's binding it to zero
[14:50:21] <MatthiasM> don't do that
[14:50:22] <JoshDreamland> so I can draw correctly with color
[14:50:34] <MatthiasM> disable texture if you don't need them
[14:50:37] <Iraimbilanja> hmm i always just glDisabled TEXTURE_2D
[14:50:46] <MatthiasM> or use shaders :)
[14:50:51] <JoshDreamland> so wait
[14:51:06] <MatthiasM> when using GLSL shaders you don't need to enable/disable textures at all
[14:51:09] <JoshDreamland> when you want to go from drawing textures to drawing regular colored primitives
[14:51:14] <JoshDreamland> instead of binding to zero,
[14:51:21] <JoshDreamland> you disable textures?
[14:51:25] <Iraimbilanja> yeah
[14:51:29] <MatthiasM> of course
[14:51:44] <JoshDreamland> and that's faster? ;_;
[14:51:52] <Iraimbilanja> though binding to 0 does sound convenient. i'm not sure why matthias thinks it's a bad idea
[14:51:58] <MatthiasM> don't know - but this is the clean way
[14:52:13] <JoshDreamland> I thought binding to zero was the clean way
[14:52:28] <JoshDreamland> I tried just disabling once and thought it a cheap hack to save speed
[14:52:29] <MatthiasM> if some code stupidly uploads a texture into ID 0 then you got texture instead of colors
[14:52:34] <JoshDreamland> but I don't think it worked
[14:52:51] <Iraimbilanja> but can you actually specify which ID you want?
[14:52:53] <MatthiasM> disabling works - binding 0 is a hack
[14:52:53] <JoshDreamland> I thought zero was never a texture
[14:53:05] <JoshDreamland> okay, works for me
[14:53:26] <MatthiasM> GL 1.0 did not had texture ID - and ID 0 is bound as default
[14:53:53] <JoshDreamland> XD
[14:53:59] <MatthiasM> but once you throw the FF pipe away this problem goes withit
[14:54:01] <JoshDreamland> maybe that's where I got it
[14:54:07] <JoshDreamland> also,
[14:54:24] <JoshDreamland> Is it still a problem that graphics cards can't have non power of two textures?
[14:54:39] <MatthiasM> check for the extension
[14:54:51] <Iraimbilanja> yeah think so. i'm not sure whether "npots" provides the same performance
[14:54:53] <JoshDreamland> oh wait, that's an extension?
[14:54:55] <MatthiasM> but ATI have perf issues with NPOT textures for GL_TEXTURE_2D
[14:55:13] <JoshDreamland> Wait.
[14:55:15] <MatthiasM> use ARB_texture_rectangle - it works on all cards which supports it
[14:55:22] <JoshDreamland> Do I need an extension for non power of two?
[14:55:26] <Iraimbilanja> yes
[14:55:27] <MatthiasM> yes
[14:55:33] <JoshDreamland> okay, good
[14:55:47] <JoshDreamland> that makes it not easy to roll back, though
[14:55:50] *** XT95_ has joined ##OpenGL
[14:55:52] <MatthiasM> ARB_texture_non_power_of_two
[14:56:07] <JoshDreamland> I remember that one.
[14:56:08] <Iraimbilanja> though if you use glu mipmaps you can supply a npot pixmap and appropriate sizes will be generated
[14:56:14] <MatthiasM> if this extension is there it tells you that glTexImage2D (and others) accepts NPOT sizes
[14:56:17] *** Yustme has quit IRC
[14:56:24] <JoshDreamland> problem is, I don't know how I'm going to test this stuff
[14:56:41] <JoshDreamland> since my chipset isn't likely to support any of it
[14:56:42] <MatthiasM> Iraimbilanja: and wait for ages for this conversation to be performed - this method is slow
[14:56:48] <Iraimbilanja> yes it is.
[14:57:07] <MatthiasM> JoshDreamland: get someone who can test it - or buy another PC
[14:57:30] <JoshDreamland> heh
[14:57:57] <JoshDreamland> or I could reenable my graphics card now that I'm on Windows again
[14:58:06] <JoshDreamland> it causes Linux to freak out
[14:58:30] <JoshDreamland> strangest thing, kernel doesn't update right or anything with it in.
[14:58:50] *** UUncia has joined ##OpenGL
[14:59:19] <JoshDreamland> anyway, MatthiasM, you just want me to check if ARB_texture_rectangle is there?
[14:59:30] <JoshDreamland> I don't actually need anything else from it?
[15:00:19] <MatthiasM> ARB_texture_rectangle is another texture target - read the docu
[15:02:26] *** HuntsMan has joined ##opengl
[15:16:35] *** qeed has joined ##opengl
[15:16:58] <LordHavoc> if GL_ARB_texture_non_power_of_two is listed, that doesn't mean it's accelerated with mipmaps and such, at least that has bitten me on Windows with Radeon X1600-X1950 cards (Radeon HD cards are fine though), and cards before X1600 don't list the extension anyway)
[15:17:34] <JoshDreamland> crud
[15:17:49] <JoshDreamland> now I remember why I just went on with my life
[15:18:00] <LordHavoc> but GL_ARB_texture_rectangle has never given me problems like that
[15:18:02] <JoshDreamland> too bad the rest of GL is so slow I have to come back to all this
[15:18:30] <LordHavoc> on the other hand it has weird coords (pixel coords rather than 0...1 range) and only GL_CLAMP_TO_EDGE behavior and no mipmaps
[15:19:07] <LordHavoc> the pixel coords is what bugs me the most, otherwise it would be easy to support both
[15:19:21] <JoshDreamland> So for best results, what would I want to try implementing?
[15:19:39] <HuntsMan> LordHavoc: Radeon Xsomething shouldn't list GL_ARB_npot, as they don't support the extension
[15:20:04] <LordHavoc> HuntsMan: shouldn't is right
[15:20:21] *** Kasu has joined ##OpenGL
[15:20:31] <LordHavoc> HuntsMan: just saying that I have gotten reports of bad performance and crashes on X1600 which went away with a corresponding commandline option on my engine to suppress that extension
[15:20:44] <LordHavoc> HuntsMan: I hope they've fixed it but don't know - haven't seen reports of that lately, so maybe so
[15:20:59] <JoshDreamland> Or everyone got tired of whining
[15:21:22] <LordHavoc> Quake1 engines have a knack for pushing all the right(wrong) buttons with quality in mind (for example a lot of the Quake textures are npot)
[15:21:37] <MatthiasM> LordHavoc: all the test results I got indicated that ATI and NPOT don't fit together
[15:21:43] <LordHavoc> and scaling up those textures to larger sizes results in a quality loss
[15:22:00] <LordHavoc> so if the driver claims npot support, I use it
[15:22:09] *** walt has quit IRC
[15:22:18] <LordHavoc> and expect it to work with all features
[15:22:28] <JoshDreamland> but that's all I have to do is check that it is supported
[15:22:29] <LordHavoc> (including mipmapping, anisotropic filtering, etc)
[15:22:40] <HuntsMan> LordHavoc: yeah, but ATI has a record of non-compliant GL support, but Radeon HD's are fine with GL 2.1
[15:22:48] <JoshDreamland> I don't actually get any new functions or keywords from the extension, right?
[15:22:52] <LordHavoc> yeah the NPOT extension is trivial to use, it's just an extension string
[15:23:10] <JoshDreamland> wonderful
[15:23:35] <JoshDreamland> What's the name of the extension?
[15:23:37] <LordHavoc> NPOT textures worked on NVIDIA cards with certain features all the way back to the GF3, heh
[15:23:51] <LordHavoc> GL_ARB_texture_non_power_of_two
[15:24:06] <JoshDreamland> o_o?
[15:24:12] <JoshDreamland> Where's the EXT?
[15:24:24] <HuntsMan> LordHavoc: they don't in the FX series though
[15:24:40] <MatthiasM> JoshDreamland: this extension name was written already several times to you
[15:24:53] <JoshDreamland> I didn't recognize it as an extension
[15:25:01] <JoshDreamland> because all of them I've seen have a nasty ext in it
[15:25:15] <LordHavoc> HuntsMan: fun
[15:25:31] <LordHavoc> JoshDreamland: I don't know what you mean
[15:25:51] <MatthiasM> JoshDreamland: an extension life time is like this: vendor -> EXT -> ARB -> core
[15:26:10] <LordHavoc> http://www.opengl.org/registry/specs/ARB/texture_non_power_of_two.txt
[15:26:28] <JoshDreamland> LordHavoc: I'm there
[15:27:06] <aep> anyone knows a cross platform font library for opengl?
[15:27:33] <HuntsMan> FTGL
[15:28:20] <aep> yeah sounds like my best option.  although it doesnt support foreign layouts
[15:28:54] *** x0rx0r has joined ##OpenGL
[15:28:59] *** XT95__ has joined ##OpenGL
[15:33:16] *** karsten_ has joined ##OpenGL
[15:33:28] *** XT95_ has quit IRC
[15:33:53] <JoshDreamland> Would you recommend gluX?
[15:34:38] <JoshDreamland> So far I've been loading extensions with wgl calls
[15:35:28] <JoshDreamland> ah, here it is, GLEW
[15:35:39] <JoshDreamland> that one I was thinking about using forever ago but never did
[15:36:40] <JoshDreamland> unless there's a better way to load extensions that I'm missing out on?
[15:38:10] <MatthiasM> JoshDreamland: did you read the channel topic ?
[15:38:21] <JoshDreamland> yes, sadly
[15:38:42] <JoshDreamland> not before I asked that, though
[15:39:09] <JoshDreamland> I'm reading up on GLEW right now
[15:39:42] <JoshDreamland> Going to compile it into a static lib
[15:40:02] <MatthiasM> you should use dynamic libs as much as possible
[15:40:27] <MatthiasM> a) less license issues b) faster link times c) on linux less HD space used
[15:40:41] <MatthiasM> *if more then one app uses the lib
[15:42:05] <JoshDreamland> I'll write in a preprocessor for linux
[15:42:13] *** sohail has joined ##OpenGL
[15:42:21] <JoshDreamland> On Windows, though, I want it to compile to one file
[15:42:34] <MatthiasM> preprocessor?
[15:42:49] <JoshDreamland> #if
[15:42:55] <JoshDreamland> oright, Java
[15:43:13] <MatthiasM> GCC already has a preprocessor - you don't need to write one
[15:43:20] <JoshDreamland> it's like regular code, only it's for the compiler to read, not the exe
[15:43:37] <JoshDreamland> I'm just going to tell it to use the DLL if it's compiling on Linux
[15:43:42] <MatthiasM> I know C/C++ :) I write linux device drivers and other stuff :)
[15:43:52] *** UUncia has quit IRC
[15:43:55] <JoshDreamland> oh, that's good ^_^
[15:43:57] <JoshDreamland> or maybe it's bad
[15:44:02] <JoshDreamland> I'm not sure yet
[15:44:10] <JoshDreamland> But C++ hasn't killed me yet, so
[15:44:15] <MatthiasM> on linux it's called SO - shared object - not DLL
[15:44:30] <JoshDreamland> yeah
[15:44:33] <JoshDreamland> something like that
[15:44:49] <JoshDreamland> grah,
[15:45:01] <MatthiasM> and you can just link to the dynamic lib on both system without issues
[15:45:07] <JoshDreamland> my buddies at GLEW.sf.net only provide windows binary
[15:45:09] <JoshDreamland> which makes sense
[15:45:31] <JoshDreamland> I know, but I want to keep the executable one file on Windows
[15:45:36] *** lewymati has joined ##OpenGL
[15:45:42] <MatthiasM> why?
[15:48:01] *** m4ggus has joined ##opengl
[15:48:09] <JoshDreamland> Seems cleaner to me than 100 different DLLs for all my purposes
[15:52:07] <JoshDreamland> When you move an exe, unlike a webpage's source, the DLL's don't go with it
[15:52:31] <JoshDreamland> that's the biggest problem, I think
[15:52:54] <MatthiasM> you will also have lots of data files lying around
[15:55:06] <JoshDreamland> from what?
[15:55:18] <MatthiasM> 3d models, textures etc
[15:55:21] <MatthiasM> sounds
[15:55:22] <JoshDreamland> at present, everything compiles into one EXE
[15:55:25] <JoshDreamland> nah
[15:55:31] <JoshDreamland> I compress those
[15:55:34] <JoshDreamland> and append them to the exe
[15:55:42] <MatthiasM> good luck with this approch
[15:55:44] <JoshDreamland> or extensionless file in linux
[15:55:49] <JoshDreamland> It's already functional
[15:55:51] <JoshDreamland> works great
[15:56:04] <JoshDreamland> best part is, I don't have to store in BMP
[15:56:13] <JoshDreamland> for images
[15:56:15] <JoshDreamland> or any other format, for that matter
[15:56:21] <JoshDreamland> they're just compressed RGB
[15:56:35] <Renderwahn> you'll have to rebuild your app everytime you make changes to your data
[15:56:35] <MatthiasM> who would store images as BMP anyway ?
[15:56:46] <JoshDreamland> Someone who is crazy.
[15:57:05] <JoshDreamland> and yeah, but it's er
[15:57:11] <JoshDreamland> The thing I'm working on.
[15:57:13] <JoshDreamland> It's an engine.
[15:57:32] <JoshDreamland> It's designed to give a higher level interface
[15:57:43] *** Suprano has joined ##OpenGL
[15:57:46] <JoshDreamland> and not make users worry about all the things I am right now.
[15:58:26] <JoshDreamland> GLboolean does not name a type.
[15:58:29] <JoshDreamland> Fabulous.
[15:58:34] <HideousNashimoto> why NPOT is not enabled on my graphic card?
[15:58:45] <HideousNashimoto> I mean why some cards
[15:58:51] <HideousNashimoto> support NPOT and some doesn't
[15:58:56] <MatthiasM> because they don't support it
[15:59:03] <JoshDreamland> because some cards were manufactured in 1970 especially to piss us off
[15:59:40] <HideousNashimoto> JoshDreamland, I wasn't born, in 1970's, what does it have with NPOT :)
[15:59:52] <JoshDreamland> I was joking
[15:59:58] <JoshDreamland> The cards are just terrible
[16:00:15] <JoshDreamland> like GLboolean
[16:00:20] <JoshDreamland> I'm replacing it with "bool"
[16:00:23] <JoshDreamland> any objections?
[16:00:57] <MatthiasM> JoshDreamland: GLboolean is an GLint I think
[16:01:08] <JoshDreamland> okay, here's the problem
[16:01:12] <JoshDreamland> this is a C library
[16:01:17] <JoshDreamland> I'm compiling it with G++
[16:01:22] <JoshDreamland> hmm.
[16:01:25] <MatthiasM> extern "C" {}
[16:01:26] <JoshDreamland> *swaps compiler/
[16:04:50] <JoshDreamland> okay
[16:05:00] <JoshDreamland> so I'm no better off in a C compiler
[16:07:47] <JoshDreamland> because they didn't include gl.h...
[16:07:52] <JoshDreamland> hmm
[16:07:54] <aep> wow FTGL is good
[16:10:10] <JoshDreamland> Are the fonts illegibly anorexic like mine?
[16:10:18] <JoshDreamland> if not, I'm switching
[16:10:22] *** jm|earth has joined ##OpenGL
[16:10:49] <JoshDreamland> Is 706KB reasonable for GLEW.a?
[16:11:06] <MatthiasM> why should it not?
[16:11:19] <JoshDreamland> wondering if it was all there
[16:11:31] <JoshDreamland> because I managed to compile it a lot easier than I thought I could
[16:11:43] <JoshDreamland> I guess that's big enough
[16:15:41] *** xp_prg has joined ##OpenGL
[16:19:05] *** iion has joined ##OpenGL
[16:24:54] <sparky> morning guys
[16:26:09] *** cplusplus has quit IRC
[16:26:20] *** cplusplus2 has joined ##OpenGL
[16:28:52] *** X-Scale has joined ##OpenGL
[16:33:55] *** |t4bz| has joined ##OpenGL
[16:34:29] *** ixM` has joined ##OpenGL
[16:41:08] *** k3t has quit IRC
[16:41:15] *** mm765 is now known as mm765^away
[16:49:53] *** t4bz has quit IRC
[16:50:31] *** predaeus has quit IRC
[16:54:40] *** Viko2 has joined ##OpenGL
[16:55:29] *** karsten256 has joined ##OpenGL
[16:58:18] *** lewymati has quit IRC
[17:03:12] <JoshDreamland> what, no tuna today?
[17:03:13] *** Iraimbilanja has quit IRC
[17:05:03] <JoshDreamland> okay, I'm going to blow what little faith any of you had in me, and ask what a shader is
[17:05:36] <MatthiasM> JoshDreamland: it's a program running on the GPU (if HW accelerated) and processes either vertices or fragments or geometry
[17:05:51] <JoshDreamland> that has to be lightning fast
[17:06:35] <MatthiasM> eg when you enable FF lighting - it behaves like it does - when you use a shader you can define yourself what math should be used to compute the final fragment color
[17:06:48] <MatthiasM> lighthouse3d has a tutorial for GLSL shaders
[17:07:09] <JoshDreamland> will look into
[17:07:20] *** amz has joined ##opengl
[17:07:45] <JoshDreamland> gotta finish reading up on GLEW first, though
[17:08:40] <JoshDreamland> ooh, GL_ARB_point_sprite
[17:08:45] <JoshDreamland> *looks up*
[17:10:50] <MatthiasM> it's nice but some ATI drivers are buggy with this extension :(
[17:10:51] <Viko2> Are NURBS HW accelerated?
[17:11:13] <MatthiasM> no
[17:11:14] <Plagman> on NV1, sure
[17:11:18] <Plagman> ;)
[17:11:35] <MatthiasM> but you should write a shader if you need to :)
[17:12:23] <MatthiasM> pass the control points using uniforms and use the vertices as interpolation coordinates :)
[17:12:40] *** karsten_ has quit IRC
[17:13:06] *** reprore_ has joined ##OpenGL
[17:13:38] *** reprore_ has quit IRC
[17:13:46] *** reprore_ has joined ##OpenGL
[17:14:33] <Viko2> I don't really need them to be fast yet, but I want to do some exciting things with NURBS, and if they were HW accelerated, I would slow things down terribly by tesselating them in my program and sending the result to the GPU...
[17:15:06] <JoshDreamland> PBO == pbuffer?
[17:15:30] <JoshDreamland> or are they entirely different things?
[17:16:25] <MatthiasM> no
[17:16:35] <MatthiasM> pbuffer is old offscreen rendering
[17:16:48] <MatthiasM> and PBO is Pixel buffer object - for faster up/download of texel data
[17:17:12] <JoshDreamland> Crud
[17:17:25] <JoshDreamland> *googles PBO extension*
[17:19:48] *** xp_prg has quit IRC
[17:20:20] *** xp_prg has joined ##OpenGL
[17:28:12] *** b1010 has joined ##OpenGL
[17:36:19] *** stringfellow has quit IRC
[17:39:13] *** b0000 has quit IRC
[17:53:06] *** cplusplus has joined ##OpenGL
[18:03:17] *** XT95___ has joined ##OpenGL
[18:04:34] <b1010> why do ATI suck so much does anyone know?
[18:04:48] *** dmh has quit IRC
[18:04:50] <hackkitten> what do you mean?
[18:06:05] *** ixM` has quit IRC
[18:06:06] <b1010> well their drivers suck on windows and linux and they dont support many software ONLY extensions
[18:06:38] <MatthiasM> b1010: what do you mean with "SW only" ?
[18:06:59] <b1010> EXT_direct_state_access
[18:07:21] <b1010> its simply a case of adding 192 new function entry points
[18:07:36] <MatthiasM> and most of these are for FF - meh
[18:07:52] <x0rx0r> b1010, welcome to the wonderful world of ati development xD
[18:08:12] <b1010> x0rx0r: im well familiar with it, thats why ive used NV for years
[18:08:30] <x0rx0r> haha, me too
[18:08:41] <x0rx0r> always hated when i needed to add ati compatibility
[18:08:54] <b1010> the one that pisses me off most is ATI made their own VAO extension...im not going to write a codepath for it
[18:08:55] <x0rx0r> or see why ati's glsl implementation is lacking
[18:09:13] <MatthiasM> b1010: huh?
[18:09:45] <b1010> GL_ATI_vertex_array_object
[18:10:20] *** cplusplus2 has quit IRC
[18:11:02] *** XT95__ has quit IRC
[18:11:53] <b1010> they dont support any decent extensions...yeah my conclusion is ATI/AMD suck as much as ever
[18:12:28] <b1010> MatthiasM: do you use AMD?
[18:12:40] <x0rx0r> b1010, i use ati lol
[18:12:40] <MatthiasM> AMD yes, ATI no :DD
[18:12:57] <b1010> x0rx0r: what series?
[18:13:20] <b1010> can you confirm the extensions your driver supports
[18:13:33] <x0rx0r> x1900 in my mbp, 2600xt in my mac pro :P
[18:14:07] <x0rx0r> (and i was a complete nv-fan until last year)
[18:14:23] <x0rx0r> no, never
[18:14:27] <x0rx0r> i don't use osx xD
[18:14:31] <Rolenun> when he became dissillusioned and now hates the world :D
[18:15:10] <RTFM_FTW> and BTW this: "x1900 in my mbp" doesn't exist
[18:15:17] <RTFM_FTW> that would be a X1600
[18:15:29] <x0rx0r> yea, sorry
[18:16:44] <x0rx0r>  Chipset Model:	ATY,RadeonX1600
[18:16:52] <x0rx0r> have no idea why it says aty in osx lol
[18:17:26] <RTFM_FTW> why wouldn't it?
[18:17:42] <b1010> GL_EXT_direct_state_access, GL_ARB_vertex_array_object <--- have ATI heard of either of these extensions yet?
[18:17:49] *** plediii has joined ##OpenGL
[18:18:08] <RTFM_FTW> start using Mac OS X and you would find support for VAO
[18:18:13] <x0rx0r> rtfm, because osx sucks probably
[18:18:43] <x0rx0r> u'd find support for shit in osx
[18:19:10] <b1010> x0rx0r: can you nopaste the extensions your card supports?
[18:19:22] <x0rx0r> b1010, which one ?
[18:19:30] <x0rx0r> x1600 or 2600xt ?
[18:19:32] <plediii> i'm trying to configure an app that wants opengl, but I get, hecking whether OpenGL library is available... UNRESOLVED
[18:19:34] <b1010> the better one
[18:19:48] <RTFM_FTW> actually for you I'm thinking that "Fuck-Tard OS" (TM) is probably a better sell
[18:19:50] <plediii> i would try providing it with the opengl installation directory, but I have no idea where that is
[18:20:23] <b1010> plediii: what platform?
[18:20:31] <plediii> sorry, mac os x
[18:20:49] <plediii> 10.5
[18:20:59] <x0rx0r> b1010, got the extensions, which do u want to know ?
[18:21:06] <b1010> RTFM_FTW: ATI have pissed me off so much i will write a seperate codepath for them -_-
[18:21:21] <b1010> x0rx0r: these 2 GL_EXT_direct_state_access, GL_ARB_vertex_array_object
[18:21:22] <Rolenun> plediii: Which application?
[18:21:27] <plediii> pymol
[18:21:52] <x0rx0r> got only arb_vertex_buffer_object
[18:22:16] <b1010> x0rx0r: thought so :(
[18:22:35] <x0rx0r> huh, i didn't knew i have 2 nv extensions lol
[18:22:48] <x0rx0r> nv_blend_square and nv_texgen_reflection
[18:23:18] <x0rx0r> b1010, these results are for vista64 btw
[18:23:36] *** k3t has joined ##OpenGL
[18:25:28] <Rolenun> plediii: It is most likely an application bug. Build system support for OSX on opensource projects has been a hit and miss concept for a very long time. They start out with great intentions, but their 1 or 2 devs keeping the support up-to-date kinda fall by the wayside over the years hehe.
[18:26:10] <x0rx0r> yup
[18:26:14] <plediii> Rolenun: ok, thanks
[18:27:43] <x0rx0r> b1010, gl_ext_direct_state_access is aparently available only for gf8800 and 9600
[18:28:27] <HuntsMan> no, i have a 8400M GS and i have direct_state_access
[18:28:45] <x0rx0r> then ogpengl extensions viewer 3 is broken lol
[18:28:49] <b1010> x0rx0r: its sw only, im pretty certain all NV cards will support it
[18:28:57] <x0rx0r> ah
[18:29:13] <MatthiasM> x0rx0r: the one from realtech VR ?
[18:29:21] *** plediii_ has joined ##OpenGL
[18:29:42] <x0rx0r> yes
[18:29:47] <x0rx0r> glview
[18:29:51] *** plediii has quit IRC
[18:29:59] <MatthiasM> well - after the switched the tool to .net it was useless anyway
[18:30:24] *** ixM` has joined ##OpenGL
[18:30:30] <x0rx0r> lol... anything that switches to .net becomes too bogged it will be useless at some point :P
[18:38:15] *** th0br0 has joined ##OpenGL
[18:38:16] *** th0br0 has left ##OpenGL
[18:41:41] *** Suprano has quit IRC
[18:54:41] *** calav3ra has joined ##opengl
[18:54:55] *** synchris has joined ##opengl
[18:55:39] <hackkitten> :)
[18:55:47] <hackkitten> yeah, like the ATi tray tool :P
[18:55:59] *** walt has joined ##OpenGL
[18:57:27] *** Nesca has joined ##OpenGL
[18:57:28] *** dv_ has quit IRC
[18:57:38] *** Suprano has joined ##OpenGL
[19:00:23] *** k8T has joined ##OpenGL
[19:00:37] <dennda> 4/win 20
[19:00:40] <dennda> fail.
[19:00:40] *** k8T has quit IRC
[19:01:45] *** XT95___ has quit IRC
[19:01:45] *** XT95_ has joined ##OpenGL
[19:03:43] *** HuntsMan has quit IRC
[19:07:20] *** walt has quit IRC
[19:08:11] *** walt has joined ##OpenGL
[19:13:01] *** HuntsMan has joined ##opengl
[19:20:02] *** XT95_ has quit IRC
[19:31:46] *** GuShH_ has quit IRC
[19:32:13] *** JoshDreamland has quit IRC
[19:36:57] <x0rx0r> hackkitten, every day i start up the computer i swear at the ati tray tool (ccc.exe) developers
[19:37:03] <hackkitten> :)
[19:37:15] <hackkitten> it's one reason why I'm glad I have no need for ATi/AMD cards ^-^
[19:37:20] <x0rx0r> it's a 30% chance it will work OK, without unhandled exceptions, memory leaks or anything like that
[19:37:24] <hackkitten> ouch
[19:37:31] <x0rx0r> what card do u have?
[19:37:47] <hackkitten> I use an 8800 GTS in my main system
[19:38:03] <hackkitten> 8500 GT in another
[19:38:12] <x0rx0r> nice, how long did u have them for ?
[19:38:25] <x0rx0r> i had an 8600 but the chip melted
[19:38:46] <hackkitten> the 8500 GT since late 2007, the 8800 GTS since a few months ago
[19:38:57] <MatthiasM> how can you let a GPU ? bad cooling ?
[19:39:11] <hackkitten> nVidia had a batch of bad packaging
[19:39:13] <x0rx0r> no, it's a common problem with 8600 in laptops
[19:39:16] <hackkitten> that might have killed it
[19:39:19] <b1010> my 8600M melted POS
[19:39:29] <RTFM_FTW> "had a batch of ..." LOL
[19:39:33] <x0rx0r> it will die whatever you do after about 6 months :(
[19:39:42] <b1010> yeah mine lasted only 9 months
[19:40:02] <b1010> expensive laptop too
[19:40:09] <b1010> must get it repaired
[19:40:10] <x0rx0r> what lappy b1010 ?
[19:40:18] <b1010> asus g1s
[19:40:47] <b1010> wasnt too bad but you could just tell it was an accident waiting to happen
[19:40:52] <x0rx0r> watch out so they won't put another bad chip in it lol
[19:41:04] <x0rx0r> (happened to me )
[19:41:09] <b1010> x0rx0r: it busted 4 months ago, still not got it claimed yet
[19:41:27] <b1010> also i spilt tea on the screen and busted the dvd drive in the same accident
[19:41:32] <x0rx0r> ah
[19:41:40] <b1010> so i dont know what they will say when they get it back
[19:41:46] <b1010> im gonna deny all knowledge
[19:41:49] * hackkitten is happy on this account that her laptop has an ATi IGP :)
[19:42:35] *** rnx has joined ##opengl
[19:42:39] <b1010> now i was using GTX280 sli, until the asus mobo primary SLI slot fried after < 3 months, must get that fixed too :/
[19:42:49] <b1010> i need to stop abusing my hardware
[19:42:57] <b1010> expensive habit
[19:42:58] <hackkitten> :D
[19:43:04] * hackkitten has only fried a CPU once
[19:43:13] <x0rx0r> lol
[19:43:19] *** groton has joined ##OpenGL
[19:43:24] <b1010> i just wreck hw, i think i get a kick out of it in a sick way
[19:43:25] * x0rx0r welcomes hackkitten to the club xD
[19:43:35] <hackkitten> ^-6
[19:43:37] <hackkitten> ^-^
[19:43:42] <b1010> fucking breaks my heart everytime
[19:43:45] <hackkitten> yay for improperly mounted HSFs~ (o/
[19:44:07] <b1010> lol classic
[19:44:09] *** colton_ has joined ##OpenGL
[19:44:19] * hackkitten hates the sinking feeling in her stomach at the realization she has killed a piece of innocent HW
[19:44:38] <hackkitten> yeah, Socket A HSF using the mounting holes
[19:44:47] <colton_> If I want to develop applications (games) that use opengl on ubuntu, what do I have to install?
[19:44:48] <hackkitten> used screws which were too long
[19:44:52] <b1010> hackkitten: yeah that sucks, but when its not your fault... u still feel bad in a way
[19:45:04] <b1010> thats why hw failure fucks me off
[19:45:09] <hackkitten> well, it was my fault for not checking the lengths of the screws :(
[19:45:18] * hackkitten still has the fried CPU as a reminder
[19:46:05] <x0rx0r> colton_, anjuta
[19:46:34] <colton_> anjuta?
[19:46:35] <x0rx0r> lol hackkitten
[19:46:42] *** qeed has quit IRC
[19:46:50] <x0rx0r> colton, open the package manager and search for anjuta
[19:46:51] <b1010> hackkitten: im not sexist but wats a chick doing near hardware and opengl anyway?
[19:47:05] <x0rx0r> install it, and google some opengl tutorials for anjuta c++
[19:47:18] <hackkitten> I grew up with computers, that's all I can say ^-^
[19:48:13] <b1010> fair enough. shame more dont take an interest
[19:48:38] <Renderwahn> colton_: some open-gl dev package? don't know the name
[19:48:41] <b1010> i think we got only 2 out of around 200 coders at my work
[19:48:46] <x0rx0r> b1010, there are actually many chicks that work using opengl :)
[19:49:12] <Renderwahn> colton_: anjuta is an ide and won't help you with opengl on it's own
[19:49:34] <b1010> x0rx0r: i thought it was all old guys with big beards?
[19:49:43] <colton_> what is glx?
[19:49:54] <b1010> colton_: wgl for x
[19:50:07] <x0rx0r> b1010, lol... me too initially xD
[19:51:09] <b1010> im not an old guy...but i do sometimes have a beard, but in general ALL coders are geeks, and the best ones have no life
[19:51:30] <b1010> id rather see less talented, hotter chick coders personally
[19:52:50] <x0rx0r> lol
[19:53:46] <b1010> im not a sexist or a womaniser... equal opportunities and all that eh :D
[19:54:16] <x0rx0r> sure u'r not lol
[19:54:52] <AlastairLynn> the pope MIGHT not be a catholic
[19:55:14] *** johndoe has quit IRC
[19:55:23] *** th0br0 has joined ##opengl
[20:02:05] <colton_> What is glu?
[20:02:18] *** stringfellow has joined ##opengl
[20:02:23] <b1010> open gl utility library
[20:02:33] <MatthiasM> colton_: GL utility lib
[20:02:42] <colton_> Is it necessary usually?
[20:02:45] <MatthiasM> colton_: it contains a teapot
[20:02:55] <b1010> colton_: usually for gluPerspective()
[20:03:11] <colton_> How could I get it on ubuntu?
[20:03:15] <b1010> and yes the old teapot...you cant make an ogl app without that
[20:03:23] <b1010> colton_: its standard
[20:03:34] <colton_> are you sure?
[20:03:43] <MatthiasM> b1010: shit - I never put it in any of my apps :(
[20:03:45] <colton_> It comes with the installation?
[20:04:05] <colton_> How could  I  check?
[20:04:09] <b1010> libGLU.so ?
[20:05:02] <colton_> ya.
[20:06:28] <colton_> in synaptic it says I have libglu1-mesa-dev and libglu1-mesa
[20:06:34] <colton_> Are those all I need?
[20:06:57] <colton_> If I wanted to use glu and sdl together would I need anything else?
[20:07:39] <x0rx0r> colton, be sure you have hardware graphics driver installed
[20:07:46] <x0rx0r> (and running)
[20:07:48] *** acetoxy has joined ##opengl
[20:08:00] <Renderwahn>  colton_ try to compile one of the sdl examples
[20:08:06] <Renderwahn> than you'll know :)
[20:13:18] *** Suprano has quit IRC
[20:21:03] <b1010> gl_LightSource[x].halfVector <- anyone know how to calculate this value
[20:21:04] *** Rolenun has quit IRC
[20:27:32] <Jupp3> b1010: Hmm, how is that OpenGL related?
[20:27:51] <Jupp3> And no idea about the context, what it should be etc.
[20:28:59] <Renderwahn> the orange book has afaik an example where it is calculated
[20:30:01] *** Marenz has joined ##OpenGL
[20:31:08] <b1010> Renderwahn: sadly i didnt bring my books when i moved country :/
[20:31:13] *** Rolenun has joined ##opengl
[20:31:35] <b1010> Jupp3: basically opengl calculates the half vector for a light internally, but i dont want to use the fixed function lights
[20:31:59] <Jupp3> ok
[20:32:27] <Renderwahn> lol, i could type the passage from the book :)
[20:32:27] *** kbotnen has quit IRC
[20:33:26] <Jupp3> colton_: build-essential you have probably already installed... When you install sdl dev packages, they depend on most OpenGL related packages (except glut dev, iirc)
[20:34:06] <Jupp3> Of course you don't really need glut dev, but I'd install it anyway, unless I was THAT short on disk space :)
[20:34:41] <b1010> Renderwahn: does he calculate it in his vertex shader or on cpu?
[20:34:59] <Renderwahn> b1010: vertexshader
[20:36:47] <b1010> can you nopaste the relevant code please?
[20:38:59] <Renderwahn> b1010: http://3dshaders.com/home/index.php?option=com_weblinks&catid=14&Itemid=34
[20:40:08] <Renderwahn> shadergen could be helpful for you
[20:40:30] <b1010> ok thanks...yeah that should match the ff pipeline - thanks again dude
[20:45:55] *** ixM` has quit IRC
[20:47:01] *** echelon3 has quit IRC
[20:48:29] <b1010>    halfVector = normalize(VP + eye); //ok that wasnt hard - thanks a bunch dude :D
[20:48:56] *** m4ggus has quit IRC
[20:52:58] *** tokemonstah has quit IRC
[20:52:58] *** GNU\caust1c has quit IRC
[20:52:58] *** Tempoe has quit IRC
[20:52:59] *** ville has quit IRC
[20:52:59] *** dindinx has quit IRC
[20:52:59] *** Marenz has quit IRC
[20:52:59] *** Rolenun has quit IRC
[20:53:00] *** Kasu has quit IRC
[20:53:00] *** dolphin has quit IRC
[20:53:00] *** Spkka has quit IRC
[20:53:00] *** Entelin has quit IRC
[20:53:00] *** HideousNashimoto has quit IRC
[20:53:00] *** MatthiasM has quit IRC
[20:53:00] *** positron2007 has quit IRC
[20:53:01] *** exDM69 has quit IRC
[20:53:01] *** hibread has quit IRC
[20:53:01] *** Icchan^ has quit IRC
[20:53:01] *** Plagman has quit IRC
[20:53:01] *** quicksilver has quit IRC
[20:53:01] *** GinoMan has quit IRC
[20:53:01] *** TenOfTen has quit IRC
[20:53:01] *** Deformalite has quit IRC
[20:53:01] *** memfr0b has quit IRC
[20:53:01] *** Mazon has quit IRC
[20:53:02] *** RTFM_FTW has quit IRC
[20:53:02] *** flazz has quit IRC
[20:53:02] *** aep has quit IRC
[20:53:02] *** stringfellow has quit IRC
[20:53:02] *** HuntsMan has quit IRC
[20:53:02] *** calav3ra has quit IRC
[20:53:02] *** itouch has quit IRC
[20:53:02] *** Bollinger has quit IRC
[20:53:03] *** Burga has quit IRC
[20:53:03] *** dennda has quit IRC
[20:53:03] *** pfo has quit IRC
[20:53:03] *** goruka has quit IRC
[20:53:03] *** TheFlash has quit IRC
[20:53:03] *** freespace has quit IRC
[20:53:04] *** DenizzzZ has quit IRC
[20:53:04] *** fw0rd has quit IRC
[20:53:04] *** Seeb has quit IRC
[20:53:04] *** LordHavoc has quit IRC
[20:53:04] *** cplusplus has quit IRC
[20:53:04] *** Eforen has quit IRC
[20:53:04] *** jfroy has quit IRC
[20:53:04] *** dusted has quit IRC
[20:53:05] *** ixtli has quit IRC
[20:53:05] *** avacore has quit IRC
[20:53:06] *** Weiss has quit IRC
[20:53:06] *** Hypnosekroete has quit IRC
[20:53:06] *** _3b_ has quit IRC
[20:53:06] *** |t4bz| has quit IRC
[20:53:06] *** neoneye has quit IRC
[20:53:06] *** pa has quit IRC
[20:53:07] *** Jernej has quit IRC
[20:53:07] *** nargon has quit IRC
[20:53:07] *** Xantoz has quit IRC
[20:53:07] *** jnglst has quit IRC
[20:53:07] *** Gudy has quit IRC
[20:53:07] *** elektr1k has quit IRC
[20:53:07] *** Defty has quit IRC
[20:53:08] *** furrywolf has quit IRC
[20:53:08] *** Kraln has quit IRC
[20:53:08] *** tyranis has quit IRC
[20:53:08] *** pragma_ has quit IRC
[20:53:08] *** amz has quit IRC
[20:53:08] *** duzt has quit IRC
[20:53:08] *** tac has quit IRC
[20:53:09] *** turbo24prg has quit IRC
[20:53:09] *** Jupp3 has quit IRC
[20:53:09] *** |chiz| has quit IRC
[20:53:09] *** groton has quit IRC
[20:53:09] *** Nesca has quit IRC
[20:53:09] *** X-Scale has quit IRC
[20:53:09] *** jm|earth has quit IRC
[20:53:09] *** eXtronuS has quit IRC
[20:53:09] *** Renderwahn has quit IRC
[20:53:09] *** Morphous has quit IRC
[20:53:09] *** Tenac has quit IRC
[20:53:10] *** Wil has quit IRC
[20:53:10] *** xp_prg has quit IRC
[20:53:10] *** Viko2 has quit IRC
[20:53:10] *** Yustme_ has quit IRC
[20:53:10] *** plee has quit IRC
[20:53:10] *** dvoid_ has quit IRC
[20:53:10] *** pietia_ has quit IRC
[20:53:10] *** autonomy has quit IRC
[20:53:10] *** scai has quit IRC
[20:53:10] *** druggy has quit IRC
[20:53:11] *** cmang_ has quit IRC
[20:53:11] *** groton___ has quit IRC
[20:53:11] *** arkx has quit IRC
[20:53:11] *** stef has quit IRC
[20:53:11] *** ainaker has quit IRC
[20:53:11] *** Akselii has quit IRC
[20:53:11] *** Orphis_ has quit IRC
[20:53:11] *** jezek2 has quit IRC
[20:53:12] *** replaced has quit IRC
[20:53:12] *** pgas has quit IRC
[20:54:07] *** x0rx0r has quit IRC
[20:54:40] *** Rolenun has joined ##OpenGL
[20:54:40] *** Marenz has joined ##OpenGL
[20:54:40] *** stringfellow has joined ##OpenGL
[20:54:40] *** groton has joined ##OpenGL
[20:54:40] *** HuntsMan has joined ##OpenGL
[20:54:40] *** Nesca has joined ##OpenGL
[20:54:40] *** calav3ra has joined ##OpenGL
[20:54:40] *** cplusplus has joined ##OpenGL
[20:54:40] *** xp_prg has joined ##OpenGL
[20:54:40] *** amz has joined ##OpenGL
[20:54:40] *** Viko2 has joined ##OpenGL
[20:54:40] *** |t4bz| has joined ##OpenGL
[20:54:40] *** X-Scale has joined ##OpenGL
[20:54:40] *** jm|earth has joined ##OpenGL
[20:54:40] *** Kasu has joined ##OpenGL
[20:54:40] *** Yustme_ has joined ##OpenGL
[20:54:40] *** eXtronuS has joined ##OpenGL
[20:54:40] *** plee has joined ##OpenGL
[20:54:40] *** dolphin has joined ##OpenGL
[20:54:40] *** Eforen has joined ##OpenGL
[20:54:40] *** itouch has joined ##OpenGL
[20:54:40] *** neoneye has joined ##OpenGL
[20:54:40] *** dvoid_ has joined ##OpenGL
[20:54:40] *** Spkka has joined ##OpenGL
[20:54:40] *** pietia_ has joined ##OpenGL
[20:54:40] *** tokemonstah has joined ##OpenGL
[20:54:40] *** Entelin has joined ##OpenGL
[20:54:40] *** HideousNashimoto has joined ##OpenGL
[20:54:40] *** autonomy has joined ##OpenGL
[20:54:40] *** scai has joined ##OpenGL
[20:54:40] *** Renderwahn has joined ##OpenGL
[20:54:40] *** Bollinger has joined ##OpenGL
[20:54:40] *** jfroy has joined ##OpenGL
[20:54:40] *** Burga has joined ##OpenGL
[20:54:40] *** dusted has joined ##OpenGL
[20:54:40] *** MatthiasM has joined ##OpenGL
[20:54:40] *** Morphous has joined ##OpenGL
[20:54:40] *** dennda has joined ##OpenGL
[20:54:40] *** druggy has joined ##OpenGL
[20:54:40] *** Orphis_ has joined ##OpenGL
[20:54:40] *** pragma_ has joined ##OpenGL
[20:54:40] *** Tenac has joined ##OpenGL
[20:54:40] *** aep has joined ##OpenGL
[20:54:40] *** duzt has joined ##OpenGL
[20:54:40] *** positron2007 has joined ##OpenGL
[20:54:40] *** pa has joined ##OpenGL
[20:54:40] *** Tempoe has joined ##OpenGL
[20:54:40] *** GNU\caust1c has joined ##OpenGL
[20:54:40] *** ville has joined ##OpenGL
[20:54:40] *** dindinx has joined ##OpenGL
[20:54:40] *** pfo has joined ##OpenGL
[20:54:40] *** Jernej has joined ##OpenGL
[20:54:40] *** LordHavoc has joined ##OpenGL
[20:54:40] *** nargon has joined ##OpenGL
[20:54:40] *** goruka has joined ##OpenGL
[20:54:40] *** memfr0b has joined ##OpenGL
[20:54:40] *** quicksilver has joined ##OpenGL
[20:54:40] *** Mazon has joined ##OpenGL
[20:54:40] *** exDM69 has joined ##OpenGL
[20:54:40] *** TenOfTen has joined ##OpenGL
[20:54:40] *** Icchan^ has joined ##OpenGL
[20:54:40] *** Plagman has joined ##OpenGL
[20:54:40] *** flazz has joined ##OpenGL
[20:54:40] *** Deformalite has joined ##OpenGL
[20:54:40] *** hibread has joined ##OpenGL
[20:54:40] *** RTFM_FTW has joined ##OpenGL
[20:54:40] *** GinoMan has joined ##OpenGL
[20:54:40] *** DenizzzZ has joined ##OpenGL
[20:54:40] *** freespace has joined ##OpenGL
[20:54:40] *** fw0rd has joined ##OpenGL
[20:54:40] *** TheFlash has joined ##OpenGL
[20:54:40] *** Seeb has joined ##OpenGL
[20:54:40] *** arkx has joined ##OpenGL
[20:54:40] *** ainaker has joined ##OpenGL
[20:54:40] *** stef has joined ##OpenGL
[20:54:40] *** Akselii has joined ##OpenGL
[20:54:40] *** jezek2 has joined ##OpenGL
[20:54:40] *** groton___ has joined ##OpenGL
[20:54:41] *** pgas has joined ##OpenGL
[20:54:41] *** cmang_ has joined ##OpenGL
[20:54:41] *** replaced has joined ##OpenGL
[20:54:41] *** Xantoz has joined ##OpenGL
[20:54:41] *** tyranis has joined ##OpenGL
[20:54:41] *** Weiss has joined ##OpenGL
[20:54:41] *** avacore has joined ##OpenGL
[20:54:41] *** Hypnosekroete has joined ##OpenGL
[20:54:41] *** ixtli has joined ##OpenGL
[20:54:41] *** Kraln has joined ##OpenGL
[20:54:41] *** tac has joined ##OpenGL
[20:54:41] *** _3b_ has joined ##OpenGL
[20:54:41] *** furrywolf has joined ##OpenGL
[20:54:41] *** Wil has joined ##OpenGL
[20:54:41] *** Gudy has joined ##OpenGL
[20:54:41] *** elektr1k has joined ##OpenGL
[20:54:41] *** Defty has joined ##OpenGL
[20:54:41] *** jnglst has joined ##OpenGL
[20:54:41] *** |chiz| has joined ##OpenGL
[20:54:41] *** Jupp3 has joined ##OpenGL
[20:54:41] *** turbo24prg has joined ##OpenGL
[20:57:56] *** walt_ has joined ##OpenGL
[20:59:08] *** walt has quit IRC
[20:59:48] *** scai has left ##opengl
[21:02:34] *** zwiep` has joined ##opengl
[21:03:48] *** karsten256_ has joined ##OpenGL
[21:03:59] *** McLovin` has quit IRC
[21:04:27] *** ridley has joined ##OpenGL
[21:05:08] *** karsten256 has quit IRC
[21:05:35] *** XT95_ has joined ##OpenGL
[21:05:58] *** karsten256__ has joined ##OpenGL
[21:06:01] *** colton_ has quit IRC
[21:13:21] *** karsten_ has joined ##OpenGL
[21:20:22] <ridley> Anyone in eyeshot: I'm running some really elementary demo code but am getting segfaults unless I comment out both a line with glHint and another with glPointSize. Help?
[21:21:10] <b1010> very odd
[21:21:59] <dusted> ridley, showing the code might be helpfull
[21:22:17] *** karsten256_ has quit IRC
[21:22:26] <ridley> code is http://www.cs.umu.se/kurser/TDBC07/HT04/projects/intro/code/first.c
[21:22:38] <ridley> just wanted to query to see if anyone was around first
[21:24:40] <dusted> Looks correct to me, unlees you can't do it before after setting up the window.. have you tried to run it in a debugger?
[21:24:56] <dusted> compiling it with debugging symbols first ofc
[21:25:28] *** kbotnen has joined ##OpenGL
[21:25:32] <HuntsMan> you're calling GL functions without a GL context
[21:25:37] <b1010> ridley: dont call them until after glutCreateWindow
[21:25:46] <HuntsMan> you can't call any OGL functions before opening a window
[21:25:52] <ridley> Ok.
[21:26:33] <dusted> it does not segfault here
[21:27:24] <dusted> I have teh win driver =)
[21:27:32] <ridley> I'll try HuntsMan's suggestion and get back in a minute
[21:27:45] *** karsten256 has joined ##OpenGL
[21:28:03] *** essoe- has joined ##opengl
[21:28:53] *** dolphin has quit IRC
[21:29:39] *** karsten256__ has quit IRC
[21:29:41] <ridley> Thank you Huntsman.
[21:29:45] <ridley> Worked.
[21:36:37] *** karsten256 has quit IRC
[21:40:49] *** karsten_ has quit IRC
[21:49:47] *** GinoMan has quit IRC
[21:51:41] *** synchris has quit IRC
[21:51:47] *** calav3ra_ has joined ##opengl
[21:52:09] *** synchris has joined ##opengl
[21:57:05] *** XT95__ has joined ##OpenGL
[21:57:30] *** Silmarillion has joined ##OpenGL
[21:58:49] *** XT95_ has quit IRC
[22:01:23] *** cplusplus2 has joined ##OpenGL
[22:02:13] *** jfroy has quit IRC
[22:04:05] *** dusted has quit IRC
[22:06:27] *** Silmarillion has quit IRC
[22:07:09] *** cplusplus has quit IRC
[22:08:24] *** calav3ra has quit IRC
[22:17:04] *** x0rx0r has joined ##OpenGL
[22:19:34] *** phrosty has joined ##opengl
[22:20:56] *** mishu_ has joined ##OpenGL
[22:24:20] *** cplusplus has joined ##OpenGL
[22:24:35] *** cplusplus2 has quit IRC
[22:25:27] *** reprore_ has quit IRC
[22:26:00] *** Marenz has quit IRC
[22:26:36] *** phrosty has quit IRC
[22:26:44] *** phrosty has joined ##opengl
[22:35:20] *** Suprano has joined ##OpenGL
[22:42:18] *** ken has joined ##opengl
[22:44:50] *** Orphis has joined ##opengl
[22:45:36] *** Orphis_ has quit IRC
[22:46:32] *** unknown_ has joined ##OpenGL
[22:47:50] *** Yustme_ has quit IRC
[22:48:41] *** Renderwahn has quit IRC
[22:52:04] *** groton has quit IRC
[22:52:52] *** Suprano has quit IRC
[22:53:35] *** davidc__ has joined ##opengl
[22:53:47] *** Orphis has quit IRC
[22:54:29] *** Orphis has joined ##opengl
[22:55:25] *** scai has joined ##opengl
[23:02:16] *** AlastairLynn has quit IRC
[23:02:33] *** AlastairLynn has joined ##opengl
[23:07:38] *** Orphis has quit IRC
[23:08:48] *** Orphis has joined ##opengl
[23:12:31] *** HuntsMan has quit IRC
[23:15:04] *** kbotnen has quit IRC
[23:17:52] <cplusplus> how do you describe a trajectory in 3d?
[23:20:48] <tmccrary> take a unit vector and multiply it by a scalar value to increase the magnitude
[23:21:02] <tmccrary> the scalar can be velocity or derived from some other value
[23:21:03] <MatthiasM> use the initial vector and gravity
[23:21:32] *** Suprano has joined ##OpenGL
[23:28:28] *** Viko2 has quit IRC
[23:30:36] *** GuShH has joined ##OpenGL
[23:36:07] *** XT95__ has quit IRC
[23:37:04] <cplusplus> how do you describe a trajectory in 3d?
[23:37:34] *** walt_ has quit IRC
[23:37:46] <MatthiasM> cplusplus: you got answers
[23:39:52] *** emzic has joined ##OpenGL
[23:41:47] *** itouch has quit IRC
[23:43:35] <tmccrary> cplusplus: very carefully
[23:43:51] <cplusplus> why?
[23:43:58] <tmccrary> because
[23:44:28] *** mm765^away is now known as mm765^sleep
[23:44:33] *** Gorgoroth has joined ##OpenGL
[23:44:37] *** shepherd has joined ##OpenGL
[23:45:48] *** Bollinger has quit IRC
[23:46:08] <emzic> hi everybody i have a question about the calculation of tangents and binormals for normal mapping
[23:46:38] <MatthiasM> emzic: terathon.com/code/tangent.html
[23:46:40] <emzic> what do i do about hard edges? i.e. when a vertex has different nornmals depending on which face it belongs to
[23:46:55] <MatthiasM> then you split this vertex
[23:47:00] <emzic> MatthiasM: thanks
[23:47:29] <emzic> so it gets multiple tangents and binormals too?
[23:47:34] <MatthiasM> if you first transform your mesh into VertexArray / VBO compatible format (eg vertex duplication on hard edges)
[23:47:42] <MatthiasM> and it's bitangent
[23:48:12] <emzic> so the number of tangents/bitangents is the same as the number of normals?
[23:48:18] *** bijoo_osdev has joined ##opengl
[23:48:19] *** bijoo_appdev has joined ##OpenGL
[23:48:23] <MatthiasM> yes
[23:48:26] *** Xantoz has quit IRC
[23:48:29] <MatthiasM> it's a vertex attribute
[23:48:48] <emzic> ok, cause on that site it is the same as the number of vertices
[23:48:59] <MatthiasM> yep
[23:49:10] <emzic> ok thanks
[23:49:29] <MatthiasM> everything which is per vertex aka vertex attributes has the same count and numbering
[23:49:39] <emzic> alright
[23:49:48] <MatthiasM> because OpenGL only has one index array/buffer for everything
[23:50:04] <emzic> (actually i dont do vertexarrays, VBOs yet)
[23:50:11] <emzic> just display lists :)
[23:50:47] <MatthiasM> better to use them
[23:50:56] <emzic> yeah
[23:52:34] *** Nesca has quit IRC
[23:55:48] *** Spkka has quit IRC
[23:59:23] *** plediii_ has quit IRC

   January 4, 2009  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >