#exult@irc.freenode.net logs for 15 Feb 2003 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage

[00:31:58] --> Servus has joined #exult
[02:14:51] <-- Servus has left IRC ()
[03:25:27] <-- Kirben has left IRC ("System Meltdown")
[03:32:03] --> Kirben has joined #exult
[03:32:03] --- ChanServ gives channel operator status to Kirben
[05:14:38] --- ChanServ removes channel operator status from DarkeZzz
[06:20:00] --> Yuv422 has joined #exult
[08:29:03] <-- DarkeZzz has left IRC (adams.freenode.net irc.freenode.net)
[08:29:03] <-- Yuv422 has left IRC (adams.freenode.net irc.freenode.net)
[08:29:03] <-- jer|w0rk has left IRC (adams.freenode.net irc.freenode.net)
[08:29:03] <-- Kirben has left IRC (adams.freenode.net irc.freenode.net)
[08:29:03] <-- Matt_O has left IRC (adams.freenode.net irc.freenode.net)
[08:29:17] --> Kirben has joined #exult
[08:29:17] --> Yuv422 has joined #exult
[08:29:17] --> Matt_O has joined #exult
[08:29:17] --> DarkeZzz has joined #exult
[08:29:17] --> jer|w0rk has joined #exult
[10:13:15] --- DarkeZzz is now known as Darke
[10:13:30] <Yuv422> hi Darke
[10:13:31] --- ChanServ gives channel operator status to Darke
[10:13:37] <Darke> Hiya.
[11:04:56] --> Colourless has joined #Exult
[11:04:57] --- ChanServ gives channel operator status to Colourless
[11:05:13] <Yuv422> hi Colourless
[11:05:19] <Colourless> hi
[11:08:38] <Yuv422> any way to override cout, cerr streams. I tried defining these names to global ofstreams but it doesn't seem to like it.
[11:08:45] <Colourless> hows your xbox stuff going?
[11:09:04] <Yuv422> having a problem creating a new game
[11:09:30] <Yuv422> but main menu works fine credits work, intros to both games work :)
[11:09:47] <Colourless> creating a new game writes lots of stuff to the gamedat did
[11:09:52] <Colourless> s/did/dir/
[11:10:17] <Yuv422> but it is dieing someware in the init_gamedat area. :(
[11:10:20] <Colourless> so, you'll need to setup the exult.cfg file to point the gamedat did (not sure what the config key is)
[11:10:34] <Colourless> what the.... writing did instead of dir..
[11:10:51] <Colourless> you need to point the gamedat dir to somewhere with write access
[11:11:13] <Yuv422> everywhere on the xbox should have write access I'd assume.
[11:11:34] <Yuv422> I think U7Open might be throwing though :(
[11:11:44] <Yuv422> could it be an issue with zlib?
[11:12:02] <Colourless> i would doubt that everything would be write access
[11:12:28] <Colourless> no extremely unlikely. zlib is only used when reading and writing save games from the savegame screen
[11:12:36] <Colourless> it's not used at any other time
[11:13:34] <Yuv422> hmm how do you control write access on a win32 filesystem?
[11:13:49] <Colourless> 'normally' i would assume only the E savegame drive would have write access. C under normal cicrumstances probably wouldn't (could be wrong here though), D being a cdrom wouldn't, and E of course, if mounted would
[11:15:07] <Yuv422> it does look like exult is writing "settings" changes back to the exult.xfg file
[11:15:09] <Colourless> you could probably attempt to use a dir on 'C' drive as the gamedat dir, as it is possible it might have write access thinking about it
[11:15:21] <Yuv422> so I think D: has write access. :)
[11:15:33] <Colourless> does it create a gamedat did ?
[11:15:35] <Colourless> s/did/dir/
[11:15:56] <Yuv422> hmm I made the gamedat dir
[11:16:09] <Yuv422> I'll remove it and let exult create the dir.
[11:17:31] <Colourless> it is by default each game has it's own gamedat dir which is in the gamedir\gamedat obviously (as it was with the originals)
[11:18:30] <Colourless> anyway, i'm away for a bit
[11:18:31] --- Colourless is now known as Cless|Away
[12:07:31] --- Cless|Away is now known as Colourless
[12:36:52] <-- Kirben has left IRC ("System Meltdown")
[12:44:53] --- Colourless is now known as Cless|Away
[12:51:42] <-- Yuv422 has left IRC ("[BX] Windows 95, coded entirely by blondes")
[13:24:35] --- Cless|Away is now known as Colourless
[16:01:17] * Darke summons a dozen, dancing X-Boxes to torment the colourless one.
[16:10:37] * Darke ponders creating a macro called CANT_HAPPEN() who's sole purpose is to assert(false). The number of times I've written code like `assert(false); // can't happen` is amazing. *grin*
[16:18:37] <Colourless> actually that somes like a good idea (summoning the X-Boxes and the CANT_HAPPEN() macro) :-)
[16:18:57] <Colourless> s/somes/sounds/
[16:19:06] <Colourless> don't ask, i have no idea how i made 'that' typo
[16:19:21] * Darke won't then. *grin*
[16:20:31] <Colourless> good
[16:20:50] <Darke> So CANT_HAPPEN() is something to stick in pent_include.h then? *grin*
[16:20:56] <Colourless> the only conclusion that i could come with is that i have some unrealized typing disorder
[16:21:02] <Colourless> yes that would be a good spot
[16:21:13] <Darke> You've only *just* come to that conclusion?!? *duck!*
[16:21:44] <Colourless> i never said i just thought of it *just* now
[16:22:06] <Colourless> with CANT_HAPPEN you could also make it conditional for debug builds only
[16:23:20] <Colourless> or it could be turned into something different in special builds such as outputting stuff to the console or something
[16:23:38] <Darke> Makes sense. Though really since it 'can't happen', one could leave it in the release builds anyway, and... err... doesn't assert() become a non-op when debug builds are turned off anyway?
[16:25:11] <Colourless> depends on the compiler
[16:25:18] <Colourless> but usually yes
[16:26:46] <Darke> I'm really not sure what 'special' information it could provide in special builds, given that I'm normally dropping it in areas such as switch statements where 'default' conditions should never be encountered. Or a function that should always return before we hit the end of a function and got a warning for it. Maybe we need a CANT_HAPPEN_RETURN too. *grin*
[16:28:12] <Colourless> i don't know, it was just an idea
[16:28:43] <Colourless> who knows what 'crap' we might want to try. there might be cases where CANT_HAPPEN errors occur and we don't want pentagram to quite
[16:28:49] <Colourless> s/quite/quit/
[16:29:16] <Darke> Well keep branestorming then. *grin* If there are other features that we'd like to have, we should add them now.
[16:29:32] <Darke> Wouldn't that be more of a SHOULDNT_HAPPEN though?
[16:29:51] <Darke> As in a semi-recoverable 'can't happen'.
[16:29:51] <Colourless> yes, SHOULDNT_HAPPEN would be better
[16:30:09] * Darke will define that too and just set it to assert(false) for the moment.
[16:30:20] <Colourless> yeah, something that is semi-recoverable, which might indicate a worse problem
[16:30:34] <Colourless> such as possible corrupt data files or something
[16:32:03] * Darke nods.
[16:39:12] <Colourless> I know a 'great' feature... only allowing people to change rendering modes and devices at program start up! ;-)
[16:40:33] <Colourless> you actually probably wouldn't realize how 'annoying' it can be to allow changing rendering devices while a program is running
[16:41:11] <Colourless> i am actually amazed that it works as well as it does in the 'old' pentagram sources
[16:44:05] * Darke nodnods and has no problem with people 'only' being able to change rendering modes and such at the 'main menu' thing we're planning.
[16:48:30] <Darke> It's what most games do anyway, I can only think of a few exceptions, all of them FPSes, that allow you to change resolution from anywhere other then the title screen.
[16:48:43] <Colourless> yes. that would mostly be ideal i think
[16:48:54] <Darke> And even with fpses, most effectively reload the level you're on anyway. *grin*
[16:50:23] <Colourless> now, my idea with things, which would sort of allow changing of the devices in game would be to have a function and a 'RecreateRenderSurface()' function for each gump.
[16:51:05] <Colourless> the idea of course is that each gump might have a private render surface that contains something else. For example the GameWorldGump would contain a render surface that the world is rendered too
[16:51:48] <Colourless> the type of RenderSurface that the GameWorldGump uses would either be a SubRenderSurface, or a ScaledSubRenderSurface
[16:53:18] <Colourless> the problem with having persitent RenderSurfaces for each gump is the SubRenderSurfaces will inherit from the 16bit/32bit/OpenGL RenderSurface class
[16:53:44] * Darke nods.
[16:53:50] <Colourless> and if a mode change occurs, things will either not work, or would be really messy to work around
[16:54:37] <Colourless> and I don't like the idea of having to create and delete render surfaces each frame. It's a overhead that is just not needed
[16:55:26] <Darke> Makes sense.
[16:56:02] <Colourless> i of course have many a crazy idea about 'plug-in' support. whether it be plug-in scalers, or plug-in render devices, or plug-in audio devices and so on... but i don't think we 'really' need them, but I might still create some specs for them anyway :-)
[16:58:00] <Colourless> plugs of course would be handled in a somewhat system specific way, unless someone wanted to write really really slow plugins in usecode :-)
[17:01:02] * Darke cackles! He thinks not. *grin*
[17:29:00] * Darke figures other plugins, like AI or items, could be scripted in usecode, but definately not something like an audio plugin. *grin*
[17:37:37] <Colourless> should be going now
[17:37:39] <Colourless> cya
[17:37:42] <-- Colourless has left IRC ("casts invisibility")
[18:26:43] --- Darke is now known as DarkeZzz
[20:22:54] <-- Matt_O has left IRC (Read error: 60 (Operation timed out))
[20:43:51] --> Matt_O has joined #exult
[21:21:34] --> wjp has joined #exult
[21:21:34] --- ChanServ gives channel operator status to wjp
[21:21:36] <wjp> hi
[22:19:15] <-- wjp has left IRC ("gtg")
[22:43:05] --> Dark-Star has joined #exult