[00:25:07] <-- Dominus has left IRC ("enough for now")
[00:32:53] --> Guest666 has joined #pentagram
[00:33:03] <-- Guest666 has left #pentagram (".")
[01:15:42] --> Kirben has joined #pentagram
[01:15:42] --- ChanServ gives channel operator status to Kirben
[03:52:02] <-- Darke|afk has left IRC (saberhagen.freenode.net irc.freenode.net)
[03:52:29] --> Darke|afk has joined #pentagram
[03:52:29] --- ChanServ removes channel operator status from Darke|afk
[04:44:45] <-- Darke|afk has left IRC (saberhagen.freenode.net irc.freenode.net)
[04:45:32] --> Darke|afk has joined #pentagram
[07:20:33] --- Darke|afk is now known as Darke
[07:20:35] --- ChanServ gives channel operator status to Darke
[08:12:01] <-- exultbot has left IRC (Connection reset by peer)
[08:12:04] --> exultbot_ has joined #pentagram
[08:12:04] --- Topic for #pentagram is: Pentagram... more than just a game engine, it's an Action RPG operating system
[08:12:04] --- Topic for #pentagram set by Colourless at Mon Oct 7 14:31:52 2002
[08:12:33] --> exultbot has joined #pentagram
[08:12:33] --- Topic for #pentagram is: Pentagram... more than just a game engine, it's an Action RPG operating system
[08:12:33] --- Topic for #pentagram set by Colourless at Mon Oct 7 14:31:52 2002
[08:39:10] --- wjp is now known as wjp|work
[10:14:21] --> Nadir has joined #pentagram
[12:00:23] <-- wjp|work has left IRC ("[x]chat")
[12:39:35] <-- Nadir has left IRC ("Uscita dal client")
[12:57:16] --> Kirben2 has joined #pentagram
[12:57:34] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[12:58:36] --> Colourless has joined #Pentagram
[12:58:42] --- ChanServ gives channel operator status to Colourless
[13:01:19] --> Cless has joined #Pentagram
[13:01:26] <-- Colourless has left IRC (Read error: 104 (Connection reset by peer))
[13:01:48] --- Cless is now known as Colourless
[13:01:50] --- ChanServ gives channel operator status to Colourless
[13:53:58] --- Kirben2 is now known as Kirben
[13:54:31] * Darke ponders what to ramble on about pentagram this night. There has to be _something_ we haven't rehashed a thousand times before, or we don't mind rehashing a thousand and one times! *grin*
[13:55:30] <Colourless> hmm, lets think for a moment
[13:55:36] * Colourless casts invisibility and leaves the room
[13:57:05] * Darke grabs a loooooong shepherds crook and slips it through the door. He jiggles it around until it meats resistance then pulls it back in, draging the invisible, invisible dragon with it.
[13:58:35] <Colourless> damn you rabbit, damn you to hell
[14:00:42] * Darke looks innocent.
[14:01:58] <Colourless> you realize we are going to need to implement joystick/gamepad support in to Pentagram for movement in TGWDS
[14:02:22] <Colourless> there will be complaints otherwise
[14:03:23] <Darke> Sure. That was something I was planning to do anyway. *grin* Been wanting to try out a joystick/pad with no regret, except I've got _no_ plain-old-joystick-port versions. *grin*
[14:03:56] <Darke> Isn't joysticks, etc supported 'natively' by SDL anyway?
[14:04:03] <Colourless> yes it is
[14:04:10] <Colourless> but i don't know exactly how it works
[14:04:30] <Colourless> is it event based? or does it use async device polling
[14:04:31] * Darke expects we'll find out when doing the input handling code. *grin*
[14:04:59] <Colourless> i guess it can probably do either
[14:05:03] <Darke> http://sdldoc.csn.ul.ie/guideinput.php
[14:05:37] <Darke> Looks like it's event based.
[14:05:57] <Colourless> yep, that's ok
[14:06:10] <Colourless> means we can handle them just as we do keyboard and mouse input
[14:07:01] <Darke> Oooh. Looks like it can handle multiple joysticks too. Of course since we're not handling multiplayer, it doesn't really matter. *grin*
[14:07:55] <Colourless> oh, i don't know, it might be a fun experiment to set up a split screen mode :-)
[14:08:46] <Darke> Shouldn't be _too_ hard, after all we are planning on just having the main window in a 'gump' inside the viewable area. *grin*
[14:09:39] <Colourless> of course I never said anything about it being for any games that already exist :-)
[14:10:56] * Darke snickers. Of course! Only for new games should someone make one. *grin*
[14:11:54] <Colourless> really, as long as we do everything right, splitting the game window should be pretty simple
[14:13:07] <Darke> *nod* We've got to be able to 'retarget' the main window to a different area anyway, so having two different windows with to different centers shouldn't be a problem really.
[14:13:56] <Colourless> I was actually thinking that unlike Exult that had Gumps and Gump_widgets, we should just have Gumps which are used for virtually everything
[14:14:35] <Colourless> each Gump class or an abstaction would contain a Vector for any 'sub gumps' that are owned by the game
[14:14:47] <Colourless> that way we could have gumps, within gump, within gumps
[14:15:12] <Colourless> it would also allow for a simplfied unified method of handling input into gumps
[14:15:19] <Darke> So, for example a menu would have each of it's buttons being a 'gump'?
[14:15:26] <Colourless> yes
[14:15:51] <Colourless> in Exult there was virtually no difference between the Gump and Gump_widget class
[14:16:06] <Colourless> about the only difference with Pentagram would be that Gump_widget would inherit Gump :-)
[14:16:23] <Darke> Works for me. On the Evil Plot side, it makes scripting things by usecode just that much easier if button==gump==object. *grin*
[14:17:08] <Colourless> indeed
[14:17:37] <Colourless> the background/desktop area i was thinking should be a Gump
[14:17:44] * Darke of course denies having an Evil Plot(tm).
[14:17:51] <Darke> Makes sense.
[14:19:02] <Colourless> so, then what you do is something like render_surface->lock(); Desktop->Paint(render_surface); render_surface->unlock(); and everything is done
[14:19:26] <Darke> So you've got your 'desktop' gump that's black, or has a pretty pattern that just ignores all input. Somewhere 'in' that you've got a 'main window' gump that displays your avatar moving around the landscape. And also in the 'desktop' area you have any other gumps (health/inventory/whatever), that are floating around.
[14:19:37] <Darke> Elegant. *grin*
[14:20:12] <Colourless> well, for your input, you'd pass it to the Desktop, which would then send it to the relevant 'sub gump'
[14:20:42] <Colourless> that would generally be the top level gump, or the gump the mouse cursor is over
[14:21:16] <Colourless> you'd also have a return value indicating if a input was handled
[14:22:00] <Colourless> in a sense it would just be a pretty generic windows system :-)
[14:22:01] * Darke nods.
[14:22:50] <Colourless> for all intensive purposes the Desktop gump could actually be made into the Pentagram application itself, since it is the base of the program
[14:22:59] <Darke> Which is what we want. *grin* Incidentally, have you seen that paragui gui system that sits on top of sdl? It looks pretty and flexable and 'might' be what we want, could save us some time if it is. *grin*
[14:23:02] <Colourless> but i don't think that is a good idea
[14:23:18] <Darke> Nah. You'd want to be able to swap desktop gumps really.
[14:23:19] <Colourless> (Desktop == Pentagram that is)
[14:23:42] <Colourless> can't say I've seen it
[14:23:55] <Darke> Like when starting it up, you get the 'main menu' it opens up a desktop gump, creates the icons and gets which game you want to play. Then it gets killed and you open up a 'new' desktop gump and create things inside it.
[14:24:35] <Colourless> the only issue with a pre-existing GUI system is we want it to be able to handle all our graphics formats and stuff. Now, if it's just a shell for input handling, it might be different
[14:25:13] <Darke> http://www.paragui.org/ Here's the webpage, immensely sluggish as it is.
[14:25:36] <Colourless> hey, i may not notice that it's slow you realize :-)
[14:25:59] <Colourless> heh, seems to be of an all right speed actually :-)
[14:26:17] <Darke> "181 or 182 images loaded" this is for _one_ page, with _one_ screenshot, the 182nd image which it was loading. *grin*
[14:26:28] <Colourless> ehhm looks a little MacOSXish
[14:26:44] <Colourless> page?
[14:27:35] <Darke> http://www.bms-austria.com/projects/paragui/modules.php?op=modload&name=My_eGallery&file=index&do=showgall&gid=4 This is an application it was used in. *grin*
[14:28:03] <Darke> Just one of the screenshot pages. Can't remember at the moment.
[14:28:13] <Colourless> actually it loaded pretty fast
[14:28:39] <Darke> http://www.bms-austria.com/projects/paragui/modules.php?op=modload&name=My_eGallery&file=index&do=showgall&gid=5 And here's a game.
[14:28:44] <Colourless> it 'only' has 145 images
[14:29:11] <Darke> http://www.bms-austria.com/projects/paragui/modules.php?op=modload&name=My_eGallery&file=index&do=showpic&pid=15&orderby=hitsD Screenshot from the sample application. *grin*
[14:29:13] * Darke snickers.
[14:29:56] <Darke> To me it 'looks' flexable enough to do what we would want it to do, but since I've not actually used it, I can't be sure.
[14:31:04] <Colourless> hmm, while it would work, i would find it restricting
[14:31:17] <Colourless> it would probably foul up big with any opengl plans that i have
[14:32:02] * Darke nods. I was considering this library before I knew you had any opengl plans, so it's probably not as 'good' an idea now. *grin*
[14:35:41] <Darke> Also, since most of our widgets are planning to be implemented in usecode, it may just be adding extra overhead when we're not going to benefit from it.
[14:36:55] <Colourless> hmm *thinking* should we have a base PentagramObject, which Gump and GameObject would be inherited from?
[14:37:24] <Darke> What widgets do we need anyway? I know the general 'button', and 'enter text' area, along with a 'window'.
[14:37:31] <Colourless> usecode classes would then be based on PentagramObject
[14:37:37] <Colourless> sliders
[14:37:40] * Darke nods. Makes sense.
[14:38:17] <Darke> *ponder* Yes, 'sliders' can't be easily emulated by 'buttons'.
[14:38:23] <Colourless> now, if we want to developer an editor too, we might want check boxes and radio buttons to
[14:38:42] <Colourless> of which a Check box is just a button that looks different :-)
[14:38:44] <Darke> Check boxes are just buttons with a face that changes.
[14:38:48] * Darke grins.
[14:39:07] <Colourless> radio buttons need special handling
[14:39:26] <Colourless> since you need to uncheck the others in the group when another one is checked
[14:39:26] <Darke> What are radio buttons generalisations of?
[14:39:31] * Darke nods.
[14:40:51] <Colourless> all you'd really need is for each radio button to have a pointer to the 'group' that it belongs to and when it's clicked, to uncheck the other buttons, and to check itself
[14:41:34] <Darke> *nod* So the obvious question is... is that possible to do using usecode and a 'normal' button object. *grin*
[14:41:44] <Colourless> no
[14:42:10] <Colourless> you could make the normal button a single group radio button though :-)
[14:42:54] <Colourless> of the 3 types of buttons
[14:43:09] <Colourless> standard button: auto resets after being pressed
[14:43:18] <Colourless> check box: toggle able
[14:43:54] <Colourless> radio button: resets the others in group, and becomes checked after being pressed. can not be unchecked
[14:45:14] <Colourless> all pretty simple
[14:45:33] <Colourless> i would think that having 3 classes would be the Object orientated way of doing things
[14:45:53] <Colourless> perhaps have a BaseButton class, that is abstracted to StandardButton, CheckBox, and RadioButton
[14:46:11] <Darke> (standard button) Maybe it resets after being pressed, depending upon the usecode. *grin* If we're handling the button animation in usecode the mousedown event could turn the button to 'depressed', but the mouseup event doesn't necessarily have to 'undepress' it. *grin*
[14:46:58] <Colourless> yes you 'could' do that. perhaps a flag upon creation :-)
[14:47:17] <Colourless> BUTTON_NO_AUTO_RESET or something
[14:48:12] * Darke is literally thinking that we have usecode attached to a gump, and that we just derive whatever type of usecode we want for that gump from it's base class (StandardButton/...), then override it with the appropriate shape numbers and effects upon clicking. If that makes sense. *grin*
[14:48:48] <Colourless> that would be in the spirt of usecode
[14:48:50] <Darke> What psudocode, or are you horrified at the thought of using usecode for such a 'core' ability? *grin*
[14:50:46] <Darke> It'd be especially easy to 'write' once we get some sort of gui editor for it, but a lot of the code will be boiler-plate cut&paste code for each different button at the start, only difference being the 'effect' of each button press, and the frame/shape numbers changing for the depressed/undepressed states.
[14:52:15] <Colourless> one would think that changing a shape number on a press would be a bad idea since it would change the class :-)
[14:55:52] <Darke> And you _can't_ see someone doing so to achieve a funky effect? *grin*
[14:57:05] <Darke> Admittedly, I've got all sorts of odd ideas that I want to test out, deliberately to stress the compiler/interpreter when we get them working. *grin* It's going to be fun!
[14:57:11] <Colourless> user brings up strange Dialog box. Pushes button. Button changes shape to something completely different, i.e. an NPC shape. User clicks an button acts like the NPC. User Responce, "WTF... hmm this is kind of cool"
[14:58:23] <Darke> Hey, I didn't say it'd be _useful_ did I? *grin*
[14:58:48] <Colourless> well, regardless, it will be possible anyway
[14:58:58] <Colourless> an object can always change it's shape
[15:01:55] <Darke> I actually can think of a reason to be able to change an object's shape, and thus it's effect. It's more 'inventory' related though then actual menu related.
[15:05:01] <Darke> For example, 'transmuting' items, like the standard alchemy stuff. I have 'potion ingredient' and 'potion bottle'. Stealing the example from M&M8, I mix 'red potion ingredient' with 'empty potion bottle' and get 'red potion bottle' which heals you. Rather then have each seperate potion effect within a massive case statement inside a generic 'empty potion bottle' class, you have each effect in their own class.
[15:06:37] <Colourless> you do know, that "void Item::setType(ushort type)" already exists :-)
[15:08:28] <Darke> That has the overhead of a function call. Not something a l33t h4x0r would do. *grin*
[15:09:32] <Colourless> you want it as an opcode then? Direct Access to object structures in usecode is a terrible idea, and you know it\
[15:12:23] <Darke> Sure. You'd have to fiddle with the raw assembler to get it to DTRT. *grin* This is a "you've got go be kidding me" idea, not anything practical you know.
[15:14:18] * Darke occasionally wonders if he could be any more dumb, and is regularly given the answer 'yes' by his compiler. *sigh*
[15:21:26] <Colourless> might interest you: http://www.levenez.com/lang/history.html#04
[15:22:30] --> Dark-Star has joined #pentagram
[15:23:32] * Darke oooohs! Neat! I've seen something like this before, but not as extensive.
[15:24:50] * Darke wonders why the _draft_ Fortran2000 is detailed as being in 2002...
[15:25:43] <Colourless> Fortran 95 was in 1997
[15:26:09] <Darke> Yeah, just saw that too. *grin* At least C99 was in 1999.
[15:26:23] <Colourless> Fortan 90 was in 1991
[15:26:35] <Colourless> 77 in 1978
[15:27:13] <Darke> It's missing Modula3, which is _completely_ understandable. Modula2 was dying a slow and painful death as it was when Mod3 came out.
[15:27:54] <Darke> Obviously Fortran is just a little bit slower then the rest. *grin*
[15:28:02] * Dark-Star wonders what has happened to #uwadv
[15:28:43] <Colourless> ok, so waht is the difference between Perl 5.000 and Perl 5.005_50 other than 4 years difference?
[15:29:13] * Darke is pretty sure the 'release' of Mod3 killed off Mod2. Simply because people weren't willing to code what little they did with an 'older' standard, and weren't willing to invest in updating to a new standard given that they weren't really using the old one.
[15:29:14] <Colourless> it seems like a really tiny version change for such a long time :-)
[15:29:36] <Darke> Colourless: Probably lots of library work. *grin*
[15:30:51] * Darke wonders why Haskall didn't steal the relatively sane syntax of scheme when it derived itself from it. As it is, sceme is slightly readable, Haskell isn't.
[15:32:24] <Darke> MS Basic 2.0 (1975) -> Visual Basic 1.0 (1991). Gee... not only did they take, what, 16 years to get the next version, they actually _decremented_ the version number? *grin*
[15:33:06] <Colourless> hehe
[15:33:39] * Darke thinks that beats Perl 5.0 hands down. *grin*
[15:35:21] <Colourless> C# is the results of inbreeding. C++ (1983) -> Oak (1991) -> Java 1 (1995) -> Java 2 (1.2 1998) and C++ (1983) -> ANSI C++ (1998) :-)
[15:37:28] * Darke boggles and always thought that C# was a bastard of a language, now we've proof! *grin*
[15:38:32] <Colourless> well, C++ has a bit of inbreeding too but you've got to go back to 1960, and lots of generations
[15:39:49] * Darke noddles.
[15:40:25] <Colourless> but Modula2, well, that's even closer than C#. Pascal (1970) -> Moldula (1975) -> Modula 2 (1979) and Pascal (1970) -> Mesa (1977) -> Modula2 (1979)
[15:40:56] * Darke snickers.
[15:41:51] <Colourless> actually expand it back a generation you get Algol 68 -> Pascal, and Algol 68 -> Mesa (1977)
[15:45:04] * Colourless decides to close the IE window, could spend hours at that page
[15:45:31] * Darke nodnods. Him too. *grin*
[15:46:00] <Darke> On a different note, the 'int's in the event names are actually uint16/word's yes?
[15:46:09] <Darke> s/uint32/sint32/
[15:46:20] <Darke> s/32/16/g Bleah, mind's going...
[15:46:56] * Darke is just trying to clear things up and get a little consistancy around the place. *grin*
[15:47:07] * Colourless 's head explodes
[15:47:29] <Colourless> int = sint16
[15:47:30] * Darke icks.
[15:48:48] <Darke> Cool. So would outputting: `guardianBark(word)` or `guardianBark(sint16)` be more 'correct'? *grin* I'm guessing the former unless we're going to be using the [u|s]int[8|16|32] syntax in usecode.
[15:50:02] <Colourless> yes
[15:59:30] <Darke> Looks like you can have negative str/int/dex, but not negative hp.
[16:00:19] <Darke> And there's a maximum of 255 different music tunes to play? playMusic only takes a char.
[16:01:38] <Colourless> actually there's only 128 possible tunes :-)
[16:02:19] <Colourless> 0->127 are General Midi songs, 128->255 are for Adlib/FM synth songs
[16:02:25] * Darke ahhs.
[16:02:33] <Colourless> the playMusic function automatically does the addition
[16:03:43] * Darke ponders knocking that up to a word. The usecode only ever specifies 0-127 then?
[16:03:58] <Colourless> yes only 0-127
[16:04:20] <Darke> Can be increased easily then, with no 'cost' to us. *grin*
[16:31:58] * Darke wanders off to do this 'sleeping' thing. He'll finish cleaning up code tommorrow. _Lots_ of little 'int's scattered around the code that really shouldn't be there. *grin* Night!
[16:32:07] <Colourless> cya
[16:32:12] --- Darke is now known as Darke|zzZ
[16:37:15] <-- Colourless has left IRC ("casts invisibility")
[16:47:44] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[16:51:50] --> wjp has joined #pentagram
[16:51:50] --- ChanServ gives channel operator status to wjp
[17:33:14] <-- Dark-Star has left #pentagram ("Client Exiting")
[20:15:00] --> Dark-Star has joined #pentagram
[23:58:19] <-- Dark-Star has left #pentagram ()