The Allegro Wiki is migrating to github at https://github.com/liballeg/allegro_wiki/wiki

Allegro Hack Day/2007 August 04/log

From Allegro Wiki
Jump to: navigation, search
Aug 04 14:05:27 -->	tjaden (n=tjaden@22.104.233.220.exetel.com.au) has joined #allegro-dev
Aug 04 14:05:27 ---	ChanServ gives voice to tjaden
Aug 04 14:06:17 <leverton>	hello
Aug 04 14:06:24 <tjaden>	hi
Aug 04 14:06:27 <elias>	hi tjaden
Aug 04 14:06:54 <tjaden>	have you started?
Aug 04 14:07:15 <leverton>	not yet
Aug 04 14:07:20 <elias>	<elias> we could vote a new Allegro administrator..
Aug 04 14:07:20 <elias>	<Tigge> elias, what?
Aug 04 14:07:23 <elias>	so.. not really :P
Aug 04 14:07:56 <leverton>	yeah, just elais trying to push things through without a quorum ;)
Aug 04 14:08:00 <leverton>	elias
Aug 04 14:10:03 <elias>	i think there won't be anything important from my side.. nothing much new for the display API (i had no time to work on it :/).. and not sure if trentg will come
Aug 04 14:10:32 <--	leverton has quit ()
Aug 04 14:10:36 <tjaden>	i'm just here to observe :)
Aug 04 14:10:44 <tjaden>	and now matthew's gone
Aug 04 14:10:54 <elias>	yeah, as i said on the wiki, maybe each month is too often for those meetings?
Aug 04 14:10:55 <elias>	heh
Aug 04 14:11:08 -->	leverton (n=konforce@c-24-14-119-215.hsd1.il.comcast.net) has joined #allegro-dev
Aug 04 14:11:08 ---	ChanServ gives voice to leverton
Aug 04 14:11:21 <tjaden>	well, we just releases 4.2.2
Aug 04 14:11:26 <tjaden>	*released
Aug 04 14:13:06 <elias>	so, we want to open a 4.3.x branch next
Aug 04 14:13:23 <tjaden>	i did svn copy
Aug 04 14:14:16 <tjaden>	i'm also trying to merge the changes from 4.2 into the 4.9 branch, but the macosx stuff is getting in the way, as usual
Aug 04 14:14:31 <elias>	ah, i see.. doing "svn co  https://alleg.svn.sourceforge.net/svnroot/alleg/allegro/branches/4.3.10plus" right now..
Aug 04 14:14:47 <tjaden>	there's no changes in there
Aug 04 14:16:43 <elias>	we want AllegroGL, the D bindings, and the AmigaOS 4 port in there, right?
Aug 04 14:17:44 <tjaden>	AGL and D.  the other ports are optional
Aug 04 14:19:16 <elias>	i was just wondering, of something like ./configure --with-opengl would work
Aug 04 14:19:29 <tjaden>	sure
Aug 04 14:19:51 <elias>	so then make would build allegro.so and allegrogl.so
Aug 04 14:20:07 <leverton>	supporting complex configure stuff like that on Windows will (not) be fun
Aug 04 14:20:25 <tjaden>	how's cmake on windows?
Aug 04 14:21:01 <leverton>	I don't know... I was just thinking of the makefiles
Aug 04 14:21:21 <tjaden>	i think we talked about having a target: make agl
Aug 04 14:22:31 <leverton>	it would be nice if all compatible add-ons could be dropped in a sub dir, and picked up
Aug 04 14:22:50 <elias>	ah, true, one idea was to also add loadpng
Aug 04 14:23:21 <leverton>	there's a nifty "lodepng" library that has no dependency on libpng
Aug 04 14:24:02 <elias>	yes, i've seen it
Aug 04 14:24:02 <leverton>	it's in currently in C++ , but would probably be trivial to port to C ... just a thought anyway
Aug 04 14:24:20 <tjaden>	avoiding libpng is a bit silly
Aug 04 14:24:40 <elias>	yes, i think there's no real reason to
Aug 04 14:25:41 <elias>	maybe we also want an .ogg and .ttf addon, those certainly would need have dependencies on libvorbis and freetype and so on
Aug 04 14:26:55 <elias>	so, how should they be included? have a folder addons, then addons/allegrogl, addons/loadpng?
Aug 04 14:27:02 <elias>	and they would follow certain conventions
Aug 04 14:27:03 <tjaden>	yes
Aug 04 14:27:13 <elias>	fix.sh could then call addons/*/fix.sh
Aug 04 14:27:20 <elias>	and things like that..
Aug 04 14:27:46 <tjaden>	not sure how it would work, but something like that
Aug 04 14:28:42 <elias>	i can try playing with allegrogl - get it to work for unix somehow that way
Aug 04 14:29:23 -->	trentg (n=trent@75.152.135.148) has joined #allegro-dev
Aug 04 14:29:24 ---	ChanServ gives voice to trentg
Aug 04 14:29:32 <leverton>	whatever we do, it should be something that's simple to maintain cross platform
Aug 04 14:30:02 <trentg>	Sorry, slept in
Aug 04 14:30:28 <leverton>	duly noted
Aug 04 14:30:39 <tjaden>	hi
Aug 04 14:30:45 <trentg>	Hi
Aug 04 14:31:06 <elias>	ah, good, so we can also talk about display api, after all :)
Aug 04 14:31:56 <trentg>	Yes, I think we should decide once and for all about the api
Aug 04 14:32:18 <trentg>	Generally anyway
Aug 04 14:33:11 <trentg>	Obviously that alternative api was no good
Aug 04 14:33:51 <trentg>	I think we should stick with the current one on the wiki
Aug 04 14:35:15 <leverton>	what were the reasons to try alternatives?
Aug 04 14:35:35 <trentg>	I guess to make sure what we're doing is the best way
Aug 04 14:35:45 <elias>	it seems many APIs use a different way
Aug 04 14:35:53 <elias>	e.g. Qt, GTK, Java, Win32
Aug 04 14:37:01 <elias>	where all kinds of stuff (current clipping rect, current blending mode, color, ...) are its own "device context/graphics context/paint object" or similar
Aug 04 14:38:05 <elias>	in allegro 4, and also the new API, those are just placed where they seemed to make sense
Aug 04 14:38:13 <tjaden>	they have pretty sophisticated 2d graphics routines, which we don't support
Aug 04 14:38:18 <elias>	globals, thread-local, per-gfx-driver, per-bitmap, ...
Aug 04 14:39:02 <elias>	yeah. a point i put on the wiki is "Patterned drawing? Blending?"
Aug 04 14:39:24 <elias>	i'd consider those sophisticated as well
Aug 04 14:40:00 <elias>	especially if we get patterned drawing again, i want also line patterns - always missed them in A4 :)
Aug 04 14:40:16 <tjaden>	i was going to suggest dropping them
Aug 04 14:40:53 <elias>	yeah. so going the SDL way basically, only having minimal support and encouraging use of addons
Aug 04 14:41:36 <elias>	i'm somehow torn between people seeing Allegro as the all-in-one solution, and that
Aug 04 14:41:47 <leverton>	well, with a proper add-on system, it wouldn't matter
Aug 04 14:44:15 <trentg>	Less code for me to maintain is better.. I just got out of the hospital and I can't do too much stress :)
Aug 04 14:46:02 <trentg>	 But seriously, I think the code quality could be better in addons
Aug 04 14:47:07 <elias>	as in, it is currently bad?
Aug 04 14:47:18 <elias>	or as in, it could be batter than if stuff is in core?
Aug 04 14:47:21 <elias>	*better
Aug 04 14:47:59 <trentg>	No, I just meant that we wouldn't have to keep it somewhat minimal like we do now, in an addon you could go as far as you want.
Aug 04 14:48:54 <elias>	ok
Aug 04 14:49:20 <trentg>	I mean, there are probably many dozens of blending modes, supporting them all in the library, for which we'd have to support software drivers as well, would be hard to do.
Aug 04 14:50:04 <elias>	yeah, that's really a problem. if we support all the logically possible blending modes, some are bound to not work HW accelerated
Aug 04 14:50:29 <tjaden>	i think the only thing from the Display page i'm not sure about is the list of formats for al_set_new_display_format
Aug 04 14:50:37 <elias>	otoh, something like simple additive blending, or tinting to a color, will work trivially in D3D and OpenGL..
Aug 04 14:52:19 <trentg>	The formats are confusing, because it's a choice of going MSB first or LSB first. D3D uses MSB and OpenGL uses LSB.
Aug 04 14:52:53 <elias>	ah, true, that's a detail we should decide (probably not what tjaden meant thoguh)
Aug 04 14:53:10 <trentg>	So maybe we can do a few blending modes, the most important ones, and leave hooks for an addon to do the rest.
Aug 04 14:53:28 <tjaden>	well, i don't know if i want to be choosing between ARGB_8888 or RGBA_8888
Aug 04 14:53:53 <elias>	my idea was, that you normally wouldn't call that function, as a driver might only support one and not the other
Aug 04 14:54:26 <trentg>	We were thinking of adding ANY16, ANY32 etc too
Aug 04 14:54:54 <elias>	and we still need an API for enumerating possible display modes
Aug 04 14:55:02 <elias>	hm, or is it there yet.. /me checks
Aug 04 14:55:11 <trentg>	It is
Aug 04 14:55:13 <elias>	ah, yes, it is :)
Aug 04 14:55:43 <elias>	so  AL_DISPLAY_MODE would then have the format, and can use that
Aug 04 14:56:15 <elias>	#  ALLEGRO_PIXEL_FORMAT_ARGB_8888
Aug 04 14:56:15 <elias>	# ALLEGRO_PIXEL_FORMAT_RGBA_8888 
Aug 04 14:56:33 <elias>	those means right now:
Aug 04 14:56:39 <elias>	0xaarrggbb
Aug 04 14:56:43 <elias>	0xrrggbbaa
Aug 04 14:56:45 <elias>	respectively
Aug 04 14:56:57 <elias>	so just the other way around to OpenGL naming
Aug 04 14:57:25 <elias>	i.e. in opengl, the first letter is the lowest byte in memory
Aug 04 14:58:17 <elias>	it will be important when directly modifying pixels in a video bitmap
Aug 04 14:58:57 <tjaden>	probably more intuitive this way
Aug 04 15:01:17 <elias>	hm, we were also talking about merging  al_set_new_display_format and al_set_new_display_flags back into  al_create_display
Aug 04 15:01:42 <elias>	i wanted to have them separate, as i'm too lazy to type out ALLEGRO_PIXEK_FORMAT_ANY in each program :P
Aug 04 15:02:57 <tjaden>	*shrug* just pick one
Aug 04 15:03:09 <trentg>	Yeah, it can save some typing and doesn't do any harm so separate should be good
Aug 04 15:04:31 <elias>	ok. so back to blending, we just support a few selected ones?
Aug 04 15:05:06 <tjaden>	whatever the implementors think worthwhile :)
Aug 04 15:05:56 <trentg>	I always use translucency, so it would be a bit of a pain to have to use an addon just for that
Aug 04 15:06:10 <elias>	translucency definitely should be default
Aug 04 15:06:20 <elias>	i.e. if you load a bitmap with an alpha channel, then it will blit it using the alpha channel
Aug 04 15:06:39 <elias>	color-key masking is more of a problem to me
Aug 04 15:07:16 <trentg>	It's ugly with modern apis
Aug 04 15:07:24 <elias>	as in opengl, it just works much better if you convert the color-key to a proper alpha channel on loading
Aug 04 15:07:47 <elias>	even if it's a 1-bit channel, as in 5551 format
Aug 04 15:09:12 <trentg>	So we can get rid of ALLEGRO_USE_ALPHA and ALLEGRO_NO_ALPHA?
Aug 04 15:09:22 <trentg>	And maybe add ALLEGRO_CONVERT_TO_ALPHA?
Aug 04 15:09:28 <tjaden>	do we have a function to make a memory bitmap compatible with a display?
Aug 04 15:09:48 <trentg>	A memory bitmap will always be compatible with a display
Aug 04 15:10:31 <elias>	not necessarily
Aug 04 15:10:35 <tjaden>	optimised for the display?
Aug 04 15:10:42 <elias>	e.g. if you use al_set_new_bitmap_format with a format not supported..
Aug 04 15:11:27 <trentg>	So we could add a memory bitmap -> display bitmap function
Aug 04 15:12:42 <elias>	al_set_new_display_format(al_get_display_format())
Aug 04 15:13:00 <elias>	al_create_bitmap(bmp->w, bmp->h)
Aug 04 15:13:04 <elias>	then blit it over..
Aug 04 15:13:11 <trentg>	yeah
Aug 04 15:13:41 <elias>	hm, but yes - if alpha channel/color key are bitmap properties
Aug 04 15:14:11 <elias>	then on conversion, a color-keyed bitmap could be converted to an alpha one
Aug 04 15:16:45 <elias>	so instead of al_set_mask_color, there would be al_mask_bitmap(ALLEGRO_BITMAP *, ALLEGRO_COLOR *)
Aug 04 15:16:48 <elias>	or something like that
Aug 04 15:17:01 <elias>	and it just sets a mask for that bitmap
Aug 04 15:17:31 <elias>	and color conversion would then be able to take it into account
Aug 04 15:20:51 <trentg>	Would that change all the pixels to alpha?
Aug 04 15:22:16 <elias>	yes. if there's a bitmap with an active color key, and is converted to display format, that should be the logical thing to do then
Aug 04 15:22:42 <elias>	might even work the other way around (in case there's a driver which does not use alpha blitting)
Aug 04 15:24:23 <trentg>	Before tjaden leaves, what should we do about the new mouse driver's use of gfx_driver in the cursor related functions?
Aug 04 15:25:10 <tjaden>	let me just look at that again
Aug 04 15:27:05 <elias>	i think we should not have mouse cursor emulation
Aug 04 15:27:47 <tjaden>	yes
Aug 04 15:28:41 <elias>	but a function like show_os_cursor in A4.. possibly in the system driver
Aug 04 15:29:05 <elias>	so by default, there is a mouse cursor as decided by the window manager..
Aug 04 15:29:06 <tjaden>	trentg, which uses are you thinking of?
Aug 04 15:29:09 <elias>	and you can hide it
Aug 04 15:29:39 <elias>	and in cases like DirectX fullscreen (not sure if Vista still has no cursor there).. it's up to the user to draw their own cursor
Aug 04 15:29:54 <trentg>	in al_create_mouse_cursor for example
Aug 04 15:30:07 <trentg>	and al_set_mouse_cursor
Aug 04 15:31:07 <trentg>	I think there is a cursor in fullscreen DX in Vista, but besides the point
Aug 04 15:31:16 <tjaden>	can more than one gfx_driver be active at once?
Aug 04 15:31:46 <trentg>	We don't use gfx_driver at all in the new api, except  when the compatibility layer is active
Aug 04 15:31:51 <elias>	there is no more gfx_driver.. just an AL_SYSTEM, and several AL_DISPLAY
Aug 04 15:32:23 <elias>	(normally only one AL_DISPLAY, unless you have multiple OS windows)
Aug 04 15:32:27 <tjaden>	ok, i guess those methods get shipped to the system driver
Aug 04 15:33:49 <elias>	al_set_system_mouse_cursor should be dropped i think
Aug 04 15:33:53 <trentg>	Even still, the system drivers aren't the same
Aug 04 15:34:14 <elias>	as it should be the same as al_set_mouse_cursor
Aug 04 15:34:57 <elias>	oh, wait
Aug 04 15:35:07 <elias>	this is about providing own bitmap vs not
Aug 04 15:35:10 <elias>	should be ok then
Aug 04 15:35:39 <tjaden>	in a windowed setup, the mouse cursor is a system driver sort of thing, right?
Aug 04 15:35:57 <elias>	in X11, it's a window property
Aug 04 15:36:18 <elias>	but - should be easy enough to intercept a message and always set the current Allegro cursor
Aug 04 15:36:44 <elias>	so if we want it to be one global Allegro cursor should work
Aug 04 15:37:16 <tjaden>	didn't think of that
Aug 04 15:37:34 <tjaden>	do we want a cursor per window?
Aug 04 15:37:57 <tjaden>	i guess most window environments would support that
Aug 04 15:38:04 <tjaden>	(or should)
Aug 04 15:38:15 <tjaden>	we could emulate it anyway
Aug 04 15:38:22 <elias>	in that case, we could just move the cursor function from the mouse driver to the display driver
Aug 04 15:38:26 <elias>	*functions
Aug 04 15:39:01 <elias>	some cases like the XP-DirectX-fullscreen will not support cursor either way anyway
Aug 04 15:39:12 <elias>	so users just must know that it might fail
Aug 04 15:39:28 <tjaden>	yes, so then they have to draw their own
Aug 04 15:40:14 <elias>	ok, so move them to display vtable?
Aug 04 15:40:23 <tjaden>	makes sense
Aug 04 15:40:43 <elias>	this automatically removes the access to gfx_driver as well i guess
Aug 04 15:41:33 -->	M_Matty (i=MattyMat@cpc1-birk4-0-0-cust819.bagu.cable.ntl.com) has joined #allegro-dev
Aug 04 15:41:33 ---	ChanServ gives voice to M_Matty
Aug 04 15:41:40 <elias>	btw, should i rename alex.png to icon.png?
Aug 04 15:42:22 <tjaden>	why?
Aug 04 15:42:58 <elias>	Johan said on allegro.cc that he keeps all rigts to the alex character
Aug 04 15:43:14 <M_Matty>	no immediate problem with that. peitz has explicitly given permission to use it as an icon
Aug 04 15:43:17 <elias>	so he really just gave the square of pixels to us under the giftware license
Aug 04 15:43:23 <tjaden>	yes
Aug 04 15:43:26 <elias>	but not the name "Alex"
Aug 04 15:43:42 <tjaden>	it's just a filename
Aug 04 15:43:47 <leverton>	yeah, renaming it is sufficient
Aug 04 15:44:12 <tjaden>	it doesn't imply that somehow Alex the character is free for all
Aug 04 15:44:16 <elias>	well, a user could still use it in a game and name it alex, and say the name comse from the allegro distribution.. if we rename it, would be better i think
Aug 04 15:44:32 <elias>	then it clearly is stolen from peitz
Aug 04 15:44:38 <elias>	and we can't be blamed
Aug 04 15:45:00 <tjaden>	i don't think it makes a difference, but rename it if you like
Aug 04 15:45:03 <elias>	(not that it would matter in practice of course.. i can't see anyone making a game using alex the allegator as main character..)
Aug 04 15:45:05 <M_Matty>	in the meantime, if any wants to write a Grozilla game... :)
Aug 04 15:45:22 <tjaden>	i never should have put the icon in there
Aug 04 15:45:44 <elias>	well, i think it's nice how allegro programs have that icon by default
Aug 04 15:45:44 <M_Matty>	elias, it's quite likely. look at all the tux games
Aug 04 15:46:39 <M_Matty>	part of the attraction of a mascot is it gives you a protagonist for games
Aug 04 15:47:07 <M_Matty>	which is why all my suggestions are fierce and sprite-shaped 
Aug 04 15:50:01 <elias>	yes, and it would be public domain from the beginning, if we really replace it
Aug 04 15:50:30 <elias>	the mailing list responnce leverton linked to: "That is super allright. :) I'd like to keep the rights to the character
Aug 04 15:50:30 <elias>	himself though (if it's possible and not very difficult). I have plans for
Aug 04 15:50:30 <elias>	him.:)"
Aug 04 15:50:57 <elias>	so i'll rename it at least
Aug 04 15:54:05 <M_Matty>	gotta share the latest version for those who haven't seen it :) http://wiki.allegro.cc/Image:Grozilla3.svg
Aug 04 15:54:37 <M_Matty>	for the record. this character, the image, etc. is all giftware 
Aug 04 15:54:38 <tjaden>	spiffy :)
Aug 04 15:54:57 <M_Matty>	the name belongs to you tjaden. that's giftware too?
Aug 04 15:55:29 <M_Matty>	it's from an ancient GUI discussion
Aug 04 15:55:41 <tjaden>	pffft, it was just a silly idea i had once
Aug 04 15:55:51 <elias>	hm, we could decide to just use grozilla as A5 icon :)
Aug 04 15:56:03 <M_Matty>	so was micket mouse :)
Aug 04 15:56:28 <M_Matty>	^mickey
Aug 04 15:56:42 <tjaden>	if someone gets fabulously rich off it, *then* i'll sue
Aug 04 15:57:24 <M_Matty>	hmmph. no joking. for the record, please :)
Aug 04 15:58:07 <M_Matty>	I've put 20 odd hours into that character 
Aug 04 15:58:16 <tjaden>	i hereby place the name "Grozilla" into the public domain
Aug 04 15:58:23 <elias>	hehe
Aug 04 15:58:26 <M_Matty>	w00tz :)
Aug 04 15:58:41 <CIA-2>	alleg: elias * r8111 /allegro/branches/4.2/ (10 files in 3 dirs): renamed alex to icon, just in the unlikely case someone names a game character after that filename and Johan Peitz would then blame us
Aug 04 15:59:41 <tjaden>	i think i like the png version of the grozilla image better though, has some texture to it
Aug 04 16:00:10 <elias>	i wonder how it looks as 16x16 version
Aug 04 16:00:23 <elias>	i think that's the size my X11 uses for its window icons
Aug 04 16:00:34 <M_Matty>	terrible at 16x16.  it'll need stylising
Aug 04 16:01:00 <M_Matty>	and the 8-bit png is half the size of that svg
Aug 04 16:02:30 <tjaden>	ok, so was the Display page sorted out?
Aug 04 16:03:18 <tjaden>	i assume it's already what's implemented in SVN anyway, right?
Aug 04 16:03:34 <elias>	yes, wiki and implementation should be in sync
Aug 04 16:03:43 <elias>	should convert it to natural docs actually
Aug 04 16:04:00 <elias>	hm.. "Do we need al_enable_clipping?"
Aug 04 16:04:07 <elias>	that's just minor
Aug 04 16:04:37 <elias>	but i guess the possibility to save a single if in putpixel doesn't warrant a function these days
Aug 04 16:05:18 <elias>	so clipping would just be always active in A5
Aug 04 16:07:40 <CIA-2>	alleg: elias * r8112 /allegro/branches/4.2/src/x/icon.xpm: forgot one occurence of alex
Aug 04 16:08:58 <tjaden>	don't forget alex.xpm and alex.png are referenced in various makefiles, scripts, etc.
Aug 04 16:09:12 <elias>	yeah, should hopefully all be covered
Aug 04 16:09:26 <elias>	i used grep
Aug 04 16:09:56 <tjaden>	ok
Aug 04 16:09:58 <elias>	i hate svn merge syntax
Aug 04 16:11:27 <CIA-2>	alleg: elias * r8113 /allegro/branches/4.3.10plus/ (10 files in 3 dirs): merged icon renaming (revision 8110->8112) to 4.3
Aug 04 16:12:38 <CIA-2>	alleg: elias * r8114 /allegro/branches/4.9/ (10 files in 3 dirs): merged icon renaming (revision 8110->8112) to 4.9
Aug 04 16:14:28 <elias>	ok, only point left from the wiki is "File routines"
Aug 04 16:15:58 <tjaden>	ugh
Aug 04 16:17:12 <tjaden>	the problem is that allegro doesn't understand that the filename encoding is not necessarily ASCII or the encoding used for strings
Aug 04 16:19:14 <tjaden>	secondly, non-ASCII filenames in unix (before UTF-8) is completely stupid and dependent on the user's locale
Aug 04 16:19:36 <M_Matty>	same as in DOS
Aug 04 16:19:48 <tjaden>	thirdly, we had that problem where win98 and dmd didn't support wide char functions
Aug 04 16:19:49 <elias>	i think Allegro currently just assumes UTF-8 in unix
Aug 04 16:20:13 <tjaden>	except when you use system_none
Aug 04 16:20:26 <elias>	hm
Aug 04 16:20:26 <M_Matty>	what about allegro's built in wide char funcs?
Aug 04 16:20:34 <elias>	system_none seems to be a general problem..
Aug 04 16:21:00 <elias>	are the file function part of the system driver?
Aug 04 16:21:42 <tjaden>	some
Aug 04 16:21:50 <M_Matty>	it seems sensible
Aug 04 16:22:10 ---	Notify: Madgarden is online (kubrick.freenode.net).
Aug 04 16:22:11 <M_Matty>	most are just part of libc tho
Aug 04 16:22:43 <tjaden>	s/some/none
Aug 04 16:23:06 <tjaden>	but there are platform specific routines
Aug 04 16:23:15 <elias>	so how can SYSTEM_NONE affect them?
Aug 04 16:23:39 <tjaden>	that's the problem
Aug 04 16:23:44 <elias>	btw, i'm unable to find the place where pack_fopen actually opens a file :P
Aug 04 16:24:10 <tjaden>	it calls _pack_fdopen
Aug 04 16:24:42 <tjaden>	er
Aug 04 16:25:10 <leverton>	under windows, the only problem related to unicode file paths is system_none does not detect the operating system 
Aug 04 16:26:09 <tjaden>	pack_fopen calls _al_open then calls _pack_fdopen
Aug 04 16:26:32 <M_Matty>	I'll look for that windows problem. I'm rummaging around there still
Aug 04 16:26:46 <leverton>	well, the solution is trivial for windows
Aug 04 16:26:53 <leverton>	but it doesn't address the bigger problem with Linux
Aug 04 16:27:00 <elias>	ahh.. #define _al_open(filename, mode, perm)   open(filename, mode, perm)
Aug 04 16:27:52 <leverton>	for windows, SYSTEM_NONE could be overridden to call an os_init() function that is common to NONE / AUTODETECT
Aug 04 16:28:07 <M_Matty>	yep
Aug 04 16:28:22 <leverton>	what is the definition of a "system" anyway?
Aug 04 16:28:41 <M_Matty>	it's a platform :)
Aug 04 16:28:58 <M_Matty>	O/S pretty much
Aug 04 16:29:01 <elias>	well, what this mean for SYSTEM_NONE?
Aug 04 16:29:19 <M_Matty>	good point
Aug 04 16:29:26 <elias>	by that interpretation, with SYSTEM_NONE, you probably couldn't access the filesystem
Aug 04 16:29:33 <elias>	which would make it quite useless :P
Aug 04 16:29:36 <leverton>	exactly
Aug 04 16:29:56 <leverton>	is there anything defined besides AUTODETECT / NONE ?
Aug 04 16:30:11 <M_Matty>	so for A5, there's no point in SYSTEM_NONE
Aug 04 16:31:07 <leverton>	for example SYSTEM_DIRECTX
Aug 04 16:31:16 <elias>	well, SYSTEM_NONE could be made like SYSTEM_AUTODETECT
Aug 04 16:31:20 <leverton>	the name itself is weird
Aug 04 16:31:31 <leverton>	if DirectX is a system, it shouldn't affect the file system
Aug 04 16:31:36 <elias>	just it would detect a driver which won't open a window
Aug 04 16:31:54 <M_Matty>	that's because the DX was the first windows version. there's a lot of names like that
Aug 04 16:32:01 <elias>	so SYSTEM_LINUX_NONE and SYSTEM_WINDOWS_NONE
Aug 04 16:32:16 <tjaden>	or _BARE
Aug 04 16:32:19 <elias>	the system driver in A4 decided what kind of window to open
Aug 04 16:32:45 <M_Matty>	in A5, the window shouldn't open until set_gfx_mode()
Aug 04 16:32:53 <elias>	well, depends
Aug 04 16:32:59 <elias>	we could have drivers which do it either way
Aug 04 16:33:14 <tjaden>	i think getting rid of the system driver is a good idea
Aug 04 16:33:26 <M_Matty>	in windows, you have to open an invisible window at least to capture input
Aug 04 16:33:37 <elias>	if you want input, you should not use SYSTEM_NONE
Aug 04 16:33:58 <leverton>	I agree
Aug 04 16:34:36 <M_Matty>	the system driver is how a lot of the cross platform is implemented, although the compiler could handle that
Aug 04 16:35:21 <elias>	hm, so in linux, _unix_guess_file_encoding() is called only when one of the unix drivers is used, not with SYSTEM_NONE
Aug 04 16:35:35 <leverton>	yeah
Aug 04 16:35:37 <tjaden>	yes, same problem as windows
Aug 04 16:35:46 <M_Matty>	I would keep the system driver, as it gives a way to implement x/non-x input regimes with 1 program
Aug 04 16:36:00 <tjaden>	so if we only care about utf-8 then we can do the same as matthew's suggestion for unix
Aug 04 16:36:31 <elias>	os_init()?
Aug 04 16:37:00 <tjaden>	maybe just _al_init_file_encoding
Aug 04 16:37:09 <leverton>	I didn't literally mean a standard os_init function  ... just that windows could use a standard function 
Aug 04 16:37:21 <elias>	and it would be #defined depending on platform
Aug 04 16:37:27 <elias>	makes sense i guess
Aug 04 16:37:51 <leverton>	I think file_encoding is a bit misleading
Aug 04 16:37:58 <leverton>	vs filename_encoding
Aug 04 16:38:04 <tjaden>	sorry, filename is the right name
Aug 04 16:38:07 <elias>	true
Aug 04 16:38:38 <elias>	does OSX also use locales to decide the encoding?
Aug 04 16:38:39 <leverton>	and the get/set_file_encoding functions should either be renamed as well if they are to officially be made public
Aug 04 16:39:00 <tjaden>	i have a feeling OSX uses UTF-8
Aug 04 16:39:09 <elias>	yeah, but currently, it also calls unix_guess_file_encoding
Aug 04 16:39:20 <elias>	which just graps the locale for "utf8"
Aug 04 16:39:23 <elias>	*greps
Aug 04 16:40:09 <leverton>	I don't see any locale environment variables in os x 10.4
Aug 04 16:40:21 <elias>	TRACE(PREFIX_I "Assumed libc encoding is %s.\n", encoding);
Aug 04 16:40:30 <elias>	do you have any OSX allegro.log?
Aug 04 16:40:36 <elias>	what does it say for the above?
Aug 04 16:41:17 <leverton>	I have one allegro.log on disk, but it's from '06 and doesn't say anything
Aug 04 16:41:55 <M_Matty>	All my file accesses tend to be platform dependent anyway.  I've tried to write funcs which alias C:\\ to /windows/C etc. 
Aug 04 16:42:48 <elias>	r5816 | elias | 2006-05-30 15:05:01 +0200 (Tue, 30 May 2006) | 4 lines
Aug 04 16:42:48 <elias>	Chris fixed some problems with non-ASCII filenames under Windows, and also made it work again under Win98.
Aug 04 16:42:48 <elias>	me and Chris fixed problems for UTF8 filenames under Unix, as reported by Grzegorz. Non ascii non utf8 filenames remain 
Aug 04 16:42:48 <elias>	broken.
Aug 04 16:42:57 <elias>	^ that was the commit which adds it to allegro.log
Aug 04 16:43:17 <tjaden>	btw, that log message sucks
Aug 04 16:43:21 <elias>	hehe
Aug 04 16:43:34 <leverton>	what do I do to generate an allegro log?
Aug 04 16:43:47 <elias>	i think i never had any idea what changed in windows, and KittyCat didn't have commit rights yet
Aug 04 16:43:55 <M_Matty>	"non ascii non utf8" does that mean dos/windows codepages?
Aug 04 16:44:00 <elias>	yeah
Aug 04 16:44:37 <tjaden>	maybe patch submissions should come with log messages
Aug 04 16:44:38 <M_Matty>	so we need to enable codepage support
Aug 04 16:44:58 <M_Matty>	well, it would be nice. codepages are a lot of trouble
Aug 04 16:45:22 <M_Matty>	but the encoding type should allow for it
Aug 04 16:46:26 <M_Matty>	I should write a big friendly file selector that uses that 16 pix high font
Aug 04 16:46:29 <leverton>	al-unix INFO: Assumed libc encoding is unknown.
Aug 04 16:46:30 <leverton>	al-main INFO: Allegro initialised (instance 1)
Aug 04 16:46:51 <elias>	so if OSX libc indeed always returns utf8, we should change that..
Aug 04 16:46:57 <elias>	just set _filename_encoding to utf8
Aug 04 16:47:29 <elias>	and that commit message indeed sucks
Aug 04 16:47:41 <elias>	apparently it was the commit who first introduced that unix_guess_filename_encoding concept
Aug 04 16:48:19 ---	elias sets mode -e elias
Aug 04 16:48:19 ---	You are now known as allefant
Aug 04 16:48:19 ---	services. sets mode +e allefant
Aug 04 16:48:26 <allefant>	i wonder who did that commit..
Aug 04 16:49:22 <M_Matty>	oy persching!
Aug 04 16:49:22 <tjaden>	on another project (which i get paid for) the log messages are reviewed as part of the patch, and are regularly a page or two long...
Aug 04 16:50:10 <allefant>	yes, detailed log messages never hurt
Aug 04 16:51:18 <M_Matty>	although the commit number is a good reference for discussing it in detail elsewhere
Aug 04 16:52:29 <tjaden>	hmm, it seems OSX uses UTF-8 filenames in some variant of NFD normalisation
Aug 04 16:52:57 <M_Matty>	sometimes I read the latest changlogs of programs I'm about to install, and I don't want minutae there
Aug 04 16:53:10 <allefant>	changelog != commit logs
Aug 04 16:53:38 <M_Matty>	ah ok. I thought one was generated from t'other
Aug 04 16:53:50 <allefant>	well, some projects do that
Aug 04 16:54:10 <allefant>	in allegro, it's done manually (using svn2cl as a base i think)
Aug 04 16:54:41 <tjaden>	i just use svk log and prune
Aug 04 16:54:56 <M_Matty>	so, we could do our messages in _tx with headings and stuff :)
Aug 04 16:54:56 <leverton>	I just did a simple test on OS X, and using a UTF-8 string worked
Aug 04 16:55:53 <tjaden>	i wonder if the string was NFC (precomposed glyphs) or NFD
Aug 04 16:55:57 <allefant>	probably "unknown" uses the current allegro encoding
Aug 04 16:56:01 <allefant>	which usually is UTF8 :)
Aug 04 16:56:16 <leverton>	I renamed a file to 0\1000.mp3 
Aug 04 16:56:27 <leverton>	that is 0 followed by unicode 0x1000
Aug 04 16:57:00 <leverton>	I used the string '0',0xe1,0x80,0x80,'.','m','p','3',0 
Aug 04 16:59:00 <tjaden>	ok, but what happens if you use a filename like fílènåmë ?
Aug 04 16:59:31 <allefant>	should make no difference
Aug 04 16:59:37 <tjaden>	just copy that directly into a string literal
Aug 04 16:59:41 <allefant>	the file would be encoded as utf8 by his editor
Aug 04 16:59:48 <allefant>	the C compiler would copy it as-is
Aug 04 16:59:51 <allefant>	so the result is the same
Aug 04 16:59:55 <leverton>	I cannot because I'm here, and my macmini is over there ;)
Aug 04 17:00:20 <tjaden>	no, but in NFD it would be stored fi(accent)le(accent)na(accent)me(accent)
Aug 04 17:00:33 <allefant>	ob
Aug 04 17:00:35 <allefant>	*oh
Aug 04 17:00:44 <leverton>	this is for chars in the 128-255 range?
Aug 04 17:00:57 <tjaden>	i think so
Aug 04 17:01:08 <tjaden>	let me refresh
Aug 04 17:01:16 <M_Matty>	his editor might be a smartarse and convert utf-8 in the copy buffer to codepage in the file
Aug 04 17:01:59 <M_Matty>	I don't think any versions of VS do that tho, they'd just paste junk
Aug 04 17:02:00 <tjaden>	or maybe mac OS X libc will automatically decompose
Aug 04 17:02:59 <allefant>	the problem would also exist under linux
Aug 04 17:03:18 <allefant>	e.g. do fopen("NFC-name", "w"); fopen("NFD-name", "w");
Aug 04 17:03:25 <allefant>	will you now have two files or one?
Aug 04 17:03:27 <M_Matty>	can't you assume utf-8 there too?
Aug 04 17:03:38 <tjaden>	allefant, two files
Aug 04 17:03:51 <allefant>	ah, but OSX is different?
Aug 04 17:04:23 <tjaden>	hmm, i don't know
Aug 04 17:05:09 <leverton>	well I created a file named 0Ò.mp3 on the desktop using the GUI
Aug 04 17:05:23 <leverton>	and it opened with {'0', 0xc3, 0x92, '.', 'm', 'p', '3', 0}
Aug 04 17:06:22 <leverton>	thats Unicode / ASCII  0xD2
Aug 04 17:07:02 <allefant>	is there a way to find out the NFD sequence of that?
Aug 04 17:07:35 <leverton>	it does not open with {'0', 0xD2, '.', 'm', 'p', '3', 0} (ASCII)
Aug 04 17:08:17 <allefant>	yeah, that would require libc to expect a codepaged string
Aug 04 17:09:07 <allefant>	anyway, the NFC/NFD issue is not currently a problem.. so we can fix that later
Aug 04 17:09:45 <M_Matty>	 yeah, as long as UTF-8 works
Aug 04 17:10:24 <allefant>	so, for now, we should make a platform-dependent function to call set_filename_encoding - which is called in allegro_init but independent of the chosen system driver
Aug 04 17:10:54 <tjaden>	yes
Aug 04 17:11:00 <M_Matty>	so in windows, would the file routines use _wfopen() and convert to UTF-8?
Aug 04 17:11:12 <allefant>	(i can do for unix.. there it's trivial, just moce the guess_filename_encoding call from each system driver to src/allegro.cc inside an #ifdef)
Aug 04 17:14:21 <tjaden>	well, we convert from the current string encoding to the current filename encoding then pass it to _wopen
Aug 04 17:14:29 <M_Matty>	on the subject of file selectors, are we going to have a function that wraps all the system ones into a common API?
Aug 04 17:14:58 <tjaden>	that was what thomas wanted to do, isn't it?
Aug 04 17:15:20 <M_Matty>	ah ok. I'll talk to him about it
Aug 04 17:15:30 <allefant>	yes, so it would replace PACKFILE
Aug 04 17:15:44 <M_Matty>	no not that. the GUI file selector
Aug 04 17:16:05 <M_Matty>	which is currently fugly and lo-power
Aug 04 17:16:28 <allefant>	you mean, a function to display a system-specific file selector?
Aug 04 17:16:36 <M_Matty>	it would be nice to use the Windows one while staying cross-platform
Aug 04 17:16:50 <allefant>	i guess that's outside the scope of allegro, personally
Aug 04 17:16:57 <allefant>	you can just use Wx to get that
Aug 04 17:17:47 <allefant>	or write an addon
Aug 04 17:18:01 <M_Matty>	the alternative is to soup up the built-in one.  with multiple windows that'll be a doddle
Aug 04 17:18:09 <allefant>	so under let's say Windows, OSX and KDE it could display such a selector, else fial
Aug 04 17:18:11 <allefant>	*fail
Aug 04 17:18:19 <leverton>	char fn_nfc[] = {'0', 0xC3, 0x85, 0};
Aug 04 17:18:19 <leverton>	char fn_ufd[] = {'0', 0x41, 0xcc, 0x8a, 0};
Aug 04 17:18:26 <M_Matty>	no, or else revert to crappy one
Aug 04 17:18:26 <leverton>	I wrote to nfc, and was able to read from ufd
Aug 04 17:18:52 <allefant>	ah, let me try that here..
Aug 04 17:18:56 <leverton>	err nfd, nfc
Aug 04 17:18:58 <tjaden>	ok, so it looks like mac libc does some translating
Aug 04 17:19:02 <tjaden>	or the kernel
Aug 04 17:19:04 <allefant>	leverton: can you paste the test program?
Aug 04 17:19:43 <M_Matty>	how does it know that ufd one isn't ufc?
Aug 04 17:19:57 <leverton>	because 0xcc,0x8a is a special char
Aug 04 17:20:00 <leverton>	that is the accent char
Aug 04 17:20:03 <M_Matty>	nfd/nfc :p
Aug 04 17:20:06 <leverton>	0x41 is just the A
Aug 04 17:20:28 <leverton>	whereas 0xC385 is the A with the nice little hat all in one
Aug 04 17:20:49 <M_Matty>	ah cool, so they are both valid utf-8
Aug 04 17:21:37 <leverton>	http://pastebin.com/m1c4c25b7
Aug 04 17:22:29 <leverton>	http://pastebin.com/m34537aff with the d being printed
Aug 04 17:23:35 <leverton>	that's only one trivial example though 
Aug 04 17:24:16 <leverton>	http://www.unicode.org/unicode/reports/tr15/ has plenty of examples
Aug 04 17:24:18 <allefant>	fn_nfc: 0Å 0x601010
Aug 04 17:24:18 <allefant>	fn_nfd: 0Å (nil)
Aug 04 17:24:47 <allefant>	so i guess, in my locale/kernel/file-encoding/lib-version.. it does ignore nfc/nfd equality
Aug 04 17:24:52 <leverton>	yeah
Aug 04 17:25:15 <allefant>	-rw-r--r--   1 elias elias    4 2007-08-04 17:25 0Å
Aug 04 17:25:15 <allefant>	-rw-r--r--   1 elias elias    4 2007-08-04 17:24 0Å
Aug 04 17:25:15 <leverton>	so maybe that's a sign that OS X supports both good enough for Allegro not to care about anything
Aug 04 17:25:22 <allefant>	^ it also displays them differently
Aug 04 17:25:30 <leverton>	the first one is NFD, I assume
Aug 04 17:25:37 <allefant>	yes
Aug 04 17:25:55 <allefant>	and it displays as A followed by °
Aug 04 17:26:07 <tjaden>	yes, that's just the terminal being wrong
Aug 04 17:26:22 <allefant>	indeed
Aug 04 17:26:31 <leverton>	well, the OS X terminal just says ???
Aug 04 17:26:33 <allefant>	gnome displays them both as a single letter
Aug 04 17:26:48 <allefant>	heh, but they look slightly different
Aug 04 17:27:09 <allefant>	one has the ° a pixel more to the right
Aug 04 17:27:16 <leverton>	NFD is probably drawn in two strokes then
Aug 04 17:27:44 <allefant>	likely
Aug 04 17:27:52 <allefant>	and it gets it wrong by one pixel
Aug 04 17:28:05 <leverton>	anyway, it seems that defaulting to utf-8 for OS X should be good enough for Allegro 
Aug 04 17:28:11 <tjaden>	yep
Aug 04 17:28:15 <M_Matty>	allefant, that's the font
Aug 04 17:28:28 <allefant>	yeah, the font drawing library, most likely
Aug 04 17:28:30 <allefant>	so freetype
Aug 04 17:28:49 <allefant>	it *should* display the ° just in the middle of the A, but in the NFD case messes up
Aug 04 17:28:53 <M_Matty>	no, the position of the loop itself in the font will be different
Aug 04 17:29:06 <allefant>	well, it should be the same font for both
Aug 04 17:29:16 <allefant>	i guess
Aug 04 17:30:11 <M_Matty>	the free-standing ° will be in a diffent place
Aug 04 17:30:19 <M_Matty>	even in the same font
Aug 04 17:30:48 <allefant>	yeah.. but likely it's supposed to place it correctly (?)
Aug 04 17:31:00 <M_Matty>	it just overlaps two chars
Aug 04 17:31:22 <M_Matty>	so you can put accents on chars that don't have a NFC equivalent
Aug 04 17:31:23 <allefant>	yeah, so Å is one glyph in the font
Aug 04 17:31:44 <allefant>	and Å are two glyphs
Aug 04 17:31:57 <allefant>	but if it works properly, they should look the same i guess
Aug 04 17:32:15 <allefant>	xchat messes up completely as well when i paste it :/
Aug 04 17:32:24 <M_Matty>	it's the font, I'm sure
Aug 04 17:32:39 <allefant>	it split it into Å  for some reason
Aug 04 17:32:48 <leverton>	in Opera, I see the NFD as two chars
Aug 04 17:33:29 <allefant>	it's another stupid invention in any case..
Aug 04 17:33:40 <leverton>	anyway, on another topic ... why are there still open bugs from 2004 on the sf bug tracker? ;)
Aug 04 17:33:42 <allefant>	what if i now zip up my folder with the two files, and send to someone using OSX?
Aug 04 17:34:00 <leverton>	allefant: the universe will implode
Aug 04 17:34:13 <tjaden>	i hate using the sf bug tracker
Aug 04 17:34:28 <leverton>	but surely, OS X could open them individually IF they both exist ?
Aug 04 17:34:35 <leverton>	who knows though, heh
Aug 04 17:34:42 <leverton>	I'm betting on the universe imploding
Aug 04 17:35:06 <leverton>	can we disable it (the bug tracker) ?
Aug 04 17:35:12 <M_Matty>	"file 1 already exists. overwrite?"
Aug 04 17:35:15 <leverton>	it just sort of looks bad to see 3 year old bugs
Aug 04 17:35:18 <tjaden>	well, it's useful
Aug 04 17:35:35 <tjaden>	when the submitter bothers to reply
Aug 04 17:35:42 <allefant>	leverton: do you have enough access rights to close bugs?
Aug 04 17:36:13 <leverton>	I only have access to upload files
Aug 04 17:36:32 <tjaden>	and probably quite a few bugs aren't actually fixed
Aug 04 17:36:57 <leverton>	apathy is a form of a fix
Aug 04 17:37:07 <allefant>	yeah, i think i looked at the old ones some time ago, and the only option would have been to just say "outdated without ever being fixed"
Aug 04 17:37:38 <leverton>	the tracker sure is ugly
Aug 04 17:37:46 <tjaden>	it's true, wait long enough and the OS that the bug showed up on gets end-of-lifed
Aug 04 17:38:34 <allefant>	leverton: you are now Tech&Admin for all trackers.. not sure what that means..
Aug 04 17:38:54 <leverton>	it means all bugs will be resolved in 2 mins , heh heh
Aug 04 17:38:55 <tjaden>	give him commit access too if he's not got it
Aug 04 17:39:09 <allefant>	he already got it
Aug 04 17:39:28 <tjaden>	then what the hell was i doing all that hard work for?
Aug 04 17:39:41 <allefant>	heh
Aug 04 17:40:05 <leverton>	if I knew i had write access, 5.0 would have been released by now
Aug 04 17:40:32 <tjaden>	 release party next week then?
Aug 04 17:40:52 <leverton>	sure, as soon as Elias reports on bug #1663211 which is assigned to him ;)
Aug 04 17:41:10 <allefant>	what
Aug 04 17:41:13 <tjaden>	it's on you elias
Aug 04 17:42:12 <allefant>	ahh, bug #1663211 is marked as fixed
Aug 04 17:42:22 <allefant>	i only forgot to close when 4.2.2 was released
Aug 04 17:43:06 <allefant>	btw, should the asignee do the fixed->closed, or the one doing the release? :P
Aug 04 17:43:28 <allefant>	in wesnoth, it's the job of the release manager to flip the 200+ bugs in each release :)
Aug 04 17:44:04 <leverton>	feature request in 2003 : GBA support
Aug 04 17:44:11 <tjaden>	i just close it as the same time as i mark it fixed
Aug 04 17:44:24 <allefant>	ah, i see
Aug 04 17:44:24 <leverton>	that's what I'd do 
Aug 04 17:44:26 <allefant>	ok
Aug 04 17:44:40 <allefant>	yeah, in wesnoth, they are left open to avoid too many duplicates
Aug 04 17:44:46 <leverton>	this was the first time in a while we've seen 2 releases of Allegro within 12 months
Aug 04 17:45:08 <leverton>	so for the most part, they'll just be open for so long we'll forget about them
Aug 04 17:45:44 <allefant>	ok, now the only open ones are assigned to "nobody"
Aug 04 17:46:36 <leverton>	what about the MID() thing , do we want to "fix" that in 4.4 ?
Aug 04 17:46:44 <leverton>	that is rename it to CLAMP() 
Aug 04 17:47:11 <tjaden>	and retain MID?
Aug 04 17:47:14 <allefant>	was that decided upon in the a.cc thread about it?
Aug 04 17:47:22 <leverton>	either have a real MID or not include it
Aug 04 17:47:40 <leverton>	obviously for source reasons, including it would be easier
Aug 04 17:48:14 <tjaden>	ok, have the real MID, but warn that older versions of Allegro have an incorrect implementation?
Aug 04 17:48:34 <leverton>	I htink for 4.4, that should be good enough
Aug 04 17:48:39 <allefant>	old uses would keep working anyway
Aug 04 17:48:45 <leverton>	because you're likely to be using other functions anyway
Aug 04 17:49:00 <leverton>	so it's not like a person could compile it against a 4.2 library
Aug 04 17:49:17 <tjaden>	4.4 should be highly compatible with 4.2 i think
Aug 04 17:49:26 <leverton>	yeah 
Aug 04 17:49:31 <leverton>	but at least there's a clean distinction
Aug 04 17:49:36 <leverton>	I wouldn't change MID in 4.2
Aug 04 17:49:46 <tjaden>	sounds ok
Aug 04 17:49:46 <allefant>	yes, but the only use in 4.2 code would be MID(0, -12, 100) giving 0..
Aug 04 17:50:01 <leverton>	right, but if you wrote that in 4.4 , assuming it worked in 4.2
Aug 04 17:50:03 <leverton>	then you'd have a problem
Aug 04 17:50:04 <allefant>	so if 4.4 "fixes" it so MID(100, -12, 0) also returns 0, nothing breaks
Aug 04 17:50:11 <allefant>	ahh
Aug 04 17:50:14 <allefant>	yeah
Aug 04 17:52:21 <leverton>	in the discussion on [AD], Evert and Milan wrote "Just don't remove MID if you introduce CLAMP."
Aug 04 17:52:47 <leverton>	wasn't really any other points made against it
Aug 04 17:53:06 <M_Matty>	you need the existing one for blending funcs.  the fixed version is slow
Aug 04 17:53:20 <allefant>	well, can just use CLAMP then
Aug 04 17:53:28 <allefant>	all internal uses would be renamed MID->CLAMP
Aug 04 17:53:29 <M_Matty>	yeah
Aug 04 17:53:41 <leverton>	MID wouldn't even be used by Allegro internal
Aug 04 17:53:48 <leverton>	at least, it doesn't need to at the moment
Aug 04 17:53:49 <M_Matty>	that makes sense
Aug 04 17:54:13 <M_Matty>	so, why have MID in allegro at all?
Aug 04 17:54:30 <leverton>	forward source compatibility
Aug 04 17:54:34 <allefant>	yeah, so 4.2 user code won't break
Aug 04 17:54:40 <leverton>	or backward , I guess
Aug 04 17:54:44 <allefant>	apparently people used it, even though it's not documented
Aug 04 17:54:52 <leverton>	well I used it once
Aug 04 17:54:59 <leverton>	I defined it and got a warning or something
Aug 04 17:55:07 <leverton>	so thought, "cool , Allegro already has a MID"
Aug 04 17:55:11 <M_Matty>	well it will be "broken" if user blending funcs (fblend?) become 2x slower
Aug 04 17:55:52 <allefant>	hm, they can just rewrite using CLAMP if they think it is too slow
Aug 04 17:55:55 <M_Matty>	I think it just needs documenting 
Aug 04 17:56:25 <leverton>	time for a new a.cc coding challenge: best implementation of MID ;)
Aug 04 17:56:28 <allefant>	i don't care either way.. i never used the function
Aug 04 17:56:31 <M_Matty>	AL_MID() :)
Aug 04 17:56:46 <allefant>	can bug 1755144 be closed?
Aug 04 17:57:11 <M_Matty>	looks like it
Aug 04 17:57:20 <M_Matty>	if the fix made it into 4.2.2
Aug 04 17:57:23 <allefant>	tjaden replied with "Thanks. It was fixed a few months ago in the Subversion repository, so it
Aug 04 17:57:23 <allefant>	will appear in 4.2.2. I don't the answers to your other questions."
Aug 04 17:57:30 <allefant>	but there seems to be no other question anyway :)
Aug 04 17:57:49 <leverton>	1) Is w32api-3.9 tied inextricably to mingw-runtime-3.12 -- that is, does
Aug 04 17:57:49 <leverton>	the API expect the new runtime to be present?
Aug 04 17:57:49 <leverton>	2) May the 3.12 runtime update be successfully used with older versions of
Aug 04 17:57:49 <leverton>	the API (that is, is API 3.9 the only update to avoid for now)? 
Aug 04 17:57:51 -->	mimix (i=1000@vipnet253-165.mobile.CARNet.hr) has joined #allegro-dev
Aug 04 17:57:52 ---	ChanServ gives voice to mimix
Aug 04 17:58:11 <leverton>	do those questions even concern us?
Aug 04 17:58:14 <allefant>	ah, those are not related to allegro though, just pasted out of some mingw thread, if i understand right
Aug 04 17:58:27 <tjaden>	close it
Aug 04 17:58:35 <tjaden>	hi mimix 
Aug 04 17:58:42 <mimix>	hi
Aug 04 18:00:25 <leverton>	surely "[ 1255193 ] OSX dependencies not correct in RC1" is resolved
Aug 04 18:00:34 <leverton>	looks like it was just used as an attachment
Aug 04 18:01:00 <tjaden>	since you tested 4.2.2 on osx,...
Aug 04 18:01:19 <leverton>	this was RC1 of year 2005 ;)
Aug 04 18:01:56 <allefant>	hm, is September 1 good as next meeting date? or will there be speedhack?
Aug 04 18:02:42 <leverton>	at the moment, August 16  is winning
Aug 04 18:03:09 <leverton>	although August 30 is not far behind ... so I'd mark it as "pending SH date"
Aug 04 18:05:49 <trentg>	gotta go
Aug 04 18:06:08 <--	trentg has quit ("Leaving")
Aug 04 18:06:19 <M_Matty>	I'll vote for aug 16th if that'll help :)
Aug 04 18:06:48 <M_Matty>	I'm up for it
Aug 04 18:07:04 <allefant>	you can vote on allegro.cc
Aug 04 18:07:09 <leverton>	http://www.speedhack.allegro.cc/which-weekend
Aug 04 18:07:29 <leverton>	it's the only weekend I didn't vote for, heh
Aug 04 18:07:39 <M_Matty>	yeps I guessed. I haven't entered yet
Aug 04 18:08:23 <M_Matty>	Grozilla and the <working title>
Aug 04 18:08:40 <allefant>	heh
Aug 04 18:08:54 <leverton>	I must participate because the world needs a C64 game rewritten in D/Allegro
Aug 04 18:09:13 <allefant>	i should make a pyalleg game
Aug 04 18:09:53 <leverton>	I made PHP and Ruby bindings, but they were so horribly slow
Aug 04 18:10:01 <allefant>	:P
Aug 04 18:10:03 <leverton>	is pyAlleg usable for games?
Aug 04 18:10:11 <M_Matty>	hmm. now the blender python api written to use allegro would be damned handy
Aug 04 18:10:12 <allefant>	should be
Aug 04 18:10:32 <leverton>	I ported (peter's?) Molly the sheep (or whatever) SH game to Ruby
Aug 04 18:10:41 <leverton>	that was about the extent that it could handle, haha
Aug 04 18:10:49 <allefant>	i also committed a simple AGL binding, so with that it should be possible to do anything those pygame opengl games can do
Aug 04 18:10:52 <tjaden>	wow cool
Aug 04 18:11:03 <allefant>	heh
Aug 04 18:11:11 <allefant>	i don't remember, what game was that?
Aug 04 18:11:25 <tjaden>	molly and her bicycle pump
Aug 04 18:11:36 <leverton>	yeah , I digged it for the music
Aug 04 18:11:45 <tjaden>	which i nicked
Aug 04 18:11:54 <leverton>	puff the magic dragon midi I think
Aug 04 18:12:29 <allefant>	ahh, yes, i did play that.. http://www.speedhack.allegro.cc/blog/images/7809-1
Aug 04 18:13:02 <allefant>	but it looks like a cow..
Aug 04 18:13:10 <leverton>	because that's not the game
Aug 04 18:13:11 <leverton>	hehe
Aug 04 18:13:22 <allefant>	heh
Aug 04 18:13:36 <tjaden>	just keeping up the tradition
Aug 04 18:14:08 <tjaden>	speedhack and farm animals go hand in hand
Aug 04 18:15:54 <allefant>	ah, so that one :) http://www.speedhack.allegro.cc/blog/images/9483-1
Aug 04 18:16:04 <allefant>	with a white cat..
Aug 04 18:16:17 <tjaden>	>:|
Aug 04 18:16:19 <leverton>	:O
Aug 04 18:16:33 <leverton>	that was one of the best games!
Aug 04 18:16:58 <tjaden>	clearly it's a cloud with legs
Aug 04 18:17:35 <leverton>	Batman against the Vampires was great too
Aug 04 18:18:49 <tjaden>	i think i will go to bed
Aug 04 18:20:04 <--	tjaden has quit ("Leaving")