#low@irc.freenode.net logs for 31 Aug 2005 (GMT)

Archive Today Yesterday Tomorrow
LoW homepage


[00:36:51] --> Coren_ has joined #low
[00:36:51] --- ChanServ gives channel operator status to Coren_
[01:37:24] --- smatthews_ is now known as servus
[01:38:23] <Coren_> That and glProgramEnvParameter4fvARB seems to only take effect when I rebind the program.
[01:38:51] <Coren_> ... which doesn't jive with my understanding of the spec.
[01:39:35] <servus> It does not require a rebind.
[01:39:47] <servus> Oh, well maybe it does. I use ProgramLocal, which does not require a rebind.
[01:39:50] <servus> Use local :)
[01:40:11] <Coren_> Hm.
[01:40:13] * Coren_ tries
[01:41:53] <Coren_> Same difference. Only has effect if I rebind. Oddness. Maybe it has something to do with the fact that the only rendering I do is through glDrawElements (and thus no explicit glBegin())
[01:42:43] * Coren_ pores over the spec.
[01:43:29] <Coren_> It's all the more odd because vertex programs don't seem to be behaving that way.
[01:48:54] <servus> I don't use any glBegins
[01:49:12] <servus> And I only rebind my vertex program twice per rendering cycle... Once for lights, once for water.
[01:49:21] <servus> Same with fragment programs. Once per lights, once per water.
[01:50:10] * Coren_ boggles.
[01:50:25] <Coren_> There must be something subtly wrong that I'm doing.
[01:50:53] <servus> Yeah :)
[01:51:05] <servus> Sure you are setting before you draw?
[01:52:19] <Coren_> Yes, because I see the effect properly. Basically, I'm setting ambient color before I draw a tile; then draw the tile. But right now, every tile keeps the ambient color of the first tile drawn.
[01:52:47] <Coren_> If I insert a rebind, everything works as it should.
[01:53:27] <Coren_> If I don't rebind, the parameter will keep its first value all the way through.
[01:53:52] <Coren_> Vertex parameters, however, which are set at exactly the same point in the code, are correcly changed.
[01:56:02] <servus> Are you sure you're not binding over the fragment parameters, later on?
[01:57:13] <servus> Here's what I like to do: MOV result.color, program.env[1]; # et cetera
[01:57:43] <servus> Put that at your program's end, and do some glProgramEnvParameter4fARB( 1, FALSE, 1, 0, 0 ); or whatever the syntax is
[01:58:07] <Coren_> Yes. The code flow is trivial: bind_programs; while(tiles) { bind_params; draw; }.
[01:58:45] <servus> Grep for glProgram
[01:58:45] <Coren_> The vertex parameters are properly updated for every tile, the fragment parameters keep the values of the first tile.
[01:59:13] <servus> Be back in a bit
[01:59:44] <Coren_> If I do bind_programs; while(tiles) { bind_params; bind_programs_again; draw; } everything works.
[02:08:49] <servus> Try it with local?
[03:06:02] <Coren_> I did. Same result.
[03:09:54] <servus> Well then, maybe it's your drivers. The very first step of my rendering pipeline is to bind programs, and mine works fine
[03:11:23] <Coren_> I guess it could be. Although, to date, whevenever NVidia's driver disagree with what I tought they should have been doing, I've been the one that was wrong. :-)
[03:12:17] <Coren_> We both might be relying in some gap of the spec; works for you and not for me because of implementation details. I note the spec is actually quite vague about when changes to parameters are supposed to be applied.
[03:12:26] <servus> Coren_: Even I support that sort of collision detection, silly boy.
[03:12:54] <servus> Well gimme your non-working Windows binary and I'll try it :P
[03:13:01] <Coren_> You know, you're being rather offensive at times. I'm not quite certain why you feel the need for one-upmanship, but I find it rather disagreeable.
[03:13:13] <servus> Hm.
[03:13:38] <servus> I'm being jocular. If you're going to get offended by the same type of behaviour you exhibit towards me, fine.
[03:15:42] <Coren_> Sure. I'm the one who, first thing hearing I had a working fragment program, felt the need to compare number-of-ops. It appears evident you have considerably more practice at 3d engines than I do, apparently you feel the need to point this out over and over again. Shall we try our hand and embedded control or network protocols?
[03:16:01] <Coren_> s/hand and/hand at/
[03:16:21] * Coren_ shrugs.
[03:16:43] <servus> If you're going to get angry, I won't provoke you, I'll simply bid you good-day.
[03:16:49] <Coren_> I'm rather a diva myself, so I usually ignore such abrasiveness. You just have this particular skill at it.
[03:17:21] <Coren_> Laughing at me on #exult, for instance, was entirely uncalled for.
[03:18:27] <servus> "teases coren" is not what I consider offensive.
[03:18:32] * servus sighs
[03:18:38] <servus> Good-day.
[03:18:39] <-- servus has left #low (":wq")
[03:23:53] <Coren_> For the record, Servus, (In case you should decide to read the log), I've double checked and I misatributed the "laughs at" emote. My original point stands, but please accept my apologies for the specific instance.
[04:00:04] <-- Coren_ has left IRC (kornbluth.freenode.net irc.freenode.net)
[04:00:04] <-- ChanServ has left IRC (kornbluth.freenode.net irc.freenode.net)
[04:00:12] <-- exultbot has left IRC (signing off...)
[04:05:29] --> exultbot has joined #low
[04:05:29] --- Topic for #low is: Labyrinth of Worlds: Ultima Underworld II revisited (http://low.sourceforge.net)
[04:05:29] --- Topic for #low set by Coren_ at Tue Aug 16 03:03:38 2005
[05:42:12] --> Khelz has joined #low
[07:37:58] <-- Khelz has left IRC (Connection timed out)
[14:10:20] <-- Coren_ has left IRC (Read error: 110 (Connection timed out))
[16:32:40] --> Khelz has joined #low
[17:44:07] <-- Khelz has left IRC ()
[18:24:59] <-- ChanServ has left IRC (Shutting Down)
[18:26:37] --> ChanServ has joined #low
[18:51:56] --> Coren_ has joined #low
[18:51:56] --- ChanServ gives channel operator status to Coren_
[19:54:56] --> Coren__ has joined #low
[19:58:36] --> _Coren has joined #low
[20:11:57] <-- Coren_ has left IRC (Read error: 110 (Connection timed out))
[20:12:07] --- _Coren is now known as Coren_
[20:12:16] --- ChanServ gives channel operator status to Coren_
[20:14:20] <-- Coren__ has left IRC (Read error: 110 (Connection timed out))