May 2, 2008 
< | 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 | >
May 2, 2008 [00:01:27] *** Lemml has quit IRC[00:03:47] *** Burga_ has quit IRC[00:11:12] *** Suprano has quit IRC[00:22:24] *** juanmabc has quit IRC[00:23:40] *** emnit has quit IRC[00:29:05] *** rsp has left ##opengl[00:34:01] *** Xmas| has joined ##OpenGL[00:40:35] *** amalon_ has joined ##opengl[00:40:53] *** johndoevodka has quit IRC[00:47:41] *** amalon_ has quit IRC[00:53:03] *** amalon has quit IRC[01:00:46] *** mapreduce has joined ##OpenGL[01:08:51] *** prophile has quit IRC[01:10:36] *** darka has quit IRC[01:14:31] *** JernejL_ has joined ##OpenGL[01:23:53] *** TheLorax has quit IRC[01:28:44] *** JernejL has joined ##OpenGL[01:32:15] *** Xmas| has quit IRC[01:32:20] *** Jernej has quit IRC[01:33:16] *** mm765 is now known as mm765^away[01:34:46] *** DMINATOR has quit IRC[01:44:24] *** JernejL_ has quit IRC[01:46:31] *** ViRUS has quit IRC[01:57:03] *** Ademan has quit IRC[01:57:44] *** Ademan has joined ##OpenGL[02:05:16] *** Walt has quit IRC[02:07:05] *** amz has joined ##opengl[02:12:41] *** Walt has joined ##opengl[02:14:12] *** echelon has joined ##OpenGL[02:24:40] *** Jorachim has quit IRC[02:37:22] *** Jorachim has joined ##openGL[02:53:53] *** mm765^away is now known as mm765[02:57:14] *** blight_ has quit IRC[03:21:38] *** Jorachim has quit IRC[03:31:10] *** dvoid_ has quit IRC[03:38:12] *** rnx has left ##opengl[03:41:16] *** Scutter has quit IRC[03:44:56] *** hibread has joined ##opengl[03:48:47] *** Scutt has joined ##OpenGL[04:08:42] *** Rangar has quit IRC[04:08:47] *** _Rangar_ has joined ##OpenGL[04:09:13] *** LiQuiDninja has quit IRC[04:14:01] *** replor_ has joined ##OpenGL[04:25:20] *** Baba_ has quit IRC[04:25:31] *** Baba__ has joined ##OpenGL[04:31:10] *** Osah has joined ##OpenGL[04:31:48] *** replor has quit IRC[04:33:50] *** replor_ has quit IRC[04:34:38] *** hibread has quit IRC[04:45:15] *** rutski has quit IRC[04:55:17] *** echelon has quit IRC[05:01:25] *** echelon has joined ##OpenGL[05:04:02] *** aalex has quit IRC[05:05:45] *** Jernej has joined ##OpenGL[05:07:01] *** xonev has joined ##OpenGL[05:12:43] *** passed has joined ##OpenGL[05:15:44] *** Plagman__ has joined ##opengl[05:23:47] *** JernejL has quit IRC[05:31:21] *** speedy1 has quit IRC[05:31:28] *** passed has quit IRC[05:31:59] *** Plagman_ has quit IRC[05:48:18] *** Ademan has quit IRC[05:49:22] *** Ademan has joined ##OpenGL[05:57:55] *** XypherOrion has joined ##OpenGL[06:04:33] *** _Rangar_ has quit IRC[06:12:40] *** XypherOrion has left ##OpenGL[06:12:58] *** XypherOrion has joined ##OpenGL[06:19:53] <garou> Hi.[06:20:05] *** BahamutZERO has quit IRC[06:20:12] <garou> I ran into a weird problem using GLUT. My display function gets called once and only once.[06:45:46] <sohail> garou, it will get called again only if you post a redisplay[06:46:19] <sohail> see glutPostRedisplay (I think!)[06:47:55] <garou> Yup, works, thank you. :)[06:48:38] <garou> BTW, *is* this an appropriate channel for questions that are as noobish as it reaveals itself to be to me now?[06:54:46] <Madsy> We prefer you to read the specs if you bother, but most people here are more than willing to help.[06:55:03] <sohail> I'm a noob[06:55:04] <Madsy> As long as the question is phrased in a proper manner.[06:55:38] <Madsy> "It doesn't work" is not appropriate.[06:56:12] <Madsy> As long as we don't need to *fish* for information, you are almost guaranteed an answer/sollution.[06:58:52] <garou> *g* That won't be a problem. :)[07:00:38] <Madsy> In that case, I bid you welcome[07:00:39] *** mm^away has joined ##opengl[07:01:31] *** echelon has quit IRC[07:09:08] <Madsy> Most questions goes on like this: http://rafb.net/p/1Lepoh52.html[07:09:20] <Madsy> Yes I wrote that, and yes I am bored.[07:10:33] *** amz has quit IRC[07:10:50] <garou> Oh... my... goodness. That gave me a fit of nervous laughter. I hope you reported him to the Code Patrol?[07:13:52] <Madsy> I wish we had one :-)[07:15:23] <Madsy> Right now, I'm setting up a forum I intend to invite regulars to.[07:16:02] <Madsy> Perhaps it sounds elitist, but I hope we can get some nice discussions going, and a prime environment to ask for help and feedback, with little "noise".[07:16:17] *** mm765 has quit IRC[07:17:09] <garou> What's elitist about that? Do you intend it to be for a restricted audience?[07:17:39] <Madsy> Regulars from here.[07:17:54] <Madsy> Let's say, those who don't behave like in the example above :-)[07:18:11] <Madsy> Restricted indeed.[07:18:38] <garou> Mmmmh... Okay, that's *technically* elitist.[07:18:39] <Madsy> I won't open it up until I have something to contribute with, though. Like some threads with useful information[07:19:17] <Madsy> In that case, you will *love* stupidfilter ;-)[07:19:24] <garou> Like a QTSNBAH?[07:19:37] <Madsy> http://stupidfilter.org/main/[07:20:29] <garou> Errr... A generic bayesian filter?[07:21:02] <garou> Won't help, even that idiot you pasted knew how to write.[07:21:21] <Madsy> Hahaha.[07:21:32] <Madsy> Because *I* know how to write.[07:21:38] <garou> Oh...[07:21:53] <Madsy> It was just an example which I wrote in a hurry.[07:22:40] <Madsy> Add some really bad grammar, and mix in some AOL abbreviations, and you got your average IRC user.[07:23:39] <garou> I thought that freenode was better than that...[07:24:01] <Madsy> Well, FreeNode and IRCNet is better than most.[07:24:25] <Madsy> I don't even dare to connect to QuakeNet anymore.[07:24:36] <Madsy> And I was an avid gamer.[07:30:36] *** [this] has joined ##opengl[07:49:08] <garou> Is there any reason why one would *not* use doublebuffering?[07:50:31] *** quicksil1er is now known as quicksilver[07:52:15] <Madsy> Well, you might win some efficiency on using single-buffering if you render still images.[07:52:31] <Madsy> Other than that, no. Animation looks like crap without it.[07:55:27] *** Lemml has joined ##OpenGL[07:59:46] <garou> And is there good reason to call glFlush() more than once per frame?[08:01:15] <Walt> Madsy :O Have you perhaps nicke Mady Ze Wady in a game?[08:01:41] <Madsy> Nope.[08:01:44] <Walt> I see[08:01:47] <Madsy> It has always been madsy[08:01:48] <Walt> could have been, heh[08:02:05] <Madsy> Since about.. 1993, when I first logged on online[08:02:26] <Madsy> I used to surf on happypuppy and yahoo back then :-)[08:02:27] <Walt> I played guild wars for some time, with someone nicking Madsy/Mady ze wady. And we hung around on QNet[08:02:57] <Madsy> Then my dad got Doom, and I was hooked.[08:03:06] <Walt> ah, Doom[08:03:07] <Madsy> 14400 baud modems was the shit back then.[08:03:25] <Madsy> Finally I moved to Quake and later QuakeWorld[08:03:32] <Madsy> Now known as GameSpy[08:07:10] *** Walt has quit IRC[08:08:06] *** korff has quit IRC[08:08:10] <garou> Damn this Peer! One day I'll hunt that guy down, wherever he might be. Sounds danish, though...[08:09:04] <Madsy> Okay, my forum sections are finally finished. Any suggestions on what topics I could write HOWTOs and articles about?[08:09:19] <Madsy> I'm soon done with an OpenGL FAQ[08:10:33] <garou> "What are some good papers on {trees,fire,terrain,NURBS} and where do I get them without being in the ACM?"[08:12:01] <garou> Also, "Is there any reason to call glFlush() more than once per frame?". :)[08:13:09] *** Tuxiscool has joined ##OpenGL[08:13:27] <HuntsMan> BTW how does the HW handles constants and variables on a GLSL shader?[08:15:06] <HuntsMan> garou: some people post their papers on their personal sites, but getting an ACM account and digital library access would be killer[08:15:09] <HuntsMan> i have :)[08:15:30] <garou> So do I. :) Well, the university has.[08:15:46] <HuntsMan> if you are student, it's more or less 45 USD to get one[08:15:58] <HuntsMan> 25 to get an ACM membership, and 20 to get digital library full access[08:16:02] <HuntsMan> anually[08:16:30] <Tuxiscool> Most companies should be pretty happy to pay for a membership too.[08:16:33] <garou> Well... Got it for free ATM. ^^[08:16:43] <HuntsMan> better :)[08:17:18] <HuntsMan> the just search :)[08:17:54] *** Castigador has joined ##Opengl[08:19:08] *** Suprano has joined ##OpenGL[08:19:12] <garou> I will once the basics of what I'm writing ATM are done. No point in going over complex algorithms if I've got nothing to display them yet.[08:19:46] <HuntsMan> yep[08:22:15] <garou> Looks like my glFlush() questions has some complex implications: http://developer.apple.com/technotes/tn2004/tn2093.html#TNTAG6[08:29:36] *** neoneye has joined ##OpenGL[08:33:11] <garou> k, grabbing a little sleep, CU in a few hours.[08:35:57] *** charlie_zzz is now known as charlie5[08:38:02] *** Aardappel has joined ##OpenGL[08:40:22] *** prophile has joined ##opengl[08:41:56] *** prophile has quit IRC[08:44:23] *** Roderic has joined ##OpenGL[08:44:24] *** Roderic is now known as Ingenu[08:48:15] *** Walt has joined ##opengl[08:57:39] *** korff has joined ##OpenGL[09:03:19] *** dolphin has joined ##OpenGL[09:06:12] *** Madsy has quit IRC[09:06:13] *** SirRace has quit IRC[09:06:13] *** Shoozza has quit IRC[09:06:14] *** CNU has quit IRC[09:15:01] *** enoex has left ##OpenGL[09:18:04] *** Madsy has joined ##OpenGL[09:18:04] *** CNU has joined ##OpenGL[09:18:04] *** SirRace has joined ##OpenGL[09:18:04] *** Shoozza has joined ##OpenGL[09:19:54] *** [AD]Turbo has joined ##OpenGL[09:20:46] <[AD]Turbo> yo all[09:25:13] <Ingenu> '[09:28:53] *** Scutt has quit IRC[09:32:24] *** Lemml has quit IRC[09:35:43] *** kaotrix has joined ##OpenGL[09:36:57] *** Scutter has joined ##OpenGL[09:37:47] *** LordHavoc has quit IRC[09:44:31] *** Watermelon2 has joined ##OpenGL[09:46:29] *** HuntsMan has quit IRC[09:49:45] *** Scutter has quit IRC[09:55:34] *** Tuxiscool has quit IRC[09:57:29] *** Scutter has joined ##OpenGL[10:02:45] *** sohail has quit IRC[10:02:45] *** HuntsMan has joined ##opengl[10:03:51] *** Watermelon2 has quit IRC[10:11:57] *** joakim_ has joined ##OpenGL[10:22:41] *** Watermelon2 has joined ##OpenGL[10:23:26] *** dvoid_ has joined ##OpenGL[10:28:43] *** Lemml has joined ##OpenGL[10:29:49] *** Scutter has quit IRC[10:30:19] *** Watermelon2 has quit IRC[10:42:27] *** rhythm has joined ##Opengl[10:49:57] *** echelon has joined ##OpenGL[10:50:32] *** groton has joined ##OpenGL[10:51:22] *** Scutt has joined ##OpenGL[10:51:50] *** Scutt is now known as Scutter[11:00:20] *** BahamutZERO has joined ##OpenGL[11:06:53] *** stuckie has quit IRC[11:08:58] *** Suprano has quit IRC[11:09:01] *** Maerz has joined ##OpenGL[11:09:59] *** mm^away is now known as mm765[11:11:55] *** FierceGuppy has joined ##OpenGL[11:12:11] *** FierceGuppy has left ##OpenGL[11:12:55] *** MatthiasM has quit IRC[11:13:03] *** MatthiasM has joined ##opengl[11:28:23] *** LtJax has joined ##opengl[11:32:53] *** elite01 has joined ##opengl[11:33:35] *** Ingenu has quit IRC[11:35:31] *** ville has quit IRC[11:36:30] *** XypherOrion has quit IRC[11:38:39] *** scy has joined ##opengl[11:38:40] *** Roderic has joined ##OpenGL[11:38:41] *** Roderic is now known as Ingenu[11:39:08] *** Plagman has joined ##OpenGL[11:39:29] *** charlie5 is now known as charlie_zzz[11:44:45] *** DobosCake has quit IRC[11:45:03] *** Baba__ is now known as Baba[11:45:08] *** Baba is now known as baballama[11:45:36] *** DobosCake has joined ##OpenGL[11:49:48] *** DobosCake has quit IRC[11:49:56] *** DobosCake has joined ##OpenGL[11:57:07] *** Osah has quit IRC[11:57:17] *** Osah has joined ##OpenGL[11:57:58] *** Rangar has joined ##OpenGL[12:02:06] *** quicksil1er has joined ##opengl[12:02:09] *** DobosCake has quit IRC[12:03:49] *** quicksilver has quit IRC[12:03:53] *** quicksil1er is now known as quicksilve[12:03:56] *** quicksilve is now known as quicksilver[12:16:29] *** samuel has joined ##OpenGL[12:16:33] <samuel> Hi,[12:16:51] <samuel> I'm trying to use an array of floats as a lookup table in GLSL but it won't compile[12:17:05] <samuel> even stuff cut and paste from the 1.20 opengl GLSL specification won't compile[12:17:13] <samuel> this is on an Nvidia 8600M GT[12:17:28] <samuel> can anyone give me feedback?[12:17:53] <exDM69> what does the compile error log say[12:18:29] <exDM69> a wild guess: try adding #version 120[12:18:34] <exDM69> to the shader source[12:18:41] <samuel> ERROR: 0:19: 'array of float' : constructor not supported for type[12:18:42] <samuel> ERROR: 0:19: 'array of float' : no matching overloaded function found[12:18:42] <samuel> ERROR: 0:19: 'const float' : cannot declare arrays of this type[12:18:51] <samuel> ERROR: 0:19: 'c' : redefinition[12:19:00] <samuel> I've tried adding version 120[12:19:03] <samuel> but it didn't help[12:19:36] <samuel> trying to compile: const float c[3] = float[3](5.0, 7.2, 1.1);[12:19:48] <samuel> that line is from the glsl specification[12:21:18] <samuel> do you have any idea why it could be not working[12:21:21] <samuel> it seems so strange[12:23:26] <samuel> hello?[12:28:23] *** karabash has joined ##OpenGL[12:29:35] <karabash> hi[12:29:40] <samuel> hi[12:32:56] *** blight_ has joined ##opengl[12:37:00] *** elite01 has quit IRC[12:37:13] *** elite01 has joined ##opengl[12:37:30] *** anli has quit IRC[12:44:25] *** samuel has quit IRC[12:47:57] *** Jorachim has joined ##openGL[13:11:27] *** LtJax has quit IRC[13:11:54] *** scy has left ##opengl[13:19:08] *** Bollinger has joined ##opengl[13:31:21] *** Maerz has quit IRC[13:32:02] <garou> Hi again.[13:32:11] *** rnx has joined ##opengl[13:43:27] *** hibread has joined ##opengl[13:45:59] *** Burga_ has joined ##OpenGL[13:46:20] *** Watermelon2 has joined ##OpenGL[13:48:22] *** scy has joined ##opengl[13:49:56] *** Castigador has quit IRC[14:02:44] *** karabash has quit IRC[14:02:59] *** karabash has joined ##OpenGL[14:05:45] *** morgajel has quit IRC[14:05:57] *** morgajel has joined ##OpenGL[14:22:31] *** LordMetroid has joined ##OpenGL[14:24:39] *** lordmetroid_ has joined ##OpenGL[14:33:17] *** Jorachim has quit IRC[14:41:08] *** LordMetroid has quit IRC[14:50:24] *** echelon has quit IRC[14:54:22] *** Ademan_ has joined ##OpenGL[14:55:06] *** Jupp3 has joined ##OpenGL[15:00:35] *** korff has quit IRC[15:03:44] *** aalex has joined ##OpenGL[15:06:16] *** Lemml has quit IRC[15:08:30] *** Lemml has joined ##OpenGL[15:10:08] *** Ademan has quit IRC[15:14:28] *** Lemml has quit IRC[15:21:50] *** Lemml has joined ##OpenGL[15:22:56] *** mm765 is now known as mm765^sleep[15:25:55] <garou> And hi again.[15:26:07] <garou> I've researched a little about doublebuffering.[15:26:53] <garou> As far as I could see, it's not save to call Flush() before swapping buffers, as some commands might end up being executed on the new offxcreen buffer, is that correct?[15:27:46] <garou> Also, does Finish() wait for commands to be executed which were Flush()ed earlier?[15:28:51] *** mastro has quit IRC[15:35:16] *** TheLorax has joined ##opengl[15:35:37] *** aalex has quit IRC[15:42:25] *** Lucine has quit IRC[15:42:55] *** Lucine has joined ##OpenGL[15:43:15] *** tmccrary has joined ##OpenGL[15:45:44] <Ingenu> swap implicitely flushes[15:45:50] <Ingenu> herm finishes even[15:46:53] <garou> Thank you.[15:47:02] *** replor has joined ##OpenGL[15:47:27] *** Suprano has joined ##OpenGL[15:51:22] *** Jorachim has joined ##openGL[15:59:23] *** Watermelon2 has quit IRC[16:01:02] *** Walt has quit IRC[16:02:27] *** lordmetroid_ has quit IRC[16:05:21] *** Watermelon2 has joined ##OpenGL[16:06:56] *** LtJax has joined ##opengl[16:08:13] *** [this] has quit IRC[16:08:40] *** bbeausej has joined ##OpenGL[16:16:06] <hibread> Ingenu: wouldn't that be flush? Finish() doesn't return until everything has been flushed[16:25:35] *** prophile has joined ##opengl[16:26:55] *** dvoid_ has quit IRC[16:29:35] *** sohail has joined ##OpenGL[16:30:41] *** chammiya has joined ##OpenGL[16:30:54] *** chammiya has quit IRC[16:34:34] *** Keyframe2 has joined ##OpenGL[16:35:00] *** pfo has joined ##OpenGL[16:38:16] *** LtJax has quit IRC[16:38:29] *** Aardappel has quit IRC[16:45:26] *** Jorachim has quit IRC[16:49:04] *** sanjin has joined ##OpenGL[17:01:09] *** rhythm has quit IRC[17:01:10] *** amz has joined ##opengl[17:10:38] *** karabash has quit IRC[17:12:49] *** Keyframe2 has quit IRC[17:30:23] *** Ingenu has quit IRC[17:30:41] *** [AD]Turbo has quit IRC[17:33:09] *** nitrotrigger has joined ##opengl[17:34:14] <nitrotrigger> do you think 345fps for software opengl in glxgears is a sufficient result?[17:34:58] <HuntsMan> glxgears isn't a benchmark, so, no[17:35:23] <dindinx> glxgears isn't a benchmark, so, yes[17:35:28] <Watermelon2> "software opengl"...[17:35:37] <Watermelon2> cpu benchmark...[17:35:52] *** samuel has joined ##OpenGL[17:36:02] <nitrotrigger> I have amilo a7640, sempron 3000+, SiS M760 128MB shared memory, gpu integrated, 512mb slow memory[17:36:40] <nitrotrigger> I know it's not a benchmark[17:37:02] <Watermelon2> your gfx card sux...[17:37:11] <nitrotrigger> I know that too[17:37:14] <Watermelon2> probably there is no linux driver for that...[17:37:17] <nitrotrigger> but does it suck that much?[17:37:19] <Watermelon2> with 3d acceleration[17:37:57] <samuel> does anyone here have experience with glsl?[17:38:15] <HuntsMan> samuel: just ask the question[17:38:31] <samuel> i'm having trouble with const arrays in glsl[17:38:37] <samuel> can't get it to compile[17:38:44] <samuel> even the examples in the glsl reference documentation[17:38:50] <samuel> const float c[3] = float[3](5.0, 7.2, 1.1);[17:38:57] <samuel> won't compile[17:39:04] <samuel> but its right out of the reference documentation[17:39:12] <samuel> i'm running nvidia 8600M[17:39:41] <samuel> is anyone able to see if that line will compile as part of a vertex or fragment shader[17:40:37] <HuntsMan> well i have the same problem here on 8400GS M, and sounds like a compiler bug[17:40:48] <HuntsMan> as even using #version 110 or 120 it doesn't compile[17:40:55] <samuel> did you just try to compile it[17:41:06] <HuntsMan> no, but tried yesterday :)[17:41:22] <samuel> oh really[17:41:26] <samuel> so you tried to use arrays too[17:41:30] <HuntsMan> yeah[17:41:31] <samuel> and couldn't get it to work?[17:41:38] <samuel> thats really odd[17:41:40] <HuntsMan> non-const, yes[17:41:41] <HuntsMan> const, no[17:41:52] <HuntsMan> yep[17:41:56] <samuel> how did you get non-const arrays to work[17:42:06] <HuntsMan> just remove the const[17:42:12] <samuel> and it worked?[17:42:17] <samuel> was there much of a performance hit?[17:42:51] <HuntsMan> i would think as yes, but i do not have something to compare against with[17:43:12] <samuel> can you show me the exact syntax you were using?[17:43:21] <samuel> i'm still getting trouble even just removing const[17:43:49] <HuntsMan> vec2 gradients2D[] = vec2[](vec2(0.7071, 0.7071), vec2(-0.7071, 0.7071), vec2(0.7071, -0.7071), vec2(-0.7071, -0.7071));[17:43:49] <HuntsMan> for example[17:44:41] <samuel> I get: 'array of 2-component vector of float' : constructor not supported for type[17:44:51] <samuel> 'array of 2-component vector of float' : no matching overloaded function found[17:44:58] <samuel> 'gradients2D' : redefinition[17:45:16] <HuntsMan> lol[17:45:24] <HuntsMan> i have 169.12 drivers for Linux BTW[17:45:52] <samuel> i'm running on mac os x: NVIDIA GeForce 8600M GT OpenGL Engine 2.0 NVIDIA-1.5.26[17:46:08] <samuel> how annoying[17:46:13] <HuntsMan> only OpenGL 2.0?[17:46:26] <samuel> what version are you running[17:46:27] <samuel> 2.1?[17:46:31] <HuntsMan> yeah[17:46:34] <samuel> ah i see[17:46:48] <HuntsMan> and #version 120[17:48:20] <HuntsMan> BTW i wanna know how many constants does a implementation support, any ideas?[17:48:32] <samuel> no idea sorry[17:52:34] <samuel> http://developer.apple.com/graphicsimaging/opengl/capabilities/ this might help you[17:53:43] *** magnet has quit IRC[17:53:44] *** TheLorax has quit IRC[17:53:54] *** magnet has joined ##OpenGL[17:54:44] *** TheLorax has joined ##opengl[17:55:16] *** sanjin has quit IRC[17:58:56] *** magnet_ has joined ##OpenGL[18:04:01] *** Lemml has quit IRC[18:06:07] *** rutski has joined ##OpenGL[18:06:19] <magnet_> hi everyone.[18:07:47] *** Lemml has joined ##OpenGL[18:07:54] <magnet_> is it normal that a texture of 512x512 scaled on a 640x480 quad use a lot of ressources ? my code run fine with 2 textures 128x128 on a 128x128 quad.[18:08:46] <magnet_> but with a 128x128 and that 512x512 one , that take 10 more time.[18:09:47] <hibread> where are you getting the figure 10 more time?[18:10:30] <magnet_> I look a the time spend to draw the opengl scene.[18:11:42] <hibread> 640x480 quad vs 128x128 quad... So you've got some screen res greater in size than 640x480, and all you're doing is rendering a quad with a texture?[18:12:08] <hibread> of 2 different sizes? 640x480 and the other of 128x128?[18:12:36] <magnet_> I use openGL for 2D, the 640x480 was supposed to be the background, and the 128x128 a sprite.[18:13:39] <magnet_> all I do atm is render 2 quads with a textures.[18:13:45] <hibread> sorry i dont follow what you're trying to do and what 2 tests you are making to see a 10x performance decrease[18:14:10] <magnet_> hehe np, I must not have been clear.[18:14:46] <magnet_> I try to draw 2 quads ( one 640x480 and the other 128x128 ), and to have a texture 512x512 on first, and 128x128 on second.[18:15:20] <hibread> yep, gotchya so far...[18:15:25] <magnet_> to see how many time it take I look at the time spend to draw the openGL scene .[18:22:40] *** dvoid__ has joined ##OpenGL[18:23:33] *** Walt has joined ##opengl[18:23:48] <magnet_> hibread: you got any idea on why I'm getting bad performances ?[18:24:07] <hibread> what actual performance are you getting?[18:24:28] <hibread> just doing that you should get hundreds of frames per second (depending ofcourse on your hardware)[18:24:37] <magnet_> I calculate fps,[18:24:52] <hibread> what is the frame rate you are getting?[18:24:53] <magnet_> with background only I got like 8k fps[18:25:14] <magnet_> with background + sprite around 3 .( not 3k just 3 ).[18:25:15] <exDM69> magnet_: fps's like that are not meaningful[18:25:27] <magnet_> and with 2 128x128 sprites, like 60.[18:25:36] <hibread> wel somethings not right there[18:25:38] <hibread> what hardware do you have?[18:25:56] <hibread> sounds like a software path is being executed[18:26:21] <magnet_> intel i945 .[18:26:38] <hibread> i know nothing about intel[18:27:40] <magnet_> having 8k for just a quad sound ok to me. 60 for the 2x128 sound already weak, and 3 fps, umm doh.[18:27:55] <magnet_> I tried other openGL applications, those works quite ok.[18:28:02] <hibread> i'd agree. Somethings not right[18:28:15] <hibread> is the program small?[18:28:21] <hibread> can you show some code?[18:28:39] <magnet_> sure, I can compress the drawing code to a few lines.[18:28:44] <magnet_> lemme pastebin it.[18:30:28] <magnet_> http://pastebin.ca/1005130[18:30:45] <magnet_> there is not much to see, I guess it's more something I forgot.[18:30:57] <hibread> oh no, another crappy language :)[18:31:03] <magnet_> if you need more code, like openGL init , tell me.[18:31:14] <magnet_> hibread: meh ! perl rox.[18:31:17] <hibread> yeah, gl init would be helpful[18:32:19] *** Yustme has joined ##opengl[18:33:09] <quicksilver> how you set up the textures might be relevant.[18:33:09] <tmccrary> perl! yikes![18:33:21] <quicksilver> it sounds a bit like it doesn't think your card is capable of a texture that big[18:33:28] <quicksilver> and ends up emulating in software?[18:33:34] <quicksilver> although you said bg alone was fine.[18:33:35] <magnet_> http://pastebin.ca/1005133[18:33:36] * quicksilver looks doubtful.[18:33:50] <magnet_> quicksilver: I had the same thinking earlier :)[18:34:31] <quicksilver> are you doing something stupid like re-loading the tex every frame?[18:34:38] <hibread> nothing evil looking in that code, except for the language[18:34:38] <quicksilver> calling texImage2D each frame?[18:34:48] <hibread> quicksilver: good thinking![18:35:23] <magnet_> quicksilver: I'm new to openGL, if I don't use that texImage2D to choose wich texture to apply, how can I do ?[18:35:40] <hibread> magnet_: you only need to call that function once..[18:35:41] <hibread> poer function[18:35:43] <hibread> *per[18:35:52] <hibread> and then bind the texture before use[18:36:31] *** tython has joined ##OpenGL[18:37:03] <magnet_> q[18:37:05] <magnet_> ops :)[18:37:36] <quicksilver> once per texture[18:37:38] <quicksilver> I think hibread means[18:37:46] <quicksilver> once you have "loaded" the image into an opengl texture[18:37:51] <quicksilver> you can then use it for the rest of your program[18:37:53] <hibread> oh yep sorry[18:38:02] <quicksilver> (hopefully it is now stored on your video card for rapid access)[18:38:41] <magnet_> whatever I only use glTexImage2d once per image, when I load images, ( in the call to image_load ).[18:45:00] <quicksilver> that sounds right[18:45:46] *** nitrotrigger has left ##opengl[18:46:15] <magnet_> I tried putting 1 sprite 128x128 , and 5 other with different size,[18:46:32] *** amalon has joined ##opengl[18:46:42] <magnet_> I get dramaticaly bad perfomances if textures are more than 32x32 .[18:47:02] <magnet_> ( scaled down, those are 128x128 on a 32x32 quad ).[18:47:13] <magnet_> quit[18:47:13] <hibread> magnet_: you're absolutely sure that you are not uploading the texture to your hardware each frame?[18:47:16] <magnet_> ops.[18:47:22] <quicksilver> the scaling certainly shouldn't matter.[18:47:29] <quicksilver> texture scaling is fast that's the whole point :)[18:47:34] <magnet_> hibread: yep the only call is at image loading.[18:47:40] <quicksilver> I think you might need to post your whole code[18:47:42] <quicksilver> well, more of it ;)[18:47:45] <HuntsMan> magnet_: are you using mipmapping?[18:47:47] <quicksilver> the main display loop.[18:48:19] <magnet_> HuntsMan: no I do not.[18:48:36] <magnet_> quicksilver: ok I update the pastebin.[18:48:39] <HuntsMan> you should, you'l get better performance[18:49:09] <magnet_> oh :)[18:49:34] <quicksilver> mipmapping mostly gives you more attractive scaling[18:49:38] <quicksilver> rather than better performane, IMO[18:49:55] <hibread> in this instance you'll not get a speed boost from mipmapping[18:50:12] <HuntsMan> if you minify textures, it should[18:50:27] <hibread> quicksilver: well.. yeah it can definitely give performance boosts in certain scenarios for sure[18:50:27] <HuntsMan> as it would access lower mipmap levels, and not minify the 0 level each render[18:50:59] <quicksilver> yeah but if the minification is just nearest-neighbour[18:51:04] <quicksilver> it doesn't take any time really[18:51:23] <magnet_> http://pastebin.ca/1005149 I added the 2 functions that act as 'main loop' .[18:51:25] <hibread> comes down to caching effectiveness does't it?[18:51:49] <hibread> magnet_: no offense, but perl isn't pretty :p[18:51:54] <quicksilver> I thought textures stored the mipmapped versions alongside the main one.[18:52:04] <quicksilver> I don't know if they can cache one and not t'other[18:52:23] <magnet_> hibread: hehe no offense.But it would be better to say 'your perl isn't pretty' :)[18:52:28] <quicksilver> you should proabbly use double buffering[18:52:41] <quicksilver> that's the preferred approach afaik[18:52:42] <magnet_> hibread: that not very polished code, it's just to test.[18:52:52] <magnet_> quicksilver: I do use double bufferring.[18:53:20] <quicksilver> you do?[18:53:25] <hibread> quicksilver: say you're rendering a triangle which only takes up say 100 pixels but the texture is 1024x1024... you're basically asking for random access[18:53:25] <quicksilver> I don't see the swapBuffers call[18:53:39] <quicksilver> hibread: yup[18:53:45] <magnet_> SDL do it for me.[18:53:49] <hibread> which is very bad performance wise[18:53:50] <quicksilver> hibread: but that's OK because RAM is random access[18:53:54] <quicksilver> ;)[18:53:57] *** nerdzyboy has joined ##OpenGL[18:54:06] <quicksilver> hibread: only if the texture isn't in the cache. If it is it really doesn't matter how you access it.[18:54:07] <hibread> quicksilver: well yes.. but its no where near as good as streaming out contiguous data :)[18:54:12] <quicksilver> on the contrary[18:54:17] <quicksilver> it's *exactly* the same speed.[18:54:20] <quicksilver> that's why it's called RAM.[18:54:22] <hibread> errr[18:54:25] <quicksilver> and nod stream ;)[18:54:35] <quicksilver> if it's in the video cards cache.[18:54:41] <hibread> how bigs the cache?[18:54:48] <quicksilver> 256M on modern cards[18:54:53] <quicksilver> (well shared with buffers and stuff)[18:55:03] <hibread> so you're talking about the vram[18:55:03] <quicksilver> smaller on old ones, of course.[18:55:11] <hibread> not actual on-die cache?[18:55:13] <quicksilver> yes. the texture cache is in the vram.[18:55:17] <nerdzyboy> could anyone refer me to an easy to use video decoding library that would allow binding video to a quad? (needs to run under linux and have c++ binding)[18:55:37] <magnet_> nerdzyboy: SDL allow to do that I think.[18:55:53] <hibread> quicksilver: I really hope you're wrong here :) Just because its random access, doesn't mean its good at it :)[18:56:23] <nerdzyboy> I'll look at the sdl documentation.. thanks[18:56:26] <quicksilver> hibread: I promise you, RAM is random access. That's what the acronym stands for.[18:56:28] *** karabash has joined ##OpenGL[18:56:37] <HuntsMan> nerdzyboy: ffmpeg[18:56:38] <quicksilver> and textures are typically pretty small pieces of memory by modern standards.[18:56:57] <quicksilver> I don't know whether any recent GPUs have auxiliary on-die caches.[18:57:10] <hibread> so you're saying that if you access some finite amount of "completely random data" from the GDDR3 video memory (or what ever) its going to read at the same pace as that same finite amount of memory that happens to be contiguous? :)[18:57:18] <quicksilver> but the purpose of the VRAM is to serve as a fast local store for frame bumffer.[18:57:22] <quicksilver> hibread: that's exactly what I'm saying, yes.[18:57:31] <hibread> well i thikn you're wrong :)[18:57:35] <quicksilver> that is how RAM chips work.[18:57:39] <hibread> but in saying that, im happy to be wrong[18:57:42] <quicksilver> ;)[18:57:50] <tmccrary> *mee moo mee moo mee moo*[18:57:57] <tmccrary> one of my detectors just went off[18:58:04] *** DR0ID_ has joined ##OpenGL[18:58:05] <tmccrary> I'll have to go see what this is all about[18:58:18] <nerdzyboy> HuntsMan, I looked at ffmpeg but their documentation is lacking a bit[18:58:23] <hibread> quicksilver: what makes you think that it'll be the same speed?[18:58:26] <hibread> just because its calle dRAM?[18:58:42] <nerdzyboy> HuntsMan, do you know of any sample code or tutorial on how to use ffmpeg?[18:59:02] <HuntsMan> nerdzyboy: no, but i've seen some on google, as with OpenGL also[18:59:13] <nerdzyboy> k thanks[19:00:15] <quicksilver> hibread: I know a fair amount about computer software and hardware having studied it for many years and taught it for some.[19:00:36] <quicksilver> hibread: I'm no expert in graphics cards in particular but I believe my knowledge of the general principles is sound.[19:00:36] <hibread> quicksilver: assuming that video memory works just as main memory (i think its all just forms of DDR), then there are latencies involved with row somethings and column somethings... doesn't that all count?[19:00:54] <quicksilver> in main memory you have the issue that the memory clock is quite a bit slower than the CPU clock[19:01:04] <quicksilver> so the main memory can't fetch data fast enough to satisfy the CPU[19:01:13] <quicksilver> and you have 1 or more layers of caches between the two[19:01:18] <quicksilver> in order to mitigate this problem.[19:01:27] <magnet_> do you guys have any suggestions on that performance trouble ?[19:01:30] <quicksilver> even so, those caches are themselves megabytes in size.[19:01:31] <hibread> which problem? the speed difference problem?[19:01:50] <quicksilver> I don't think GPUs have this extra complexity between them and the VRAM[19:01:52] <quicksilver> I could be wrong there.[19:02:06] <hibread> thats beside the point atm[19:02:21] <hibread> how come no one else is coming to the party on this debate[19:02:29] <hibread> i want to know the real truth, either way[19:03:47] <HuntsMan> magnet_: what GPU do you have?[19:03:58] <magnet_> intel i945 GM .[19:04:14] <HuntsMan> mmm, a sucky one...[19:04:24] <magnet_> yes not very good.[19:04:36] <magnet_> but I run some other openGL applications quite fine.[19:07:44] <hibread> quicksilver: well actually.. quite a while ago i programmed a post vertex processing cache optimizer. I realized that performance wasn't always "great" after i performed the optimization (eg, the way the meshes index list was originally "ordered" gave better performance than the ordering I ended up with). I then realized that i hadn't re-sorted the actual vertex/normal/texture lists.. only the index list. So the ordering in memory for more contiguous[19:07:45] <hibread> reading definitely helped here[19:08:13] <quicksilver> yes, that's because you were overflowing the cache[19:08:27] <hibread> ?[19:08:29] <hibread> :)[19:08:31] <quicksilver> if you overflow whatever portion of the VRAM the graphics card, in its wisdom, decides to allocate for a particular purpose[19:08:40] <quicksilver> (e.g, a vertex list, or a texture, or a display list, or )[19:08:48] <quicksilver> then it drops back into main memory.[19:08:54] <quicksilver> if you are in teh overflow situation[19:09:02] <quicksilver> then suddenly ordered access matters very much indeed[19:09:05] *** gotan666 has joined ##OpenGL[19:09:14] <quicksilver> because random access can keep refetching from memory more often than needed.[19:09:19] <hibread> errr... how is that related to what i was just discussing?[19:09:43] <quicksilver> you were programminga cache optimizer[19:09:45] <hibread> you think i was literally running out of vram? and swapping out to agp memory was occuring?[19:09:46] <quicksilver> so you said?[19:09:51] <quicksilver> yes, I do.[19:10:06] <hibread> even if i was only uploading say... 200k vertices...?[19:10:11] <quicksilver> the graphics driver has to make hard decisions about what to keep in memory[19:10:19] <quicksilver> vertex lists, texture lists, display lists, textures themselves[19:10:25] <quicksilver> obviously the back and front buffers[19:10:30] <quicksilver> any offscreen buffers you may be using[19:10:47] <quicksilver> so I guess you can overflow any one particular chunk into main memory[19:10:54] <quicksilver> even if you don't imagine you would "run out of VRAM" entirely.[19:11:07] <hibread> so even though i may only upload one smallish VBO for instance.. it would stil swap in and out?[19:11:13] <quicksilver> taht would be my guess as to why your optimiser worked.[19:11:20] <quicksilver> well, if it's small enough to fit in, then it won't[19:11:27] <quicksilver> at some critical size it will fall out[19:11:37] <quicksilver> and once you reach that critical size, ordering will matter a lot.[19:11:50] <hibread> well im saying right now that the amount of data i was VBO'ing was tiny with respect to the size of my VRAM[19:12:02] <hibread> yes that makes sense.. but i was definitely well below that threshold[19:12:28] <quicksilver> then I qwould be very surprised to see an ordering effect.[19:12:35] <quicksilver> it might have been a slightly different effect[19:12:44] <quicksilver> to do with keeping all the different GPU pipelines working?[19:12:57] <quicksilver> transform units, texture units.[19:13:00] <hibread> at the moment i dont have my lists interleaved either. So i expect to see a small improvament in performance once i merge the lists :)[19:13:01] <quicksilver> this is well out of my depth though :)[19:13:39] <hibread> quicksilver: its simple.. random access isn't as fast as contiguous access :)[19:14:06] <quicksilver> that is not a general property of RAM systems. Quite the opposite.[19:14:18] <quicksilver> it is a property of systems which involve intermediate caches of some sort, though[19:14:30] <quicksilver> I didn't believe there was one between the texture memory and the GPU[19:14:37] <quicksilver> which is my initial response to the query[19:14:48] <quicksilver> with a more complex issue involving keeping all your GPU pipelines full[19:14:51] <hibread> magnet_: where are all your calls to glTexImage2D(...) etc?[19:14:55] <quicksilver> there probably is :)[19:15:02] <quicksilver> magnet_: and where is the swapBuffers call?[19:15:09] <quicksilver> if you claim this is double buffered :)[19:15:19] <magnet_> hibread: I update the pastebin, it's in the image_load call . quicksilver there is now swapBuffers I believe SDL do it for me.[19:16:37] *** enoex_ has joined ##OpenGL[19:16:43] <hibread> magnet_: can i see image_draw and image_load please[19:17:51] <magnet_> http://pastebin.ca/1005168[19:17:52] *** rutski has quit IRC[19:18:09] <magnet_> image_draw is the first one, image_load the last.[19:19:42] <hibread> magnet_: not that it probably matters, but i think GL_UNSIGNED_INT_8_8_8_8 is desired over GL_UNSIGNED_BYTE[19:20:58] <magnet_> I'm ready to try anything ![19:21:56] <magnet_> yea this do not change much.[19:22:42] <hibread> what happens if you turn off blending?[19:22:57] <magnet_> I try.[19:24:18] <magnet_> umm it sound like it boost a bit speed. lemme try with just 2 quads ( one big and one small ) .[19:25:49] <magnet_> yea just a small perfomance boost , and texture colors became more red.[19:26:13] <magnet_> ( I still just have 4 fps, with 2 quad, on 640x480 and one 128x128 ).[19:26:20] <hibread> crazy[19:28:22] <magnet_> with a dozen of 32x32 textured quads I just get ~10 fps.[19:29:24] <hibread> quicksilver: http://en.wikipedia.org/wiki/Dynamic_random_access_memory Check down in the Memory timing section. Quote: "Thus, the generally quoted number is the /RAS access time. This is the time to read a random bit from a precharged DRAM array. The time to read additional bits from an open page is much less."[19:35:00] <hibread> magnet_: tried rebooting? :)[19:35:28] <magnet_> hibread: hehe I'm not desperate enough yet :)[19:38:08] <magnet_> hibread: I give a test on another computer which is more powerfull.[19:38:15] <magnet_> still it got a crappy video card.[19:38:54] <hibread> if other gl tests work fine, then i doubt its your hardware not being fast enough[19:39:15] <magnet_> you're right.[19:39:34] *** tython has quit IRC[19:39:44] <magnet_> I'm a bit short on ideas in fact.[19:39:44] <hibread> you haven't forced some huge anisotropic filtering or something in your drivers have you?[19:40:01] <magnet_> I don't think so.[19:40:32] <magnet_> no.[19:43:40] <quicksilver> hibread: I stand duly corrected. I woudl be very surprised if that was the source of the speedup you measured though.[19:44:15] <quicksilver> Now I have a question of my own. I'm doign render to texture using glTexCopyImage2D.[19:44:34] <quicksilver> it ought to be fast to use glTexCopySubImage2D though I believe[19:44:44] <quicksilver> since it knows it can reuse the basic texture[19:45:01] <quicksilver> but I lack a convenient way to say "give me an empty black texture of size x * y"[19:45:37] *** HuntsMan has quit IRC[19:46:22] <hibread> what are you trying to do with this render to texture? FBO's are generally the best way to go...[19:46:49] <quicksilver> you're almost certainly right, but I don't know how to use FBOs :)[19:46:55] <hibread> hehe learn! :)[19:47:03] <hibread> they're pretty nifty things[19:47:08] <quicksilver> I'm drawing a 'status panel' which I then textue onto some quads.[19:47:08] *** tython has joined ##OpenGL[19:47:17] <hibread> yeah, then use a FBO[19:47:37] <hibread> you create an FBO then bind empty textures to them in which to draw to[19:47:49] <hibread> and then you can use that texture as per usual to do wha ever you like[19:48:16] <quicksilver> I don't know if all my target machines support FBOs.[19:48:26] <hibread> whats the lowest end?[19:48:31] <quicksilver> I was talking to someone today who thought the linux ATI open source drivers didn't.[19:48:35] <quicksilver> radeon 9250.[19:48:45] <hibread> hmmm[19:48:47] <hibread> not sure about that[19:49:04] <hibread> either that radeon or OS ati drivers[19:49:10] <quicksilver> I will check when I get home, easy to do.[19:49:16] <quicksilver> But I don't have access to that machine frmo here.[19:49:20] <hibread> I always aim for the 2 generations from now! :)[19:49:41] <quicksilver> that's odd.[19:50:04] <quicksilver> last time I tested this I thought repeated calls to texCopyImage were leaking memory[19:50:11] <quicksilver> however running the test again they don't seem to be.[19:50:20] <quicksilver> it must be something else I was doing that was leaking memory.[19:50:47] <magnet_> ummm[19:50:57] <hibread> quicksilver: what do you use for memory leaks? valgrind?[19:51:00] <magnet_> on the other computer I got 3000 fps with the 2 quads.[19:51:08] <magnet_> I don't understand anything.[19:51:20] <hibread> interesting[19:51:24] <quicksilver> hibread: actually I'm just watching my memory usage in OSX's activity mointor.[19:51:25] <quicksilver> not very sophisticated :)[19:51:46] <hibread> quicksilver: how do you know they're memory leaks? :)[19:51:58] <quicksilver> I think it must be my "draw text to a texture" code which is leaking.[19:52:22] <hibread> Those memory apps dont generally tell you an accurate story... well, accurate on the basis of memory leaks[19:52:27] <quicksilver> hibread: because the program isn't really doing anything and memory keeps going up :)[19:52:53] <hibread> i wouldn't worry about that... OS's do some strange things sometimes[19:52:54] <quicksilver> true, it's not terribly accurate.[19:53:03] <quicksilver> but when it's rising by 5MB/second something si wrong[19:53:16] <quicksilver> and after the app has been running a few minutes the machine starts swappig like mad.[19:53:29] <hibread> well yeah, i guess if it just keeps on going and your system starts not behaving properly[19:53:40] <hibread> well yep, thats a leak[19:53:43] *** Walt has quit IRC[19:54:03] <hibread> magnet_: drivers up to date?[19:54:11] <hibread> magnet_: or drivers installed at all? :)[19:54:25] <hibread> not using some generic MS driver?[19:54:49] <hibread> quicksilver: id seriously check out http://www.opengl.org/registry/specs/EXT/framebuffer_object.txt[19:55:01] <quicksilver> I was actually reading that yesterday.[19:55:02] <magnet_> hibread: nah I'm running linux. drivers sound not up to date, I installed it a few month ago.[19:55:06] <magnet_> I'll check this out.[19:55:11] <hibread> if i remeber correctly, my old 5900xt could handle frame buffers objects[19:55:12] <quicksilver> there are more problems I haven't told you about.[19:55:17] <quicksilver> I'm using Haskell.[19:55:19] <hibread> just couldn't have more than one attached texture... maybe?[19:55:28] <quicksilver> and I'm not sure if it's opengl binding supports FBOS.[19:56:20] <quicksilver> tehere is auxBuffers in http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/Graphics-Rendering-OpenGL-GL-Framebuffer.html[19:56:27] <quicksilver> which looks like it might be an interface to FBOs but I'm not sure.[19:56:30] <hibread> magnet_: any driver post 5 years ago should render a quad without issues :)[19:56:49] <magnet_> lol.[19:57:15] *** Xmas| has joined ##OpenGL[19:57:18] <hibread> i dont think aux buffers are a part of the frame buffer object extension[19:59:29] <hibread> quicksilver: sorry i can't help you with glTexCopySubImage2D type calls.. i've only ever used FBOs[19:59:36] *** Suprano has quit IRC[20:01:22] <hibread> magnet_: you said you're using linux didn't you?[20:01:59] <magnet_> yes I do.[20:02:04] <quicksilver> hibread: nod* The only reason I thought auxBuffers might be FBOs is that that page says its based on the opengl 2.1 spec, and I wondered if auxbuffers is what FBOs got called when they were rolled into openGL 2[20:02:16] <quicksilver> hibread: it was flimsy reasoning I agree :)[20:02:28] <hibread> quicksilver: you could very well be right :)[20:02:37] <hibread> i dont even know what haskell is so :)[20:02:49] <hibread> magnet_: do you have to set the opengl implimentation with intel?[20:03:02] <magnet_> yes.[20:03:09] <hibread> magnet_: as in, i can use xorg-x11 or nvidia[20:03:11] *** Walt has joined ##opengl[20:03:21] <hibread> eselect opengl list[20:03:24] <magnet_> oh you're gentoo user ? :)[20:03:25] <quicksilver> magnet_: does glxinfo sho direct rendering : yes ?[20:03:31] <hibread> magnet_: ahh is that gentoo only is it?[20:03:38] <magnet_> yea all that stuff sound ok.[20:03:52] <magnet_> hibread: I think so. trough I run gentoo too.[20:05:03] <hibread> magnet_: so yours is definitely set to "intel" or what ever?[20:05:15] <magnet_> yep.[20:05:44] <hibread> magnet_: direct rendering as quicksilver suggested?[20:06:06] *** DMINATOR has joined ##OpenGL[20:06:32] <magnet_> yes it show Direct Rendering : yes[20:06:33] <hibread> magnet_: i suggest atleast getting a crappy nvidia card for your system :)[20:06:42] <magnet_> that a umpc :)[20:06:51] <hibread> umpc?[20:07:11] <magnet_> ultra mobile pc[20:07:17] <hibread> has legs?[20:07:35] <quicksilver> hibread: I believe I found my memory leak, and it's unrelated to my copyteximage calls[20:07:49] <hibread> quicksilver: what was it related to?[20:07:54] <quicksilver> hibread: I render my text to textures. It's supposed to intelligently cache them so it doesn't render them again the next frame.[20:08:05] <magnet_> it's very small, I cannot add anything inside.[20:08:09] <quicksilver> I broke that some how.[20:08:22] *** Suprano has joined ##OpenGL[20:08:23] <hibread> nice one[20:08:44] <magnet_> http://the-gadgeteer.com/assets/sony-vaio-ux50-3.jpg[20:08:45] <hibread> magnet_: well good luck with your integrated intel[20:09:03] <magnet_> hibread: I'm updating drivers, let's hope it will help.[20:10:15] <hibread> im off to hit the sack[20:10:19] <hibread> good luck guys![20:10:33] <magnet_> thanks again for the help ![20:11:00] <hibread> no worries![20:11:33] *** hibread has quit IRC[20:13:49] *** HuntsMan has joined ##opengl[20:15:13] *** mariazinha has joined ##OpenGL[20:18:52] <mariazinha> hi... can someone help me? http://cpp.ninjacodemonkeys.org/3981 I make materials no emiting any light calling the proc material... but The materials still have light... without any light but with glEnable(GL_LIGHTNING) the objects still emite light... i don't get why :|[20:23:10] *** CNU has quit IRC[20:26:37] *** vibe- has joined ##opengl[20:30:33] <nerdzyboy> What's the best way to change the content of a texture? (I usually destroy the texture and create a new one, but im guessing that there is a better way...)[20:31:58] <TheLorax> nerdzyboy, are you loading from a file?[20:32:05] <HuntsMan> glTexSubImage2D();[20:32:39] <nerdzyboy> no I actually generate pixel data that I load to a texture[20:36:03] <nerdzyboy> is gldrawpixels fast enough to draw video to the screen?[20:36:58] *** joakim__ has joined ##OpenGL[20:40:14] *** Suprano has quit IRC[20:47:25] <quicksilver> nerdzyboy: I was told that gldrawpixels is not the best way[20:47:33] <quicksilver> nerdzyboy: better to use glTexSubImage[20:47:38] <quicksilver> and then render the texture[20:47:43] <quicksilver> ICBW.[20:48:39] <Watermelon2> ICBM?[20:49:02] <quicksilver> ;P[20:52:48] <Watermelon2> i remember that being an alias for RTFW_FTW...[20:54:25] *** joakim_ has quit IRC[20:55:22] *** Suprano has joined ##OpenGL[21:01:49] *** Plagman has quit IRC[21:09:36] *** gotan666 has quit IRC[21:15:31] *** charlie55 has joined ##OpenGL[21:16:04] *** charlie_zzz has quit IRC[21:18:46] *** Watermelon2 has quit IRC[21:19:41] <Madsy> Yeah.. where is feelgod these days?[21:19:47] *** groton_ has joined ##OpenGL[21:21:43] *** Xmas| has quit IRC[21:25:35] *** LordMetroid has joined ##OpenGL[21:26:27] *** Ademan_ has quit IRC[21:29:00] *** korff has joined ##OpenGL[21:29:18] *** Ademan_ has joined ##OpenGL[21:30:25] *** juanmabc has joined ##opengl[21:33:34] *** mariazinha has quit IRC[21:36:59] *** Suprano has quit IRC[21:43:59] *** Chaku has joined ##opengl[21:47:46] *** speedy1 has joined ##OpenGL[21:48:39] *** dolphin has quit IRC[21:49:25] <tmccrary> He's here[21:55:01] *** groton_ has quit IRC[21:56:14] <magnet_> I'm getting some strange trouble. I wrote some small openGL code, it run fine on my main computer, but on another one I get only 4 fps .I tried running other openGL application ( like warsow ) on that computer, it works very fine. the code I wrote just put 2 quads with textures.does someone got any idea on what's going on ?[21:56:41] <tmccrary> What OS?[21:56:48] <magnet_> linux 2.6 .[21:57:19] <tmccrary> glxinfo -v | grep version[21:57:23] <tmccrary> run that and tell me what it says[21:57:45] <tmccrary> also: glxinfo -v | grep OpenGL[21:58:14] <magnet_> magnet@painkiller ~ $ glxinfo -v | grep version[21:58:14] <magnet_> server glx version string: 1.2[21:58:14] <magnet_> client glx version string: 1.4[21:58:14] <magnet_> GLX version: 1.2[21:58:14] <magnet_> OpenGL version string: 1.3 Mesa 7.0.2[21:58:44] <tmccrary> You're running software[21:58:47] <tmccrary> Its using the CPU[21:58:53] <magnet_> magnet@painkiller ~ $ glxinfo -v | grep OpenGL[21:58:54] <magnet_> OpenGL vendor string: Tungsten Graphics, Inc[21:58:54] <magnet_> OpenGL renderer string: Mesa DRI Intel(R) 945GM 20061017 x86/MMX/SSE2[21:58:54] <magnet_> OpenGL version string: 1.3 Mesa 7.0.2[21:59:11] *** Lemml has quit IRC[21:59:11] *** bbeausej has quit IRC[21:59:11] *** scy has quit IRC[21:59:12] *** Scutter has quit IRC[21:59:15] *** LiraNuna has quit IRC[21:59:15] *** taortan has quit IRC[21:59:28] <magnet_> tmccrary: if running in software , shouldn't it tell 'Indirect Rendering' ?[21:59:36] <magnet_> also why would warsow run fine ?[21:59:39] *** replor has quit IRC[21:59:51] *** Lemml has joined ##OpenGL[21:59:51] *** bbeausej has joined ##OpenGL[21:59:51] *** scy has joined ##OpenGL[21:59:51] *** Scutter has joined ##OpenGL[21:59:52] *** LiraNuna has joined ##OpenGL[21:59:52] *** taortan has joined ##OpenGL[21:59:53] <tmccrary> I've had it say exactly what yours says and not be accelerated[22:00:25] <magnet_> oh.[22:01:11] <magnet_> umm.[22:01:47] *** DR0ID_ has quit IRC[22:02:52] *** Suprano has joined ##OpenGL[22:02:54] <magnet_> tmccrary: you also have a intel card ?[22:05:28] <tmccrary> yep, my tablet has one[22:06:30] *** vibe- has quit IRC[22:06:37] *** Walt_ has joined ##opengl[22:06:56] *** Walt has quit IRC[22:07:30] <magnet_> what did you do to fix that openGL problem ?[22:18:58] <garou> Okaaay, now I have a complicated muddle of C and Scheme that draws a triangle on the screen each frame. Wow...[22:19:37] *** magnet__ has joined ##OpenGL[22:19:46] <garou> But at least I start to see an engine emerge. Now I've got to learn a bit about optimization and efficient coding with OpenGL. Where can I read about that?[22:19:58] <garou> Madsy: Would that be a good FAQ topic?[22:20:32] <Madsy> I don't really know. Perhaps.[22:20:34] <tmccrary> 1) Use native data formats where possible.[22:20:54] <tmccrary> 2) Keep api calls to an absolute minimum, i.e. batch EVERYTHING[22:20:59] <tmccrary> 3) Don't make your batches too big either[22:21:11] <Madsy> But what's "efficient" depends on a lot of factors. There is definitive answer.[22:21:21] <Madsy> is no*[22:21:36] <Madsy> tmccrary notes are good guidelines though[22:21:40] <speedy1> check gamedev.net opengl FAQ and opengl.org FAQ[22:21:42] *** Walt_ is now known as Walt[22:21:49] <garou> Thanks.[22:22:47] <Madsy> Avoid using stride. Use 16-bit indices and full batches. Use glDrawRangeElements over other ways of drawing.[22:23:20] <Madsy> Binding textures and shaders takes time. Bind as rarely as possible.[22:23:34] <speedy1> madsy: strides except if you use interleaved arrays[22:24:16] <Madsy> speedy1: Sure, that may be faster under certain circumstances. Hence my point above. There is no absolute answer.[22:24:38] <DMINATOR> the most important thing is to benchmark all the time and see what actually works for your program or doesn't[22:24:51] <Madsy> Having several textures on a big one is called atlasing. It's usually better to have a bigger texture coordinate array than several binds.[22:25:18] <Madsy> DMINATOR: Too bad there isn't a "free" alternative for us Linux and Windows users.[22:25:37] *** s1d has quit IRC[22:25:58] <DMINATOR> alternative of what ?[22:26:03] <speedy1> madsy: also, atlasing - wonder how that fares with streaming in assets[22:26:04] <Madsy> The Gremedy Debugger isn't too expensive, but it's still a lot for someone who doesn't have OpenGL as a hobby.[22:26:20] <Madsy> The Mac coders allready have a free OpenGL debugger on their system.[22:26:38] <DMINATOR> OS timer is everything that is needed i think[22:26:43] *** TheLorax has quit IRC[22:27:00] <Madsy> DMINATOR: The fps is a pretty crude thing to measure.[22:27:01] <tmccrary> What api call was the fastest regarding writing pixels to a texture?[22:27:14] <DMINATOR> but its actually what matters :)[22:27:17] <tmccrary> I am going to be writing an animation texture system soon, so I'm going to have to find that out[22:27:29] <DMINATOR> because this is what you are optimising for[22:27:35] <speedy1> tmc: you should look into PBOs[22:27:42] *** rnx has quit IRC[22:27:45] <Madsy> DMINATOR: It matters in the end, but it doesn't necessarily tell you what's *wrong* or where the bottleneck is.[22:28:01] <tmccrary> I'm thinking about going with a "double buffered" system, where one texture is being used to render, while the other is updated in the background[22:28:09] <DMINATOR> no it doesn't but if it works well enough then why bother[22:28:25] <Madsy> That's the problem. It isn't enough.[22:28:39] <Madsy> You can't compare fps measuring with a real debugger.[22:29:25] <DMINATOR> debugger goal is to find errors optimising goal is to make program work faster. They have different purposes[22:29:36] <tmccrary> ![22:29:39] <DMINATOR> so thats my point.[22:29:51] <tmccrary> I'm gonna go with Madsy here[22:29:55] *** kaotrix has quit IRC[22:30:01] <tmccrary> The goal of a debugger is to make your program run better[22:30:03] <Madsy> DMINATOR: Now you are talking crap out of your arse.[22:30:10] <DMINATOR> really ?[22:30:14] <tmccrary> or should I say, to help YOU make your program run better[22:30:30] <tmccrary> "better" meaning, more reliable, faster, etc[22:30:30] <DMINATOR> what crap did i say ?[22:31:30] <Madsy> It's too pedantic. Whatever the tools are called, the existing ones give you information about the OpenGL state.[22:31:37] <Madsy> http://www.gremedy.com/[22:31:51] <Madsy> It does exactly what a debugger AND profiler does.[22:32:24] <DMINATOR> i know about that[22:32:25] <Madsy> You can halt the OpenGL command processing, change state, and continue.[22:32:35] <Madsy> You can fetch the shader strings in applications.[22:32:50] <Madsy> You can measure the number of calls, and how long they use to execute.[22:33:00] <Madsy> You can measure whether you are GPU or CPU bound[22:33:40] *** rsp has joined ##opengl[22:34:01] <DMINATOR> so whats your point ?[22:34:10] * rsp is god[22:34:13] <rsp> That's the point[22:34:16] <DMINATOR> :)[22:34:21] <rsp> ;)[22:34:31] <tmccrary> wow, 2450 a year, no thanks[22:34:32] * DMINATOR hails to the king baby![22:34:42] * garou bows down to rsp[22:35:13] * DMINATOR calls glFlush() on rsp toilet[22:35:39] *** magnet_ has quit IRC[22:36:29] *** rnx has joined ##opengl[22:37:05] <rsp> DMINATOR: lol[22:37:24] <DMINATOR> :)[22:38:06] *** karabash has quit IRC[22:45:47] *** ramkumar has joined ##OpenGL[22:46:12] *** Eltran has joined ##OpenGL[22:46:23] *** DMINATOR has quit IRC[22:46:26] <Eltran> hey, is there a gui that i can integrate into quake 3 ?[22:46:33] *** ramkumar has left ##OpenGL[22:46:46] <rsp> yeah[22:46:46] <Eltran> I have a quake 3 engine with sdl inside[22:55:50] *** LiQuiDninja has joined ##OpenGL[23:01:35] *** Suprano has quit IRC[23:02:13] *** Suprano has joined ##OpenGL[23:24:27] *** korff has quit IRC[23:36:41] *** thesquib has joined ##OpenGL[23:43:46] *** magnet__ has quit IRC[23:48:47] <Madsy> http://www.mechcore.net/phpBB2/viewtopic.php?p=2[23:48:54] <Madsy> Improvements and suggestions are welcome[23:50:42] *** joakim_ has joined ##OpenGL[23:54:55] <garou> Can I store arrays of vertices for later use too so that I don't have to draw them via API each frame but instead maybe set another projection matrix and then just reference the array to be drawn?[23:57:45] <tmccrary> garou: VBO[23:58:12] <NeoThermic> Madsy: needs an entry at the top suggesting that people learn 3D math ;)[23:59:22] <Madsy> NeoThermic: That's implicit in the forum rules.