[00:02:12] --> Servus has joined #pentagram
[00:26:08] --> Kirben has joined #pentagram
[00:26:08] --- ChanServ gives channel operator status to Kirben
[00:34:33] --> Dark-Star has joined #pentagram
[01:24:43] <-- Dark-Star has left #pentagram ()
[02:27:19] <-- Servus has left IRC ()
[06:10:28] --> Servus has joined #pentagram
[06:19:13] --> Cless|Away has joined #Pentagram
[06:19:23] --- Cless|Away is now known as Colourless
[06:19:25] --- ChanServ gives channel operator status to Colourless
[06:41:35] --- DarkeZzz is now known as Darke
[07:37:22] --- Darke is now known as Jett
[07:37:30] --- Jett is now known as Darke
[07:50:56] <-- Colourless has left IRC ("casts invisibility")
[11:53:35] <-- Kirben has left IRC ("System Meltdown")
[11:58:37] <-- Servus has left IRC ()
[12:11:12] --> wjp has joined #pentagram
[12:11:12] --- ChanServ gives channel operator status to wjp
[12:54:30] --> Colourless has joined #Pentagram
[12:54:30] --- ChanServ gives channel operator status to Colourless
[13:54:29] <wjp> hmm... Palette might have to be a template class, since we'll need 16 and 24/32 bit palettes
[13:54:44] <Colourless> what? why?
[13:55:02] <Colourless> i just always use uint32, since an int is an int is an int :-)
[13:55:11] <wjp> or that :-)
[13:55:12] <Colourless> just use a packed format
[13:55:55] <wjp> it'll need some logic to go from palette to pixel value then, though
[13:56:21] <wjp> but that'll go into the various forms of the softrendersurface then, I guess
[13:56:43] <Colourless> well, what I was doing was loading the palettes as 3x256 uint8s. Then the softrender surface will convert the palette into it's native format
[13:56:47] * wjp is starting to find out just how unexperienced he is with writing low/medium-level graphics stuff :-)
[13:57:20] <wjp> how would that work with each shape having its own palette?
[13:57:41] <Colourless> i probably wasn't going to allow that....
[13:57:45] <wjp> ah :-)
[13:58:24] <wjp> my idea on this was to give each shape a Palette*, with most of the shapes pointing to the same palette
[13:58:49] <wjp> then you could probably have the softrendersurface construct the palettes itself, anyway
[13:58:52] <Colourless> should in theory be fine, as long as the palette doesn't change
[13:59:07] <Colourless> OpenGL + palette changes are not a good mix
[13:59:19] <wjp> hm
[13:59:44] <wjp> how does this work in opengl?
[13:59:49] <wjp> do textures have palettes?
[13:59:52] <Colourless> will require all the shapes be reloaded
[13:59:57] <wjp> painful
[14:00:17] <Colourless> textures can not have palettes, except for mostly only 3dfx cards
[14:00:23] <wjp> but opengl has other ways of doing day/night effects, I guess
[14:00:30] <Colourless> yes indeed
[14:00:38] <wjp> um, come to think of it, did U8 have those?
[14:00:45] <Colourless> u8 didn't
[14:00:55] * wjp seems to remember something about Tenebrae, the city of eternal twilight :-)
[14:01:19] <Colourless> it did some palette effects, but only with the storms and rain of fire, and the mushrooms
[14:01:52] <Colourless> the storms and rain of fire were just palette fades though
[14:01:56] <wjp> ah, right, the... what's the word... bright-flashy-weirdness mushrooms
[14:02:32] <Colourless> and the effect can easily be done with a transparent polygon drawn over the screen
[14:02:43] <Colourless> as for the mushrooms, we'll need to do a different effect for them :-)
[14:02:45] <wjp> we'd have to abstract away those effects, I guess
[14:03:18] <wjp> with the softrendersurface-type renderers using palettes or maybe some postprocessing, and the opengl-type ones using custom effects
[14:03:46] <wjp> hm, I think psychodelic was the word I was looking for with the mushrooms
[14:03:53] <Colourless> yeah
[14:04:29] <wjp> or psychedelic, apparently :-)
[14:05:53] <wjp> any idea how much of a performance penalty it would give if we used a palette for each shape (even if most shapes would have the same palette anyway)
[14:05:56] <wjp> ?
[14:06:17] <Colourless> other than memory requirements, i doubt very much at all
[14:07:02] <wjp> just an extra indirection or function call per shape to get the palette I guess
[14:07:25] <Colourless> the idea that i mostly had is all the graphics related resources would have pretty much 2 sets of data
[14:07:57] <Colourless> one set would be the native format of the data loaded into memory. the other set would be data that is for the graphics driver only
[14:08:19] <Colourless> for opengl this would include things like the OpenGL texture the shape is in, the coords in the texture for the frame and such things
[14:08:26] * wjp nods
[14:08:51] <Colourless> for softrendersurface this could have things like, the native format palette
[14:09:03] <Colourless> the best idea for the palettes, would be to have a palette manager
[14:09:22] <Colourless> this way there wouldn't be n-duplicates of the palettes for each shape
[14:09:29] <Colourless> it would also simplify opengl too
[14:09:43] <wjp> yeah, I was definitely planning on having all shapes point to the same palette
[14:09:51] <wjp> (or most shapes, anyway :-) )
[14:10:30] <Colourless> ideally being able to cross link shapes and palettes would be a nice idea so if a palette change occurs, all of the shapes are then automatically updated
[14:10:45] * wjp nods
[14:11:22] <wjp> all 'world' shapes would share a palette that could be darkened (or whatever)
[14:11:46] <Colourless> the most efficent way of doing it, even though it's not the C++ way, would be to use a linked list for the shapes
[14:12:14] <Colourless> when a shape is assigned a palette it is added to the linked list. allows for quick easy removal from the list
[14:12:28] <Colourless> also doesn't require much extra memory, nor is addition expensive
[14:14:22] <wjp> hm, I may have been mixing up objects and shapes a bit
[14:14:31] <wjp> do we want a palette per shape, or one per object?
[14:14:47] <Colourless> per object, is very much a nightmare
[14:15:46] <Colourless> if you want a different palette for an object, you should be forced to use a different shape, even if you obtained it by using something like ShapeManager::GetShapeAlternatePalette()
[14:16:15] * wjp nods; that's an acceptable workaround should we ever need it
[14:16:58] <wjp> only thing I can really think of would be the current saveload screen in U7, which has character shapes in it
[14:17:27] <wjp> (you'd want the character shapes + rest of GUI to be in a normal bright palette, even if the rest of the world is dark)
[14:18:19] <Colourless> well, you'd probably run all the GUI using a specific palette
[14:18:58] <Colourless> got go to go for a bit
[14:18:59] --- Colourless is now known as Cless|Away
[14:19:38] <wjp> hm, come to think of it, I'm rather hungry :-)
[14:19:53] <wjp> (i.e., lunchtime :-) )
[14:58:23] --- Cless|Away is now known as Colourless
[14:59:26] <wjp> wb
[15:32:46] * Darke wonders why the text being send to Item::bark() always has a space at the end of it.
[15:36:39] <Darke> Actually, it's not *always* just about... 99% of the time.
[15:37:23] <Colourless> bah, then why bring it up. can't you see, there is no reason :-0
[15:38:04] <wjp> they have painstakingly looked at every instance of Item::bark(), and decided if the alignment looked better with or without a trailing space, I bet :-)
[15:38:58] <Colourless> well, are the messages centered over the npcs?
[15:39:03] <Colourless> i honestly can not remember
[15:39:06] <Darke> Because it's... odd? *grin* Things like "tree" are padded to "tree ", I presumed to make it 'centered' above the object, then I find "diary" padded to "diary " which invalidates such.
[15:39:50] <Darke> Even the rather wordy object names, where you wouldn't notice such like "The History of Necromancy Vol.II " are padded.
[15:40:45] <Darke> Even most of the really wordy conversations are padded with a space at the end.
[15:41:03] <Colourless> well, since you say not all are padded, give us an example of a not
[15:41:35] <Darke> 36B7: 0D push string "Invoke Pentagram"
[15:41:50] <Darke> Most of the spell names aren't padded either.
[15:42:15] <Darke> 05FE: 0D push string "HERE LIES CHEL*SOME SAY SHE*WAS A*LOVELY BELLE"
[15:42:38] * Darke ooohs, looks like they did the almost standard punny gravestone epitahs too. *grin*
[15:42:44] <Darke> They're all unpadded too afaict.
[15:42:55] <wjp> heh, you never looked at the gravestones? :-)
[15:42:58] <Colourless> almost... you mad, they are all like that
[15:43:57] <Darke> The text of: THE OFFICIAL LOGBOOK OF CRIMES AND PUNISHMENTS is also unpadded. It goes on for I don't know how many words at least 25 lines by 80 chars per line words anyway. *grin*
[15:44:25] <Colourless> what I really want to know, how did the game decide what font to use with an Item::Bark().
[15:44:28] * Darke never looked at the gravestones in u8. *grin*
[15:45:14] <Colourless> different npcs used different fonts
[15:45:15] <Darke> Hmm... what had different fonts? I presume the standard 'tree' floating descs are all in one font.
[15:47:30] <Darke> Maybe their quality? Item::bark is a function that'd have access to that value internally.
[15:47:52] <Darke> Which NPC has a different to 'normal' font?
[15:47:56] <Darke> s/NPC/NPCs/
[15:48:09] <Colourless> Avatar uses a red font, Mordea uses an orange font, devon green, shaana orange
[15:48:41] <Colourless> it 'may' be a field in the npc data file
[15:51:43] <Darke> Hmm... maybe. I'd say it'd have to be stored in a basic 'item' type somewhere since there's no indication in the usecode that you're pushing anything other then a 'normal' item.
[15:52:25] <Colourless> but quality doesn't make much sense
[15:52:41] <Darke> Admittedly though, there's nothing stopping the npc loading function from grabbing a byte from the npc data file and shoving it somewhere that Item::bark can get to it.
[15:52:41] <Colourless> any item < 256 is an npc
[15:53:11] <Colourless> and due to the way the game stored it's data, there was no differentiating NPC and normal objects
[15:53:25] * Darke nods.
[15:53:44] <Colourless> an item remember, only contained the item number
[15:54:01] <Colourless> which they then used to look up in to the data arrays
[15:54:09] <wjp> can you specialize a class member by just using U8SoftRenderSurface<uint16>::paint(Shape *s, ....) ?
[15:54:18] <wjp> (as a function definition)
[15:54:32] <Colourless> yes
[15:54:38] <Colourless> you should be able to
[15:54:39] <wjp> hm, or maybe this doesn't have to be specialized
[15:54:49] <Colourless> no, doesn't have to be
[15:55:04] <wjp> if you use pointer arithmetic on a uintX* it should 'just work'
[15:55:13] <Colourless> yes
[15:55:24] <Colourless> remember you can use sizeof(unitX) too
[15:55:42] <wjp> yes, I'll need that for the pitch
[15:56:30] <Colourless> the reason i setup the template is so the code doesn't need to be duplicated n times
[15:56:46] <Colourless> if you 'really' wanted to, you could steal the code from the old module :-)
[15:57:00] <Colourless> it might need some changes to the names of member vars though
[15:57:09] <Colourless> then again, the shape format is wrong
[15:57:26] <wjp> I'm tempted to use U8-style shapes for now
[15:57:54] <Colourless> as long as you don't do any real nasty optimizations, that's fine
[15:58:26] <wjp> the actual image data format is the same, isn't it?
[15:58:35] <wjp> so it'll just be the metadata reading that'll have to be adjusted
[15:59:01] <Colourless> yes pretty much
[15:59:21] <Colourless> yeah it's in the metadata, and data sizes. pretty much just increasing things to 32 bits
[15:59:29] <Colourless> and making some optimizations here and there
[15:59:35] <wjp> all the variables in the shape/frame classes are already 32 bits
[15:59:43] <Colourless> yes, as it should be
[16:00:34] <Colourless> remember that i wanted to remove all the byte order fudging code out of the painting funcs
[16:01:02] <Colourless> but for now, it doesn't matter much if your code still assumes and load as little endian
[16:01:17] <wjp> metadata parsing is currently in the shape/frame constructors
[16:01:33] <wjp> not entirely happy with it, but I don't want to invest too much time in it for now
[16:34:13] <Colourless> going now. cya
[16:34:16] <-- Colourless has left IRC ("casts invisibility")
[16:34:51] <wjp> *sigh*.. _of course_ it doesn't work if I don't load a palette before painting
[16:34:55] * wjp hits self
[17:23:02] <Darke> No, 'self' is only in smalltalk, IIRC.
[17:23:10] * Darke paws wjp his 'this'.
[17:23:17] <wjp> thanks :)
[17:23:20] * wjp hits *this
[17:23:48] <wjp> upgraded to Gnome 2.2 last night, btw
[17:23:52] <wjp> was relatively painless
[17:24:08] * Darke yays! Always good. *grin*
[17:24:13] <wjp> sawfish 1.2 decided to be confused about the number of workspaces I had
[17:24:21] <wjp> (it swapped rows and columns)
[17:24:27] <Darke> Probably less painful then hitting yourself with a *this though. *grin*
[17:24:31] * Darke snickers.
[17:24:32] <wjp> so that took some patching
[17:24:50] <wjp> and the silly thing checked for gtk+ 1.2 with GTK_MINOR_VERSION==2
[17:24:58] <wjp> guess what happened when I compiled it with gtk+ 2.2 :-)
[17:25:19] <Darke> Umm... not-good things I would guess. *grin*
[17:26:12] <wjp> I'm still rather confused about why gnome-terminals default to a horrible font
[17:28:16] <wjp> (at least, a horrible font for terminals; I guess it's ok for normal text)
[17:30:58] <Darke> I'd love to know why pure xterms default to such a horrible fontsize too. *grin*
[17:45:36] <wjp> bbl, dinner
[18:04:03] * Darke yawns and hops off to do this 'sleep' thing. Night!
[18:04:06] --- Darke is now known as DarkeZzz
[18:04:25] <wjp> g'night
[23:31:08] <-- wjp has left IRC ("Zzzz...")