| --- Log opened Sun Jun 17 00:00:55 2012 |
| 00:01 | < celticminstrel> | Is Mix_Init() required, or only for if you want support for MP3 or OGG or whatever? |
| 00:04 | | You're now known as TheWatcher[t-2] |
| 00:07 | | You're now known as TheWatcher[zZzZ] |
| 00:54 | < gnolam> | And now, Linus Torvalds giving Nvidia the finger: https://www.youtube.com/watch?v=MShbP3OpASA#t=49m45s |
| 01:55 | < Tarinaky> | And now, a man with a recorder up his brother's nose. |
| 01:58 | < Tarinaky> | http://www.youtube.com/watch?v=AYLcZznNdvw |
| 02:29 | < celticminstrel> | I didn't call Mix_Init() and everything worked fine, so I'm assuming I'm right that it's optional. |
| 03:14 | <&Derakon> | CM: is this SDL? |
| 03:14 | <&Derakon> | You only have to initialize SDL_Mixer if you want to use it, yeah. |
| 03:15 | < celticminstrel> | Well, I am using SDL_Mixer, though. |
| 03:15 | < celticminstrel> | I'm only playing WAV files. |
| 03:18 | | Attilla [Obsolete@Nightstar-245c4d9c.as43234.net] has quit [Ping timeout: 121 seconds] |
| 03:44 | < celticminstrel> | I wish Xcode could recognize the "file too small for architecture" error as a sign that it needs to rebuild that file... |
| 03:46 | < celticminstrel> | How do I get git to add a directory but not its contents? |
| 03:46 | <@rms> | You can't |
| 03:46 | <@rms> | git gives an infinite amount of non-shits about directories. |
| 03:47 | <@rms> | It tracks files instead. |
| 03:47 | < celticminstrel> | I thought that might be the case... |
| 03:47 | | Kindamoody[zZz] is now known as Kindamoody |
| 03:49 | < celticminstrel> | Ah well. I can deal with it. |
| 03:50 | <@rms> | Use hooks! |
| 03:50 | <@rms> | (don't) |
| 03:51 | < celticminstrel> | XD |
| 03:54 | | Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has quit [[NS] Quit: beroot] |
| 04:04 | | Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has joined #code |
| 04:04 | | mode/#code [+o Alek] by ChanServ |
| 04:10 | | Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds] |
| 04:11 | <@ToxicFrog> | celticminstrel: the convention for adding empty directories if for some reason you really need them is to put an empty .gitignore file in them and then check that in |
| 04:11 | <@ToxicFrog> | (or a non-empty one, if, say, the build system requires that directory to exist to hold build output that you want to ignore) |
| 04:15 | < celticminstrel> | Eh, it's not that important at this point. |
| 04:15 | | Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 04:15 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 05:33 | < celticminstrel> | Yay tie(). |
| 05:33 | <~Vornicus> | what's that do? |
| 05:34 | < celticminstrel> | Basically like list() in PHP. |
| 05:34 | < celticminstrel> | For tuple unpacking. |
| 05:34 | < celticminstrel> | So, "tie(a,b) = some_tuple;". |
| 05:34 | < celticminstrel> | Or pair. |
| 05:36 | | iospace is now known as iospacingout |
| 06:09 | | You're now known as TheWatcher |
| 06:28 | | Vash [Vash@Nightstar-e8057de2.wlfrct.sbcglobal.net] has quit [[NS] Quit: I lovecraft Vorn!] |
| 06:51 | | Derakon is now known as Derakon[AFK] |
| 07:47 | | Derakon[AFK] [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds] |
| 07:49 | | Derakon[AFK] [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 07:57 | | celticminstrel [celticminst@Nightstar-5d22ab1d.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 08:06 | | Kindamoody is now known as Kindamoody|afk |
| 08:47 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Connection closed] |
| 08:48 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 08:48 | | mode/#code [+o himi] by ChanServ |
| 08:49 | | Kindamoody|afk is now known as Kindamoody |
| 09:45 | | You're now known as TheWatcher[afk] |
| 09:48 | | Thalass|sleeping is now known as Thalass |
| 10:17 | | Kindamoody is now known as Kindamoody|afk |
| 10:38 | | Thalass is now known as Thalass|DINNAR |
| 11:21 | | Attilla [Obsolete@Nightstar-245c4d9c.as43234.net] has joined #code |
| 11:46 | | Thalass|DINNAR is now known as Thalass |
| 12:03 | | Kindamoody|afk is now known as Kindamoody |
| 13:01 | | Kindamoody is now known as Kindamoody|out |
| 14:02 | | Kindamoody|out is now known as Kindamoody |
| 14:12 | | celticminstrel [celticminst@Nightstar-5d22ab1d.cable.rogers.com] has joined #code |
| 14:23 | | Vash [Vash@Nightstar-e8057de2.wlfrct.sbcglobal.net] has joined #code |
| 14:23 | | mode/#code [+o Vash] by ChanServ |
| 14:48 | | Thalass is now known as Thalass|montypython |
| 15:24 | | iospacingout is now known as iospace |
| 15:26 | | celmin [celticminst@Nightstar-5d22ab1d.cable.rogers.com] has joined #code |
| 15:28 | | celticminstrel [celticminst@Nightstar-5d22ab1d.cable.rogers.com] has quit [Ping timeout: 121 seconds] |
| 15:28 | | celmin is now known as celticminstrel |
| 15:37 | | Kindamoody is now known as Kindamoody|out |
| 15:38 | | Rhamphoryncus [rhamph@Nightstar-5697f7e2.abhsia.telus.net] has quit [Operation timed out] |
| 15:42 | | Rhamphoryncus [rhamph@Nightstar-5697f7e2.abhsia.telus.net] has joined #code |
| 16:38 | | Derakon[AFK] is now known as Derakon |
| 16:38 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 17:11 | | Thalass|montypython [thalass@Nightstar-4db696da.bigpond.net.au] has quit [[NS] Quit: Leaving] |
| 17:38 | | NoahEnderOfAnts [nbarr@Nightstar-a092c26c.pools.spcsdns.net] has quit [Ping timeout: 121 seconds] |
| 17:44 | | Noah [nbarr@Nightstar-a092c26c.pools.spcsdns.net] has joined #code |
| 18:08 | | Vash [Vash@Nightstar-e8057de2.wlfrct.sbcglobal.net] has quit [[NS] Quit: I lovecraft Vorn!] |
| 18:27 | | Rhamphoryncus [rhamph@Nightstar-5697f7e2.abhsia.telus.net] has quit [Client exited] |
| 18:33 | | cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 18:47 | | rms is now known as Vasi |
| 18:48 | | Derakon is now known as Derakon[AFK] |
| 18:49 | | Kindamoody|out is now known as Kindamoody |
| 18:56 | | You're now known as TheWatcher |
| 19:01 | | Kindamoody is now known as Kindamoody[zZz] |
| 19:46 | | Vasi is now known as rms |
| 19:57 | < celticminstrel> | Why does it take so long to update the screen... |
| 20:00 | <@rms> | Are you drawing a pixel at a time? |
| 20:00 | < celticminstrel> | No? |
| 20:00 | < celticminstrel> | I'm drawing in 32x32 chunks. |
| 20:02 | < celticminstrel> | Anyway, the time is in SDL_Flip(), not any of the blitting calls. |
| 20:05 | < celticminstrel> | (Rendering text was taking awhile too, but it's not hard to reduce that time since I know it doesn't change much.) |
| 20:05 | < celticminstrel> | s/much/often/ |
| 20:05 | <@rms> | Draw to a surface in memory then blit it to the screen. |
| 20:06 | < celticminstrel> | What, triple buffering? :P |
| 20:06 | <@rms> | SDL? |
| 20:06 | < celticminstrel> | I thought that was what double buffering did. And yes, SDL. |
| 20:06 | <@rms> | If so I can't recall what'd cause slow draws. |
| 20:07 | < celticminstrel> | It's not really slow. It's just slow enough that it takes longer than the period between "animation frames". |
| 20:08 | < celticminstrel> | Up to about 80 ticks according to SDL_GetTicks(), and that's including the blitting. |
| 20:09 | < celticminstrel> | Would trying not to redraw the whole screen help? Maybe I need to do something to only SDL_UpdateRect with the areas that have actually changed? |
| 20:10 | <@rms> | That might work |
| 20:10 | < celticminstrel> | Which one? Or both? |
| 20:11 | | Derakon[AFK] is now known as Derakon |
| 20:11 | <@rms> | Both |
| 20:11 | < celticminstrel> | Ugh. Okay. Hm. |
| 20:13 | <@rms> | It's called dirty rectangle drawing |
| 20:15 | < celticminstrel> | It means I need to figure out a way to record what has changed. |
| 20:16 | | Noah [nbarr@Nightstar-a092c26c.pools.spcsdns.net] has quit [Ping timeout: 121 seconds] |
| 20:20 | < celticminstrel> | And, potentially, a way to see if the thing that needs to be drawn is different from what's already there. |
| 20:24 | < celticminstrel> | Whee. "SDL_UpdateRects(G->screen, dirty.size(), dirty.data());" |
| 20:47 | < celticminstrel> | Hm. It doesn't seem to have helped much at all. If it even helped at all. |
| 20:47 | <@rms> | :/ |
| 20:48 | < celticminstrel> | It looks like it does slightly reduce update time on average, but not enough. :/ |
| 20:48 | <&Derakon> | What are you actually drawing? |
| 20:48 | < celticminstrel> | 32x32 tiles. |
| 20:49 | <&Derakon> | Each is an individual SDL_Surface? |
| 20:49 | <&Derakon> | And how many are there? |
| 20:49 | < celticminstrel> | 450 of them. They're all drawn from the same SDL_Surface at different locations. |
| 20:49 | < celticminstrel> | By 450 I mean there's 450 onscreen. |
| 20:49 | <&Derakon> | Yeah. |
| 20:49 | < celticminstrel> | (Some come from a second surface.) |
| 20:49 | <&Derakon> | That's a lot for SDL, sadly. |
| 20:50 | <&Derakon> | I know for Fusillade, my game which used SDL rendering, I couldn't have more than maybe 500 bullets onscreen at a time. |
| 20:50 | < celticminstrel> | Oh right. |
| 20:50 | <&Derakon> | Probably less; it's been a few years since I worked on that. |
| 20:50 | < celticminstrel> | I'm actually drawing more than 450 since there can be multiple on a space. |
| 20:50 | <&Derakon> | You'll be able to have a lot more if you use OpenGL rendering instead. |
| 20:50 | < celticminstrel> | Hm. |
| 20:50 | < celticminstrel> | Oh? |
| 20:50 | <&Derakon> | Yeah. |
| 20:50 | <&Derakon> | It's a bit of a pain to set up though. |
| 20:50 | < celticminstrel> | Would I be able to do that without changing anything else? |
| 20:50 | <&Derakon> | I recommend downloading Jetblade's source code if you want to see how it works. |
| 20:51 | <&Derakon> | Depends on how well you separated the rendering code out. :) |
| 20:51 | < celticminstrel> | ie would the changes be confined to just a few places. |
| 20:51 | <&Derakon> | http://code.google.com/p/jetblade/ |
| 20:51 | < celticminstrel> | The rendering code for tiles is all in main.cpp; other stuff is in another file. |
| 20:51 | <&Derakon> | Your program initialization is different, you have to convert all of your loaded SDL_Surfaces into OpenGL textures, and you need to change your "draw a Surface of these dimensions at this location" code. |
| 20:52 | <&Derakon> | Since it'll instead be "bind this texture and draw it here." |
| 20:52 | < celticminstrel> | The last would be one function, I think. |
| 20:52 | <&Derakon> | (You can also chop up the texture and display portions of it, like you're doing with your Surface) |
| 20:52 | < celticminstrel> | Converting is probably also one function since I have a surface() function to wrap an SDL_Surface in a shared_ptr. |
| 20:52 | <&Derakon> | Ah, you're using C++, right. |
| 20:53 | < celticminstrel> | I shall look into this, at least. |
| 20:53 | < celticminstrel> | Yes. |
| 20:53 | <&Derakon> | Well, Jetblade will probably still serve as a guide of sorts, but the functions will of course be different in how they're invoked and so on. |
| 20:53 | < celticminstrel> | So when I get an SDL_Surface from TTF_RenderText, I don't have to worry about freeing it. |
| 20:54 | <&Derakon> | ...making a roguelike? |
| 20:57 | < celticminstrel> | Not quite. |
| 20:57 | | Vash [Vash@Nightstar-a60eef95.ct.comcast.net] has joined #code |
| 20:57 | | mode/#code [+o Vash] by ChanServ |
| 20:57 | | Vash is now known as VV |
| 21:25 | < celticminstrel> | Blah, this feels like too much work... OpenGL is horrible. |
| 21:29 | < celticminstrel> | Hm. If I do use OpenGL textures, does that mean I can free the surface containing the tilesheet once it's bound as a texture? |
| 21:32 | < gnolam> | Huh |
| 21:36 | < celticminstrel> | Oh hey, there exists something called SFML. |
| 21:36 | < celticminstrel> | Probably wouldn't help though... |
| 21:43 | < gnolam> | celticminstrel: if you've created a texture, you can destroy the SDL surface, yes. |
| 22:01 | < celticminstrel> | Do textures have to be explicitly freed? |
| 22:03 | < gnolam> | Yes. |
| 22:03 | < gnolam> | glDeleteTextures() |
| 22:04 | < celticminstrel> | Oh, all at once. |
| 22:05 | < gnolam> | If you want to. |
| 22:06 | < gnolam> | glDeleteTextures(GLsizei n, const GLuint *textures); |
| 22:06 | < gnolam> | Is the actual prototype. |
| 22:06 | < celticminstrel> | ...hm, if I have "int a, b, c, d" that's not equivalent to "int a[4]" is it... |
| 22:06 | < gnolam> | Nope |
| 22:09 | < celticminstrel> | Oh come on. C++ allows "int x = 0" inside a class now, and "static const int x = 0"; why can't it allow "static int x = 0"? |
| 22:09 | < gnolam> | I use a resource manager class to handle loading/creation/deletion of textures. |
| 22:09 | < celticminstrel> | I'm trying to figure out how to do this at the moment. |
| 22:09 | < celticminstrel> | Creating a texture class. |
| 22:10 | < celticminstrel> | Is -1 an invalid texture ID? |
| 22:13 | < gnolam> | Texture ids are uints, so yes. |
| 22:13 | < celticminstrel> | Should I assume they're assigned consecutively or randomly? |
| 22:14 | <@TheWatcher> | Randomly |
| 22:14 | < celticminstrel> | Oaky. |
| 22:14 | < celticminstrel> | ^Okay |
| 22:17 | < celticminstrel> | So, next power of two would be something like log(n) + 1...? |
| 22:18 | < celticminstrel> | log2 that is |
| 22:25 | <@VV> | well if you want 4 to give 4, you'll want 2**ceil(log2(n)). if you want 4 to give 8, you'll want 2**floor(log2(n)+1) |
| 22:26 | < celticminstrel> | Oh yeah, ceil. Why do I always forget you exist. |
| 22:31 | < celticminstrel> | Thanks Vash. |
| 22:31 | <@TheWatcher> | Because when programming, you think the sky's the limit, so you have no ceiling?~ |
| 22:31 | < celticminstrel> | XD |
| 22:32 | < celticminstrel> | Alright, I have texture loading code, now to use the texture in the blit() function. |
| 22:34 | < celticminstrel> | Query: SDL_CreateRGBSurface is being passed FF, FF00, FF0000, FF000000, while glTexImage2D is being passed GL_RGBA when creating a texture from that surface. Am I right in suspecting that this is not quite right? |
| 22:37 | | * celticminstrel looks at a tutorial... I'm guessing gluBuild2DMipmaps is a wrapper around glTexImage2D? |
| 22:39 | < celticminstrel> | Right, need to convert my texture coordinates to the required floating-point format... seems kinda silly, but whatever. |
| 22:45 | < gnolam> | IIRC, gluBuild2DMipmaps was created before GL_GENERATE_MIPMAP became part of the core spec. |
| 22:46 | | Noah [nbarr@Nightstar-fc862a6b.pools.spcsdns.net] has joined #code |
| 22:47 | < celticminstrel> | So, texture coordinates would be x/w and y/h? |
| 22:48 | < celticminstrel> | Hm, texture coordinates can also be specified as integers, but would that handle the width/height stuff or would it use the full integer range? |
| 22:50 | <&Derakon> | Texture coordinates are generally given as u/v, to avoid confusion with XYZ. But u is x and v is y, basically. |
| 22:50 | | You're now known as TheWatcher[T-2] |
| 22:50 | < celticminstrel> | By w and h I meant width and height of the texture in pixels. |
| 22:50 | < gnolam> | Correct. |
| 22:50 | <&Derakon> | Yeah. |
| 22:51 | < gnolam> | But do remember to cast to float. :) |
| 22:51 | < celticminstrel> | I'm using double, but yes, of course. |
| 22:51 | < celticminstrel> | double/int yields double? |
| 22:52 | <&Derakon> | Yes. |
| 22:52 | <&Derakon> | The int is implicitly cast to a double. |
| 22:53 | < celticminstrel> | I like how I make this look like a block statement: "opengl(GL_QUADS) { /* ... vertices and stuff ... */ }" |
| 22:53 | <&Derakon> | Got something against glBegin/glEnd? |
| 22:53 | < celticminstrel> | Yes. :P |
| 22:54 | <@VV> | WHY immediate mode |
| 22:55 | | You're now known as TheWatcher[zZzZ] |
| 22:55 | < celticminstrel> | Because it's what I know? >_> |
| 22:56 | <@TheWatcher[zZzZ]> | Hey, it works, and if it's enough for what you want, fine |
| 22:57 | < celticminstrel> | I'm just doing 2D stuff here. |
| 22:57 | < gnolam> | Immediate mode /is/ good for testing and getting a feel for how OpenGL/3d programming works. |
| 22:57 | < gnolam> | That it's been deprecated since, like, forever and has the performance of WHY GOD WHY is another matter. |
| 22:58 | <&Derakon> | It'll still have way better performance than SDL. |
| 22:59 | <&McMartin> | On modern hardware, anyway. |
| 22:59 | <&McMartin> | On an old card with a shitty fill rate - or on a system that's doing OpenGL in software - SDL's direct framebuffer will beat it. |
| 23:00 | < celticminstrel> | I don't think mine is quite that old... it's MacPro1,1 with Nvidia GeForce 7300 GT. |
| 23:00 | <&McMartin> | That'll be fine. |
| 23:01 | < celticminstrel> | It's at least six years old, if I recall correctly. |
| 23:01 | < celticminstrel> | Okay. :) |
| 23:01 | <&McMartin> | Especially if it's nVidia - nVidia was the voice in the wilderness on this right up to the point where they suddenly crushed everyone but ATI by being right. |
| 23:01 | < celticminstrel> | Heh. Okay. |
| 23:01 | <&McMartin> | Voodoo cards were not great at this, and Matrox were a near-total loss, IIRC. |
| 23:01 | <&McMartin> | Nvidia you can go back to like the Riva TNT 128 and you're basically fine for OpenGL 1.2 =P |
| 23:02 | < celticminstrel> | I probably don't need anything later than 1.2 for simple 2D graphics. |
| 23:02 | < celticminstrel> | I suppose one advantage of switching to OpenGL is that the scaling down the level for the editor will be a lot easier. |
| 23:03 | < celticminstrel> | Would it be okay for the textures to be deleted after SDL_Quit()? |
| 23:04 | <&Derakon> | Uh. |
| 23:04 | <&Derakon> | I'd delete them beforehand. |
| 23:04 | < celticminstrel> | 'kay |
| 23:06 | < celticminstrel> | vector::data() is useful for this! :D |
| 23:09 | <&Derakon> | Intelligent containers are always handy. :) |
| 23:09 | < celticminstrel> | Oddly, before today I don't think I'd ever used data(). |
| 23:12 | < celticminstrel> | Okay... need to figure out the scaling thing next. |
| 23:14 | < celticminstrel> | First, glTranslate et al are "push" functions, right? I need a "pop" function... |
| 23:16 | | gnolam is now known as The_SI_Warrior |
| 23:16 | | The_SI_Warrior is now known as slaps |
| 23:16 | | slaps is now known as gnolam |
| 23:16 | | gnolam is now known as The_SI_Warrior |
| 23:17 | | The_SI_Warrior is now known as gnolam |
| 23:18 | < celticminstrel> | glPopMatrix I guess. |
| 23:24 | < celticminstrel> | Of course it helps if I tell Xcode to link with the OpenGL framework. <_< |
| 23:27 | < celticminstrel> | If I'm using OpenGL, do I care about the SDL_Surface* returned by SDL_SetVideoMode? |
| 23:28 | < celticminstrel> | Apart from verifying it's not null. |
| 23:28 | <&Derakon> | glTranslate et all do not push. |
| 23:28 | <&Derakon> | They modify the array on the top of the stack. |
| 23:28 | < celticminstrel> | Oh. |
| 23:28 | < celticminstrel> | So how would I reverse them? Just counter them? |
| 23:29 | < celticminstrel> | Like, glTranslate(-5,-5,-5) to reverse glTranslate(5,5,5). |
| 23:29 | <&Derakon> | glLoadIdentity sets the matrix on the top of the stack to be the identity. |
| 23:29 | < celticminstrel> | I'm aware of that. |
| 23:29 | <&Derakon> | You can do glPush to make a new matrix that is a copy of the current matrix. |
| 23:29 | <&Derakon> | Then you modify that matrix with glTranslate et al. |
| 23:29 | <&Derakon> | Then when you're done and want to undo, you do glPop. |
| 23:29 | < celticminstrel> | Oh. Got it. |
| 23:29 | < gnolam> | s/modify the array on the top of the stack/multiply with the current matrix |
| 23:29 | <&Derakon> | Trying to manually undo stuff will nail you with rounding errors eventually. |
| 23:30 | < gnolam> | Surprisingly quickly, actually. |
| 23:30 | <&Derakon> | Well, at 60FPS and with a few hundred such operations per frame, it does add up. :) |
| 23:31 | < celticminstrel> | (The point was that I want to undo the translate for an individual texture without undoing any active scale setting.) |
| 23:38 | < celticminstrel> | Next step is fill rect. |
| 23:38 | < celticminstrel> | It's easy when it's the whole screen (glClearColor + glClear), but when it's a specified rect... |
| 23:40 | < celticminstrel> | alpha is opaque at 0.0, not 1.0? |
| 23:40 | < celticminstrel> | Oh wait. |
| 23:40 | < celticminstrel> | Must be, because my initial clear colour was all zeros. |
| 23:41 | < celticminstrel> | Agh, glClear takes flags. |
| 23:42 | < celticminstrel> | Any reason not to just use all of them? |
| 23:42 | <&Derakon> | I've always cleared the color and depth buffer bits. |
| 23:43 | < celticminstrel> | There's a texture bit. Should that be left alone? |
| 23:45 | < gnolam> | <celticminstrel> Any reason not to just use all of them? |
| 23:45 | < gnolam> | Performance. |
| 23:45 | < celticminstrel> | Heh. |
| 23:46 | | cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has joined #code |
| 23:46 | < celticminstrel> | So, should I clear the texture bit or not? |
| 23:47 | < gnolam> | Clear GL_COLOR_BUFFER_BIT and GL_DEPTH_BUFFER_BIT iff you use the depth buffer. |
| 23:47 | < gnolam> | ... what texture bit? |
| 23:47 | < celticminstrel> | I dunno. I looked in the header and it was there. |
| 23:47 | < celticminstrel> | GL_TEXTURE_BIT |
| 23:47 | < celticminstrel> | glColor3s is perfect for use with an SDL_Color. <_< |
| 23:48 | < celticminstrel> | Wait SDL_Color is 8-bit. Bah. |
| 23:48 | < celticminstrel> | ^, |
| 23:48 | < gnolam> | GL_TEXTURE_BIT is not for glClear(). |
| 23:49 | < celticminstrel> | ...see, that's one of the reasons why OpenGL is horrible. There's no indication of what constants are for which functions. |
| 23:49 | < celticminstrel> | glColor3b, then. <_< |
| 23:49 | < gnolam> | >_< |
| 23:49 | < celticminstrel> | Okay, it builds. Maybe it'll even work. |
| 23:49 | < gnolam> | Read the actual docs and you'll see what constants are for which functions. |
| 23:50 | < celticminstrel> | Yay, segfault, |
| 23:50 | <&Derakon> | Yeah, the OpenGL docs are kinda vital. |
| 23:50 | < celticminstrel> | But I like to rely on auto-complete! :( |
| 23:51 | <&Derakon> | Auto-complete is no substitute for having a clue what you're doing. |
| 23:53 | < celticminstrel> | Why can't Xcode set a breakpoint where I want it instead of in other random locations. |
| 23:56 | < celticminstrel> | Or maybe it's GDB. |
| 23:56 | | * celticminstrel switches to LLDB and magic happens. |
| 23:57 | < celticminstrel> | And why can't I print the value of this variable? |
| --- Log closed Mon Jun 18 00:00:10 2012 |