From Allegro Wiki
Sep 01 06:04:46 <elias> well, let's see if tjaden or Matthew turn up in the next half hour or so :)
Sep 01 06:05:07 <zap0> indeed.
Sep 01 06:06:19 <zap0> buzz me if anything happens, im getting back to hacking.
Sep 01 06:26:22 <trentg> Should've posted a reminder to the list I guess
Sep 01 06:32:11 <juvinious> ooh another meeting
Sep 01 06:37:12 <elias> ah, yes, reminder might have been good
Sep 01 06:37:22 <elias> anyway, there wasn't much up for discussion anyway
Sep 01 06:38:01 <elias> finalizing gfx api (palettes/blenders/text) is up to trentg and me anyway it seems
Sep 01 06:38:22 <juvinious> well, I just listen in to the meetings most of the time, I don't have much to contribute ::)
Sep 01 06:38:35 <elias> and for 4.3.10, hopefully someone will start working on it at some point, i don't feel like it right now myself :)
Sep 01 06:39:58 * Tomasu (n=moose@S0106000c765956b8.ed.shawcable.net) has joined #allegro-dev
Sep 01 06:40:04 * ChanServ gives voice to Tomasu
Sep 01 06:40:39 <zap0> i would like to know if YUV surfaces are on the horizon ?
Sep 01 06:40:46 <Tomasu> yup
Sep 01 06:41:09 <Tomasu> at least they were with Bob's api. I wonder if the new derived suggestions will? I hope so.
Sep 01 06:41:18 <zap0> in order to see them, do i need a telescope, my naked eye, or hubble ?
Sep 01 06:41:20 <elias> http://wiki.allegro.cc/NewAPI/Display#al_set_new_display_format
Sep 01 06:41:28 <elias> should be no problem adding other formats there
Sep 01 06:41:58 <elias> right now they are just some random formats
Sep 01 06:41:59 <Tomasu> afaik, the dx9 code already supports most/all of those...
Sep 01 06:42:26 <Tomasu> I'm sure though that a few YUV formats are a given if we can get someone knowlegable
Sep 01 06:42:54 <Tomasu> yv12, yuy2 etc
Sep 01 06:43:05 <trentg> dx9 doesn't support most of those formats, unfortunately, but the memory bitmaps support all of them.
Sep 01 06:43:11 <zap0> 12 and yuy2 at minimum
Sep 01 06:43:23 <Tomasu> trentg: right, most cases all you'll get is support in mem.
Sep 01 06:43:37 <Tomasu> though can we get video overlays supported?
Sep 01 06:43:39 <trentg> I don't know anything about yuv, so don't look at me :)
Sep 01 06:43:41 <Tomasu> xv does tuv
Sep 01 06:43:47 <Tomasu> *yuv
Sep 01 06:43:53 <elias> should drawing to such surfaces also work?
Sep 01 06:44:17 <elias> like, should line(..., makecol(255, 0, 0)) translate to some YUV color?
Sep 01 06:44:21 <zap0> it'd be nice, but that'd be alot more work.
Sep 01 06:44:33 <Tomasu> well, for video overlays, only one operation needs supported, putimage/putvideo
Sep 01 06:44:51 <Tomasu> but hmm
Sep 01 06:45:02 <zap0> most of the time when dealing with YUV, you only deal with whole surface blitting (as Tomasu just said).
Sep 01 06:45:05 <Tomasu> I think for yuv, wouldnt you use the proper color format?
Sep 01 06:45:29 <elias> maybe it could just be a set of special functions, sort of an addon
Sep 01 06:45:51 <Tomasu> well yuv support aught to be included at least imo.
Sep 01 06:46:07 <Tomasu> overlay support can be an adon, but gl is going in why not overlays? I can do the xv code ;)
Sep 01 06:46:39 <Tomasu> of course xv is becoming more and more outmoded..
Sep 01 06:46:56 <Tomasu> with drivers typically just using gl overlays and pretending its a video overlay
Sep 01 06:47:56 <elias> for now, i hope the base gfx api will soon be done, with a D3D and X11/OpenGL implementation
Sep 01 06:48:04 <Tomasu> ja
Sep 01 06:48:15 <elias> then if anyone wants to add YUV, it will be the right time to show up and implement it
Sep 01 06:48:29 <trentg> So we can decide now, I guess, whether to include palettes and text output
Sep 01 06:48:40 <elias> else it can go into 5.2.0 (in case API incompatibilities need to be done)
Sep 01 06:48:42 <Tomasu> hmm
Sep 01 06:49:02 <Tomasu> text output can be a separate lib for all it maters.
Sep 01 06:49:04 <trentg> I think everyone said palettes can go
Sep 01 06:49:18 <Tomasu> palette support will be missed by some people..
Sep 01 06:49:19 <trentg> Text output is best done with a ttf addon I think
Sep 01 06:49:23 <Tomasu> not that I care.
Sep 01 06:50:14 <elias> if text output is an addon, this boils down again to the question what is an "addon"
Sep 01 06:50:32 <elias> likely, we want the "standard download" of allegro to support text (TTF, probably also bitmap fonts)
Sep 01 06:50:48 <Tomasu> well stuff like the pack_ stuff is going into an extra lib in my branch, not in adons/ though, probably in lib/
Sep 01 06:50:52 <juvinious> bitmap'd fonts are easier than ttf
Sep 01 06:51:12 <elias> yeah, bitmap fonts can be completely done on top of the blitting API, in a platform independent way
Sep 01 06:51:14 <Tomasu> -lalpackf or some such
Sep 01 06:51:22 <zap0> everything technically should be an addon, but for those that want everything, there *ALWAYS* needs to be a clear and easy to find package that has everything intergrated.
Sep 01 06:51:27 <trentg> I think we should still have essential addons as "official" ones, included with the distro but optional to build
Sep 01 06:51:35 <Tomasu> quite.
Sep 01 06:51:41 <Tomasu> thats the point to having the adons dir
Sep 01 06:52:01 <juvinious> as for ttf implementations there are quite a handfull
Sep 01 06:52:04 <Tomasu> things like lodepng/loadpng, aljpeg, alogg or what have you
Sep 01 06:52:10 <trentg> It would be nice if someone else stepped in and wrote some of those addons though :)
Sep 01 06:52:25 <Tomasu> most already are ;)
Sep 01 06:52:38 <trentg> The api is different from 4.2 though
Sep 01 06:52:45 <Tomasu> ah well, true.
Sep 01 06:53:02 <trentg> We also still need the sound api/drivers
Sep 01 06:53:09 <Tomasu> yup..
Sep 01 06:53:13 <Tomasu> not sure where that's heading anymore
Sep 01 06:53:19 <juvinious> I thought kitty had a openal implementation
Sep 01 06:53:39 <elias> yeah, and mimix added an alsa driver to his stuff i think
Sep 01 06:54:06 <juvinious> is midi support carrying over?
Sep 01 06:54:09 <trentg> It would be nice to have dsound and whatever mac uses too
Sep 01 06:54:25 <elias> http://wiki.allegro.cc/NewAPI/Sound
Sep 01 06:54:33 <Tomasu> guh, digimid should die.
Sep 01 06:54:43 <Tomasu> its such a hair ball...
Sep 01 06:54:49 <juvinious> heh, it's a pita :P
Sep 01 06:55:06 <elias> and a dsound driver
Sep 01 06:55:17 <elias> and yes, midi will be an addon
Sep 01 06:55:21 <juvinious> cool
Sep 01 06:55:26 <Tomasu> now if entheh had the time, I bet he could do some AWESOME work on a digimid driver.
Sep 01 06:55:28 <elias> likely, using timidity
Sep 01 06:55:44 <elias> unless someone wants to salvage the digmid code as addon, or write a new midi synthesizer
Sep 01 06:56:03 <Tomasu> I think it can probably wait anyhow
Sep 01 06:56:04 <elias> yeah, entheh worked a long time on his XMAS.. so i'd say, it's not an easy task
Sep 01 06:56:17 <elias> better just use timidity, if someone needs software midi
Sep 01 06:56:28 <Tomasu> well he didnt exactly actually work that much on it, and he was never happy with the structure
Sep 01 06:56:37 <elias> ah
Sep 01 06:56:38 <MattyMatt> I've got a speech synth written. that has a lot in common with midi
Sep 01 06:56:54 <elias> speech synth also would be a nice addon :)
Sep 01 06:57:20 <zap0> speech on win32 is fairly trivial.
Sep 01 06:57:20 <elias> (of course, if people do something like an RPG where the speech synth reads the text.. i'm not sure it would add a lot to the game :P)
Sep 01 06:57:21 <MattyMatt> it needs a dictionary or text-to-speech
Sep 01 06:58:14 <MattyMatt> but anyway. add-on first
Sep 01 06:58:23 <Tomasu> ja
Sep 01 06:58:45 <Tomasu> I've started collecting some adons that should make it into the "adons/" dir
Sep 01 06:59:03 <elias> on a wiki page?
Sep 01 06:59:10 <Tomasu> not yet.
Sep 01 06:59:16 <Tomasu> some are in my svn, and some are just on disk.
Sep 01 06:59:38 <Tomasu> so far I only have some rare'er items. allegpeg, alspc, and logg
Sep 01 06:59:47 <elias> anyway, for text output..
Sep 01 06:59:58 <Tomasu> adon. imo.
Sep 01 07:00:13 <juvinious> I have a ttf implementation that could be considered for an addon
Sep 01 07:01:29 <elias> different text addons likely can share some code, e.g. unicode related stuff
Sep 01 07:02:02 <elias> but probably there should be at most two (one for ttf, one for bitmapped)
Sep 01 07:02:06 <Tomasu> well, allegro depends on its unicode routines internally
Sep 01 07:02:06 <elias> so no big issue
Sep 01 07:02:14 <Tomasu> so it cant be separated
Sep 01 07:02:39 <elias> if we have no more text output, the only place which needs unicode is the filesystem stuff
Sep 01 07:02:46 <elias> in the core, i mean
Sep 01 07:03:02 <Tomasu> and all the drivers and error messages...
Sep 01 07:03:18 <Tomasu> allegro uses the conversion functions all over the place
Sep 01 07:03:19 <elias> we have no error messages yet i think
Sep 01 07:03:24 <elias> A4 does, yes
Sep 01 07:03:28 <Tomasu> and I assume it will keep doing so
Sep 01 07:03:37 <Tomasu> all my code does so far...
Sep 01 07:03:41 <elias> so we will keep ustrnzscpy and all the u* stuff?
Sep 01 07:03:49 <Tomasu> dont see why not.
Sep 01 07:04:03 <Tomasu> the old codepage stuff may not be needed though
Sep 01 07:04:18 <elias> yeah, utf8 implementation seems to work good enough in A4
Sep 01 07:04:30 <elias> juvinious: does your ttf support things like RTL text?
Sep 01 07:04:33 <Tomasu> also, the i18n stuff should probably be kept...
Sep 01 07:04:34 <juvinious> how would the bitmapped fonts color if palettes are out the window?
Sep 01 07:04:50 <elias> they shouldn't color i think
Sep 01 07:04:57 <Tomasu> juvinious: a4 does full color fonts no?
Sep 01 07:05:18 <elias> that is, if they are on top of the blitting API, they can use all the blending modes
Sep 01 07:05:29 <juvinious> well true
Sep 01 07:05:34 <elias> and as for the compatibility layer - if it is for me, we forget about that
Sep 01 07:05:45 <Tomasu> heh
Sep 01 07:05:48 <elias> if someone wants to implement the A4 API on top of A5, then fine
Sep 01 07:05:50 <Tomasu> well it wont happen if noone does it
Sep 01 07:05:51 <elias> but i won't worry about it
Sep 01 07:05:54 <juvinious> hmm, RTL? is that unicode stuff?
Sep 01 07:05:54 <Tomasu> ;)
Sep 01 07:06:00 <Tomasu> juvinious: right To Left
Sep 01 07:06:02 <elias> juvinious: right-to-left
Sep 01 07:06:18 <elias> e.g. in Wesnoth, they had a lot of problems with the Hebrew translation and sdlttf
Sep 01 07:06:26 <elias> so in allegro, we should do it right from the beginning :)
Sep 01 07:06:52 <juvinious> oh, well I didn't consider that stuff when I made that ttf thingy ::)
Sep 01 07:07:22 <elias> i guess it just needs a flag somewhere, and then mirror all horizontal position changes
Sep 01 07:07:51 <elias> anyway, nothing important right now as well
Sep 01 07:08:48 <juvinious> it also could probably use some optimization
Sep 01 07:09:27 <zap0> what do you think needs optimz?
Sep 01 07:09:50 <elias> in allegrogl, the whole fonts is drawn to an opengl texture (in a specific size) on loading
Sep 01 07:09:59 <elias> so it's very fast
Sep 01 07:10:19 <Tomasu> hmm
Sep 01 07:10:24 <Tomasu> even massive unicode fonts?
Sep 01 07:10:24 <elias> and can still query the freetype functions for kerning and so on
Sep 01 07:10:30 <elias> Tomasu: yes :P
Sep 01 07:10:36 <Tomasu> something like that needs to be loading ranges on demand
Sep 01 07:10:40 <elias> so, ideally, would do on-demand caching there
Sep 01 07:10:57 <juvinious> exactly what needs to be done
Sep 01 07:11:05 <elias> like, when the first japanese char is used, only then draw them all to a texture
Sep 01 07:11:13 <juvinious> I'm not using bitmaps for caching, I'm just doing pixel by pixel
Sep 01 07:11:15 <elias> and initially only keep 7-bit ascii i guess
Sep 01 07:11:24 <juvinious> so scaling can be done easily ::)
Sep 01 07:11:35 <elias> pixel by pixel will be too slow if you have a lot of text
Sep 01 07:11:40 <juvinious> exactly
Sep 01 07:11:44 <elias> in the opengl driver, putpixel is really slow
Sep 01 07:11:45 <juvinious> that's what I meant by optimization
Sep 01 07:12:12 <elias> like, putpixel takes almost as much time as a textured quad
Sep 01 07:12:30 <elias> in fact, there's likely no difference to the gfx card
Sep 01 07:12:36 <Tomasu> well nvidias is aparently fast.
Sep 01 07:12:40 <elias> if it does putpixel, it just draws a 1-pixel quad
Sep 01 07:12:42 <Tomasu> at least the ext is
Sep 01 07:13:03 <elias> yes, but so far, i'm not using any extensions :/
Sep 01 07:13:18 <elias> need to first copy over Bob's extension handling stuff from AGL
Sep 01 07:13:36 <Tomasu> and hopefully rip out some of the older stuff
Sep 01 07:16:16 <juvinious> I also would need to convert the implementation to C, which shouldn't be too hard
Sep 01 07:18:50 <juvinious> here it is: http://www.allegro.cc/files/attachment/592632
Sep 01 07:19:23 <trentg> I agree about dropping the compatibility layer
Sep 01 07:19:33 <trentg> (was walking the dog)
Sep 01 07:20:00 <trentg> There's too much that we can't do with the HW accelerated api's
Sep 01 07:20:34 <Tomasu> quite
Sep 01 07:20:50 <elias> yes, as i see it, A4 API just is designed for software, mostly
Sep 01 07:21:01 <Tomasu> does this mean I can drop the pack_ functions totally? ;D
Sep 01 07:21:16 <elias> and a lot of stuff (palettes, magic-pink-masking, ...) just isn't worth adding complicated emulation for
Sep 01 07:22:00 <zap0> magic pink masking annoys me.
Sep 01 07:22:00 <elias> and if someone is writing something like a NES emulator, they'll likely need more specialized stuff anyway and therefore implement themselves
Sep 01 07:22:00 <juvinious> it's not like the 4.2.x series is being destroyed if they need that they can use those versions
Sep 01 07:22:32 <elias> yeah, we have the 4.3.10, and the plan is that 4.4.0 will be released, with allegrogl built in
Sep 01 07:23:54 <elias> hehe, so we decided to drop the compatibility layer? then this meeting actually had a rather big result :)
Sep 01 07:24:12 <MattyMatt> that's a mighty bold step
Sep 01 07:24:53 <Tomasu> well, we haven't gotten consensus from the others..
Sep 01 07:25:19 <MattyMatt> none needed really. the compat layer needs to be written
Sep 01 07:25:33 <MattyMatt> if nobody does, then it's dropped
Sep 01 07:25:46 <Tomasu> jaj
Sep 01 07:26:08 <elias> Tomasu: well, they did not show up.. that's how decisions in the allegro government work :)
Sep 01 07:26:17 <Tomasu> lol
Sep 01 07:26:42 <Tomasu> just wait, peter will chime in with "when did _we_ say that?" or "who is we?" ;)
Sep 01 07:26:45 <MattyMatt> hah governmemnt. we can't make anyone do anything :)
Sep 01 07:27:03 <elias> hm, and Evert can veto anything
Sep 01 07:27:33 <Tomasu> well, he _can_ but everyone else can veto the veto :P
Sep 01 07:29:37 <MattyMatt> my vector rendering could eventually lead to a freetype-free ttf, but I wouldn't count on it
Sep 01 07:29:53 <Tomasu> freetype is a mighty complex beast
Sep 01 07:30:30 <MattyMatt> yeah but the ttf aren't too bad
Sep 01 07:31:28 <Tomasu> freetype is complex because it tries to do things "properly" ;)
Sep 01 07:31:38 <MattyMatt> well. it's not a trivial operation :) but I may get there one day
Sep 01 07:35:37 <Tomasu> and I may get all 40 of my "in progress" projects done one day ;)
Sep 01 07:35:41 <juvinious> could also basically copy the ttf renderer that is in the nehe tutorials
Sep 01 07:36:57 <MattyMatt> freetype is fine for me
Sep 01 07:38:10 <juvinious> erm eyah it's using teh freetype
Sep 01 07:38:28 <juvinious> bleh, I need food bbiab
Sep 01 07:39:01 <MattyMatt> we have alfont and glyphkeeper to choose from as a freetype wrapper
Sep 01 07:41:34 <MattyMatt> what would go with the compatability layer? 8 bit bitmaps?
Sep 01 07:41:34 <trentg> And fudgefont
Sep 01 07:42:16 <trentg> I think 8 bit bitmaps will go with palettes
Sep 01 07:43:50 <MattyMatt> that's harsh
Sep 01 07:44:53 <trentg> masking is gone too
Sep 01 07:46:35 <zap0> yeah! no more magic pink
Sep 01 07:50:01 <Tomasu> magic pink should however be removed at all costs from any operations. and magicpink like colors
Sep 01 07:51:30 <MattyMatt> so bmp->mask_color will be user variable?
Sep 01 07:51:41 <Tomasu> more like use alpha
Sep 01 07:51:43 <elias> it will go
Sep 01 07:53:52 <zap0> camera input... for making eye-toy like games
Sep 01 07:54:16 <Tomasu> addon
Sep 01 07:54:18 <MattyMatt> it's an add-on
Sep 01 07:55:40 <juvinious> gui -> add-on?
Sep 01 07:55:54 <MattyMatt> I'd make it official if it worked tho
Sep 01 07:56:30 <MattyMatt> gui could be add-on if tools/examples can auto build it
Sep 01 07:57:18 <MattyMatt> no harm in compiling it separatly, but it's only 3 C files
Sep 01 07:57:44 <juvinious> well some of the examples will probably go or be revised if masking, palettes and 8-bit stuff goes...
Sep 01 07:58:03 <elias> and if text is an addon, all examples will require at least that addon
Sep 01 07:58:15 <MattyMatt> ah yeah, gui defo an addon in A5
Sep 01 07:58:44 <zap0> if everything is addon and not compiled as default, what is the point of allegro? how would it be any different to compiling a bunch of other (dare I say) more mature OSS libs ?
Sep 01 07:59:07 <Tomasu> there will be some "default" enabled addons. i think
Sep 01 07:59:22 <Tomasu> and others that are disabled by default.
Sep 01 08:00:18 <MattyMatt> make SUPERBLOAT
Sep 01 08:00:31 <zap0> is bloat a concern ?
Sep 01 08:00:42 <MattyMatt> not really
Sep 01 08:00:58 <MattyMatt> I think A5 should have a mesh addon
Sep 01 08:01:03 <juvinious> maybe 1% of the users may think so, but they don't count :P
Sep 01 08:01:33 <elias> yes, easy-of-use is most important to 99% of users i guess
Sep 01 08:01:38 <zap0> those 1% still runing 14k4 modems .. ;P
Sep 01 08:02:11 <elias> well, even if we take A4 and all current addons, would not even reach 10MB I think
Sep 01 08:02:27 <elias> and for A5 could be even less, as we are throwing out stuff
Sep 01 08:02:41 <elias> loadpng has like 100kb
Sep 01 08:02:52 <elias> which i guess is a typical size for A4 addons
Sep 01 08:06:21 <Tomasu> much of that is probably autocrap
Sep 01 08:06:58 <elias> i guess with cmake, each addon can be a config option
Sep 01 08:07:38 <elias> so the top-level cmake would somehow pick up the addons
Sep 01 08:07:46 <Tomasu> ja
Sep 01 08:07:48 <elias> and if you enable one, it configures it as well
