[01:42:12] --> Kirben has joined #pentagram
[01:42:12] --- ChanServ gives channel operator status to Kirben
[02:08:44] --> SB-X has joined #pentagram
[02:11:05] --> Kirben2 has joined #pentagram
[02:13:04] <-- Kirben has left IRC (vinge.freenode.net irc.freenode.net)
[02:21:49] --- Kirben2 is now known as Kirben
[04:30:49] * SB-X is away: No reason given
[06:47:33] <-- SB-X has left IRC (Read error: 110 (Connection timed out))
[07:30:53] --> Dark-Star has joined #pentagram
[08:01:17] <-- Dark-Star has left IRC ()
[08:08:07] --> Kirben2 has joined #pentagram
[08:08:20] <-- Kirben has left IRC (Read error: 54 (Connection reset by peer))
[08:25:30] --- Kirben2 is now known as Kirben
[08:25:34] --- ChanServ gives channel operator status to Kirben
[08:41:22] --> wjp has joined #pentagram
[08:41:22] --- ChanServ gives channel operator status to wjp
[10:34:32] --> Cashman has joined #pentagram
[10:37:40] <Cashman> hmm colourless is on icq but away
[10:39:59] <Cashman> does anyone want me to try buzz dragon on icq telling him hes wanted?
[10:49:06] <-- Cashman has left IRC ()
[10:50:49] --> Cashman has joined #pentagram
[12:51:09] --- Cashman is now known as CashZzz
[12:51:12] <-- CashZzz has left IRC ()
[13:04:06] --> Fingolfin has joined #pentagram
[13:04:06] --- ChanServ gives channel operator status to Fingolfin
[13:04:21] <wjp> hi Max
[13:05:16] <Fingolfin> yo
[13:11:58] <-- Fingolfin has left IRC ("42")
[14:19:44] --> Colourless has joined #Pentagram
[14:19:49] --- ChanServ gives channel operator status to Colourless
[14:20:16] <Colourless> hi
[14:20:36] <wjp> hi
[14:33:56] <Colourless> the way items are currently 'moved' from the world to containers is... not ideal
[14:35:00] <Colourless> we do container->addItem(item)
[14:35:11] <Colourless> when really it should be item->moveToContainer(container)
[14:35:55] <Colourless> the reason why cause it's making fast area stuff hard :-)
[14:36:08] <Colourless> you asked the other day about unforeen problems... and that is one of thtem
[14:38:25] <Colourless> of course it's not a 'huge' problem
[14:45:31] <wjp> hm, I see
[14:47:48] <Colourless> it's not 'overly' important though exactly how it work. the reason i would prefer moveToContainer is simply to unify the way item moving works
[14:49:47] <Colourless> of course the 'big' problem is that it's upto StopDraggingItem() to remove an item from the world
[14:50:31] <Colourless> which all realate to the moveToContainer() idea
[14:50:38] <wjp> yeah... moving an item is a two-step process now
[14:51:09] <Colourless> Item::move() will remove an item from the world
[14:51:26] <Colourless> but there is no equiv for moving to a container.
[14:52:12] <Colourless> now, Container::addItem() could do that but i would prefer that the item itself was responsible for removing itself from the CurrentMap
[15:02:02] * wjp nods; would probably be cleaner
[15:02:23] <wjp> the Container::addItem functions would still have to exist, but they'd be called by moveToContainer
[15:09:11] <Colourless> if you 'want' something to do with pentagram... you could implement the mouse!
[15:09:15] <Colourless> oh the horror!
[15:09:23] <Colourless> :-)
[15:10:55] <wjp> oh no! :-)
[15:11:11] <Colourless> ignoring any ideas that i previously had with mouse cursors would probably be a good idea, and just do it anyway you want :-)
[15:11:30] <Colourless> just think about what is required
[15:11:43] * wjp somehow feels like he's being tricked into writing mouse cursor code ;-)
[15:12:03] <wjp> can we render the mouse more than once per frame?
[15:12:14] <Colourless> well yes
[15:12:21] <wjp> depends on the mode SDL is in, though
[15:13:12] <Colourless> if the mouse isn't a process then it shouldn't be a problem
[15:13:13] * wjp checks
[15:13:35] <wjp> SDL_FULLSCREEN or no flags at all
[15:13:51] <wjp> so we can use UpdateRect on a small area
[15:14:01] <Colourless> i wouldnm
[15:14:08] <Colourless> wouldn't have done it that way though
[15:14:24] <Colourless> the problem is you are tempted to repaint the mouse every move
[15:14:57] <Colourless> however, that leads to a trap. if painting is 'slow' and the mouse sends lots of events then you will slow down pentagram 'heaps'
[15:15:11] <Colourless> exult's menu did that :-)
[15:15:19] <Colourless> mmm. mouse lag....
[15:15:21] <wjp> I remember :-)
[15:15:30] <wjp> but just because it was updating the full screen at every mouse move
[15:15:44] <Colourless> yeah
[15:16:06] <Colourless> my recommendation is to just paint the mouse in the GUIApp::paint function
[15:16:13] <Colourless> in 320x200 pentagram runs 'really' damn fast
[15:16:27] <Colourless> it's actually the item sorting that is 'slow'
[15:16:30] <Colourless> as far as I can tell
[15:16:58] <Colourless> and remember 'Update Rect' isn't friendly to non software surfaces
[15:17:26] <wjp> I thought we were only using swsurfaces?
[15:17:44] <Colourless> non software surfaces include opengl, which i do intend to support
[15:17:53] <wjp> ah
[15:18:28] <Colourless> of course it could be made an optional thing
[15:20:28] <wjp> yes... something like only when using swsurfaces, and only every 20ms or so (at most)
[15:22:21] <wjp> I guess it could only be done in-between processes, though
[15:22:29] <wjp> (the rest of the time it's painting anyway)
[15:26:15] <Colourless> something about the paperdoll... it's behaviour is strange... or at least it was the other day. You try dragging an item that can't fit in it, and it's as if the gump doesn't exist at all
[15:26:56] <Colourless> it 'should' be accepting the items, and putting them into the backpack (if there is one which there always should be)
[15:29:16] <wjp> it should be doing that
[15:29:52] <wjp> as long as you drag the item over the item-area
[15:30:31] <wjp> e.g., when I drag a fish over the paperdoll, the transparent fish shows up over the backpack
[15:30:59] <Colourless> ah ok... i can't compile pentagram at the moment, so I can't exactly check what it's doing 'now'
[15:32:07] <wjp> ah, ok. I only added this late last night (about 17 hours ago)
[15:53:45] <Colourless> so when are we going to implement stealing.
[15:53:54] * Colourless points at Item::FLG_OWNED
[15:54:34] <Colourless> is there an actual point to having the 'EXT_FIXED' flag?
[15:54:56] <DarkeZzz> Wow. Toaster-head's backpack and paperdoll are *real* tiny...
[15:55:36] <Colourless> well, you 'do' run at a really high res
[15:56:19] <DarkeZzz> Hmm... yeah, I suppose. Maybe I should purchase a magnifiying glass to use for inventory sorting. *squint*
[15:56:51] <Colourless> you could just run pentagram in fullscreen mode
[15:57:37] <wjp> EXT_FIXED isn't _really_ necessary, I guess, but as long as we have a spare bit it won't hurt :-)
[15:57:55] <wjp> it just means the item is from fixed.dat, and only matters when switching maps
[15:58:02] <DarkeZzz> Colourless: Well... yes. But that would be the *logical* solution. Can't have that, can we?
[16:02:37] <Colourless> i guess it doesn't matter
[16:02:53] <Colourless> just thinking of crusader, and it would probably be best if it was kept
[16:03:02] <Colourless> there is no nonfixed in crusader
[16:03:15] <Colourless> and as far as i know, you can't backtrack to ealier levels
[16:03:32] <Colourless> so it would be best if all the fixed items in other maps were not saved :-)
[16:07:04] <wjp> probably, yes :-)
[16:07:40] <Colourless> oh know, i mentioned the 'c' word :-)
[16:07:54] --> SB-X has joined #pentagram
[16:07:55] <wjp> I did that too, the other day...
[16:08:30] <Colourless> s/know/no/
[16:08:51] * Colourless hangs his head in shame, not for the 'c' word, but because of no/know
[16:09:37] * DarkeZzz obligatory tisktisks.
[16:11:46] <wjp> that didn't sound quite right either :-)
[16:12:35] <wjp> anyway, dinner. I'll bbl
[16:18:51] <-- Kirben has left IRC (Read error: 54 (Connection reset by peer))
[16:19:47] --> Kirben has joined #pentagram
[16:19:47] --- ChanServ gives channel operator status to Kirben
[16:25:14] * SB-X is away: No reason given
[16:35:03] <wjp> b
[16:35:13] <Colourless> wb
[16:35:19] <wjp> thx
[17:39:42] <-- Kirben has left IRC (Read error: 54 (Connection reset by peer))
[18:21:56] --> Dominus has joined #pentagram
[18:22:18] <wjp> hi
[18:22:28] <Dominus> hi
[18:22:30] <Dominus> wjp: nice work on the paperdoll
[18:22:41] <Colourless> hi
[18:22:45] <wjp> not quite like in the original yet
[18:23:07] <wjp> of course, I don't _remember_ how exactly it worked in the original... but still :-)
[18:23:10] <Dominus> and was 'r' used in the original as well? Can't remember. A shame if it was and I never knew....
[18:23:23] <wjp> post-patch according to Colourless
[18:23:39] <Dominus> hmmm
[18:23:48] <Dominus> I never played pre-patch :-)
[18:23:58] <wjp> I hardly played post-patch :-)
[18:24:23] <Dominus> damn, dinner is done. got to go again
[18:24:32] <wjp> bye
[18:24:56] <Dominus> one more thing about keyboard input: already ran into the old qwertz vs. qwerty problem :-)
[18:25:22] <wjp> yes... I wonder how to solve that problem cleanly
[18:25:39] <wjp> configurable keys is one way
[18:25:55] <Colourless> #05 Keyboard Hotkeys
[18:25:57] <wjp> detecting swapped y/z is possible too
[18:25:58] <Colourless> The following hotkeys have been added to enhance the user interface:
[18:26:03] <Colourless> a) F7 will now save the game to a special hotkey savegame file
[18:26:06] <Colourless> b) F8 loads the hotkey savegame file.
[18:26:09] <Colourless> c) B will activate the bedroll.
[18:26:13] <Colourless> d) R will activate the Recall Item.
[18:26:17] <Colourless> e) K will activate the keyring.
[18:26:42] <Dominus> I hope no one thinks thatis in pentagram now
[18:26:43] <Colourless> from u8patch.txt
[18:26:52] <Dominus> anyway, I'm off
[18:26:56] <Dominus> thy. Colourless
[18:26:57] <wjp> "WARNING! This feature can become so addictive that it becomes the sole way of saving the game. It is not wise to depend on one saved game throughout the entire Ultima VIII quest." :-)
[18:26:59] <Dominus> bye
[18:27:04] <wjp> bye
[18:27:13] <Colourless> they can try.. but f7 and f8 don't do anything in pentagram
[18:27:13] <-- Dominus has left IRC (Read error: 104 (Connection reset by peer))
[18:27:24] <Colourless> wjp: i learnt that one the hardway :-)
[18:28:30] <Colourless> pressing the wrong key and accidently saving the game after I had done something 'really' stupid and made the game unwinnable :-)
[18:31:45] <wjp> I never thought putting the quicksave/quickload keys next to eachother (without an easy way to remember which was which, on top of that) was such a bright idea...
[18:32:10] <Colourless> seven for save!
[18:32:16] <Colourless> is about the only one there is
[18:53:59] --> Dominus has joined #pentagram
[18:54:19] <wjp> wb
[18:54:31] <Dominus> b
[18:54:38] <Colourless> wb
[18:57:26] <Dominus> about the y/z issue, we can just handle it the exult and original ultima way: ignore it :-)
[18:57:59] <wjp> in exult you can modify the key layout
[18:58:25] <Dominus> true but it still seems more like a hack this way
[18:59:14] <wjp> not sure if there's a clean way
[19:00:03] <Colourless> it's... a strange problem
[19:00:17] --> Fingolfin has joined #pentagram
[19:00:17] --- ChanServ gives channel operator status to Fingolfin
[19:00:22] <Colourless> due to keyboard scan codes
[19:01:19] <Fingolfin> yo
[19:01:19] <Colourless> unless unicode mode it worked, you get raw scancodes
[19:01:32] <wjp> hi again Max
[19:01:42] <Colourless> the problem with unicode though is it causes problems for modifiers
[19:01:43] <Dominus> hi Fingolfin
[19:01:44] <wjp> but unicode won't really work for ctrl/alt
[19:01:47] <Colourless> hi Fingolfin
[19:02:09] <wjp> and I'm sure there are international input methods which will do even stranger things
[19:06:59] <Colourless> i wonder if the windows VkKeyScan function would 'help'
[19:07:18] <Colourless> it converts an ascii (or unicode) charater into scan codes
[19:08:16] <Colourless> I wonder if doing VkKeyScan('z') would return 'y' for Dominus
[19:08:50] <Dominus> how can i check?
[19:09:07] * wjp wonders how he can change his keymap in X
[19:10:01] <Colourless> well, you could add pout << "Checking scan code " << VkKeyScan('z') << std::endl;
[19:10:06] <Colourless> somewhere into pentagram
[19:10:11] <wjp> setxkbmap looks interesting
[19:10:17] <Colourless> with #include <windows.h> somewhere above that
[19:10:27] <Colourless> oh
[19:10:31] <DarkeZzz> Easy solution: Make (Ctrl|Alt|Meta|Cokebottle)+(y|z) work identically. That way it won't matter one iota whether you're a querty or quertz.
[19:10:36] <Colourless> also, you will need to make sure that it's cast as a char
[19:10:48] <Colourless> so use
[19:10:56] <Colourless> pout << "Checking scan code " << static_cast<char>(VkKeyScan('z')) << std::endl;
[19:11:20] <Dominus> any idea in which file to put that?
[19:11:39] <Colourless> somewhere you know it will be run...
[19:11:50] <wjp> somewhere in GUIApp.cc near a 'normal' startup message or so
[19:11:56] <Colourless> GUIApp::GUIApp or GUIApp::startup
[19:12:12] <wjp> not the contructor
[19:12:18] <wjp> constructor
[19:12:31] <Colourless> ok then GUIApp::startup :-)
[19:12:39] <Colourless> i would recommend at the bottom
[19:16:39] <Dominus> hmm, it just said "Checking scan code Z" but did not give any "answer"
[19:16:58] <Colourless> hmm
[19:17:12] <Colourless> make it pout << "Checking scan code " << VkKeyScan('z') << std::endl;
[19:18:36] <Colourless> uh
[19:19:06] <Colourless> you should be using uppercase characters too
[19:19:20] <wjp> hmm... I managed to swap y/z on the console, but not in X...
[19:20:19] <Dominus> now it says chacking scan code 90 and does not do anything with it
[19:20:49] <wjp> the number is the interestin bit :-)
[19:20:54] <wjp> s/tin/ting/
[19:21:09] <wjp> 90 is Z, btw
[19:21:13] <Dominus> aehm, okay :-)
[19:21:34] <Colourless> so, it's returning Z for Z :-)
[19:23:23] <Dominus> and now?
[19:25:17] <wjp> hmm.. according to Sam Lantinga on the SDL ML this should work properly in linux
[19:25:33] <wjp> (this = swapping y/z automatically)
[19:25:56] <Dominus> with sdl release or snapshot?
[19:26:06] <wjp> this is a post from 2001
[19:26:11] <Dominus> oh
[19:26:32] <-- SB-X has left IRC (vinge.freenode.net irc.freenode.net)
[19:26:47] --> SB-X has joined #pentagram
[19:27:42] <wjp> if you're interested: (quote)
[19:27:46] <wjp> It's not a bug in SDL. It's what I've been saying for ages... that's
[19:27:46] <wjp> what DirectX is returning as the key code. You can't rely on the VK
[19:27:46] <wjp> keysyms reflecting the keyboard layout because they're just great big
[19:27:46] <wjp> gamepad button identifiers. It's only when they're translated into
[19:27:46] <wjp> character codes that they start to have meaningful ascii values and
[19:27:47] <wjp> will match the actual keyboard layout.
[19:29:51] <Dominus> that's about what I had remembered vaguely from prior discussions about this problem
[19:30:32] <Colourless> so, it's a direct input problem
[19:32:54] <wjp> the mail goes on with:
[19:33:09] <wjp> Max hacked the MacOS code to do a partial keyboard translation on each
[19:33:09] <wjp> key so we know what it _should_ be, but really MacOS has the same problem.
[19:33:19] <wjp> (end quote)
[19:33:28] <wjp> I think I can guess who this 'Max' is ;-)
[19:33:34] <Dominus> me too
[19:33:56] <Colourless> i wonder if windows has the problem if it's forced to use dib for rendering
[19:34:47] <Dominus> any easy way to check this (easy for me that is)?
[19:34:57] <Colourless> yes i think so
[19:35:12] <wjp> an environment var, probably
[19:37:13] <Colourless> yes
[19:37:29] <Colourless> set SDL_VIDEODRIVER=windib
[19:38:02] <wjp> (in a dos prompt; run pentagram from the same dos window)
[19:38:25] * Dominus knows at least that :-)
[19:38:50] <wjp> k :-)
[19:39:25] <Dominus> that works
[19:40:02] <Dominus> of course I can't get to the console now :-)
[19:41:16] <Dominus> that needs to be ctrl+alt++ on my keyboard and somehow that doesn't seem to work :-)
[19:41:48] <Dominus> so in the end I'm probably just better off configuring a key file :-)
[19:42:10] <wjp> hm, SDL windib gets the keysym straight from the scancode
[19:42:50] <Colourless> the scancodes are translated into Virtual keys code by windows, which makes them 'correct'
[19:42:54] <Colourless> DirectInput passes raw codes
[19:43:49] <wjp> ok, makes sense... so the wParam to the KEYDOWN message is already translated
[19:43:49] <Colourless> or more specifically, it's own version of scan codes
[19:44:43] <wjp> VkKeyScan is obsolete, btw :-)
[19:45:38] <Colourless> yes i know
[19:45:45] <Colourless> you are supposed to use VkScanEx
[19:45:51] <Colourless> VkKeyScanEx
[19:45:54] <wjp> with an extra 'locale' parameter
[19:46:16] <Colourless> yeah and getting locale is a pain in the ass, especially when I just what the 'default' current local
[19:50:09] <wjp> could MapVirtualKey be what we need?
[19:51:03] <Colourless> maybe
[19:51:19] <Colourless> to get that to work, directx 8.1 or 9 is required
[19:51:33] <Colourless> IF i understand the directinput sdk info correctly
[19:52:00] <Colourless> DIPROP_SCANCODE
[19:52:00] <Colourless> Retrieves the scan code for a keyboard key
[19:52:17] <Colourless> The scan codes reported in Microsoft DirectX® 8.1 are different from the ones reported in DirectX 8.0. In DirectX 8.0, the property actually reported the single byte DIK_* constant associated with the key, not the scan code. In DirectX 8.1 and DirectX 9.0, the property reports the make scan code as would be reported by a PS/2 keyboard. In some cases, scan codes are multiple bytes, in which case the scan code bytes are ordered with the first b
[19:52:58] <wjp> (message was cut off after "with the first b")
[19:53:27] <Colourless> with the first byte in the least significant byte of the DWORD retrieved by the property.
[19:54:07] <wjp> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardinput/keyboardinputreference/keyboardinputfunctions/mapvirtualkey.asp doesn't mention DirectInput at all
[19:54:19] <Colourless> no i wouldn't
[19:54:28] <Colourless> try Multimedia\directx
[19:57:15] <Colourless> actually it might work anyway
[19:57:22] <Colourless> regardless of DX version
[20:00:40] * Fingolfin pops in for a moment
[20:00:48] <Fingolfin> regarding key codes, we had some discussions for SDL 2
[20:00:51] <Colourless> dominus try this for me
[20:01:09] <Fingolfin> the real problem is that there are three kinds of uses which are fit under two kinds of representation, which of course fails
[20:01:12] <Colourless> std::cout << "Checking scan code " << static_cast<char>(MapVirtualKey(0x2C,1)) << std::endl;
[20:01:30] <Colourless> s/std::cout/pout/
[20:01:32] <wjp> 2C?
[20:01:42] <Colourless> #define DIK_Z 0x2C
[20:01:52] <Colourless> scancode for 'Z'
[20:01:56] <Fingolfin> keyboard layout ("the key right of X"), key combos (Alt-A vs. å on my machine), and ascii input
[20:01:56] <wjp> ah
[20:02:19] <Fingolfin> layout specific control isn't really possible with SDL
[20:02:20] <Colourless> that 'should' output Y for dominus if it works correctly
[20:02:22] * Fingolfin pops out again
[20:04:08] <Dominus> #define DIK_Z 0x2C ar the start of guiapp.cpp?
[20:04:24] <wjp> no, that was just for me I think :-)
[20:04:39] <Dominus> he he?
[20:04:44] <Colourless> no, just use the checking scan code like. as wjp said, the define wsa for him
[20:04:47] <Dominus> scratch the ? :-)
[20:06:05] <Dominus> got the Y
[20:06:12] <Colourless> ok. :-)
[20:06:20] <Colourless> good (or bad depending on your point of view)
[20:08:45] <wjp> where to plug this in is rather an interesting matter
[20:09:07] <Colourless> DX5_InitOSKeymap() is a place where it could be done (in sdl)
[20:09:51] <Colourless> you'd hack things to use the VK_keymap array from DIB_InitOSKeymap()
[20:10:28] <Colourless> or something with TranslateKey() in SDL_dx5events
[20:10:42] <Colourless> vkey = MapVirtualKey(scancode, 1);
[20:10:53] <Colourless> is already called in that function
[20:10:57] <Colourless> but only for unicode translation
[20:12:33] <wjp> it would have to be something like sym = VK_keymap[MapVirtualKey(scancode, 1)); I guess
[20:12:44] <Colourless> yeah could be
[20:12:47] <wjp> s/);/];/
[20:13:03] <Colourless> i'm thinking though that's not 'ideal'
[20:13:21] <Colourless> but it should work
[20:13:39] <Colourless> i don't think an extra function call per key input will matter
[20:14:09] <wjp> you could precompute it into DIK_keymp
[20:14:18] <Colourless> yeah that's what i was thinking
[20:14:37] <wjp> I wonder if the SDL devels would consider this
[20:14:55] <Colourless> should send it to the mailing list
[20:15:08] <Dominus> would be nice if they did
[20:16:00] <Dominus> the problem is really annoying at times
[20:16:17] <Dominus> with most of the sdl-based programs
[20:40:56] <Colourless> i should be going
[20:40:59] <-- Colourless has left IRC ("cya")
[21:43:53] <-- Dominus has left IRC ("enough for now")
[22:31:31] <-- wjp has left IRC ("Zzzz...")
[22:57:46] <-- Fingolfin has left IRC ("42")