The Allegro Wiki is migrating to github at

Allegro Hack Day/2007 September 1

From Allegro Wiki
Jump to: navigation, search
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 ( 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>
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>
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:
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