#pentagram@irc.freenode.net logs for 20 Jan 2004 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[03:53:04] <watt> Crap.. spent a lot of time figuring out what I thought I just messed up only to find that the problem was in the mouse patch..
[04:08:46] <watt> and appears to be in wjp's cvs snapshots as well...
[04:18:43] <watt> but works in anony cvs which hasn't caught up to the current cvs.... so yeah.. it was my last patch.. hmmm let's see what I did wrong
[04:18:47] * watt bonks
[04:22:03] <watt> oh.. I'm stupid.. need a break; in HIDManager::getBinding between the key and mouse cases.
[04:34:06] <watt> yup that worked
[05:34:15] <watt> well.. I managed to create a RotationalMoverProcess... except it doesn't play friendly with AvatarMoverProcess running at the same time
[09:52:33] --> SB-X has joined #pentagram
[11:13:38] <wjp> watt: I just added that break in cvs
[11:50:27] --> shinji-kun has joined #pentagram
[12:25:07] <-- Kirben has left IRC ("brb")
[12:46:58] --> sbx has joined #pentagram
[12:46:58] <-- SB-X has left IRC (Read error: 54 (Connection reset by peer))
[13:03:44] --> EsBee-Eks has joined #pentagram
[13:03:45] <-- sbx has left IRC (Read error: 104 (Connection reset by peer))
[13:04:17] --- EsBee-Eks is now known as SB-X
[13:12:34] <-- SB-X has left IRC (Read error: 104 (Connection reset by peer))
[13:12:38] --> SB-X has joined #pentagram
[13:55:48] <watt> coo
[14:02:15] --> Kirben has joined #pentagram
[14:02:20] --- ChanServ gives channel operator status to Kirben
[14:16:00] --> Colourless has joined #Pentagram
[14:16:00] --- ChanServ gives channel operator status to Colourless
[14:17:11] <Colourless> hi
[14:18:39] <wjp> hi
[14:46:21] <-- Kirben has left IRC ("System Meltdown")
[14:48:41] <-- wjp has left IRC ("bbl")
[15:26:09] --> wjp has joined #pentagram
[15:26:09] --- ChanServ gives channel operator status to wjp
[16:15:56] --> sbx has joined #pentagram
[16:15:57] <-- SB-X has left IRC (Read error: 54 (Connection reset by peer))
[18:27:47] <-- sbx has left IRC (Read error: 104 (Connection reset by peer))
[19:06:19] --> SB-X has joined #pentagram
[19:27:00] --> sbx has joined #pentagram
[19:27:00] <-- SB-X has left IRC (Read error: 104 (Connection reset by peer))
[19:46:54] --> EsBee-Eks has joined #pentagram
[19:46:54] <-- sbx has left IRC (Read error: 104 (Connection reset by peer))
[19:48:34] <wjp> Colourless: that recent talk about custom fonts for Exult made me think about using SDL_ttf in pentagram
[19:48:39] <wjp> should be fairly easy to do
[19:51:25] <wjp> you'd be able to override fonts from u8fonts.flx with a .ttf font
[19:51:43] <wjp> would need (at least) .ttf file, point size, text colour, border size, border colour
[20:00:23] <wjp> although it doesn't help that the font drawing routines are in RenderSurface
[20:01:11] <wjp> the actual drawing of a Font is delegated to the shape drawing functions of a RenderSurface, so it would be acceptable to move PrintChar/PrintText from RenderSurface to Font
[20:06:11] <-- shinji-kun has left IRC (""Baka!" - Asuka-chan")
[20:08:32] <wjp> I was thinking of changing the Font class into a superclass for ShapeFont and TTFFont
[20:08:53] <wjp> ...where ShapeFont would be the current Font, and TTFFont a Font using SDL_ttf
[20:09:59] <Colourless> in theory it would 'probably' be fine. I'd need to know how SDL_ttf works though
[20:10:24] <wjp> the SDL_ttf.h header is fairly self-explanatory
[20:11:02] <wjp> you load a .ttf at a given pointsize into a TTF_Font structure
[20:11:12] <wjp> then you can render a given text into an SDL_Surface
[20:11:29] <wjp> it accepts 'text', utf-8 and unicode input
[20:11:34] <Colourless> ah ha, and there in lies the 'problem'
[20:12:04] <Colourless> it will force software rendering via sdl
[20:12:25] <wjp> well, that depends on what you do with the SDL_Surface
[20:12:38] <wjp> hm, I phrased that earlier comment a bit sloppily
[20:12:46] <wjp> it creates a new SDL_Surface with the text in it
[20:13:24] <wjp> (either an 8 bit indexed one or a 32 bit RGBA)
[20:14:26] <wjp> ...so I would guess that in software mode you could blit the text to the screen surface (although it may need to be done a bit differently to add a border)
[20:14:58] <Colourless> does it support antialiasing?
[20:15:09] <wjp> "Create a 32-bit ARGB surface and render the given glyph at high quality,
[20:15:14] <wjp> using alpha blending to dither the font with the given color."
[20:15:44] <Colourless> well, i guess it's features will be pretty much those of freetype, since that is what it uses
[20:18:56] <wjp> hm, so we have a bit of a complex dependency between the rendersurface and the font
[20:19:40] <wjp> so there might not be a way to fully separate the different fonts and different rendersurfaces
[20:20:22] <Colourless> idea of how things 'generally' work is it. Draw into a temporary buffer, alpha blit that to the screen and repeat
[20:20:49] <wjp> how would you do borders, if at all?
[20:20:49] <-- EsBee-Eks has left IRC (Read error: 104 (Connection reset by peer))
[20:21:00] --> EsBee-Eks has joined #pentagram
[20:21:21] <Colourless> there is an 'icky' way of doing it
[20:21:58] <wjp> loop over the to-be-blitted surface and draw black pixels around it, and then finally alpha-blit? :)
[20:22:01] <Colourless> you redraw the font 6 times.... 5 times black (normal pos, left 1 pixel, up 1 pixel, right 1 pixel, down 1 pixel) and the final coloured pass
[20:22:08] <wjp> ah
[20:22:30] <wjp> that would you'd at least also get an AA border
[20:22:59] <Colourless> it's also 'really' slow in software doing it that way :-)
[20:23:04] <wjp> :-)
[20:23:13] <wjp> well, the amount of text we have should be fairly limited
[20:23:45] <wjp> and if necessary we could cache the text+borer
[20:23:49] <wjp> s/borer/border/
[20:27:11] <Colourless> you can also do it with out the actual drawing too
[20:27:26] <Colourless> you can do a special 'blit' that will add the border
[20:27:33] <Colourless> (read 5 pixels at a time)
[20:27:59] <Colourless> just replicate the behaviour of the shifts
[20:28:35] <Colourless> speed should be 'ok'
[20:29:50] <Colourless> using the 'shaded' render mode in SDL_ttf would be best
[20:30:03] <Colourless> no point going to bit mode if we'd be blending ourselves
[20:30:09] <Colourless> s/bit/32bit/
[20:31:36] <Colourless> for more speed Solid could be used instead. In fact rendering solid with a border would actually be pretty fast
[20:31:39] <Colourless> (releative)
[20:36:41] <Colourless> ideal way of doing things:
[20:37:11] <Colourless> the gump that owns that is displaying the text would get the SDL_Surface
[20:37:41] <Colourless> it would request the render surface to convert that into a Texture object (for opengl)
[20:38:17] <Colourless> the gump would then keep the Texture for rendering over multiple frames
[20:38:54] <Colourless> the RenderSurface classes would be extended to support the special text rendering modes from the Texture object
[20:43:11] <wjp> hm, I see
[20:48:51] <Colourless> you know, i wouldn't object to any suggestions to make pentagram unicode... :-)
[20:49:49] * wjp suggests making pentagram utf-8 :-)
[20:50:51] * wjp wonders how the french/german strings are encoded
[20:52:33] <Colourless> hey automatic conversion of odd encoded multibyte usecode strings into unicode/utf-8 wouldn't be such a terrible idea
[20:53:14] <Colourless> and we could extend our usecode to be native unicode :-)
[20:57:22] <wjp> it would just be a bit of a hassle when working with the original u8 fonts
[20:57:38] <Colourless> well, no it wouldn't
[20:57:40] <wjp> unless we make unicode-to-fontindex tables
[20:58:08] <Colourless> remember 'conversion' stage
[20:58:32] <Colourless> convert the original fonts encoding into something compatible with unicode
[21:04:46] <wjp> come to think of it, I know fairly little about unicode and fonts
[21:05:26] <wjp> is it a matter of assigning a single font glyph to each unicode char?
[21:05:41] <Colourless> afaik that is how it works
[21:06:08] <Colourless> but there are other complexities involved
[21:06:31] <Colourless> such as multiple glyphs can be combined into a single character
[21:06:54] <wjp> fun fun fun :-)
[21:07:26] <wjp> of course that's not something that we'd have to handle with the u8 fonts
[21:07:35] <Colourless> well no
[21:07:43] <wjp> and freetype would take care of it with .ttf's
[21:07:54] <Colourless> biggest problem with unicode is the huge range of characters
[21:08:39] <wjp> utf-8 is a fairly elegant solution to one side of that problem
[21:08:44] <Colourless> pretty much you need to construct your font's character table as a table of tables, where only used ones are actually allocated
[21:09:28] <Colourless> if you want to know all about unicode go to http://www.unicode.org :-)
[21:10:25] <wjp> given that 'related' unicode chars are assigned in blocks, that should work fairly well
[21:12:01] --> Cashman has joined #pentagram
[21:13:12] <Cashman> hmm yeah there are spoons :-(
[21:13:28] <Colourless> that is unconfirmed
[21:14:03] <Cashman> :-P
[21:14:28] <wjp> I mean, that thing in my teacup _looks_ like a sppon, but how can I be sure it actually exists?
[21:14:50] <Colourless> yeah well a sppon isn't a spoon
[21:14:57] <wjp> see
[21:15:08] <Cashman> yeah thats true I guess - everything we humans know us by trial and error really, we are based on science
[21:15:17] <wjp> another possibly occurence of a 'spoon' disproved
[21:16:33] <Cashman> human science that is, not superior science, heh the true superior of existance is just as much of a mind game as the spoon or could you say its the same thing
[21:17:16] <Colourless> wjp: unicode char codes that are probably relevant to the game fonts http://www.unicode.org/charts/PDF/U0000.pdf http://www.unicode.org/charts/PDF/U0080.pdf
[21:17:32] <-- Cashman has left IRC ()
[21:18:53] <wjp> judging by the numbers those would be low-ascii and various accented forms?
[21:19:02] <Colourless> yep
[21:19:34] --> Cashman has joined #pentagram
[21:19:40] <Colourless> all of the relevant chars would be in the 0-FF range
[21:19:55] <wjp> unless we'd need runic or gargish or something :-)
[21:20:00] <Cashman> hey any of u guys had experience wif wireless Access points, anyone know whats a recommended one??
[21:20:14] <Cashman> I hear that the dlink ap900+ can be crappy
[21:20:16] <wjp> Cashman: sorry, never used any
[21:20:42] <Cashman> ok, yeah I'm new to this stuff, I think darke might know - hopefully I can catch him sometime
[21:21:06] <Colourless> wjp: well i'm pretty sure gargish has a character sheet in the 'user' range
[21:21:54] <wjp> yeah, me too
[21:22:02] <Colourless> http://www.evertype.com/standards/csur/gargoyle.html
[21:22:44] <Cashman> heh nice guys :-P
[21:22:53] <Colourless> http://www.evertype.com/standards/csur/ophidian.html <- note this is actaully one of the more complex sheets :-)
[21:23:25] <wjp> hm, 'conjoining' characters
[21:23:52] <wjp> I wonder if there are any fonts that actually supply these
[21:24:08] <wjp> (properly; not like those I've seen that just replace the latin a-z)
[21:24:59] <wjp> hm, Gargoyle is listed as registered while ophidian is just a proposal
[21:25:05] <Colourless> yeah
[21:25:13] <-- Cashman has left IRC ()
[21:25:52] <wjp> U16A0 has runic
[21:26:05] <wjp> hard to tell if it has all the glyphs used in ultima, but I see quite a few
[21:31:46] <Colourless> doesn't have all of them
[21:32:02] <wjp> I think I don't see hur
[21:32:48] --> sbx has joined #pentagram
[21:32:48] <-- EsBee-Eks has left IRC (Read error: 104 (Connection reset by peer))
[21:32:53] <Colourless> but the repersentation in ultima might just be different
[21:33:05] <Colourless> look at the character names on the second page
[21:33:10] <wjp> yeah, I know
[21:33:25] <wjp> Ultima's runic is not "real" runic
[21:33:31] <wjp> although it's close
[21:33:37] <Colourless> yeah
[21:34:15] <Colourless> it's actually 'real' close
[21:34:38] <Colourless> i'm pretty sure RG had a source for the char mappings
[21:34:59] <wjp> yeah, the chance of getting it accidentally almost right is fairly small :-)
[21:36:11] <Colourless> there are a few 'big' mistakes though. such as the ultima character for EE should actually be the character for 'NG'
[21:38:43] <Colourless> ultima's X is also badly wrong (Runic Letter for CALC)
[21:39:53] <Colourless> Y may or may not be right. Ultima may use a different representation of the character
[21:40:26] <Colourless> W is wrong RUNIC LETTER HAEGL H
[21:41:19] <wjp> hm, and ultima H is 'WUNJO WYNN W'
[21:41:25] <wjp> (I guess I just missed hur earlier :-) )
[21:42:16] <wjp> so they apparently swapped 'W' and 'H' (or something W-like and something H-like, at least)
[21:42:24] <Colourless> yeah
[21:43:59] <Colourless> Ultima Q is real K
[21:44:17] <Colourless> s/real K/KAUN K/
[21:53:18] --> EsBee-Eks has joined #pentagram
[21:53:19] <-- sbx has left IRC (Read error: 54 (Connection reset by peer))
[21:55:47] <wjp> btw, was the SDL_Surface->Texture thing you mentioned earlier meant for opengl only or for the software renderer as well?
[21:55:48] <EsBee-Eks> "Damn you IRC! Daaamnn yyooouuu!"
[21:56:01] <Colourless> both
[21:56:22] <wjp> so the ShapeFont renderer would also initially render into an SDL_Surface?
[21:56:24] <Colourless> though software would actually just use the SDL_Surface (texture would just 'wrap' it)
[21:57:03] * wjp notices there already is a Texture class
[21:57:17] <Colourless> yeah but it's not quite how i want it yet :-)
[21:57:25] <Colourless> sort of inflexible :-)
[21:57:29] <wjp> mind if I leave the Texture class to you? :-)
[21:57:42] <Colourless> not a problem :-)
[21:57:56] <Colourless> thing about shapes vs TTF is the shape fonts don't need borders and stuff done
[21:58:05] * wjp nods
[21:58:33] <wjp> hm, one annoying thing about SDL_ttf is that it doesn't add any empty space around the actual text in the surface
[21:58:43] <Colourless> that isn't really a problem
[21:59:07] <wjp> not a problem, no; just annoying :-)
[21:59:18] <wjp> adds an extra copy pass
[21:59:28] <Colourless> why?
[21:59:29] <wjp> although that probably can be done efficiently when 'bordering'
[21:59:47] <Colourless> yeah not having a border can actually be faster :-)
[22:00:28] <Colourless> since if you are reading 5 pixels at a time, the top-1 and bottom+1 lines would only read one pixel, top and bottom would read 4
[22:01:59] * wjp wonders how efficient adding a border can be done (minimizing number of pixel reads and writes)
[22:02:35] <wjp> hm, for that matter, how exactly does a adding a border work with a 'shaded' text?
[22:02:40] <Colourless> fairly efficent actually
[22:02:42] <wjp> s/a //
[22:03:10] <Colourless> you only try to add a border if the centre pixel isn't completely opaque
[22:03:12] <wjp> (specifically: do you want to AA the border itself)
[22:03:58] <Colourless> you treat shaded text as an alpha channel
[22:04:39] <Colourless> if you don't want to bother with AAing the border drawing could be quite quick
[22:04:58] <Colourless> anyway things would work like this:
[22:06:28] <Colourless> if (centre_pixel != 255) calculate a black border pixel and blend centre with it
[22:07:04] <Colourless> calculating a border pixel would probably involve adding the values for of the 4 surrrounds and the centre and averaging or something simliar
[22:08:13] <Colourless> the black border + centre blend would be like this: black * inverse_center + colour * center
[22:08:33] <Colourless> (assuming shaded as alpha)
[22:08:48] <wjp> so we'd let SDL_ttf draw in pure white?
[22:08:57] <Colourless> yes
[22:23:51] <wjp> the option to have a border larger than 1 pixel wide would be nice too
[22:24:10] <wjp> (the crusaders had twice the resolution of U8, didn't they?)
[22:24:35] <wjp> so a two-pixel border there might be appropriate
[22:25:22] <Colourless> yeah probably
[22:26:34] <wjp> might take some experimentation, but I doubt that that'll pose any fundamental problems
[23:02:47] <-- EsBee-Eks has left IRC (Read error: 104 (Connection reset by peer))
[23:24:13] <-- Colourless has left IRC ("casts invisibility")
[23:39:53] --> Kirben has joined #pentagram
[23:39:53] --- ChanServ gives channel operator status to Kirben