#uwadv@irc.freenode.net logs for 24 Sep 2002 (GMT)

Archive Today Yesterday Tomorrow
Underworld Adventures homepage


[13:32:37] --> vividos has joined #uwadv
[13:32:37] --- ChanServ gives channel operator status to vividos
[14:11:16] <vividos> for the lurkers: http://www.martinmanning.com/interpreters.htm#underworldadventures
[14:28:49] <-- vividos has left IRC ("Leaving")
[15:49:27] --> wjp has joined #uwadv
[15:49:27] --- ChanServ gives channel operator status to wjp
[17:49:14] --> vividos has joined #uwadv
[17:49:14] --- ChanServ gives channel operator status to vividos
[17:49:18] <vividos> hi wjp
[17:59:42] <wjp> hi
[18:14:52] <vividos> any news? :)
[18:16:50] <wjp> guess :-)
[18:24:30] <vividos> yes?? :))
[18:25:05] <vividos> I should code a bit for uwadv
[18:27:56] <vividos> bad that no one got back to me that applied for the 3d modeler
[18:28:23] <vividos> oh and played uw2 today. movement was rather jerky, as was the collision detection (uuah)
[18:30:46] <wjp> jerky movement? hm, can't remember that
[18:30:57] <vividos> maybe the dos window slowed down things a bit
[18:31:26] <vividos> and the conversation system seems more complicated. speaker and portraits can change during conversation, just as in U7
[18:31:45] <vividos> and the "command" buttons are awful to use, IMHO
[18:32:07] <vividos> maybe it's that I got used to uw1's system
[18:34:01] <vividos> have to restart
[18:34:02] <-- vividos has left IRC ("Leaving")
[18:35:50] --> vividos has joined #uwadv
[18:35:50] --- ChanServ gives channel operator status to vividos
[18:37:30] <wjp> was uw2's interface that different from uw1's?
[18:45:23] <vividos> the command button are on the left side, at the bottom of the screen, which makes it rather annoying to change command mode
[19:00:14] <vividos> hmm, just tried Telemachos suggestion, and the number of thin lines at least reduced in the ingame screen
[19:03:30] <vividos> yay! we have a commit!
[19:03:35] <vividos> :)
[19:09:38] <wjp> whee! :-)
[19:10:27] <vividos> hope I can allocate more time for uwadv again :)
[19:11:55] <wjp> hm, lines are still there, though
[19:12:21] <wjp> re. interface: what about key shortcuts for command modes?
[19:13:19] <vividos> but not so visible. could be rounding problems
[19:13:41] <wjp> the one in the message scroll is still very visible here
[19:13:55] <vividos> there are the usual ones, f1 through f6, but using them is bit more complicated than using the mouse
[19:16:01] <wjp> hm, I can't wear items anymore
[19:16:41] <vividos> hmm, me too ...
[19:17:22] <vividos> I'll look at it later. have to go then
[19:17:30] <wjp> see you later
[19:17:37] <vividos> bye
[19:17:40] <-- vividos has left IRC ("Leaving")
[20:36:18] --> vividos has joined #uwadv
[20:36:18] --- ChanServ gives channel operator status to vividos
[20:36:19] <vividos> re
[20:37:17] <wjp> wb
[20:38:46] <vividos> any news on exult, btw? I occasionally read the channel logs, but there isn't happening much
[20:38:55] <wjp> not much, no
[20:39:04] <wjp> we're fixing some occasional bugs
[20:39:19] <wjp> forum is still moderately active, too
[20:39:21] <vividos> is fixing bugs at this stage hard?
[20:39:32] <wjp> some bugs are very hard to fix, yes
[20:40:16] <vividos> why are they hard? is the code so complex?
[20:40:58] <wjp> in some cases, yes. It doesn't help that we sometimes need to guess at the exact meaning of usecode opcodes and intrinsics
[20:41:05] <wjp> and then there's the timing issues...
[20:41:28] <vividos> there are still unknown opcodes?
[20:41:35] <wjp> nah, just details
[20:41:49] <wjp> I think the last change I made to an opcode was the loop opcode
[20:42:04] <wjp> turned out that in one location in usecode the loop array was modified in mid-loop
[20:42:19] <wjp> and our loop implementation wasn't handling that in exactly the same way as the original's
[20:42:30] <vividos> ah ok
[20:42:33] <wjp> resulting in an infinite loop :/
[20:42:37] <vividos> what about the timing?
[20:42:50] <wjp> a bug Jeff just fixed (hopefully):
[20:43:48] <wjp> there's an automated where you walk onto a teleporter. Two things need to happen there: 1) your inventory is emptied, 2) you are actually teleported
[20:44:14] <wjp> the first thing needs to be executed _before_ the actual teleport, because of the way the usecode function that handles that is written
[20:44:37] <wjp> however, the two actions are using different mechanism, which apparently had to interact differently
[20:45:20] <wjp> (one of the two was triggered by an 'egg', which is what the uw specs call a 'trap'; the other was triggered by the usecode that also executed the rest of the automated sequence, IIRC)
[20:45:56] <wjp> (s/automated/automated scene/ in the first line)
[20:46:34] <vividos> is the egg stuff mostly done on guesswork?
[20:47:21] <wjp> yeah
[20:47:46] <vividos> it seems that the u7 designers exhausted the engine quite a bit
[20:48:01] <wjp> serpent isle really did, yes
[20:48:14] <wjp> the original u7 wasn't as demanding
[20:48:25] <vividos> for uw1 most stuff is logical, apart from unknown fields in tables which we didn't yet decode
[20:49:11] <wjp> u8 is built more logical than u7 too, as far as we can tell
[20:49:43] <vividos> I saw some stuff. they seemed to connect usecode and C++ functions, right?
[20:50:04] <wjp> well, yes, but uw1 and u7 do that too
[20:50:58] <vividos> well, uw1 doesn't have such an object oriented approach. we just have C-like functions
[20:51:40] <wjp> hm, u8's usecode is OO, yes
[20:53:45] <vividos> btw, we have another commit :)
[20:54:07] <wjp> oh, wow. Two on one night? :-)
[20:54:16] <vividos> and more to come! :)
[20:54:24] <wjp> oooh, new files?
[20:54:43] <vividos> :)
[20:54:56] <wjp> load game screen?
[20:55:00] <vividos> yes
[20:55:15] <wjp> how do I access it?
[20:55:37] <vividos> I'm currently refining the underworld object a bit
[20:56:01] <wjp> hmmm, the current 'paperdoll' looks really weird
[20:56:04] <vividos> the load game screen is called when you click on "yourney onwards". that one only appears if you have savegames
[20:56:15] <vividos> hmm, weird?
[20:56:16] <wjp> all the objects seem to be placed too high
[20:56:38] <vividos> hmm, I don't see a difference
[20:56:52] <wjp> and somehow I can only get a female character
[20:57:03] <vividos> after char. creation?
[20:57:06] <wjp> inventory: illegal item list access
[20:57:41] <vividos> exception?
[20:57:54] <wjp> it just quit after that
[20:58:26] <vividos> hmm, sounds strange, but could be related to that inventory problem
[20:58:41] * wjp is going to commit something too! :-)
[20:58:50] <vividos> yay!
[20:58:56] <wjp> (*cough*getting rid of some warnings*cough*)
[20:59:13] <vividos> ah ok :)
[20:59:28] <wjp> what's that 'SDL_TABLESIZE', btw?
[21:00:27] * wjp greps through some SDL headers
[21:00:40] <vividos> it returns sizeof(table)/sizeof(table[0])
[21:00:52] <vividos> the number of table indices
[21:01:29] <wjp> I'm getting quite a lot of signed/unsigned warnings there :/
[21:01:56] <wjp> hm, I'll change some of the array indices to unsigned ints
[21:02:03] <vividos> ok
[21:02:23] * wjp re-orders some member initializers, too
[21:03:04] <wjp> ack, I didn't commit that "Requires: SDL_mixer >= 1.2.4" yet
[21:06:06] <wjp> umm... oops
[21:06:46] * wjp thinks he should keep that 'rawbits' variable unsigned
[21:07:25] <wjp> btw, did you want to use C++-style casts or C-style casts?
[21:08:33] <vividos> a good question. I usually use c++-style casts when there should be absolutely clear what should be converted in what
[21:08:44] <vividos> for static_cast<> I think we can use C-style casts, too
[21:09:25] * wjp nods; that's pretty much how I usually do casts too
[21:09:40] <vividos> there's also the ctor-style cast :)
[21:09:56] <vividos> Uin16 n = Uint16(sth)
[21:11:10] <wjp> yeah, I'm not a great fan of that :-)
[21:11:51] <vividos> calling a ctor explicitly may not be a good thing :)
[21:13:19] <wjp> now, let's see if I can reproduce that inventory bug
[21:15:09] <wjp> hm, now there's a black line under the mouse cursor?
[21:15:54] <wjp> strange thing is that the line is constant, i.e., it doesn't change when you move the mouse around
[21:16:18] <wjp> when I drag and drop some stuff the line sometimes appears below the mouse, and sometimes doesn't
[21:16:29] <wjp> when it's there it stays until the mouse cursor changes shape again, though
[21:17:12] <vividos> yes, is a problem with the wrapping, still
[21:17:27] <wjp> ok, got an exception in the inventory code again
[21:18:04] <wjp> #1 0x08051adc in ua_inventory::append_item (this=0xbffff68c, cont=65535,
[21:18:04] <wjp> item=27) at inventory.cpp:527
[21:18:04] <wjp> #2 0x080511ff in ua_inventory::drop_floating_item (this=0xbffff68c,
[21:18:04] <wjp> index=65535) at inventory.cpp:281
[21:18:04] <wjp> #3 0x0808578c in ua_ingame_orig_screen::inventory_click (this=0x859a3c8,
[21:18:05] <wjp> inv=@0xbffff68c, pressed=false, left_button=false,
[21:18:07] <wjp> area=ua_area_inv_container) at screens/ingame_orig.cpp:1224
[21:18:09] <wjp> #4 0x08085328 in ua_ingame_orig_screen::mouse_action (this=0x859a3c8,
[21:18:11] <wjp> click=true, left_button=false, pressed=false)
[21:18:13] <wjp> at screens/ingame_orig.cpp:1096
[21:18:45] <wjp> I think it happened when I tried to drop a bag on the character portrait
[21:19:28] <vividos> hmm, the code shouldn't call append_item for this type of item
[21:19:33] <vividos> (I think)
[21:20:41] <wjp> although the code seems to think I dropped it on a normal inventory slot
[21:22:16] <vividos> I think the code to determine the slot category is wrong
[21:23:21] <vividos> I'll look at it later. have to watch "harald schmidt" now :)
[21:23:33] --- vividos is now known as vividos|away
[21:25:49] <wjp> ahh.. it happens when you try to drop something on the place where open containers are displayed
[21:25:58] <wjp> (when there is no open container)
[21:29:57] <wjp> ok, fixed it
[21:44:41] <wjp> fixed dropping problem too
[21:45:12] <wjp> (the constants were named lua_inv_cat_xyz, but the function returned inv_cat_xyz. Took me a few reading passes to spot that one :-) )
[22:14:42] <wjp> ...and fixed the problem with the avatar portrait too
[22:15:15] <wjp> pl.get_attr(ua_attr_appearance)%5 + female? 5 : 0 <-- that means (pl.get_attr(ua_attr_appearance)%5 + female) ? 5 : 0
[22:15:27] * wjp added some parentheses
[22:29:27] --- vividos|away is now known as vividos
[22:29:46] <vividos> cool :)
[22:30:39] <vividos> on the expression:
[22:31:06] <vividos> it should be pl.get_attr(ua_attr_appearance)%5 + (female? 5 : 0)
[22:31:16] <wjp> yeah
[22:31:23] <vividos> when the "female" bool is set to true, 5 is added
[22:31:29] * wjp points at cvs :-)
[22:32:44] * wjp is having fun with texture coordinates, in the meantime
[22:33:02] <wjp> (just experimenting with things a bit to get a bit of a 'feeling' for this opengl stuff)
[22:33:09] <vividos> which ones?
[22:33:15] * wjp is creating all kinds of warped message scrolls :-)
[22:35:40] <vividos> hehe
[22:36:35] <wjp> hm, this got rid of the lines
[22:36:48] <wjp> but I'll have to check some docs to see if it actually fixed anything
[22:38:45] <vividos> OpenGL docs?
[22:38:55] <wjp> not sure yet :-)
[22:39:49] <vividos> you can of course ask me, too :)
[22:40:39] <wjp> what I'm basically wondering is how exactly the pixels on a texture are mapped to the (u,v) coordinates
[22:41:24] <wjp> when rendering a quad with a texture, you use (0,v), (u, v), (u, 0), (0, 0) as texture coords
[22:41:38] <wjp> where u = origx / xres
[22:41:46] <wjp> (origx = size of 'image', xres = size of 'texture')
[22:42:01] <wjp> (I'm ignoring double/int conversion for the moment, btw)
[22:42:24] <vividos> ok
[22:42:56] <wjp> it looks about right, but there's something bothering me there with mapping discrete coordinates to continuous coordinates
[22:43:22] <vividos> a 2d texture basically is a square with u and v coordinates ranging from 0.0 to 1.0
[22:43:47] <wjp> the '0.0' _seems_ to mean the 'point' to the left of the 0'th pixel, while the '1.0' _seems_ to mean the 'point' to the right of the (xres-1)'th pixel
[22:44:46] <vividos> if you think of a pixel as a rectangle, 0.0; 0.0 is the bottom left side of the first pixel
[22:45:07] <vividos> 1.0; 1.0 is the top right side of the last pixel
[22:45:46] <wjp> ok, that's more or less what I expected
[22:46:00] <vividos> when you have a texture of size 64x182, the range 0..63 is mapped to 0.0 .. 0.999999999..
[22:46:27] <vividos> that way texture coordinates are independent of the real size of the image
[22:46:57] <vividos> sorry, the one before the last line was kind of wrong :)
[22:50:10] * wjp hmms
[22:51:20] <vividos> more questions?
[22:51:56] <wjp> so if I understand correctly this problem would be caused by not being able to clamp at u, but only at 1?
[22:52:50] <vividos> yes
[22:53:47] <vividos> or at least I think so
[22:53:57] <vividos> the OpenGL docs are not exactly clear at that point
[22:54:47] <wjp> how about adding an extra row/col of pixels to the edges?
[22:55:03] <wjp> (if the edge doesn't coincide with the texture edge)
[22:55:07] <vividos> would work, yes
[22:55:25] <vividos> same for the cursor image
[22:55:36] <vividos> and the ingame objects (but that's a bit tougher)
[23:01:16] <wjp> in the case of split textures you should technically make that extra row of pixels the first row of the next image
[23:02:20] <vividos> right
[23:02:55] <wjp> adding the extra column to the textscroller does indeed remove the line there, btw
[23:03:30] <vividos> hmm, doesn't work for me yet
[23:07:28] <wjp> I just hacked in some code in the copy code in ua_texture::convert
[23:08:16] <vividos> :)
[23:08:35] <wjp> not really the proper place, but it had to do :-)
[23:20:29] <wjp> time for me to go
[23:20:31] <wjp> g'night
[23:20:49] <-- wjp has left IRC ("Zzzz...")
[23:21:41] <vividos> night!
[23:23:29] <-- vividos has left IRC ("Leaving")