The Allegro Wiki is migrating to github at

Allegro Hack Day/2007 July 07/log

From Allegro Wiki
Jump to: navigation, search
Jul 07 14:04:52 -->	leverton ( has joined #allegro-dev
Jul 07 14:04:52 ---	ChanServ gives voice to leverton
Jul 07 14:09:59 <allefant>	hm, i wonder if tjaden wanted to join
Jul 07 14:12:00 <leverton>	he didn't put his name up on the wiki
Jul 07 14:12:46 <allefant>	Tomasu put his name, but he's probably still asleep, being even one or two hours behind your timezone :)
Jul 07 14:17:35 <leverton>	is everyone else in here awake?
Jul 07 14:18:48 <juvinious>	I didn't put my name ::)
Jul 07 14:19:42 <juvinious>	I just woke up a bit ago, I don't know if I'll be able to stick around through the entire time
Jul 07 14:20:24 <allefant>	well, if there's not much to discuss currently, it will be short
Jul 07 14:20:58 <allefant>	looking at the wiki, multi monitor support..
Jul 07 14:21:04 <allefant>	i don't know much about that
Jul 07 14:21:36 <juvinious>	as do I
Jul 07 14:21:40 <leverton>	is trentg here? I suppose he wrote most of the Display/Graphics topics
Jul 07 14:22:49 <allefant>	yeah, so far, it was mostly him and me working on the display/graphics stuff - so I'm never really sure the API is going to what is wanted for A5
Jul 07 14:23:27 <leverton>	well, IMO, the people who write the drivers basically define what Allegro is
Jul 07 14:24:12 <allefant>	yeah. but the two current drivers are for D3D and OpenGL, so things might look different for "classic", software-only drivers
Jul 07 14:24:41 <leverton>	well, Allegro 4 is software based ... I see nothing wrong with designing 5 with hardware in mind
Jul 07 14:25:42 <allefant>	yeah, and even things like phones/consoles have such abilities these days
Jul 07 14:25:57 <trentg>	Some features will be very difficult in software
Jul 07 14:25:58 <allefant>	er phones/handheld thingies
Jul 07 14:26:37 <allefant>	or otherwise, quite slow
Jul 07 14:26:53 <allefant>	e.g. one thing which was bothering me is transparency
Jul 07 14:27:03 <allefant>	for software, it's easiest to have a mask color
Jul 07 14:27:10 <allefant>	for OpenGL, it's easiest to have an alpha channel
Jul 07 14:27:37 <leverton>	I think we should focus on modern hardware
Jul 07 14:28:05 <leverton>	don't all video cards support basic OpenGL/DX?
Jul 07 14:28:22 <trentg>	Anything from the last 5 years I think
Jul 07 14:28:46 <trentg>	DX9 came out in 2002 I think
Jul 07 14:29:00 <leverton>	to me, things like GBA aren't worth worrying about
Jul 07 14:29:08 <leverton>	or whatever ports people are playing with
Jul 07 14:29:46 <allefant>	so we could drop things like palette support, and also go for floating point positions
Jul 07 14:30:25 <leverton>	well, I don't see why palette support would be needed in the hardware drivers
Jul 07 14:30:57 <leverton>	of course I never use palettes, so my opinion is biased
Jul 07 14:31:12 <allefant>	same here
Jul 07 14:31:22 <allefant>	the one use is probably writing an emulator
Jul 07 14:31:59 <trentg>	Not hard to have a color conversion table in that case
Jul 07 14:32:32 <allefant>	except for blitting
Jul 07 14:32:41 <allefant>	you'd need some kind of special blender
Jul 07 14:32:52 <trentg>	You could convert the sprites beforehand
Jul 07 14:32:58 <juvinious>	well the gba/nds ports are still separate from the main repo so yeah, not a concern :P
Jul 07 14:33:15 <allefant>	yeah, i was thinking about emulating palette effects
Jul 07 14:33:29 <allefant>	like having guys with different colors, from the same bitmap
Jul 07 14:33:42 <juvinious>	that would be neat
Jul 07 14:33:44 <trentg>	Yeah, that wouldn't be easy
Jul 07 14:34:11 <leverton>	I don't see a problem with saying palettes are only available in software drivers ... if that helps
Jul 07 14:34:53 <leverton>	palettes imply 8-bit dispays, which implies that you don't need hardware acceleration
Jul 07 14:35:27 <allefant>	true. and trentg coded support for that already anyway..
Jul 07 14:35:47 <trentg>	For what?
Jul 07 14:36:06 <allefant>	palettes in software mode
Jul 07 14:36:32 <allefant>	i.e. we can display palettes bitmaps in the conversion functions, apparently
Jul 07 14:36:36 <trentg>	Oh... yeah, color conversions
Jul 07 14:36:37 <allefant>	*paletted
Jul 07 14:37:51 <trentg>	I'm thinking palettes won't be difficult in hardware if we do software too
Jul 07 14:38:11 <trentg>	But it can always be a driver writes choice
Jul 07 14:40:17 <leverton>	Allegro 5.0 doesn't have to be perfect either ... hopefully more people start helping out once the new graphics drivers are working
Jul 07 14:41:01 <allefant>	true. we should probably try to get a new 4.9 version with initial working display/graphics API out soon
Jul 07 14:41:33 <allefant>	then a lot can still change from the current API
Jul 07 14:41:41 <trentg>	Yeah. Maybe we should trim out some stuff.. I'm thinking about patterend drawing.
Jul 07 14:42:08 <trentg>	It works ok with D3D but I'm guessing it won't with OpenGL.
Jul 07 14:42:26 <leverton>	it would help to have a milestone set
Jul 07 14:42:27 <allefant>	likely it does, just have to enable texturing
Jul 07 14:42:48 <allefant>	and it would be easy to also support rotating/scaling of the pattern
Jul 07 14:43:05 <trentg>	Ah, yeah, with texturing it would work better.
Jul 07 14:43:18 <allefant>	but i'm wondering if we really want something like that, as a better way to get the same effect would be al_polygon_3d..
Jul 07 14:43:45 <allefant>	(which somehow would defeat our resolve to throw away the 3D stuff)
Jul 07 14:44:54 <leverton>	is the OpenGL driver as far along as the DX one?
Jul 07 14:45:31 <allefant>	well, it also can open multiple resizable windows and do blitting and drawing in them..
Jul 07 14:45:59 <allefant>	but it e.g. has no blending yet
Jul 07 14:46:13 <allefant>	and it only supports RGBA8888 format for video bitmaps and screen
Jul 07 14:47:01 <allefant>	but probably enough to say it has reached sort of a first milestone
Jul 07 14:47:48 <leverton>	I think the earlier a 4.9 release is made, the easier it will be to ignore critics when 5.0 is ready
Jul 07 14:48:14 <leverton>	because we all know that everyone and his dog will complain about whatever new API is used
Jul 07 14:49:28 <allefant>	true :P
Jul 07 14:50:05 <allefant>	ok, so let's just aim for merging the newgfx branch back to trunk and getting out 4.9.2 (or whatever it will be) sometime this summer
Jul 07 14:50:40 <trentg>	Sounds good to me.
Jul 07 14:51:47 <leverton>	well, that takes care of the "palettes?" entry :)
Jul 07 14:52:12 <allefant>	so next is Build System.. that's about 4.2.2 i guess
Jul 07 14:52:12 <leverton>	what about the multi-monitor stuff ? is that from trentg?
Jul 07 14:52:21 <allefant>	Tomasu added it i think
Jul 07 14:52:22 <trentg>	I think that's from Tomasu
Jul 07 14:52:41 <leverton>	okay, he's not here to defend himself , so it can be shelved
Jul 07 14:52:58 <allefant>	i wouldn't mind having an API for it, al_get_monitors and so on, just the function he said are needed, basically..
Jul 07 14:53:03 <leverton>	yeah
Jul 07 14:53:31 <leverton>	I don't think we have to get totally carried away with multi-monitor support yet , but if it's trivial to implement then go for it
Jul 07 14:53:57 <allefant>	yeah. mostly it will be handled by the OS i guess, so we probably shouldn't even try to do weird things there
Jul 07 14:54:18 <leverton>	it's a tricky subject , I think
Jul 07 14:54:24 <leverton>	like I have 3 monitors on 2 cards
Jul 07 14:54:47 <leverton>	I'm not sure if you can actually request full screen per monitor ... or just full screen per card
Jul 07 14:55:25 <allefant>	i guess, the idea would be, have a game display your inventory in one monitor, and the main game in another..
Jul 07 14:55:56 <leverton>	I've never seen an app that sets full screen in both monitors on the same card
Jul 07 14:56:59 <allefant>	hm, i have two monitors at work, never tried putting anything to fullscreen yet though.. but i'd be able to test things in any case
Jul 07 14:57:21 <leverton>	I have a few windows apps that let me pick which _card_ to use as the full screen device
Jul 07 14:57:55 <allefant>	i see. so in allegro, it should be possible to enumerate those cards, so the user could be offered this choice
Jul 07 14:58:16 <leverton>	I think that's how Windows works
Jul 07 14:59:16 <allefant>	and Tomasu seems to know how X11 usually does it, so shouldn't be that hard to implement platform independent, I hope
Jul 07 15:00:10 <leverton>	yeah
Jul 07 15:00:45 <allefant>	oh, i just see, AL_ prefixes clashing with OpenAL
Jul 07 15:01:04 <leverton>	then we should ask the OpenAL guys to change their library ;)
Jul 07 15:01:07 <allefant>	from the things mentioned in #allegro, I most liked just using ALLEGRO_ instead of AL_ (but keeping al_)
Jul 07 15:01:11 <allefant>	heh
Jul 07 15:01:32 <leverton>	what name collisions are likely?
Jul 07 15:02:00 <allefant>	hm, i wonder if KittyCat is here
Jul 07 15:02:18 <allefant>	he brought it up
Jul 07 15:02:58 <leverton>	while I think it's smart not to use AL_* that already are colliding, I don't think we should necessarily change every AL_ constant into ALLEGRO_
Jul 07 15:03:32 <leverton>	it's not like they are going to have AL_DISPLAY, etc
Jul 07 15:04:26 <allefant>	hm, but AL_DOPPLER_FACTOR
Jul 07 15:04:58 <allefant>	AL_OUT_OF_MEMORY
Jul 07 15:05:26 <trentg>	It might be hard to remember which are AL_ and which are ALLEGRO_
Jul 07 15:05:54 <leverton>	is there a list of all the openal AL_* stuff?
Jul 07 15:06:11 <allefant>	i'm desperately trying to find one with google
Jul 07 15:06:18 <allefant>	but it seems, there isn't :/
Jul 07 15:07:15 <juvinious>	did you guys finish discussing the build system or haven't got to that yet?
Jul 07 15:07:27 <leverton>
Jul 07 15:07:43 <leverton>	we haven't started 
Jul 07 15:07:50 <juvinious>	ok
Jul 07 15:07:52 <allefant>	ahh, the source is of course a good place :)
Jul 07 15:07:52 <leverton>	although if you're interested and need to leave soon, we can 
Jul 07 15:09:24 <juvinious>	well, maybe just had some questions regarding the eventual goals of the build system were? ie scons, cmake etc etc
Jul 07 15:10:04 <leverton>	for MSVC, I think the answer is simply the project files
Jul 07 15:10:10 <leverton>	for other builds, I don't know
Jul 07 15:10:21 <juvinious>	well cmake can produce msvc project files
Jul 07 15:10:32 <juvinious>	but most of the time people think it's overly complex
Jul 07 15:10:46 <juvinious>	and perhaps having a static set would do it more justice
Jul 07 15:11:02 <leverton>	I already wrote scripts that create project files, so tha'ts not a problem
Jul 07 15:11:25 <leverton>	we'd have to include pre-built project files anyway, so it doesn't really matter how they get generated
Jul 07 15:12:43 <juvinious>	k
Jul 07 15:13:26 <juvinious>	I know kazz and allefant were working on scons
Jul 07 15:13:51 <juvinious>	and I worked with peter some time ago on some of the cmake stuff
Jul 07 15:13:52 <allefant>	scons doesn't use timestamps like (i believe) cmake does
Jul 07 15:14:07 <leverton>	what are the problems with makefiles ?
Jul 07 15:14:08 <allefant>	so it is fault safe
Jul 07 15:14:15 <juvinious>	cmake generates makefiles
Jul 07 15:14:21 <allefant>	normal makefiles need too much maintanance in linux
Jul 07 15:14:35 <allefant>	the standard way is to use autotools to generate them
Jul 07 15:14:47 <juvinious>	cmake allows the makefiles be configured to the users environment
Jul 07 15:14:53 <allefant>	but autotools is the most abominable software every created.. so that's why there's cmake
Jul 07 15:15:00 <juvinious>	so it's a good replacement for autotools
Jul 07 15:15:53 <juvinious>	as well I see lots of projects considering or moving to cmake
Jul 07 15:16:04 <leverton>	we could just say that A5 uses cmake and go from there
Jul 07 15:16:13 <leverton>	or Allegro 4.4
Jul 07 15:16:35 <allefant>	for 4.4, someone would need to backport it
Jul 07 15:16:46 <juvinious>	I can do that
Jul 07 15:16:49 <leverton>	if its easier to maintain, and someone is willing to write it, I don't see what the problem is
Jul 07 15:16:53 <juvinious>	whenever I get a chance
Jul 07 15:17:17 <leverton>	I know that the makefile system on windows has always been a painful experience
Jul 07 15:17:34 <juvinious>	I think it was due to the asm stuff
Jul 07 15:17:44 <leverton>	and all the magic
Jul 07 15:17:48 <allefant>	in 4.4, asm should not be used by default, i'd say
Jul 07 15:17:56 <juvinious>	agreed
Jul 07 15:18:15 <leverton>	with the MSVC project files, I wouldn't be surprised to see Allegro 4.2.2 be mostly C only now
Jul 07 15:18:19 <leverton>	from the Windows side
Jul 07 15:18:46 <allefant>	as our asm code is mostly an optimization only on ancient intel HW, no loss
Jul 07 15:18:59 <allefant>	e.g. on 64bit it won't work at all
Jul 07 15:19:11 <juvinious>	I can see two or three people complaining, but today I don't see the big difference as C is just as efficient
Jul 07 15:19:31 <leverton>	if those 2 or 3 people aren't in this room, then too bad ;)
Jul 07 15:19:36 <juvinious>	heh
Jul 07 15:19:55 <allefant>	well, at the time Bob made his MMX blendes, it was like twice as fast
Jul 07 15:20:06 <allefant>	but yeah, not today
Jul 07 15:20:36 <leverton>	simple benchmarks should silence critics
Jul 07 15:21:22 <juvinious>	nod
Jul 07 15:21:41 <trentg>	From my experience with stretch_blit, asm was something like 5% faster
Jul 07 15:22:16 <trentg>	Not worth maintaining for 5%
Jul 07 15:22:22 <leverton>	yeah
Jul 07 15:22:34 <leverton>	especially when that 5% is not 5% of your overall runtime 
Jul 07 15:22:59 <trentg>	Yeah, it would be like half of that
Jul 07 15:23:05 <allefant>	i remember some benchmarks from from some time ago, where some things where faster in asm, some in C
Jul 07 15:23:30 <juvinious>	yeah that was a few months back when that was brought up, I think it was on AD as well
Jul 07 15:24:28 <juvinious>	I think milan was the main opposition for default to C ::)
Jul 07 15:24:55 <allefant>	hm, i didn't know he knows asm
Jul 07 15:25:34 <juvinious>	idk, it was a while back so don't quote me on that :P
Jul 07 15:26:00 <allefant>	anyway, back to the AL_ - maybe we should discuss it on the mailing list?
Jul 07 15:26:25 <leverton>	I just dread having to type ALLEGRO_BITMAP and stuff like that
Jul 07 15:26:36 <allefant>	if we now decide for A_ or ALL_ or ALG_ or ALLEGRO_ here, and Evert or tjaden have some argument against it..
Jul 07 15:26:56 <leverton>	but  looking through the AL headers, they define a lot of crap
Jul 07 15:27:15 <allefant>	yeah, keeping AL and just avoiding clashes will be dangerous
Jul 07 15:27:19 <allefant>	especially as they might add stuff
Jul 07 15:27:30 <juvinious>	ok, well I'm out, if stuff is needed to be done with cmake I'll be able to help out on that front :)
Jul 07 15:27:40 <leverton>	what's the plan regarding Allegro 5's sound api?
Jul 07 15:28:00 <allefant>	KittyCat and mimix were doing some work on it in the past
Jul 07 15:28:27 <allefant>	from features, it was about as A4's
Jul 07 15:28:39 <leverton>	and people use OpenAL with Allegro?
Jul 07 15:28:57 <leverton>	where people > 1 or 2
Jul 07 15:29:00 <allefant>	the two implemented drivers were for OpenAL and alsa
Jul 07 15:29:16 <leverton>	that's what I was wondering
Jul 07 15:29:44 <leverton>	personally I don't like any of the alternatives
Jul 07 15:29:56 <allefant>	likely, we want it to be possible to just use OpenAL without any of allegro's sound api
Jul 07 15:29:56 <leverton>	it's probably going to have to be the least of the evils
Jul 07 15:30:38 <leverton>	A_ is too short
Jul 07 15:30:41 <leverton>	ALL_ is a word
Jul 07 15:30:44 <leverton>	ALG_ is hard to type
Jul 07 15:31:05 <leverton>	and when you get longer than that, you might as well just type ALLEGRO
Jul 07 15:31:16 <trentg>	KittyCat suggested ALX (eXtended api)
Jul 07 15:31:18 <allefant>	ALE? ALF? ALI?
Jul 07 15:31:54 <leverton>	we could just change the name from Allegro to something else, heh
Jul 07 15:31:54 <allefant>	not sure what F and I would be for :P
Jul 07 15:32:05 <allefant>	hm
Jul 07 15:32:14 <allefant>	AllegroPro
Jul 07 15:32:19 <allefant>	then use ap_ and AP_
Jul 07 15:32:35 <allefant>	or a5_ and A5_
Jul 07 15:32:40 <leverton>	I was going to say that
Jul 07 15:32:46 <leverton>	A5_ would be good for at least 10 years ;)
Jul 07 15:33:25 <leverton>	the thing is, al_* for functions is fine
Jul 07 15:33:45 <leverton>	which is why it's annoying that AL_* has potential problems
Jul 07 15:34:14 <allefant>	yeah, it's annoying. if C had namespaces, we'd just use namespace Allegro
Jul 07 15:34:34 <allefant>	then people could choose to use a long prefix, or none
Jul 07 15:34:56 <leverton>	I think we should take it up on the mailing list
Jul 07 15:35:46 <allefant>	ok. i'll write there, unless someone else wants to
Jul 07 15:35:50 <leverton>	my vote is for AL_* , but if it's far too problematic, then to use ALLEGRO_*
Jul 07 15:36:26 <leverton>	we already work around things like Windows' BITMAP 
Jul 07 15:36:39 <trentg>	I like ALLEGRO
Jul 07 15:37:10 <trentg>	I can see future problems using AL_
Jul 07 15:38:17 <leverton>	whatever it is, it needs to be consistent
Jul 07 15:38:49 -->	CGamesPlay (n=cgames@allegro/user/CGamesPlay) has joined #allegro-dev
Jul 07 15:38:49 ---	ChanServ gives voice to CGamesPlay
Jul 07 15:39:42 <trentg>	yeah, and with AL_ there could be some clashes with the sound api especially
Jul 07 15:40:03 <allefant>	but also with other parts
Jul 07 15:40:15 <allefant>	(else we could just have provided a way to exclude Allegro's sound API)
Jul 07 15:41:13 <leverton>	lets just have allefant post on the list, and we can see where it goes
Jul 07 15:42:04 <leverton>	I added the two build system entries on the wiki ... they are simple enough
Jul 07 15:42:23 <leverton>	first, I have a gcc-wrapper script for OS X that I made a while ago
Jul 07 15:42:42 <leverton>	it basically takes a standard gcc command and turns it into something that creates a universal (ppc/intel) file
Jul 07 15:43:28 <leverton>	I'll probably just post that on the mailing list ... I don't think there are many OS X users
Jul 07 15:44:05 <leverton>	the downside to the current method (using gcc 4 switches) is that it makes the makefile more complex and it doesn't have as good of backward compatibility with OS X
Jul 07 15:44:37 <leverton>	with my wrapper, you just set and everything happens for free
Jul 07 15:44:54 <trentg>	nice
Jul 07 15:45:24 <leverton>	I'm pretty sure it's the same approach that Apple's XCode IDE uses
Jul 07 15:45:55 <leverton>	also, I wrote "MSVC project files - should be completed before meeting"
Jul 07 15:46:01 <leverton>	which they are, so there's nothing to be said there
Jul 07 15:47:24 <leverton>	I also listed the DMC thing under Allegro 4.2.2 RC
Jul 07 15:47:51 <leverton>	it has problems with the al_find* functions
Jul 07 15:48:03 <leverton>	with the wide char (unicode, I assume) versions
Jul 07 15:48:22 <leverton>	I was wondering if anyone knew what other functions might be affected by that
Jul 07 15:48:35 <leverton>	DMC uses its own C runtime, not MSVC's
Jul 07 15:48:44 <allefant>	hm, which functions in particular?
Jul 07 15:48:56 <leverton>	the for_each_file_ex ones 
Jul 07 15:49:02 <leverton>	I noticed if I do this, it works:
Jul 07 15:49:06 <leverton>	os_type = OSTYPE_WIN98;
Jul 07 15:49:06 <leverton>	for_each_file_ex(buf2, 0, ~(FA_ARCH | FA_RDONLY | FA_DIREC),
Jul 07 15:49:06 <leverton>	                    parse_source,
Jul 07 15:49:06 <leverton>	                    (void *)(unsigned long)(strlen(buf2) - 3));
Jul 07 15:49:06 <leverton>	os_type = OSTYPE_WINVISTA;
Jul 07 15:49:23 <leverton>	because then it uses the non-wide char version of the function calls
Jul 07 15:49:30 <allefant>	ah, i thought the problem is some libc function used by it
Jul 07 15:49:38 <leverton>	(that's from the Allegro demo)
Jul 07 15:50:07 <leverton>	in fact, I had to add some #defines to the aldmc.h platform file
Jul 07 15:50:16 <leverton>	so I'm thinking maybe DMC just doesn't support it
Jul 07 15:51:59 <leverton>	yeah, I had to define "_wfinddata_t"
Jul 07 15:51:59 <allefant>	AL_FUNC(int, al_findfirst, (AL_CONST char *pattern, struct al_ffblk *info, int attrib));
Jul 07 15:52:21 <leverton>	when I hack os_type to be Win98, that triggers the OLD_WINDOWS define
Jul 07 15:52:34 <leverton>	which then uses the non-wide versions
Jul 07 15:52:37 -->	tjaden ( has joined #allegro-dev
Jul 07 15:52:37 ---	ChanServ gives voice to tjaden
Jul 07 15:52:48 <leverton>	but I didn't know if there were other allegro functions that would be affected
Jul 07 15:52:57 <leverton>	because if not, I'd just add a hack to say || DMC and be done with it
Jul 07 15:53:13 <tjaden>	hi, forgot
Jul 07 15:53:37 <leverton>	in your absense, we renamed Allegro 5 to AlleFant 5
Jul 07 15:53:46 <tjaden>	excellent
Jul 07 15:54:01 <allefant>	it's just so we can use af_ and AF_ prefixes, which won_t clash
Jul 07 15:54:18 <leverton>	that and it's so much cooler
Jul 07 15:54:40 <leverton>	tjaden: do you know what Allegro functions use _wfinddata_t?
Jul 07 15:54:43 <tjaden>	AF_ clashes with some constants from the sockets API i think
Jul 07 15:54:53 <leverton>	other than al_find and findnext ?
Jul 07 15:55:18 <leverton>	I'm not sure if DMC supports it (it uses its own runtime)
Jul 07 15:55:48 <tjaden>	that's all i see using a grep, so i guess that's it
Jul 07 15:55:49 <leverton>	see <> for a hack that works
Jul 07 15:56:15 <leverton>	setting the os_type to Win98 triggers the OLD_WINDOWS (or something)  define
Jul 07 15:56:21 <leverton>	which uses the older api
Jul 07 15:56:24 <allefant>	i assume your grep result started with /?
Jul 07 15:56:45 <tjaden>	?
Jul 07 15:57:18 <allefant>	ah, you refered to al_find and findnext
Jul 07 15:57:38 <leverton>	so I was thinking that just adding a check for DMC to those places that use the _wfinddat versions would sufficiently solve the problem for 4.2.2
Jul 07 15:57:56 <leverton>	unless that would cause some other problems
Jul 07 15:58:37 <tjaden>	i don't know. what is it?
Jul 07 15:59:20 <allefant>	only place i can see for them being used is wfile.c
Jul 07 15:59:51 <leverton>	ok, well, I'll write a quick patch to work around the DMC problem for now 
Jul 07 15:59:54 <tjaden>	the change that introduced it is this:
Jul 07 15:59:57 <tjaden>	r5863 (orig r5816):  elias | 2006-05-30 23:05:01 +1000
Jul 07 15:59:57 <tjaden>	Chris fixed some problems with non-ASCII filenames under Windows, and also made 
Jul 07 15:59:57 <tjaden>	me and Chris fixed problems for UTF8 filenames under Unix, as reported by Grzego
Jul 07 15:59:57 <tjaden>	broken.
Jul 07 16:00:23 <leverton>	the thing is, most people would use DMC for static builds of D
Jul 07 16:00:35 <leverton>	in which case, you really wouldn't probably use Allegro's functions for that anyway 
Jul 07 16:00:55 <tjaden>	erm, sorry, i was wrong
Jul 07 16:01:09 <allefant>	i wonder how the os_type = OSTYPE_WIN98; can affect this
Jul 07 16:01:18 <leverton>	because there's an OLD_WINDOWS define
Jul 07 16:01:22 <leverton>	that is triggered by the os type
Jul 07 16:01:33 <leverton>	and on the older windows, it calls the non-wide versions
Jul 07 16:01:41 <allefant>	but the #define can't be triggered by a runtime variable..?
Jul 07 16:01:50 <leverton>	it is a run time check
Jul 07 16:01:55 <allefant>	ahh
Jul 07 16:02:03 <allefant>	i see
Jul 07 16:02:09 <leverton>	that surprised me 
Jul 07 16:02:11 <tjaden>	ok, so the DMC version might not support wide chars but otherwise would be ok
Jul 07 16:02:12 <leverton>	I don't know the details of why it is
Jul 07 16:02:15 <allefant>	so OLD_WINDOWS is just a global variable
Jul 07 16:02:16 <leverton>	yeah
Jul 07 16:02:23 <leverton>	yes to tjaden
Jul 07 16:02:33 <leverton>	that's the only problem I've found, anyway 
Jul 07 16:02:37 <tjaden>	i think that's acceptable
Jul 07 16:02:39 -->	kazzmir ( has joined #allegro-dev
Jul 07 16:02:39 ---	ChanServ gives voice to kazzmir
Jul 07 16:03:03 <allefant>	yeah. if someone knows how to get unicode names with DMC, we can always add that later
Jul 07 16:03:20 <leverton>	yeah
Jul 07 16:03:34 <allefant>	using a #define or other global variable (i still wonder why there is that IS_OLD_WINDOWS though :P)
Jul 07 16:03:40 <allefant>	but it seems useful now :)
Jul 07 16:04:12 <leverton>	the define would better if it were something like UNICODE_SUPPORT
Jul 07 16:04:40 <leverton>	I don't know if the old windows define is even used for anything else
Jul 07 16:04:49 <tjaden>	doesn't look like it
Jul 07 16:04:57 <tjaden>	you could rename it
Jul 07 16:05:34 <tjaden>	make it a "function-macro" like: _al_win_os_supports_unicode()
Jul 07 16:06:16 <allefant>	#define IS_OLD_WINDOWS (os_type==OSTYPE_WIN3  || os_type==OSTYPE_WIN95 ||
Jul 07 16:06:24 <leverton>	do we have an easy runtime check for compiler?
Jul 07 16:06:43 <tjaden>	don't think so
Jul 07 16:06:44 <leverton>	if not, I can find a DMC define
Jul 07 16:06:51 <leverton>	I'm sure it defines something
Jul 07 16:06:54 <leverton>	duh
Jul 07 16:06:56 <leverton>	i want run time ;P
Jul 07 16:07:03 <tjaden>	do you?
Jul 07 16:07:05 <leverton>	well
Jul 07 16:07:08 <leverton>	doesn't matter, I guess
Jul 07 16:07:42 <leverton>	for DMC it's always negative 
Jul 07 16:07:56 <leverton>	for MSVC, it would still be runtime
Jul 07 16:08:02 <allefant>	IS_OLD_WINDOWS should really by replaced by a variable then i guess
Jul 07 16:08:27 <allefant>	which is set according to the current os_type checks, or else (with compile time check) if it's DMC
Jul 07 16:09:22 <leverton>	okay, I'll get a patch sent to AD
Jul 07 16:10:54 <leverton>	that concludes my topics
Jul 07 16:11:16 <tjaden>	do you think we will conflict with openal?
Jul 07 16:11:41 <allefant>	i sent a mail about that to the mailing list before..
Jul 07 16:12:00 <leverton>
Jul 07 16:12:05 <leverton>	I posted that link earlier in the session
Jul 07 16:12:21 <trentg>	Even if there is no conflict, it would still be very confusing when mixing the apis
Jul 07 16:12:36 <tjaden>	true
Jul 07 16:12:38 <allefant>	and as i wrote, they might add stuff and not care about us
Jul 07 16:12:43 <kazzmir>	what about using alleg_ as the prefix
Jul 07 16:12:50 <tjaden>	too long for mine
Jul 07 16:12:52 <leverton>	al_ isn't the problem 
Jul 07 16:12:54 <leverton>	AL_ is
Jul 07 16:13:02 <tjaden>	AG_?
Jul 07 16:13:10 <tjaden>	ALG_?
Jul 07 16:13:33 <allefant>	AG means the same as Inc. in german :P
Jul 07 16:13:59 <tjaden>	gives a professional edge
Jul 07 16:14:03 <leverton>	I don't think any solution will be pretty
Jul 07 16:14:24 <allefant>	and should we go al_ and AG_ or ag_ and AG_ then?
Jul 07 16:14:46 <allefant>	and i'd prefer a5_ and A5_ i think
Jul 07 16:14:54 <tjaden>	yuck
Jul 07 16:15:08 <leverton>	al_BITMAP (don't shoot me)
Jul 07 16:15:14 <kazzmir>	it would be a huge pain but you could have short_prefix.h which uses #define to make al_ for all the things
Jul 07 16:15:16 <allefant>	almost the same to type, 5 is just 2 rows above g
Jul 07 16:15:29 <tjaden>	looks poo
Jul 07 16:15:48 <allefant>	a5_line()
Jul 07 16:16:02 <allefant>	hm, maybe you're right
Jul 07 16:16:11 <leverton>	a5_lin3() could be the l33t version
Jul 07 16:17:31 <tjaden>	ALG_EVENT_KEY_DOWN
Jul 07 16:17:47 <tjaden>	ALLEG_EVENT_KEY_DOWN
Jul 07 16:17:58 <allefant>	ALLEGRO_EVENT_KEY_DOWN
Jul 07 16:18:11 <tjaden>	hey!
Jul 07 16:18:37 <tjaden>	AX_EVENT_KEY_DOWN
Jul 07 16:18:46 <tjaden>	X because X is cool
Jul 07 16:18:57 <leverton>	AZ_EVENT_KEY_DOWN
Jul 07 16:19:02 <allefant>	someone suggested it as eXtended already :)
Jul 07 16:19:03 <leverton>	Z because A to Z is even cooler
Jul 07 16:19:46 <allefant>	Z could be leet for 5, so Allegro Z
Jul 07 16:19:53 <allefant>	(not i have 0 idea about leet speak :P)
Jul 07 16:19:55 <allefant>	*note
Jul 07 16:20:13 <tjaden>	LA_EVENT_KEY_DOWN
Jul 07 16:20:19 <leverton>	al_EVENT_KEY_DOWN
Jul 07 16:20:20 <tjaden>	it's french
Jul 07 16:20:41 <leverton>	I just don't want to type allegro_blit or alg_blit or alleg_blit or whatever
Jul 07 16:20:49 <allefant>	i like LA :)
Jul 07 16:20:55 <leverton>	I'll have to get a wide screen monitor
Jul 07 16:21:03 <allefant>	and "allegro" also is french (or italian)
Jul 07 16:21:48 <leverton>	la is also part of "do re me fa so la ti do" 
Jul 07 16:21:50 <trentg>	AGL_ would be good
Jul 07 16:21:53 <leverton>	and los angeles
Jul 07 16:22:15 <allefant>	LAG_ (in case we add networking)
Jul 07 16:22:24 <tjaden>	honestly i like AG_ the best
Jul 07 16:22:29 <leverton>	agl = Aglero?
Jul 07 16:22:36 <trentg>	Allegro Game Library
Jul 07 16:22:58 <allefant>	ag_draw_bitmap(AG_BITMAP *bitmap, ...)
Jul 07 16:23:02 <allefant>	i'd be fine with that
Jul 07 16:23:14 <leverton>	agl sounds like allegro gl
Jul 07 16:23:36 <allefant>	AG_ could be for Allegro Game
Jul 07 16:23:52 <leverton>	ag is ugly , but 2 keys are better than 3
Jul 07 16:24:26 <tjaden>	ugly in which way, conceptually or just the two letters together?
Jul 07 16:24:38 <tjaden>	or both :)
Jul 07 16:24:51 <leverton>	basically it looks ugly to me ... 
Jul 07 16:25:01 <allefant>	and germans would say Aktien-Gesellschaft when seeing it
Jul 07 16:25:06 <leverton>	that and I live among farmers, so ag = agriculture to me
Jul 07 16:25:23 <tjaden>	it only reminds me of pirates
Jul 07 16:25:24 <trentg>	I would prefer alg_ and ALG_ ... sounds like Allegro
Jul 07 16:25:36 <allefant>	arr_
Jul 07 16:25:57 <leverton>	seriously, I'm starting to like allefant's Allegro Pro => ap_ suggestion  , heh
Jul 07 16:26:05 <tjaden>	al_ and ALG_ would be okay
Jul 07 16:26:31 <leverton>	the mix seems confusing
Jul 07 16:26:45 <tjaden>	arrrg
Jul 07 16:28:44 <allefant>	so, we want 2 characters, same for lower and upper case, and it should sound like Allegro..
Jul 07 16:29:02 <leverton>	AL AE AG AR AO
Jul 07 16:29:17 <tjaden>	arrg, i like AR now
Jul 07 16:30:09 <tjaden>	arrg, destroy the event queues, me hearties
Jul 07 16:30:27 <trentg>	Of those, I like ag
Jul 07 16:30:31 <leverton>	ap => allegro pirate
Jul 07 16:31:10 <trentg>	we could skip to version 10 and call it ax
Jul 07 16:31:13 <tjaden>	ao might conflict with libao
Jul 07 16:31:29 <allefant>	or just X for meaning any version
Jul 07 16:31:47 <trentg>	or allegro eXtended as mentioned
Jul 07 16:33:06 <trentg>	or even alx
Jul 07 16:33:22 <trentg>	looks like Alex :)
Jul 07 16:33:42 <tjaden>	we don't have to change the name, just say that the prefix was chosen to avoid clashes with everyone else
Jul 07 16:33:51 <allefant>
Jul 07 16:34:07 <allefant>	not that we wouldn't find any obscure library for whatever we choose :P
Jul 07 16:34:22 <tjaden>	well, not everyone else, but libraries in the multimedia and related fields
Jul 07 16:34:54 <leverton>	well, my favorite choice of the moment is al_ and ALLEGRO_
Jul 07 16:35:00 <tjaden>	LG_EVENT_KEY_DOWN!
Jul 07 16:35:12 <tjaden>	GE_EVENT_KEY_DOWN
Jul 07 16:35:23 <leverton>	the wiki currently has stuff like ALLEGRO_PIXEL_FORMAT_ABGR_8888
Jul 07 16:35:39 <leverton>	and shaving 5 key strokes off that isn't going to make much of a difference :P
Jul 07 16:35:39 <trentg>	That was a placeholder
Jul 07 16:35:42 <leverton>	hehe
Jul 07 16:35:47 -->	MattyMatt ( has joined #allegro-dev
Jul 07 16:35:47 ---	ChanServ gives voice to MattyMatt
Jul 07 16:35:58 <allefant>	i wouldn't mind ALLEGRO_ - but then, i do always avoid abbreviations myself
Jul 07 16:36:11 <allefant>	so my own function names can easily span a whole lined
Jul 07 16:36:15 <allefant>	*line
Jul 07 16:36:24 <leverton>	to me, it's just that al_* is so nice 
Jul 07 16:36:26 <trentg>	I like ALLEGRO_ as well
Jul 07 16:36:30 <leverton>	and it's a shame to change it just for the defines
Jul 07 16:36:57 <tjaden>	ALLEGRO_ is ok for the constants, but i don't want it on the functions
Jul 07 16:37:22 <leverton>	al_set_new_display_flags(ALLEGRO_OPENGL);
Jul 07 16:37:33 <tjaden>	yes, that's nice
Jul 07 16:37:34 <MattyMatt>	that looks good to me
Jul 07 16:37:46 <leverton>	ALLEGRO_BITMAP or AL_BITMAP ?
Jul 07 16:37:50 <allefant>	yeah, i think it's the least weird of all the options discussed
Jul 07 16:38:02 <trentg>	We should use ALLEGRO_ for all constants and structures
Jul 07 16:38:30 <allefant>	AL_BITMAP could be used by OpenAL, if there's something in sound processing using a map of bits
Jul 07 16:38:53 <trentg>	It would be too confusing to have a mix of AL_ and ALLEGRO_
Jul 07 16:38:53 <tjaden>	i'm just afraid in practice it will be ugly *and* annoying
Jul 07 16:39:21 <leverton>	yeah
Jul 07 16:39:29 <leverton>	I distlike ALLEGRO_* for structs
Jul 07 16:39:30 <MattyMatt>	any prefix is, and OpenAL has stolen the least annoying
Jul 07 16:39:43 <tjaden>	no, i like short prefixes
Jul 07 16:39:53 <allefant>	if (((ALLEGRO_KEY_EVENT *)event).code == ALLEGRO_ESCAPE)
Jul 07 16:39:57 <tjaden>	things without prefixes look wrong to me now
Jul 07 16:40:11 <tjaden>	like they don't belong
Jul 07 16:40:25 <MattyMatt>	or are system calls
Jul 07 16:40:47 <CGamesPlay>	AG seems to be the next most logical after AL
Jul 07 16:40:56 <MattyMatt>	which Allegro is, to some people :)
Jul 07 16:41:04 <MattyMatt>	AGL
Jul 07 16:41:25 <MattyMatt>	that's similar to matrox's MGL
Jul 07 16:42:09 <MattyMatt>	AGL means Allegro GL though, not games lib
Jul 07 16:43:00 <allefant>	we are going in circles :P
Jul 07 16:43:33 <MattyMatt>	AGL_BITMAP * bmp = create_bitmap(AGL_STYLISH | AGL_DEPTH_96)
Jul 07 16:43:59 -->	Sevalecan (i=sevaleca@allegro/user/Sevalecan) has joined #allegro-dev
Jul 07 16:43:59 ---	ChanServ gives voice to Sevalecan
Jul 07 16:44:18 <allefant>	almost pronounced as UGLY_BITMAP
Jul 07 16:44:29 <MattyMatt>	yeah
Jul 07 16:45:51 <MattyMatt>	I think ALLEGRO_ for structs and consts is the 'best' way, but it will cause nearly all users to keep the compatability layer active
Jul 07 16:46:26 <leverton>	compatability layer is another topic in itself ;)
Jul 07 16:46:39 <allefant>	if we get proper D and C++ wrapper who could hide it in a namespace, wouldn't be that much of a problem
Jul 07 16:47:01 <MattyMatt>	yeah most users prefer C++ anyway
Jul 07 16:47:03 <leverton>	hehe, I was going to say that as a DAllegro user, I ultimately don't care 
Jul 07 16:47:40 <allefant>	and i'm fine with either, the prefix is not what makes a good or bad API
Jul 07 16:49:03 <MattyMatt>	so use a long prefix for now.  it's easier to find than a short one with global s'n'r
Jul 07 16:49:41 <tjaden>	well, is ALG_ too objectionable?
Jul 07 16:49:50 <trentg>	I don't mind it
Jul 07 16:50:21 <MattyMatt>	it doesn't rip off the tounge. it's like a fake 3LA
Jul 07 16:50:23 <allefant>	so al_ and ALG_?
Jul 07 16:50:33 <MattyMatt>	^trip off
Jul 07 16:50:55 <tjaden>	that's what i'm thinking
Jul 07 16:51:16 <tjaden>	at least you can still read them as 'allegro'
Jul 07 16:51:42 <leverton>	I prefer ALLEGRO_BITMAP over ALG_BITMAP
Jul 07 16:51:48 <MattyMatt>	me too
Jul 07 16:52:01 <leverton>	in fact, I wrote it as AGL_BITMAP before I corrected it, heh
Jul 07 16:52:37 <tjaden>	ok, go for the conservative option then
Jul 07 16:52:50 <tjaden>	try again later
Jul 07 16:52:51 <leverton>	mainly, I just don't want to change al_
Jul 07 16:53:27 <MattyMatt>	yeah, keep al_ for now. OpenAL will use alBlah exclusively
Jul 07 16:53:41 <allefant>	but change to ALLEGRO_?
Jul 07 16:53:55 <tjaden>	yes AL_ -> ALLEGRO_ until we can figure out something
Jul 07 16:54:03 <allefant>	ok
Jul 07 16:54:37 <allefant>	probably we should merge newgfx back to trunk before the change
Jul 07 16:55:06 <tjaden>	i think it needs a bit of cleanup
Jul 07 16:55:22 <tjaden>	or have all the commented out code been restored?
Jul 07 16:55:42 <allefant>	nah, it needs cleanup
Jul 07 16:55:54 <allefant>	i believe there's also some unused 4.x code now
Jul 07 16:56:11 <tjaden>	btw, i still can't run it on my X server
Jul 07 16:56:21 <tjaden>	glx 1.3 functions, i think
Jul 07 16:56:27 <tjaden>	what are you running?
Jul 07 16:56:39 <allefant>	yeah, i should copy over the agl initialization code
Jul 07 16:56:55 <allefant>	(and rename the driver to GLX instead of XDUMMY)
Jul 07 16:57:00 <allefant>	glx 1.3 here i think
Jul 07 16:57:10 <tjaden>	which X server?
Jul 07 16:57:19 <allefant>	xorg 11.0
Jul 07 16:58:12 <allefant>	can you find out what is not supported?
Jul 07 16:58:49 <tjaden>	i'll try
Jul 07 16:59:14 <allefant>	likely glXChooseFBConfig or glXCreateNewContext or 
Jul 07 16:59:30 <allefant>	those are not in glx 1.2 i think
Jul 07 17:00:02 <allefant>	best would be to just use the (working) allegrogl code
Jul 07 17:00:24 <tjaden>	yes, i remember when i did the old a5 demo (so long ago) that i used that, then switched away so it would work on solaris
Jul 07 17:00:45 <tjaden>	now it doesn't work on my linux, weird
Jul 07 17:00:58 <MattyMatt>	bitrot
Jul 07 17:01:24 <MattyMatt>	it happens to the most stable code
Jul 07 17:02:30 <allefant>	i'll change to the allegrogl code. the reason i was hesitating is, pulling in AGL with all the extension checking means the code will get more complicated and harder to work on
Jul 07 17:02:33 <allefant>	but can't be helped
Jul 07 17:03:11 <tjaden>	great, then i can try it out
Jul 07 17:05:20 <tjaden>	glXCreateNewContext is the problem
Jul 07 17:06:44 <allefant>	ok, i should use glXCreateContext instead
Jul 07 17:08:44 <allefant>	d->context = glXCreateContext(system->xdisplay, vi, NULL, True);
Jul 07 17:08:49 <allefant>	replacing with that should work
Jul 07 17:09:09 <allefant>	i just must have coded this off an example which used the other one
Jul 07 17:10:47 <allefant>	ah, just see, there's still points on the wiki: signed vs. unsigned types
Jul 07 17:11:38 <allefant>	i think we should not use unsigned at all, e.g. al_create_bitmap(int w, int h) instead of al_create_bitmap(unsigned int w, unsigned int h)
Jul 07 17:11:56 <allefant>	since in my experience, the unsigned leads to all sorts of warnings from gcc
Jul 07 17:12:31 <leverton>	I agree
Jul 07 17:13:29 <leverton>	I think the notable exception would be for unsigned chars where appropriate
Jul 07 17:13:41 <MattyMatt>	yeah, and x & y can be negative anyway, so you'd end up with mixed params
Jul 07 17:15:00 <tjaden>	allefant: glXCreateContext didn't work either. anyway, never mind it for now
Jul 07 17:15:32 <tjaden>	i agree about the signedness thing
Jul 07 17:16:16 <allefant>	yeah, i'll read through the AllegroGL code and do like it's done there
Jul 07 17:16:58 <allefant>	ok. so last point was, do we want things like bitmap->w - or should we only allow al_get_bitmap_width(bitmap)
Jul 07 17:17:20 <tjaden>	in my mind there are two uses for structs
Jul 07 17:17:30 <tjaden>	as objects, and as tuples
Jul 07 17:18:06 <allefant>	ah, yes. on the wiki it says "Should we discourage use of structure internals?" - but i think it was about when trentg and me talked about bitmap->w
Jul 07 17:18:27 <trentg>	Yes
Jul 07 17:18:34 <leverton>	I prefer bitmap->w
Jul 07 17:18:45 <leverton>	if I change it, I'm an idiot
Jul 07 17:19:13 <trentg>	Some things don't work exactly though. Like bitmap->memory for display bitmaps.
Jul 07 17:19:30 <MattyMatt>	yeah but that's well known
Jul 07 17:19:40 <allefant>	so we just document it properly
Jul 07 17:19:47 <allefant>	e.g. bitmap->memory would not appear in the docs
Jul 07 17:19:53 <MattyMatt>	line[] are only valid for memory bitmaps
Jul 07 17:20:10 <allefant>	and line is gone anyway, in favor of AL_LOCK_REGION
Jul 07 17:20:41 <allefant>	sorry, ALLEGRO_LOCKED_REGION
Jul 07 17:20:43 <MattyMatt>	hmm, that's a pain for custom blits that use them
Jul 07 17:20:59 <tjaden>	in D you could set up a property (?) so bitmap.w calls al_get_bitmap_width, right?
Jul 07 17:21:02 <allefant>	yeah, but as we said earlier, we focus on D3D and OpenGL
Jul 07 17:21:18 <allefant>	same in Python
Jul 07 17:21:24 <leverton>	tjaden: I don't believe D supports that
Jul 07 17:22:50 <allefant>	python has it easy supporting that, as everything happens at runtime (it looks up the "w", then looks if it is an attribute or function, then looks in both cases what C function to call..)
Jul 07 17:23:14 <tjaden>	yes, python is balls
Jul 07 17:23:26 <leverton>	ruby and php can do it as well
Jul 07 17:23:36 <tjaden>	also balls
Jul 07 17:24:38 <tjaden>	i'm pretty sure D can do it though
Jul 07 17:24:38 <MattyMatt>	I think languages that use getters and setters can be forced to use them
Jul 07 17:24:59 <MattyMatt>	e.g. the members could be private in the C++ wrapper
Jul 07 17:25:24 <allefant>	and if some language can't access struct members, there can be glue code to define getters/setters
Jul 07 17:26:22 <allefant>	but it's why i initially thought it's nice to have no structs at all
Jul 07 17:27:03 <MattyMatt>	you can't write a C lib without them :p
Jul 07 17:27:14 <allefant>	could just do: dll = LoadLibrary("allegro.gll"); bitmap = dll.al_create_bitmap(w, h); print dll.al_get_bitmap_width(bitmap);
Jul 07 17:27:17 <allefant>	without any wrapper at all
Jul 07 17:27:27 <MattyMatt>	and any language that can't access them is broken
Jul 07 17:27:29 <allefant>	yes, in the API
Jul 07 17:28:19 <MattyMatt>	yeah no harm in having getters/setters there
Jul 07 17:28:21 <allefant>	well, in the python case, a wrapper (e.g. SWIG or pyrex) is needed
Jul 07 17:29:46 <tjaden>	i just tested the D thing and it works
Jul 07 17:30:49 <tjaden> Properties are member functions that can be syntactically treated as if they were fields.
Jul 07 17:31:13 <allefant>	nice
Jul 07 17:31:36 <leverton>	yeah, I just saw that
Jul 07 17:31:53 <tjaden>	open to abuse, but anyway
Jul 07 17:32:20 <allefant>	even read/write-only
Jul 07 17:32:38 <MattyMatt>	I've been looking at how COM is usable both in C and C++, by dereferencing the vtable manually in the C version.
Jul 07 17:33:23 <leverton>	but how does this relate to the API itself?
Jul 07 17:33:28 <MattyMatt>	dunno if that's possible with gcc, giving the vtable a C label like that
Jul 07 17:33:37 <leverton>	DAllegro is just a direct import of Allegro
Jul 07 17:34:13 <leverton>	I'm writing a D wrapper over top of DAllegro, and of course, it could make use of it
Jul 07 17:34:29 <allefant>	yeah, whether we have an al_get_bitmap_width wouldn't really matter that much
Jul 07 17:35:00 <tjaden>	is bitmap.w the only one?
Jul 07 17:35:14 <leverton>	I just think any get* function should have justification
Jul 07 17:35:25 <leverton>	other than to make it read only
Jul 07 17:35:36 <tjaden>	easier to maintain ABI compatibility
Jul 07 17:36:03 <tjaden>	ability to change internals without worrying about the interface
Jul 07 17:36:03 <MattyMatt>	for when int=128 bits?
Jul 07 17:36:28 <allefant>	there could e.g. be an AL_BITMAP with variable dimensions
Jul 07 17:36:35 <trentg>	There are others
Jul 07 17:36:37 <allefant>	backbuffer of a resizable window or something
Jul 07 17:36:47 <trentg>	Like clipping. If the user sets clipping manually, it won't work with D3D.
Jul 07 17:36:50 <allefant>	(just as example, it's not how it is actually done)
Jul 07 17:37:14 <allefant>	clipping already is a function in 4.x
Jul 07 17:37:16 <MattyMatt>	a bitmap always has a width and height at any moment in time
Jul 07 17:37:46 <allefant>	MattyMatt: yes, but it might not be available as the .w and .h variables (in my contrieved case)
Jul 07 17:38:12 <tjaden>	will the bitmap w/h be needed as often as in 4.x?
Jul 07 17:38:22 <tjaden>	e.g. you needed it just to do blit
Jul 07 17:38:36 <tjaden>	although draw_sprite was okay
Jul 07 17:38:42 <trentg>	Not as much, but still often I think
Jul 07 17:38:46 <MattyMatt>	it's used too often to lose
Jul 07 17:39:33 <tjaden>	maybe separate BITMAP into struct {BITMAP_INTERNALS *p; int w; int h} BITMAP
Jul 07 17:39:34 <MattyMatt>	I can't think how to macro blah->foo to al_blah_get_foo()
Jul 07 17:40:55 <trentg>	Yes, I think it would be a good idea to hide stuff other than w/h
Jul 07 17:41:01 <MattyMatt>	that's already done with the vtable. that could have a pointer to a struct
Jul 07 17:41:50 <allefant>	i agree, we sholdn't have internals in the public API
Jul 07 17:42:00 <MattyMatt>	lotsa derefs though.  bmp->vtable->internals->memory
Jul 07 17:42:31 <allefant>	we could also use the "derivation" trick already used for some stuff
Jul 07 17:43:03 <allefant>	struct AL_BITMAP {w, h}; struct AL_BITMAP_INTERNAL {AL_BITMAP bitmap; int clipx, clipy; void *memory;};
Jul 07 17:43:18 <allefant>	struct AL_BITMAP {int w, h}; struct AL_BITMAP_INTERNAL {AL_BITMAP bitmap; int clipx, clipy; void *memory;};
Jul 07 17:43:51 <leverton>	Most of the structs on have no "public" properties
Jul 07 17:44:08 <trentg>	But they're used a lot
Jul 07 17:44:24 <leverton>	err, I guess more do than I first though
Jul 07 17:44:29 <leverton>	*thought
Jul 07 17:45:13 <allefant>	hm, i didn't even no about "clip, cl, cr, ct, cb" being public
Jul 07 17:45:28 <allefant>	especially as cr and cb use non-default semantics
Jul 07 17:45:43 <allefant>	i.e. one pixel outside, unlike the rest of allegro
Jul 07 17:54:49 <trentg>	That derivation trick should work for this
Jul 07 17:55:38 -->	TomasuDlrrp ( has joined #allegro-dev
Jul 07 17:55:38 ---	ChanServ gives voice to TomasuDlrrp
Jul 07 17:55:53 <TomasuDlrrp>	I seem to be quite late...
Jul 07 17:55:59 ---	TomasuDlrrp is now known as Tomasu
Jul 07 17:56:00 <tjaden>	i might go to sleep soon. anything i need to deal with?
Jul 07 17:56:16 <Tomasu>	have we talked about Multi monitor handling yet?
Jul 07 17:56:40 <trentg>	briefly
Jul 07 17:56:45 <allefant>	anything related to 4.2.2 maybe? i kept completely out of that :P
Jul 07 17:57:26 <Tomasu>	I'd like to get multi monitor stuff finalized so we can get proper Xinerama and whatnot in.
Jul 07 17:57:42 <tjaden>	recently i found out netbsd has a package system called pkgsrc and allegro is in there.. with a bunch of patches. i might try to roll those in
Jul 07 17:57:55 <Tomasu>	sounds cool
Jul 07 17:58:13 <allefant>	was the OSX and MSVC built system stuff related to 4.2.2 as well?
Jul 07 18:00:02 <Tomasu>	how can we say "full screen on "Monitor 2" or "Full Screen on the left monitor" with a5?
Jul 07 18:01:05 <Tomasu>	of course for a given DISPLAY that is
Jul 07 18:02:34 <trentg>	I imagine to to follow the rest of the api, it would be something like al_set_display_monitor(num); al_create_display(....);
Jul 07 18:03:42 <Tomasu>	but that really only needs to apply to full screen modes..
Jul 07 18:04:41 <MattyMatt>	naah, it'll be handy for windows too
Jul 07 18:04:48 <Tomasu>	not really.
Jul 07 18:04:58 <trentg>	It could be
Jul 07 18:05:00 <Tomasu>	for windowed mode you have absolute positions...
Jul 07 18:05:03 <MattyMatt>	for centring them on the chosen screen and stuff
Jul 07 18:05:27 <Tomasu>	monitor2->x/y etc
Jul 07 18:05:48 <MattyMatt>	you do at the O/S level, but it would be nice if allegro gave you a 'screen relative' system
Jul 07 18:06:13 <Tomasu>	I just breifly thought about that, but there arent any "position window here" stuff in allegro afaik
Jul 07 18:06:23 <Tomasu>	where that would actually be usefull
Jul 07 18:06:37 <Tomasu>	for full screen modes its most usefull to beable to set different full screen modes and whatnot.
Jul 07 18:06:46 <MattyMatt>	mostly in saving and loading pos on exit and startup 
Jul 07 18:06:58 <tjaden>	at least the MSVC stuff is
Jul 07 18:06:59 <--	tjaden has quit (Remote closed the connection)
Jul 07 18:07:12 <Tomasu>	you can just save the absolute pos...
Jul 07 18:07:41 <MattyMatt>	I'd rather have it screen,x,y in my config
Jul 07 18:08:45 <MattyMatt>	handy if you have screens that aren't covered by your O/S, like serial attached LCD etc
Jul 07 18:11:36 <Tomasu>	but should allegro even bother with that?
Jul 07 18:11:44 <Tomasu>	I just thought of one case where it might be needed
Jul 07 18:12:03 <Tomasu>	if the absolute positions of a second screen change when you change a mode of another
Jul 07 18:12:10 <MattyMatt>	yeah
Jul 07 18:12:25 <MattyMatt>	s,x,y lets you keep the res independent
Jul 07 18:12:51 <--	allefant has quit (Nick collision from services.)
Jul 07 18:12:51 ---	You are now known as allefant
Jul 07 18:12:55 <Tomasu>	there still arent any allegro functions to say "move window here" afaik
Jul 07 18:13:18 <MattyMatt>	there is an internal one, in the system driver
Jul 07 18:13:35 <Tomasu>	that doesnt help people that want to do it :P
Jul 07 18:13:38 <MattyMatt>	you can say system_driver->move(x,y,w,h); 
Jul 07 18:13:57 <MattyMatt>	and it'll work, I think, except maybe for threading
Jul 07 18:13:58 <allefant>	in 4.9, it can easily get added, there's already resizing
Jul 07 18:14:39 <Tomasu>	and since its allegro hack day, I'll load up my fshook kate session :D
Jul 07 18:14:39 <MattyMatt>	ah no, it's in win_gfx_driver, not system_driver, so it's win only
Jul 07 18:15:00 <allefant>	and in X11, it would automatically work with multi monitor i assume (big coordinates push it to the right monitor)
Jul 07 18:15:21 <allefant>	0/0 would be the left-most one
Jul 07 18:15:21 <Tomasu>	same with windows I'd assume
Jul 07 18:15:31 <Tomasu>	but really, matt here is arguing for relative pos
Jul 07 18:17:23 <Tomasu>	?? svn
Jul 07 18:17:24 <Allegro>	Allegro SVN Repository:
Jul 07 18:17:24 <Allegro>	Allegro SVN webview:
Jul 07 18:17:24 <Allegro>	mirrors:
Jul 07 18:17:24 <Allegro>	snapshots:
Jul 07 18:18:07 <MattyMatt>	there should be a way of calculating relative pos anyway.  allegro should discover the absolute pos of each screen at least
Jul 07 18:18:23 <Tomasu>	but if that changes when a mode is changed...
Jul 07 18:18:33 <Tomasu>	hmm
Jul 07 18:18:35 <Tomasu>	I misread that
Jul 07 18:19:18 <MattyMatt>	I'm not sure what Windows does when the left screen changes size
Jul 07 18:19:25 <MattyMatt>	or goes fullscreen
Jul 07 18:19:38 <Tomasu>	I'm not even sure what Xinerama does.
Jul 07 18:20:17 <MattyMatt>	so with all us clueless people around, it will defo help is allegro does it for you :)
Jul 07 18:20:25 <MattyMatt>	^if
Jul 07 18:21:15 <allefant>	so we need a function to list all monitors, and the coordinates of each
Jul 07 18:21:24 <MattyMatt>	yep
Jul 07 18:21:54 <Tomasu>	and size..
Jul 07 18:21:59 <MattyMatt>	handy for NDS that one
Jul 07 18:24:19 <MattyMatt>	it might be handy to have extended capabilities flags for each monitor, for HDR, stereo etc 
Jul 07 18:24:39 <MattyMatt>	that could probably wait until 6.0 tho :)
Jul 07 18:27:02 <Tomasu>	or even just a way to provide stuff like that...
Jul 07 18:27:33 <Tomasu>	al_mset(1, AL_FORCE_FSAA)  ;D
Jul 07 18:27:38 <Tomasu>	no? ;)
Jul 07 18:27:54 <MattyMatt>	sth like that :)
Jul 07 18:27:59 <Tomasu>	nah thats likelly a DISPLAY thing any how, not a monitor thing
Jul 07 18:28:29 <MattyMatt>	internally, it will be negotiated between the gfx_driver and DISPLAY yeah
Jul 07 18:28:54 <MattyMatt>	the gfx driver might need them internally anyway
Jul 07 18:28:59 <Tomasu>	so it might as well be an al_display_ method, nothing related to monitor specifically
Jul 07 18:29:33 <MattyMatt>	well, if the user could pick the biggest screen :)  one of the caps could be size in inches
Jul 07 18:30:22 <Tomasu>	hmm
Jul 07 18:30:28 <Tomasu>	Id go with mm really.
Jul 07 18:30:35 <MattyMatt>	s1 = get_monitor_caps(ALLEGRO_MC_INCHES);
Jul 07 18:30:36 <Tomasu>	X and windows probably prefer mm
Jul 07 18:30:40 <MattyMatt>	s2 = get_monitor_caps(ALLEGRO_MC_INCHES);
Jul 07 18:30:48 <Tomasu>	X exports milimeters
Jul 07 18:31:14 <MattyMatt>	al_create_display(GFX_FULLSCREEN, MAX(s1,s2));
Jul 07 18:31:16 <Tomasu>	but a generic sort of function like that is a pain.
Jul 07 18:31:26 <Tomasu>	it can only deal with one type
Jul 07 18:32:04 <MattyMatt>	int is good :)
Jul 07 18:32:17 <Tomasu>	not if you want inches ;)
Jul 07 18:34:26 <MattyMatt>	I had a dream last night. using ReactOS kernel, rebuilding a new OS with allegro instead of GDI
Jul 07 18:34:42 <Tomasu>	lol
Jul 07 18:34:53 <Tomasu>	man I'm tired as hell.
Jul 07 18:35:46 <MattyMatt>	07/07/07
Jul 07 18:36:50 <Tomasu>	and looking at my fshook stuff, I might want change the find func to take a callback instead of returning a char **...
Jul 07 18:37:16 <Tomasu>	and maybe have a flags arg
Jul 07 18:37:18 <Tomasu>	for like "recurse"
Jul 07 18:37:39 <MattyMatt>	oh yeah, now that would be useful
Jul 07 18:38:01 <MattyMatt>	foreach(WITH_RECURESE_KTHX...
Jul 07 18:38:38 <Tomasu>	al_fs_find(char *path, AL_FS_FILTER filter, AL_FS_SORT sort) and al_fs_find(char *path, AL_FS_FILTER filter, AL_FS_SORT sort, void *) so far)
Jul 07 18:39:52 <Tomasu>	sort and filter are actually fptrs...
Jul 07 18:40:16 <Tomasu>	at least in the _ex vetsion
Jul 07 18:40:27 <Tomasu>	I'll have to think about that more
Jul 07 18:45:05 <Tomasu>	ok, I'm having troubles keeping awake enough to do anything... back to dlrrp for a bit
Jul 07 18:45:08 ---	Tomasu is now known as TomasuDlrrp
Jul 07 18:45:50 <MattyMatt>	k happy zzz. me goes gack to msdn::ddraw