The Allegro Wiki is migrating to github at

Allegro Hack Day/logs

From Allegro Wiki
Jump to: navigation, search

Here is actual logs of the first IRC meeting (times are UTC+2)

Apr 07 14:09:42 <Tomasu>	woo
Apr 07 14:09:51 <tjaden>	hi guys
Apr 07 14:09:54 <Tomasu>	yo
Apr 07 14:09:58 <tjaden>	i'm in the middle of a movie though :)
Apr 07 14:10:02 <Tomasu>	heh
Apr 07 14:10:06 <Tomasu>	theatre?
Apr 07 14:10:09 <allefant>	heh, let me paste the last view lines before you joined:
Apr 07 14:10:16 <allefant>	<Tomasu> so reguarding that mail, who wants to take over 4.3?
Apr 07 14:10:16 <allefant>	<allefant> i guess, tjaden is best for that
Apr 07 14:10:16 <allefant>	<Tomasu> but hes also very busy.
Apr 07 14:10:16 <allefant>	<allefant> yeah, but who's not
Apr 07 14:10:16 <allefant>	<Tomasu> technically uou are less busy. and I am normally much less busy... but um...
Apr 07 14:10:16 <allefant>	<Tomasu> Im not exactly volunteering though
Apr 07 14:10:16 <allefant>	<Tomasu> maybe if its a last resort sort of thing. Im not the most reliable of people.
Apr 07 14:10:16 <allefant>	<allefant> well, the main privilege of it would be doing the release work, i guess.. so i'm quite sure tjaden would happily pass this to you :)
Apr 07 14:11:03 <tjaden>	hmm
Apr 07 14:11:30 <tjaden>	i'm at home
Apr 07 14:11:32 <Tomasu>	I would think the branch "leader" has more responsibility than just releases
Apr 07 14:12:34 <tjaden>	i don't think i can take it on
Apr 07 14:15:44 <kazzmir>	ok
Apr 07 14:15:49 <tjaden>	back in 20 mins :)
Apr 07 14:15:54 <kazzmir>	darn
Apr 07 14:16:04 <kazzmir>	i keep getting out of bed
Apr 07 14:16:12 <allefant>	heh
Apr 07 14:16:13 <Tomasu>	he can always read the back log
Apr 07 14:16:16 <kazzmir>	what time is it for you guys?
Apr 07 14:16:20 <Tomasu>	6:16 am
Apr 07 14:16:29 <allefant>	here it's 2pm
Apr 07 14:16:34 <kazzmir>	its 8:16am for me
Apr 07 14:17:01 <mimix>	14:17 here
Apr 07 14:17:30 <Tomasu>	I think we should structure the dev as the linux kernel has with 2.6.14+
Apr 07 14:17:47 <Tomasu>	one main maint and leaders for each sub system
Apr 07 14:17:56 -->	juvinious ( has joined #allegro-dev
Apr 07 14:18:05 <Tomasu>	someone claims a piece, and they are responsible for it
Apr 07 14:18:17 <kazzmir>	are there enough people for that anyway?
Apr 07 14:18:26 <Tomasu>	for at least a basic split up
Apr 07 14:18:37 <Tomasu>	but this would make it easier to give bits to new people
Apr 07 14:19:34 <allefant>	we sort of have that already, basically who implemented something, is responsible
Apr 07 14:19:38 <Tomasu>	allefant seems to have taken the X display stuff ;)
Apr 07 14:19:49 <Tomasu>	Im really talking of somehing a little more official
Apr 07 14:19:51 <allefant>	so tjaden has the input/events, you have the file system..
Apr 07 14:20:26 <Tomasu>	so we can document it somewhere and not have all the fuzzy setup we currently work with
Apr 07 14:20:37 <allefant>	indeed, that might be nice
Apr 07 14:21:05 <juvinious>	I assume somewhere would be the wiki?
Apr 07 14:21:15 <Tomasu>	to start with yeah
Apr 07 14:21:20 <Tomasu>	the wiki is a good place as any
Apr 07 14:21:34 <allefant>	so add a page with the positions, and people interested in it
Apr 07 14:21:49 <allefant>	interested = they automatically get it, for now :)
Apr 07 14:21:54 <Tomasu>	oh, and maybe think about some sort of election.
Apr 07 14:22:03 <Tomasu>	for people that want to take on the actual LEADER pos
Apr 07 14:22:17 <Tomasu>	of course thats for later
Apr 07 14:22:32 <Tomasu>	when more people actually know what the inside of allegro looks like
Apr 07 14:22:38 <kazzmir>	there arent enough non-dev's to vote on devs
Apr 07 14:22:47 <Tomasu>	huh?
Apr 07 14:22:47 <allefant>	yeah. if candidated need to volunteer first, right now there would be not much need to vote
Apr 07 14:22:47 <kazzmir>	or at least people who know what the dev's do really
Apr 07 14:23:42 <Tomasu>	this is why I want allegro to become a little more open and transparent... more documentation on the structure of allegro and its dev process (which there isnt much of, so it should be easy ;))
Apr 07 14:23:54 <kazzmir>	well yes that would be good
Apr 07 14:24:00 <kazzmir>	kittycat gets sound..?
Apr 07 14:24:06 <kazzmir>	shouldnt he be here
Apr 07 14:24:19 <juvinious>	he did stuff with openal
Apr 07 14:24:37 <allefant>	seems he is completely out of time to spend on allegro currently
Apr 07 14:25:02 <Tomasu>	who isnt ::)
Apr 07 14:25:46 <allefant>	angelo mottola was in #allegro a week ago, he said he was interested in maybe returning as a dev
Apr 07 14:25:48 <kazzmir>	yea
Apr 07 14:25:52 <kazzmir>	oh really
Apr 07 14:25:58 <kazzmir>	your note on his website encouraged him :)
Apr 07 14:26:07 <allefant>	yep, that's what he said :)
Apr 07 14:26:12 <juvinious>	interesting
Apr 07 14:27:00 -->	KittyCat (i=kitty@allegro/developer/KittyCat) has joined #allegro-dev
Apr 07 14:27:30 <kazzmir>	so the 4.3 osx port is broken
Apr 07 14:27:42 <Tomasu>	so KittyCat want to officially take on the 4.3 sound maintainer/lead role?
Apr 07 14:27:44 <kazzmir>	ultio had an interest in fixing it
Apr 07 14:28:15 <allefant>	having the osx port working for 4.3.1 certainly would be nice
Apr 07 14:28:37 <KittyCat>	I'm better at just fixing/hacking on things.. I don't tihnk I'd do too well as a lead
Apr 07 14:28:49 <Tomasu>	I think youd be better than noone ;)
Apr 07 14:28:58 <kazzmir>	and for some reason examples crash when built with the scons system instead of make
Apr 07 14:29:20 <kazzmir>	KittyCat, can you just document whatever the architecture is and maybe someone else can do it?
Apr 07 14:29:21 <Tomasu>	KittyCat: as it is, a "lead" really doesn't have much to do, besided fix and hack on things ;)
Apr 07 14:29:23 <allefant>	does cmake work under OSX?
Apr 07 14:29:42 <Tomasu>	for sound we do need to get a plan in place, which has to come first.
Apr 07 14:29:50 <kazzmir>	i dunno i think i asked about cmake on the list but then i just used make
Apr 07 14:29:53 <juvinious>	allefant: yes
Apr 07 14:30:18 <Tomasu>	I vote fehemently for dropping autotools from 4.3 asap.
Apr 07 14:30:26 <Tomasu>	delete it ALL
Apr 07 14:30:28 <allefant>	yeah, i'd like to get rid of manual make and autotools
Apr 07 14:30:34 <juvinious>	heh
Apr 07 14:30:41 <allefant>	so if on OSX the manual makefile is the only thing to work currently, that sounds bad :P
Apr 07 14:30:57 <allefant>	either having cmake or scons work would be nice :)
Apr 07 14:30:59 <Tomasu>	well, keep it where its needed till cmake works
Apr 07 14:31:09 <Tomasu>	but autotools can be dropped.
Apr 07 14:31:12 <Tomasu>	afaik
Apr 07 14:31:30 <kazzmir>	scons works 100% on linux, 99% on osx and 90% on windows for what its worth
Apr 07 14:31:31 <juvinious>	I guess I can look at the osx cmake build and get it working
Apr 07 14:31:32 <allefant>	yeah, autotools would have been a good point to put on the wiki, Evert always was strongly in favor of keeping it
Apr 07 14:31:34 <kazzmir>	has anyone tested cmake on windows?
Apr 07 14:32:10 <juvinious>	I thought there were problems with it because of the asm crap on windows?
Apr 07 14:32:16 <Tomasu>	I'll just fo and add a section to the page then
Apr 07 14:32:20 <kazzmir>	yea i had the same troubles with scons
Apr 07 14:32:30 <allefant>	but really, on unix, both scons and cmake work 100%, and it's the only port where autotools does work at all, so i don't see much reason to keep it
Apr 07 14:32:56 <allefant>	well, s/unix/linux/ 
Apr 07 14:33:12 <Tomasu>	if evert wants to keep autotools, he can maintain it.
Apr 07 14:33:18 <Tomasu>	I won't be touching it myself.
Apr 07 14:34:34 <allefant>	oh, Windows-leader and OSX-leader also would be two good position to fill
Apr 07 14:34:41 <Tomasu>	ja
Apr 07 14:34:46 <Tomasu>	we really need a WinLeader
Apr 07 14:35:02 <kazzmir>	eric botcazou used to do that, right?
Apr 07 14:35:11 <Tomasu>	I _think_ so.
Apr 07 14:35:21 <allefant>	yes, he rewrote tons of code
Apr 07 14:35:21 <kazzmir>	i wonder if we can encourage him to come back
Apr 07 14:35:24 <Tomasu>	but he hasnt been around in years. which is why evert took over
Apr 07 14:35:29 <kazzmir>	oh btw, allegro is slightly broken on vista
Apr 07 14:35:29 <Tomasu>	hes just too busy
Apr 07 14:35:39 <Tomasu>	everything is slightly broken on vista.
Apr 07 14:35:40 <kazzmir>	it turns the transparent window decoration stuff off
Apr 07 14:35:53 <allefant>	likely this has to do with those manifest files?
Apr 07 14:36:08 <KittyCat>	maybe due to using the old ddraw interface
Apr 07 14:36:16 <allefant>	only guessing at that because with py2exe, i need to distribute manifest files under XP to have it use the theme
Apr 07 14:36:49 <tjaden>	hi, i'm back. gonna read the comments so far for a while
Apr 07 14:37:15 <Tomasu>	I've added some notes so far:
Apr 07 14:39:10 <tjaden>	ok read it
Apr 07 14:39:17 <allefant>	maybe we can find someone on to fix 4.2 under vista?
Apr 07 14:39:47 <tjaden>	what's the problem?
Apr 07 14:39:48 <kazzmir>	maybe matthew leverton is a good choice
Apr 07 14:40:04 <kazzmir>	tjaden, the transparent window borders become solid when allegro programs are running
Apr 07 14:40:18 <kazzmir>	not really a big deal, but one of my users complained about it :p
Apr 07 14:40:30 <tjaden>	oh. i have vista on this laptop but i immediately switched off the new interface
Apr 07 14:40:35 <kazzmir>	ah
Apr 07 14:41:49 <allefant>	tjaden: how far are you with the 4.3.1 release?
Apr 07 14:42:10 <tjaden>	it was all ready to go, except for the osx port
Apr 07 14:42:18 <Tomasu>	also whats so different between .0 and .1?
Apr 07 14:42:29 <tjaden>	enough :)
Apr 07 14:42:49 <tjaden>	remember in the early 3.9.x days, there was a new release every week
Apr 07 14:42:50 <Tomasu>	Im actually wondering :P I dont know
Apr 07 14:43:29 <kazzmir>	well you could release 4.3.1 for now and just say osx is broken
Apr 07 14:43:31 <allefant>	any ideas what might cause the problems under OSX?
Apr 07 14:43:33 <kazzmir>	at least it would get some attention
Apr 07 14:43:49 <tjaden>	Tomasu, mouse API and documentation
Apr 07 14:43:53 <Tomasu>	ah
Apr 07 14:43:59 <Tomasu>	probalby more than enough
Apr 07 14:44:01 <kazzmir>	and the colors were messed up in ex12bit for some reason
Apr 07 14:44:18 <allefant>	ex12bit should probably be removed from 4.3
Apr 07 14:44:26 <tjaden>	i guess i will release it tomorrow or monday then
Apr 07 14:44:36 <kazzmir>	all the examples really need to be redone
Apr 07 14:44:37 <allefant>	the compatibility layer likely can't deal with the internal hacking to get 12-bit bitmaps :P
Apr 07 14:45:28 <allefant>	yes, i guess for now, we can just add more exnew_* examples
Apr 07 14:45:52 <allefant>	the old ones are a good test for the compatibility layer
Apr 07 14:46:01 <tjaden>	yes they are
Apr 07 14:46:04 <Tomasu>	yup.
Apr 07 14:46:17 <Tomasu>	though Im dreading the compat layer for all the old pack stuff.
Apr 07 14:46:27 <allefant>	oh, what i wanted to bring up is my resizable windows patch for 4.2
Apr 07 14:46:36 <Tomasu>	evert seems to be against that
Apr 07 14:46:58 <allefant>	yeah, evert said this in the mail:
Apr 07 14:47:06 <kazzmir>	and my draw_sprite_ex ;)
Apr 07 14:47:14 <allefant>	My position is yes, only bug fixes allowed. For a variety of reasons: 
Apr 07 14:47:14 <allefant>	testing of new functionality, possibility of introducing new bugs, 
Apr 07 14:47:14 <allefant>	backward compatibility in the compatibility layer of 4.3, time taken away 
Apr 07 14:47:14 <allefant>	from 4.3 development.
Apr 07 14:47:41 <kazzmir>	do you have a working patch for resize screen on all platforms?
Apr 07 14:47:46 <Tomasu>	if we can try and focus more on 4.3 it might be better in the short and long term
Apr 07 14:47:52 <tjaden>	i agree with the evert's first three points
Apr 07 14:48:09 <allefant>	the 3rd point would be not much of an issue in my case, i think
Apr 07 14:48:15 <allefant>	as 4.3 will have resizable windows anyway
Apr 07 14:48:31 <tjaden>	under a different API
Apr 07 14:49:06 <allefant>	true, it would add to the compatibility layer of course
Apr 07 14:50:10 <tjaden>	but in general i don't think we can hold features back from 4.2 if users would add them
Apr 07 14:50:20 <allefant>	my biggest issue is, i don't see when i will start recommending 4.3 for actual use in development
Apr 07 14:50:36 <allefant>	and in some cases, window resizing really is a very nice feature to have
Apr 07 14:51:05 <allefant>	of course, my patch only works in X11, so it doesn't actually help that much :/
Apr 07 14:51:25 <kazzmir>	i think i implemented resizeable windows a while ago in x11 too
Apr 07 14:51:58 <tjaden>	i think we can't accept it then
Apr 07 14:52:20 <kazzmir>	but shouldnt it exist for all platforms?
Apr 07 14:52:35 <allefant>	yes, but someone would need to implement it
Apr 07 14:52:40 <tjaden>	yes
Apr 07 14:53:48 <tjaden>	if we commit a patch for resizable windows in X11, then nobody follows up on other platforms, then we make a release and find out too late that it won't work for other platforms..
Apr 07 14:54:09 <kazzmir>	such is the problem with multi-platform software..
Apr 07 14:54:12 <allefant>	yes - so don't categorically disallow it, but require it to work at least under 2 platforms
Apr 07 14:54:25 <kazzmir>	anyway it should be do-able for windows and osx, but i guess qnx and beos will be out of luck
Apr 07 14:54:50 <tjaden>	qnx and beos are irrelevant
Apr 07 14:54:51 <allefant>	the same goes for the draw_sprite_ex then i guess
Apr 07 14:55:07 <allefant>	kazzmir: what does it do again, in short?
Apr 07 14:55:13 <kazzmir>	i suppose. i thought they would be completely irrelevant for 4.3
Apr 07 14:55:18 <kazzmir>	but 4.2 still claims to support them
Apr 07 14:55:48 <kazzmir>	allefant, its just an abstraction over draw_sprite/lit/trans so that you dont need 3 different functions for them. you just pass in DRAW_LIT or whatever
Apr 07 14:56:18 <kazzmir>	so that implementing draw_trans_h_flip or whatever i needed would be easy
Apr 07 14:57:37 <allefant>	hm
Apr 07 14:57:56 <allefant>	so there would be draw_sprite_h_flip_ex as well?
Apr 07 14:58:43 <kazzmir>	yea there is one _ex for each of the draw_sprite routines. h/v/vh_flip and rotate/pivot
Apr 07 14:59:21 <kazzmir>	although i dont think my last patch had the rotate/pivot ones
Apr 07 14:59:37 <allefant>	should be easy doing a general fallback solution using a temp bitmap
Apr 07 15:00:08 <allefant>	so that could be added to all vtables where it's not implemented properly yet
Apr 07 15:00:41 <kazzmir>	well its in the C sprite stuff, so every platform would get it
Apr 07 15:00:52 <kazzmir>	some platforms accelerate those functions, thats where things would be lacking
Apr 07 15:01:14 <kazzmir>	making a temp bitmap and then using the accelerated functions is probably slower than just using the C one
Apr 07 15:01:51 <allefant>	but it's using vtables, so it's at least possible to do an accelerated version?
Apr 07 15:01:57 <allefant>	(e.g. for AllegroGL)
Apr 07 15:02:34 <allefant>	anyway, it would only leave the compatibility-layer point from Evert's 4 points against new functions
Apr 07 15:04:27 <kazzmir>	his point was just that the compatibility layer should be functioning, right?
Apr 07 15:04:41 <Tomasu>	and it be easy to maintain ;)
Apr 07 15:04:43 <allefant>	yes, and how much work is required for it
Apr 07 15:05:00 <Tomasu>	easy == good, simple == good  ;)
Apr 07 15:07:23 <tjaden>	where did you post the proposal, kazzmir?
Apr 07 15:07:53 <kazzmir>	on [AD] on 3/5/07
Apr 07 15:08:20 <kazzmir>	v/h flip for draw_list/trans
Apr 07 15:08:45 <allefant>	maybe post again the complete proposal (all 4 new functions)
Apr 07 15:09:20 <allefant>	so just the 4 functions with parameters they have.. should get clear than how they fill a gap in the current API
Apr 07 15:09:50 <kazzmir>	its 5 functions right, v/h/vh/rotate/pivot
Apr 07 15:10:07 <kazzmir>	there might be others, pivot_h_flip or something
Apr 07 15:10:12 <allefant>	hm
Apr 07 15:10:45 <allefant>	for 4.3, we have nothing like that yet
Apr 07 15:11:06 <Tomasu>	I thought blit handled that all?
Apr 07 15:11:14 <Tomasu>	just add H_FLIP and PIVOT ?
Apr 07 15:12:00 <allefant>	yeah, al_rotate_scaled_bitmap
Apr 07 15:12:15 <kazzmir>	actually rotate/pivot are seperate complicated functions
Apr 07 15:13:02 <allefant>	rotate is just pivot with the center uses as pivot
Apr 07 15:13:03 <kazzmir>	maybe you could pass in the blender to draw instead of using global functions to set them up
Apr 07 15:13:18 <allefant>	at least when allowing floating point coordinates
Apr 07 15:14:47 <allefant>	in 4.3, blending also is a state
Apr 07 15:14:51 <Tomasu>	I thought al_blit handled ALL of this with its flags
Apr 07 15:15:02 <allefant>	so not much point adding something different to 4.2
Apr 07 15:15:10 <allefant>	Tomasu: apparently not
Apr 07 15:15:20 <Tomasu>	not much point of adding _anything_ to 4.2 :P
Apr 07 15:15:23 <allefant>	it would need scaling, pivot and rotation parameters
Apr 07 15:15:35 <mimix>	i can say that implementing draw_trans_hv/flip/rotate/pivot_sprite will be quite easy to implement in AGL
Apr 07 15:15:35 <kazzmir>	why cant blending be a parameter in 4.3?
Apr 07 15:15:39 <allefant>	Tomasu: if 4.3 would be useable anytime soon, i'd agree :)
Apr 07 15:15:50 <Tomasu>	then lets FOCUS on 4.3 :P
Apr 07 15:16:03 <Tomasu>	with some actual work, it might become usable soonish
Apr 07 15:16:10 <allefant>	kazzmir: it can be of course
Apr 07 15:16:22 <allefant>	but then we need to modify the holy A5 graphics API :)
Apr 07 15:16:35 <allefant>	it already has an al_set_blender currently
Apr 07 15:16:47 <tjaden>	allefant, which API are you going off?
Apr 07 15:16:52 <Tomasu>	I don't think the api is _fixed_...
Apr 07 15:16:56 <allefant>
Apr 07 15:17:10 <allefant>	tjaden: oh, you mean in my 4.3-xdummy branch?
Apr 07 15:17:12 <kazzmir>	oh bobs masterpiece
Apr 07 15:17:23 <allefant>	i went for what seemed most sane to me personally in there, so far
Apr 07 15:17:34 <allefant>	e.g. float position instead of integer
Apr 07 15:18:07 <allefant>	e.g. i always curse how i can only draw circles with even diameter whenever i used circle() in 4.2 :P
Apr 07 15:18:49 <tjaden>	isn't there some opposition to bob's api from people who want it more state like?
Apr 07 15:19:05 <allefant>	yeah, i think the current display should be a state
Apr 07 15:19:25 <allefant>	this is not a question of state-based or not as evert says, to me
Apr 07 15:19:32 <Tomasu>	which would "simplify" the api somewhat. but make the backend a little more complex?
Apr 07 15:19:36 <allefant>	as there always will be some state (e.g. clipping state)
Apr 07 15:19:41 <Tomasu>	and slower if its per thred vars...
Apr 07 15:19:48 <tjaden>	i don't mind the current display as a state
Apr 07 15:19:50 <Tomasu>	thread vars are supposed to be somewhat slow
Apr 07 15:20:00 <tjaden>	they are, a bit
Apr 07 15:20:15 <kazzmir>	could there be non-state versions of most of the functions? in case the user really doesn't want state
Apr 07 15:20:28 <Tomasu>	hmm
Apr 07 15:20:31 <allefant>	can't opengl be used from different threads?
Apr 07 15:20:50 <tjaden>	yes. each thread can have its own GL context
Apr 07 15:20:51 <allefant>	so they likely keep the current context per-thread as well
Apr 07 15:20:54 <Tomasu>	sure but you have to set the state in each. and make sure youre not accessing the same display...
Apr 07 15:21:04 <Tomasu>	at the same time that is
Apr 07 15:21:09 <allefant>	that should be fine for 4.3 as well, i guess
Apr 07 15:21:20 <allefant>	don't draw to the same display from two threads without locking
Apr 07 15:21:29 <tjaden>	the speed penalty is not likely to matter
Apr 07 15:21:44 <kazzmir>	yea
Apr 07 15:21:50 <Tomasu>	probably not
Apr 07 15:21:54 <tjaden>	in a tight loop, maybe
Apr 07 15:22:03 <Tomasu>	unless people only use setpixel on the display \o/
Apr 07 15:22:15 <Tomasu>	which is so retarded that it doesnt really matter
Apr 07 15:22:51 <tjaden>	is the current bitmap also a state?
Apr 07 15:23:08 <Tomasu>	that Im not sure would work so well
Apr 07 15:23:10 <allefant>	it would have to
Apr 07 15:23:18 <kazzmir>	current bitmap the drawing routines work on?
Apr 07 15:23:19 <Tomasu>	like for bliting to memory bitmaps?
Apr 07 15:23:24 <Tomasu>	I dunno
Apr 07 15:23:26 <allefant>	e.g. if we have: line(x1, y1, x2, y2, color)
Apr 07 15:23:33 <allefant>	and i want it to draw to a bitmap
Apr 07 15:23:41 <kazzmir>	mm.. code would be littered with setCurrentBitmap or whatever
Apr 07 15:23:45 <Tomasu>	ja
Apr 07 15:23:49 <kazzmir>	its what makes the java api so ugly, imo
Apr 07 15:24:02 <Tomasu>	I dont think it makes sense for the bitmaps.
Apr 07 15:24:03 <allefant>	not sure, usually you don't draw to multiple bitmaps at the same time
Apr 07 15:24:07 <KittyCat>	it works well with opengl
Apr 07 15:24:11 <allefant>	more like:
Apr 07 15:24:14 <Tomasu>	opengl doesnt have bitmaps.
Apr 07 15:24:19 <allefant>	al_set_bitmap_display(backbuffer)
Apr 07 15:24:22 <allefant>	drawing commands
Apr 07 15:24:24 <Tomasu>	it has a render context, and thats it
Apr 07 15:24:26 <KittyCat>	no, it has framebuffers
Apr 07 15:24:47 <KittyCat>	you set one, and drawing goes to it
Apr 07 15:24:50 <KittyCat>	until you set another
Apr 07 15:24:54 <allefant>	that is, backbuffer is a bad example, as you don't access that as bitmap
Apr 07 15:25:06 <kazzmir>	i suppose the user could just override those functions, my_line( bitmap, ... ){ set( bitmap ) ...; unset() }
Apr 07 15:25:07 <allefant>	so in general, you'd only draw to bitmaps in special occasions anyway
Apr 07 15:25:08 <Tomasu>	which is like the DISPLAY context in a4.3
Apr 07 15:25:15 <juvinious>	brb
Apr 07 15:25:19 <--	juvinious has quit ("Leaving")
Apr 07 15:25:41 <Tomasu>	well I suppose it makes sense in OpenLayer doesnt it?
Apr 07 15:25:43 <Tomasu>	maybe
Apr 07 15:25:44 <allefant>	yes, in my 4.3 branch, an AL_DISPLAY is supposed to hold an OpenGL context, if the AL_OPENGL flag is given on creation
Apr 07 15:25:56 <Tomasu>	I'd have to see some actual code to see how it works
Apr 07 15:26:03 <Tomasu>	for bitmap states
Apr 07 15:26:29 <KittyCat>	a display would have an implicit front (and back) frame buffer.
Apr 07 15:26:39 <KittyCat>	extra bitmaps can be allocated after that
Apr 07 15:26:43 <Tomasu>	right the display is supposed to handle all that for you iirc
Apr 07 15:26:46 <Tomasu>	in 4.3
Apr 07 15:26:54 <Tomasu>	flipping buffering etc
Apr 07 15:26:58 <KittyCat>	and drawing to the extra bitmaps/framebuffers disables drawing to the implicit front/back buffer
Apr 07 15:27:24 <Tomasu>	to me itd just redirect from DISPLAY to "BITMAP"
Apr 07 15:27:38 <allefant>	those extra bitmaps is what currently are video bitmaps?
Apr 07 15:27:39 <Tomasu>	al_select_bitmap(foo);
Apr 07 15:27:39 <KittyCat>	so you'd have something like:
Apr 07 15:27:59 <KittyCat>	dpy->SetTarget(dpy->FrontBuffer());
Apr 07 15:28:01 <KittyCat>	or
Apr 07 15:28:06 <KittyCat>	dpy->SetTarget(dpy->BackBuffer());
Apr 07 15:28:08 <KittyCat>	or
Apr 07 15:28:14 <KittyCat>	dpy->SetTarget(SomeOtherBuffer);
Apr 07 15:28:26 <kazzmir>	and then dpy->flip() ?
Apr 07 15:28:29 <Tomasu>	set_target(display) and let it worry about the front or back buffer ;D
Apr 07 15:28:43 <KittyCat>	what about the other buffers?
Apr 07 15:28:50 <allefant>	what are those other buffers?
Apr 07 15:28:59 <KittyCat>	there are auxilliary buffers
Apr 07 15:29:04 <KittyCat>	FBOs
Apr 07 15:29:06 <KittyCat>	pbuffers
Apr 07 15:29:29 <allefant>	ok
Apr 07 15:29:32 <tjaden>	wait, so the thread has a current display, and the current display has a current buffer?
Apr 07 15:29:37 <Tomasu>	well yah, but that can be a set_target(fbo) or whatever. being able to just select "please choose my buffer for me" is a good option.
Apr 07 15:29:44 <allefant>	so al_create_display_bitmap() might return an AL_BITMAP which has an FBO
Apr 07 15:30:33 <KittyCat>	depends
Apr 07 15:30:45 <KittyCat>	it can be
Apr 07 15:31:01 <allefant>	i see
Apr 07 15:31:07 <allefant>	in that case, we need no current buffer
Apr 07 15:31:30 <allefant>	setting the AL_BITMAP as target would be sufficient
Apr 07 15:31:42 <allefant>	(not sure how to handle the front buffer.. likely that one wouldn't be accessible at all)
Apr 07 15:31:49 <Tomasu>	which is why I kinda didnt see the case for a "current" bitmap target.
Apr 07 15:31:59 <allefant>	yeah, i don't see as well
Apr 07 15:32:05 <KittyCat>	you don't need to pass a buffer to every drawing function, IMO. just set whatever AL_BITMAP you want as a target, and it's corresponding buffer would be the drawable one
Apr 07 15:32:41 <KittyCat>	a 'current' bitmap would be the one you last set.
Apr 07 15:33:11 <allefant>	hm
Apr 07 15:33:33 <allefant>	ah, i guess it's like tjaden set then, after all
Apr 07 15:33:36 <allefant>	*said
Apr 07 15:34:03 <tjaden>	i'm utterly lost
Apr 07 15:34:34 <tjaden>	can someone explain it?
Apr 07 15:34:49 <allefant>	as i see it, if i do line(0, 0, 100, 100, red) - that can mean 3 things:
Apr 07 15:34:57 <allefant>	- draw to a memory bitmap
Apr 07 15:35:05 <allefant>	- draw to the current displays's backbuffer
Apr 07 15:35:13 <allefant>	- draw to some other buffer/video bitmap
Apr 07 15:35:35 <KittyCat>	it would mean: you draw to the bitmap you last selected/set
Apr 07 15:35:57 <Tomasu>	which can depend on a render target state. so you ahve to figure out which bitmap or device you selected..
Apr 07 15:36:57 <tjaden>	ok, so there is a thread-specific current bitmap, and not a current display
Apr 07 15:37:40 <KittyCat>	a display would have the bitmaps. you shouldn't have a bitmap without a display
Apr 07 15:37:43 <Tomasu>	but then you have to select a given buffer in a display.
Apr 07 15:37:52 <allefant>	unless it is a "memory bitmap"
Apr 07 15:38:04 <KittyCat>	a memory bitmap would need to be associated with a display, too
Apr 07 15:38:04 <allefant>	i.e. device independent, e.g. RGBA8
Apr 07 15:38:05 <Tomasu>	instead of saying "I want the display to handle the buffers for me"
Apr 07 15:38:19 <allefant>	no, i think we need display-less bitmaps
Apr 07 15:38:30 <KittyCat>	you could have a NULL/dummy display
Apr 07 15:38:33 <allefant>	true
Apr 07 15:38:45 <tjaden>	what's the advantage of that?
Apr 07 15:38:59 <Tomasu>	simplifying selecting displays intead of disaplys AND bitmaps
Apr 07 15:39:10 <tjaden>	ok, true
Apr 07 15:39:35 <KittyCat>	bitmaps would need information about the display they're going to be drawn to
Apr 07 15:39:36 <allefant>	yeah, so if an AL_BITMAP has NULL for its display field, it is a memory bitmap
Apr 07 15:39:43 <KittyCat>	that's what acceleration relies on
Apr 07 15:39:54 <Tomasu>	hmm
Apr 07 15:40:03 <Tomasu>	kc has a point
Apr 07 15:40:09 <KittyCat>	I don't see why a display couldn't generate memory bitmaps
Apr 07 15:40:16 <Tomasu>	mem bitmaps could be associated with a given bitmap
Apr 07 15:40:22 <Tomasu>	*given disaply
Apr 07 15:40:25 <Tomasu>	*display
Apr 07 15:40:31 <tjaden>	but maybe i'm writing a displayless program
Apr 07 15:40:49 <allefant>	or i want to blit a memory bitmap to multiple display
Apr 07 15:40:52 <KittyCat>	a NULL display would be for generic device-independant bitmap operations
Apr 07 15:40:54 <Tomasu>	you use a dummy display hat provides the color depth and rgb/bgr info
Apr 07 15:41:24 <allefant>	there's already format/depth stuff in Bob's proposal
Apr 07 15:41:29 <KittyCat>	you could covert a bitmap for one display to another, but that'd be costly. hence keeping bitmaps together in a display
Apr 07 15:41:32 <allefant>	so a memory bitmap always would have a clearly defined format
Apr 07 15:41:36 <Tomasu>	with what Im thinking of allefant you can, just that the bitmaps sources its depth and whatnot from its associated display
Apr 07 15:41:47 <allefant>	yeah
Apr 07 15:41:57 <allefant>	a normal bitmap would be like current "video bitmaps"
Apr 07 15:42:04 <allefant>	e.g. optimized to blit to it
Apr 07 15:42:14 <Tomasu>	this would even let cache "mem" bitmaps in "agp" or vid mem for some uses.
Apr 07 15:42:17 <allefant>	(in the case of OpenGL, might upload an associated texture)
Apr 07 15:42:48 <allefant>	yes
Apr 07 15:43:28 <allefant>	but only one. if you (very unlikely) work with two displays, you should create a bitmap for each
Apr 07 15:43:49 <allefant>	or else it possibly will be slow
Apr 07 15:43:52 <KittyCat>	yeah. a bitmap for one display won't work directly on another
Apr 07 15:44:03 <KittyCat>	you'd have to do something like:
Apr 07 15:44:11 <Tomasu>	I dont see why it couldnt work, you just have to convert depth if needed.
Apr 07 15:44:22 <Tomasu>	though X is dropping the idea of different "Displays"
Apr 07 15:44:30 <KittyCat>	new_bmp = dpy->Covert(another_dpy, another_dpy_bmp);
Apr 07 15:44:44 <Tomasu>	one "Screen", and multiple "windows" into the screen. one depth, one byte ordering.
Apr 07 15:44:45 <allefant>	Tomasu: it might do something like upload a texture
Apr 07 15:45:00 <--	mimix has quit (Connection timed out)
Apr 07 15:45:04 <Tomasu>	so X wont allow you to have two bit depts natively anymore
Apr 07 15:45:06 <allefant>	you might not be able to use a texture from one OpenGL context in another
Apr 07 15:45:45 <Tomasu>	yeah, which is what I was saying, its possible, just not that "fast". unless of course you have a mem copy. then its faster
Apr 07 15:46:01 <kazzmir>	ah i found the problem with osx. the version reading is broken when there are only two version numbers, 10.4 instead of 10.4.1
Apr 07 15:46:09 <KittyCat>	as long as the mem copy is in sync with a video copy
Apr 07 15:46:22 <KittyCat>	which kind of voids the point of hardware acceleration
Apr 07 15:46:27 <Tomasu>	youd want to keep them synced at all times.
Apr 07 15:46:37 <Tomasu>	though that is hard with shaders
Apr 07 15:47:01 <KittyCat>	every video->video bitmap would incure a video->mem copy, then
Apr 07 15:47:08 <KittyCat>	*bitmap operation
Apr 07 15:47:15 <Tomasu>	which I dont think is worth it then
Apr 07 15:47:59 <tjaden>	it seems we are all agreed that AL_DISPLAY and AL_BITMAP are different
Apr 07 15:48:06 <Tomasu>	ja
Apr 07 15:48:06 <KittyCat>	yes
Apr 07 15:48:12 <Tomasu>	which is the same as it was before
Apr 07 15:48:32 <tjaden>	good. we made one decision
Apr 07 15:48:50 <Tomasu>	heh
Apr 07 15:48:54 <KittyCat>	an AL_DISPLAY would have one or two AL_BITMAPs implicitly (except maybe in the case of the NULL display)
Apr 07 15:49:16 <KittyCat>	at the very least, you'd have a front buffer/screen/window
Apr 07 15:49:24 <KittyCat>	and usually a back buffer, too
Apr 07 15:49:44 <Tomasu>	but most people only want to draw to the context, and let it handle the back/front buffers.
Apr 07 15:50:02 <Tomasu>	maybe a al_disaply_current_bitmap() I dunno.
Apr 07 15:50:20 <allefant>	there could be a convenience function: al_select_display(AL_DISPLAY *dpy) {al_select_bitmap(al_display_backbugger(dpy));}
Apr 07 15:50:28 <allefant>	*backbuffer
Apr 07 15:50:47 <tjaden>	i'm okay with the implicit bitmap parameter now
Apr 07 15:50:51 <Tomasu>	but the "backbuffer" changes when you "flip"
Apr 07 15:50:58 <allefant>	it shouldn't
Apr 07 15:51:09 <KittyCat>	the back buffer is undefined after a flip
Apr 07 15:51:10 <Tomasu>	yes, the back and front buffers swap on a flib.
Apr 07 15:51:17 <allefant>	hm
Apr 07 15:51:22 <KittyCat>	the front buffer will have what the back buffer did
Apr 07 15:51:30 <Tomasu>	not nesesarily, but usually.
Apr 07 15:51:37 <Tomasu>	no sorory
Apr 07 15:51:41 <Tomasu>	I read that wrong
Apr 07 15:51:45 <KittyCat>	that way you can abstract what Allegro' terms double buffering, and page flipping
Apr 07 15:51:50 <Tomasu>	ja
Apr 07 15:51:56 <allefant>	well, there could be an AL_BITMAP always being the back buffer
Apr 07 15:52:03 <allefant>	and al_flip() would just swap some fields within
Apr 07 15:52:19 <tjaden>	interesting idea
Apr 07 15:52:23 <KittyCat>	yeah, an AL_BITMAP would always point to the back buffer, if double buffering was set on the display
Apr 07 15:52:26 <allefant>	e.g. back_buffer->data = front_buffer->data
Apr 07 15:53:01 <allefant>	with an OpenGL driver, the back/front buffers would only have a flag which they are anyway
Apr 07 15:53:04 <KittyCat>	al_flip would just call glXSwapBuffers/al_blit/whatever else
Apr 07 15:53:10 <allefant>	yep
Apr 07 15:53:19 <KittyCat>	the same bitmap would continue to point to the back buffer
Apr 07 15:53:19 <tjaden>	i like it
Apr 07 15:53:33 <allefant>	so al_display_get_back_buffer() would return a dummy AL_BITMAP for an OpenGL driver, which just says "i'm the back buffer" :)
Apr 07 15:53:52 <KittyCat>	in a sense
Apr 07 15:54:34 <KittyCat>	it wouldn't be a dummy AL_BITMAP
Apr 07 15:55:06 <KittyCat>	it'd be just as valid as anything else, except contain the information needed to let opengl know where to draw to
Apr 07 15:55:23 <allefant>	yeah
Apr 07 15:56:02 <allefant>	i just meant, compared to a driver with a real backbuffer, it wouldn't necessarily have any memory region associated with it
Apr 07 15:56:47 <KittyCat>	it wouldn't have a RAM memory region no. none of the video bitmaps would have a RAM memory region, as far as allegro's concerned
Apr 07 15:57:09 <KittyCat>	a specific driver could do it if it needed a backup (*cough*DX*cough*)
Apr 07 15:57:17 <Tomasu>	though shouldnt that be an option? to cache the rendering to the ram, then upload?
Apr 07 15:57:42 <KittyCat>	that's what buffering is
Apr 07 15:57:47 <allefant>	yeah, that's all driver dependent then
Apr 07 15:57:52 <KittyCat>	you'd make a memory bitmap then blit it to a video bitmap
Apr 07 15:57:58 <allefant>	each AL_BITMAP will have a vtable, like in 4.2
Apr 07 15:58:16 <Tomasu>	ja
Apr 07 15:58:45 <allefant>	if you blit the backbuffer to a memory bitmap, it will call glGrabPixels (or whatever the function is called)
Apr 07 15:59:02 <KittyCat>	yeah
Apr 07 15:59:27 <KittyCat>	same with any other video bitmap
Apr 07 16:00:50 <allefant>	ok, 14.00 UTC.. guess the meeting should official end now :)
Apr 07 16:01:02 <tjaden>	?
Apr 07 16:01:26 <Tomasu>	no reason to
Apr 07 16:01:33 <Tomasu>	if theres still stuff to talk about
Apr 07 16:01:40 <Tomasu>	we need a good audio plan still
Apr 07 16:01:52 <allefant>	yeah
Apr 07 16:01:54 <tjaden>	milan's gone
Apr 07 16:01:55 <Tomasu>	and if anyone wants to talk about the file stuff, Im open
Apr 07 16:02:17 <allefant>	we could always schedule another one in 2 weeks to discuss remaining stuff though
Apr 07 16:02:40 <tjaden>	i guess we decided a couple of gfx issues
Apr 07 16:02:44 <Tomasu>	everyone is still here.
Apr 07 16:02:56 <tjaden>	is anyone prepared to write a gfx api spec?
Apr 07 16:03:02 <allefant>	milan said something about his laptop running out of power earler
Apr 07 16:03:48 <tjaden>	anyone at all?
Apr 07 16:04:07 <allefant>	i volunteer for it, was planning to do it anyway
Apr 07 16:04:22 <tjaden>	great
Apr 07 16:04:36 <allefant>	basically take Bob's functions, and put in the agreed AL_DISPLAY/AL_BITMAP semantics
Apr 07 16:05:52 <tjaden>	i won't be doing much coding on allegro any more, but will prod people with a stick if they want me to do that :)
Apr 07 16:06:04 <Tomasu>	stick proding is good
Apr 07 16:06:32 <tjaden>	i can still do merges and releases
Apr 07 16:07:04 -->	juvinious ( has joined #allegro-dev
Apr 07 16:07:13 <allefant>	i want to finish a first 4.3 display/graphics driver
Apr 07 16:07:23 <allefant>	but i guess i'm working on it now over a year
Apr 07 16:07:31 <allefant>	without too much progress :/
Apr 07 16:08:10 <allefant>	milan is doing a lot of work on AllegroGL, should try to interest him in 4.3 somehow :)
Apr 07 16:08:38 <tjaden>	can we divide the gfx spec into essential and non-essential parts?
Apr 07 16:08:49 <allefant>	yeah, that's a good idea i think
Apr 07 16:08:52 <tjaden>	selecting bitmaps and whatnot is essential, drawing ellipses is not
Apr 07 16:08:59 <Tomasu>	right
Apr 07 16:09:03 <Tomasu>	first the core
Apr 07 16:09:14 <allefant>	yes, i'll move line(), circle() and so on to a "Graphics Primitives" proposal
Apr 07 16:09:21 <tjaden>	once you have the core, you should be able to supplement that with GL
Apr 07 16:10:23 <allefant>	in my last 4.3-xdummy merge, text functions were a stumbling block for exnew_events :P
Apr 07 16:10:41 <tjaden>	hmm
Apr 07 16:11:14 <allefant>	i should make some compatibility stuff in the other direction
Apr 07 16:11:32 <allefant>	use 4.2 functions to draw to 4.3 display
Apr 07 16:12:12 <tjaden>	probably useful anyway, if it's not too much work
Apr 07 16:16:50 <tjaden>	anything else to discuss?
Apr 07 16:17:45 <Tomasu>	sound?
Apr 07 16:17:55 <Tomasu>	file stuff if anyone is conserned
Apr 07 16:18:08 <tjaden>	milan's not here, but ok, sound
Apr 07 16:18:21 <tjaden>	so... what's up with that KittyCat ? ;)
Apr 07 16:18:33 <Tomasu>	KC is the sound dude.. is milan one too?
Apr 07 16:18:34 <allefant>	milan got KittyCat's API working with alsa, right?
Apr 07 16:18:41 <Tomasu>	ooh
Apr 07 16:18:44 <KittyCat>	nothing new since I last posted to AD about it
Apr 07 16:18:47 <allefant>	(instead of openal.. not sure though)
Apr 07 16:19:06 <KittyCat>	alsa sorta works, but needs to be restructured
Apr 07 16:19:33 <tjaden>	is the API basically ok?
Apr 07 16:19:51 <KittyCat>	it's not fully complete, but what's there should work fine
Apr 07 16:20:00 <KittyCat>	it's missing volume and pan control, mostly
Apr 07 16:20:23 <tjaden>	i still think it should be in SVN
Apr 07 16:20:42 <tjaden>	in a branch if nothing else
Apr 07 16:22:18 <KittyCat>	the link I gave was the latest version. unless milan's done some more work that I haven't seen
Apr 07 16:22:31 <tjaden>	but it's not integrated
Apr 07 16:23:03 <allefant>	is the mouse api branch here integrated into trunk now?
Apr 07 16:23:12 <tjaden>	yes
Apr 07 16:23:18 <allefant>	maybe we should hide it then
Apr 07 16:23:28 <tjaden>	yes, i forgot to delete it
Apr 07 16:24:00 <allefant>	ok. then a sound branch like the vfs or xdummy really would be nice
Apr 07 16:27:09 <tjaden>	we should make a decision on the driver structure as well
Apr 07 16:28:50 <Tomasu>	ja
Apr 07 16:28:57 <Tomasu>	what do you have in mind?
Apr 07 16:29:13 <tjaden>	i have no problem with how it is now
Apr 07 16:29:23 <allefant>	same here
Apr 07 16:29:35 <allefant>	so, basically, the 4.2 vtables
Apr 07 16:29:42 <Tomasu>	hmm
Apr 07 16:29:55 <Tomasu>	I kinda like the idea of using a function to set the vtable using an enum.
Apr 07 16:30:12 <Tomasu>	thats how my fshooks stuff is working.
Apr 07 16:30:34 <allefant>	but internally, allegro would still be able to do: driver->vtable->function(...)
Apr 07 16:30:39 <Tomasu>	sure
Apr 07 16:30:53 <allefant>	just instead of: driver-vtable->function from user code, provide an enum based function
Apr 07 16:31:02 <Tomasu>	though the fshook drivers themselves init with al_fs_set_hook(...)
Apr 07 16:31:07 <allefant>	driver-vtable->function = something, i mean
Apr 07 16:32:31 <tjaden>	what does that buy us?
Apr 07 16:33:26 <Tomasu>	I did have a reason
Apr 07 16:34:18 <Tomasu>
Apr 07 16:34:37 <Tomasu>	though that doesnt give a reason.. its ssupposed to make it so you can change and reorder vtable entries
Apr 07 16:34:50 <tjaden>	it breaks type safety though
Apr 07 16:34:53 <Tomasu>	which it does if the enum value isn't a array index or anything.
Apr 07 16:35:09 <Tomasu>	for vtables? I dont think it matters.
Apr 07 16:35:43 <tjaden>	if you add a parameter to an existing method, you'd want the compiler to catch code which didn't get updated
Apr 07 16:36:15 <Tomasu>	then wed have to go with an intermediate vtable structure, which is then passed to and used in the internal vtable...
Apr 07 16:36:22 <allefant>	so the 4.2 vtables are actually type safe, i must correct that in the table
Apr 07 16:36:41 <Tomasu>	or a new function for each and every vtable item :o
Apr 07 16:37:20 <tjaden>	i don't think it's worth it just so we can reorder
Apr 07 16:38:21 <tjaden>	*reorder without updating all relevant vtables
Apr 07 16:38:38 <Tomasu>	in all extensions...
Apr 07 16:39:05 <tjaden>	there are no extensions
Apr 07 16:39:14 <Tomasu>	there have been, and there will be.
Apr 07 16:39:23 <--	juvinious has quit (Read error: 104 (Connection reset by peer))
Apr 07 16:39:31 <allefant>	AllegroGL was a major reason we wanted another system i think
Apr 07 16:39:40 <tjaden>	exactly
Apr 07 16:39:53 <tjaden>	also fonts, actually
Apr 07 16:40:05 <Tomasu>	and allegroGL like extensions.
Apr 07 16:40:06 <allefant>	when a new Allegro came out, old AllegroGL versions would crash
Apr 07 16:40:38 <Tomasu>	the enum method just allows better compatibility. imo
Apr 07 16:40:57 <Tomasu>	as do the others, but theres no string comparison, or extra structs to mess with
Apr 07 16:43:54 <KittyCat>	I think this is pretty interesting, how wine is able to make C++ interfaces with C
Apr 07 16:45:18 <KittyCat>	it doesn't let you use new or delete on objects, but it allows you to use them directly
Apr 07 16:45:54 <tjaden>	how does it work?
Apr 07 16:45:55 -->	juvinious ( has joined #allegro-dev
Apr 07 16:46:48 <KittyCat>	it basically makes all the functions virtual (in C++ terms). the vtable is just a list of function pointers, with the object as the first paramter
Apr 07 16:47:12 <KittyCat>	for C, it puts a pointer to the vtable as the first thing in the struct
Apr 07 16:47:33 <KittyCat>	in C++, it makes a regular class with all the functions virtual, and no internals
Apr 07 16:48:14 <allefant>	sounds quite similar to what we already do (vtable being a list of functions, and passing object as first..)
Apr 07 16:48:27 <tjaden>	so it reproduces the C++ object layout in C
Apr 07 16:49:00 <KittyCat>	I think..
Apr 07 16:49:12 <KittyCat>	here, lemme write up and example
Apr 07 16:54:41 <tjaden>	what's clear is that (1) there won't be any extensions for the foreseeable future, and (2) we want type safety
Apr 07 16:55:33 <tjaden>	so i think the allegro internals should stick to the 4.2 vtables, then perhaps provide one of the other methods for extension writers as needed
Apr 07 16:57:00 <Tomasu>	the fshook stuff will have extensions. thats what its made for. you provide a few handlers for things like Physfs...
Apr 07 16:57:28 <Tomasu>	and I'm pretty much writing the default stdio driver as an example.
Apr 07 16:57:54 <tjaden>	that's fine, but most other subsystems aren't made for user hooking
Apr 07 16:58:06 <KittyCat>
Apr 07 16:58:21 <Tomasu>	I would think itd be used more if it wasn't such a pain in the but.
Apr 07 17:01:11 <tjaden>	interesting, but how do wine deal with portability between C++ compilers?
Apr 07 17:01:33 <KittyCat>	how do you mean?
Apr 07 17:01:38 <allefant>	i think it's not meant to be ABI compatible
Apr 07 17:01:53 <allefant>	basically.. #ifdef __cplusplus C++ version #else C version #endif
Apr 07 17:01:58 <allefant>	^ that's how i understand it
Apr 07 17:02:06 <KittyCat>	yeah
Apr 07 17:02:07 <tjaden>	AFAIK not all C++ compilers lay out an object the same way
Apr 07 17:02:08 <allefant>	they are not to be mixed
Apr 07 17:02:17 <KittyCat>	in C++, you'd have to use the C++ method, in C, you need to use the C method
Apr 07 17:02:24 <Tomasu>	I dont understand how it handled foo->func() properly in C++
Apr 07 17:02:49 <Tomasu>	will it work if say part was gcc and another was msvc?
Apr 07 17:02:57 <KittyCat>	I guess the C++ specs say where the vtable goes
Apr 07 17:03:10 <KittyCat>	wine uses this, so it works all throughout windows, at least
Apr 07 17:03:10 <tjaden>	i'm not sure that's true
Apr 07 17:03:28 <Tomasu>	I had thought every one finally agreed on one ABI
Apr 07 17:03:37 <allefant>	hm
Apr 07 17:03:42 <Tomasu>	the Itanium based thing intel made. not sure though
Apr 07 17:04:02 <KittyCat>	wine has no C++ code, even though windows provides C++ interfaces
Apr 07 17:04:05 <KittyCat>	that's how it does it
Apr 07 17:04:36 <tjaden>	i guess it's standardised on windows
Apr 07 17:04:53 <allefant>	ok, now i understand, you actually create it from C, then use as C++
Apr 07 17:05:01 <KittyCat>	wine uses normal GCC to compile the object files
Apr 07 17:06:38 <tjaden>	anyway, we won't be doing that :)
Apr 07 17:07:50 <allefant>	and if we have the active drawing target as state, there wouldn't be much benefit
Apr 07 17:08:06 <allefant>	since even in C++ you would call line(x, y, ..)
Apr 07 17:08:17 <KittyCat>	I think it'd be pretty nice to have an implicit C++ interface, and still hide the internals
Apr 07 17:09:03 <KittyCat>	it modularizes nicely, so writing drivers using that won't be a problem
Apr 07 17:09:41 <KittyCat>	the only problem is that the vtable can't be re-ordered. but you can still add on to it
Apr 07 17:10:22 <tjaden>	it would constrain the API into a C++ view and it's too fragile
Apr 07 17:11:00 <allefant>	i also think, using the C API unmodified, or instead a proper C++-ified version, are enough C++ options
Apr 07 17:11:14 <KittyCat>	it'd get rid of the overhead a C++ wrapper would have, since it calls the same code directly
Apr 07 17:11:45 <Tomasu>	a good c++ wrapper wouldnt provide the same interface imo
Apr 07 17:11:49 <allefant>	yes, that's the nice thing about it, the C vtable directly is used as C++ vtable
Apr 07 17:12:02 <allefant>	the wrapper would have one indirection per method call more
Apr 07 17:12:12 <allefant>	likely not noticeable though, in practice
Apr 07 17:12:29 <KittyCat>	a good C++ wrapper would be as close to the original as possible, just C++-ified
Apr 07 17:12:52 <KittyCat>	you don't really want the interface different between C and C++ so much that it feels like you're using a different lib
Apr 07 17:12:57 <Tomasu>	nah. a good C++ wrapper is OpenLayer like. why limit yourself to the C interface?
Apr 07 17:13:03 <tjaden>	in this case you would be C++-fying the original interface :)
Apr 07 17:13:31 <KittyCat>	it's OO-ing it, which is pretty much how it's done anyway
Apr 07 17:13:31 <allefant>	namespace Allegro { class Bitmap { AL_BITMAP *bmp; Bitmap(int w, h) {bmp = al_create_bitmap(w, h);} } }
Apr 07 17:13:39 <allefant>	^ something like that would look nicer to the end user
Apr 07 17:14:03 <KittyCat>	allegro could put itself in a namespace
Apr 07 17:14:41 <allefant>	yes, that's what i mean, AL_BITMAP would be ugly in C++
Apr 07 17:15:06 <allefant>	so likely we want a wrapper anyway for "true" C++, and otherwise, zusing the C way of calling methods should be fine
Apr 07 17:15:16 <allefant>	*using
Apr 07 17:15:40 <KittyCat>	it could be named differently in C++
Apr 07 17:16:24 <KittyCat>	#ifdef __cplusplus
Apr 07 17:16:33 <KittyCat>	namespace Allegro { class Bitmap {
Apr 07 17:16:34 <KittyCat>	...
Apr 07 17:16:38 <KittyCat>	}; };
Apr 07 17:17:07 <allefant>	but AL_BITMAP *al_create_bitmap()
Apr 07 17:17:30 <allefant>	ah, but it could use my constructor above
Apr 07 17:17:35 <allefant>	and the rest would then work
Apr 07 17:17:44 <allefant>	hm, wait
Apr 07 17:17:54 <Tomasu>	uh, no.. unless you can delete this; and this = bmp;
Apr 07 17:17:55 <allefant>	*this = al_create_bitmap(...)
Apr 07 17:17:57 <allefant>	would that work?
Apr 07 17:18:05 <Tomasu>	which is retarded.
Apr 07 17:18:56 <KittyCat>	what is 'this'?
Apr 07 17:19:16 <allefant>	inside the constructor of Bitmap
Apr 07 17:19:26 <allefant>	the user in C++ does:
Apr 07 17:19:37 <allefant>	Bitmap *my_bitmap = new Bitmap(w, h);
Apr 07 17:19:53 <allefant>	so somehow we need to get the vtable-from-C-hacked AL_BITMAP in there
Apr 07 17:19:54 <KittyCat>	you could do: bmp = dpy->create_bitmap();
Apr 07 17:20:18 <KittyCat>	if bitmaps are going to be tied to displays, the creation method should be part of the display struct
Apr 07 17:20:38 <allefant>	yeah
Apr 07 17:20:57 <allefant>	so just need a C++ version of that function to return an Allegro::Bitmap instead of AL_BITMAP
Apr 07 17:21:03 <KittyCat>	and new Bitmap(640, 480);looks ugly anyway :P
Apr 07 17:21:19 <allefant>	yes, C++ code always does :P
Apr 07 17:22:09 <allefant>	C++ version: class Display { Bitmap *create_bitmap(); }
Apr 07 17:22:25 <allefant>	C version: struct AL_DISPLAY_vtable { AL_BITMAP *create_bitmap; }
Apr 07 17:22:34 <allefant>	guess that would work
Apr 07 17:23:06 <allefant>	anyway, for now, we don't need to worry about that i think
Apr 07 17:23:29 <allefant>	the current version will be sufficiently similar to it that it should stay doable later if we want it at some point
Apr 07 17:23:32 <KittyCat>	it'd deal with how the vtable is structured. that's what you were discussing, wasn't it?
Apr 07 17:24:08 <allefant>	yes, just was wondering how the C++ version would return a Bitmap instead of AL_BITMAP, for the same vtable entry
Apr 07 17:26:15 <KittyCat>	I can understand that it'd feel hacky, but I think it's quite clever. and it works. and it'd get rid of the "why isn't Allegro C++?!11!?/1" cries
Apr 07 17:26:30 <allefant>	heh
Apr 07 17:27:28 <allefant>
Apr 07 17:27:44 <allefant>	guess we got quite a lot covered by now :)
Apr 07 17:28:30 <tjaden>	thanks for that
Apr 07 17:30:24 <Tomasu>	thanks for taking the time out for this :)
Apr 07 17:30:57 <Tomasu>	I still wonder why noone is interested in the fshook stuff at all? :P
Apr 07 17:31:22 <tjaden>	it's not that important :)
Apr 07 17:31:28 <Tomasu>	:P
Apr 07 17:31:57 <Tomasu>	I think it is. that lame datafile stuff isnt really useful anymore. people want a zip archive, or integrate with KDE's kio system.
Apr 07 17:32:27 <tjaden>	well, not the KDE stuff
Apr 07 17:32:40 <Tomasu>	it wouldnt be hard to make a kio fshook
Apr 07 17:32:50 <Tomasu>	then you can have free samba, sftp and whatnot support.
Apr 07 17:33:22 <tjaden>	you can do that with fuse as well
Apr 07 17:33:42 <KittyCat>	hold off 'til KDE4 before you start thinking of a kio hook
Apr 07 17:33:42 <Tomasu>	kio has many more kio handlers
Apr 07 17:33:48 <Tomasu>	well duh.
Apr 07 17:34:05 <Tomasu>	and fuse keeps breaking fuse modules.
Apr 07 17:34:18 <Tomasu>	the latest version wont work with most of the fuse systems right now.
Apr 07 17:34:33 <Tomasu>	you need the latest for ntfs3g, but everything else wants the last version.
Apr 07 17:34:38 <Tomasu>	atm its one or the other.
Apr 07 17:34:52 <tjaden>	can you use kio stuff from the command line?
Apr 07 17:34:55 <Tomasu>	and kio will work on windows.
Apr 07 17:34:55 <tjaden>	can you use kio stuff from the command line?
Apr 07 17:35:00 <Tomasu>	I think so. depends.
Apr 07 17:35:09 <tjaden>	i don't use many kde programs
Apr 07 17:35:13 <Tomasu>	if an app supports it yes. if theres a fuse module for it yes ;)
Apr 07 17:35:44 <allefant>	so there could be something like an allegro module, and it allows accessing those kio pathes over allegro's VFS?
Apr 07 17:35:51 <Tomasu>	I also like the audiocd:// thing. lets you see the tracks in cdr, mp3 and ogg format.
Apr 07 17:35:59 <Tomasu>	right.
Apr 07 17:36:00 <allefant>	and who writes the allegro program could sit on OSX and never even heared abot kio..?
Apr 07 17:36:06 <Tomasu>	thats what the fshooks are for.
Apr 07 17:36:26 <Tomasu>	kio on kde4 will work on osx and windows :D
Apr 07 17:36:33 <Tomasu>	just need it installed is all.
Apr 07 17:36:38 <allefant>	ok
Apr 07 17:36:58 <allefant>	i'm more wondering what it gets the user of an allegro program..
Apr 07 17:36:58 <Tomasu>	course Id also like to see a complete windows driver too.
Apr 07 17:37:10 <Tomasu>	oh things like Physfs support.
Apr 07 17:37:15 <Tomasu>	free zip access, etc.
Apr 07 17:37:32 <KittyCat>	fish://
Apr 07 17:37:34 <KittyCat>	ftp://
Apr 07 17:37:41 <KittyCat>	man://
Apr 07 17:37:41 <allefant>	hm
Apr 07 17:37:51 <tjaden>	all fun but useless for most games
Apr 07 17:37:53 <Tomasu>	kio: audiocd:// sftp:// fish:// http:// etc
Apr 07 17:38:03 <allefant>	yeah, it only would matter in cases where the user inputs a path in some way
Apr 07 17:38:16 <allefant>	which is unlikely in a typocal game
Apr 07 17:38:17 <Tomasu>	Im just sating kio would be neat. but first comes native handlers.
Apr 07 17:38:33 <Tomasu>	stdio is first, then comes win32 and whatnot.
Apr 07 17:38:42 <kazzmir>	hm, i think the problem with osx is a mutex is being locked and not unlocked
Apr 07 17:38:45 <Tomasu>	then someone can do a Physfs handler.
Apr 07 17:38:58 <tjaden>	what does win32 need something different?
Apr 07 17:39:01 <Tomasu>	and I'll work on my VFS thing.
Apr 07 17:39:09 <Tomasu>	\\share\paths ?
Apr 07 17:39:19 <Tomasu>	CreateFileEx vs fopen
Apr 07 17:39:28 <Tomasu>	there are differences iirc
Apr 07 17:39:30 <tjaden>	oh, stdio doesn't work for network shares?
Apr 07 17:39:34 <Tomasu>	Im not sure.
Apr 07 17:39:53 <Tomasu>	I will look into it at some point.
Apr 07 17:40:07 <Tomasu>	but stdio will be default, and is already mostly done (its uber simple)
Apr 07 17:41:16 <kazzmir>	is al_mutex_lock supposed to be a semaphore or a mutex?
Apr 07 17:41:26 <tjaden>	mutex
Apr 07 17:41:30 <kazzmir>	acquire_win acquires the mutex and then drawRect, in another thread, tries to acquire the mutex
Apr 07 17:41:39 <Tomasu>	the windows code already does use some win32 stuff for finding paths and whatnot.
Apr 07 17:41:44 <kazzmir>	it seems like drawRect is doing the right thing, i guess acquire_win shouldnt acquire the mutex?
Apr 07 17:42:51 <kazzmir>	the x port doesnt acquire locks at all
Apr 07 17:43:30 <kazzmir>	well it still uses xwin_lock at least
Apr 07 17:43:47 <allefant>	and the events API itself also will do locking
Apr 07 17:44:00 <tjaden>	you could compare the 4.2 and 4.3 branches
Apr 07 17:44:43 <tjaden>	afaik the graphics stuff should be almost identical
Apr 07 17:45:03 <kazzmir>	hm, in 4.2 acquire_win did mutex_lock, but it doesnt have this drawRect routine
Apr 07 17:46:08 <KittyCat>	acquire_win locks a mutex, then waits on a function in another thread that also locks the mutex?
Apr 07 17:46:16 <kazzmir>	yea
Apr 07 17:46:33 <kazzmir>	if i remove the lock in acquire win for now everything works
Apr 07 17:46:37 <KittyCat>	can you safely unlock() wait() lock()?
Apr 07 17:46:47 <tjaden>	hold on, that should work
Apr 07 17:46:57 <tjaden>	i thought we implemented recursive mutexes
Apr 07 17:47:10 <KittyCat>	not if the other call is from another thread
Apr 07 17:47:13 <tjaden>	oops, nm
Apr 07 17:48:34 <kazzmir>	events( keyboard, mouse ) are still messed up though
Apr 07 17:48:45 <tjaden>	what's wrong?
Apr 07 17:49:07 <kazzmir>	the program doesnt receive any events
Apr 07 17:49:31 <Tomasu>	heh. drag and drop from dolphin to k3b works :D
Apr 07 17:51:28 <tjaden>	maybe go back in time until events work again
Apr 07 17:51:41 <kazzmir>	im not sure whats wrong, 4.2 seems to be doing the same thing about locking
Apr 07 17:51:54 <kazzmir>	acquire_win locks and then prepare_window_for_animation locks it again
Apr 07 17:51:54 <tjaden>	unfortunately the macosx port is probably broken at most points in time
Apr 07 17:52:04 <kazzmir>	prepare_window_for_animation was renamed to drawRect
Apr 07 17:52:45 <tjaden>	i'm going to bed