#bitfighter IRC Log

IRC Log for 2015-03-12

Timestamps are in GMT/BST.

00:22:23 raptor ah, now i see why kaen had to use those function pointers - because the functions are different between the varios opengl implementations
00:45:06 raptor wow, kaen had it all figured out...
00:45:12 raptor waht a mess
00:45:19 raptor opengl function loading is bonkers
00:53:14 raptor Quit ()
01:23:15 fordcars Quit (Quit: Page closed)
04:42:51 Flynnn Quit (Quit: This computer has gone to sleep)
04:46:48 Flynnn has joined
05:17:46 Flynnn Quit (Quit: This computer has gone to sleep)
07:50:06 koda has joined
08:20:09 Darrel Quit (Ping timeout: 246 seconds)
09:00:50 Nothing_Much has joined
10:09:57 koda Quit (Quit: koda)
10:24:23 koda has joined
11:28:50 raptor has joined
11:28:50 ChanServ sets mode +o
11:34:08 raptor good day!
11:38:26 Nothing_Much good morning
11:38:26 raptor Quit (Read error: Connection reset by peer)
11:46:08 raptor has joined
11:46:08 ChanServ sets mode +o
11:52:42 Darrel has joined
12:40:15 kodabb has joined
12:43:24 koda Quit (Ping timeout: 264 seconds)
12:43:24 kodabb is now known as koda
13:52:29 Nothing_Much Quit (Ping timeout: 252 seconds)
14:02:34 Nothing_Much has joined
14:24:43 Flynnn has joined
14:48:16 kaen_mbp has joined
14:50:05 koda Quit (Quit: koda)
15:02:47 LordDVG has joined
15:16:00 koda has joined
15:51:49 Flynnn Quit (Quit: This computer has gone to sleep)
16:04:50 Flynnn has joined
16:30:44 Flynnn Quit (Quit: This computer has gone to sleep)
16:34:57 watusimoto1 hi
16:35:02 watusimoto1 is now known as watusimoto
16:36:06 raptor hi
16:37:26 raptor I ran into some really crazy stuff with opengl last night
16:37:34 raptor disecting kaen's code
16:38:29 raptor apparently, in order to keep ABI compatibility, not just API compabitibility, you have to do what is called opengl function loading
16:39:41 raptor so you can't just include a header and be done with it, unless it is to use opengl 1.1 or lower functions
16:40:23 Nothing_Much I used to have ABI compatibility issues, until I realized my GPU was over a decade old and decided to throw it out
16:40:38 Flynnn has joined
16:40:55 raptor see this craziness:  http://www.opengl.org/wiki/Getting_started#Getting_Functions
16:41:38 raptor hmm..  maybe the ABI compatibility reason isn't strictly true
16:41:46 raptor anyways, it's crazy
16:43:10 Nothing_Much raptor: what's the difference between API and ABI compatibility?
16:43:21 raptor B == binary
16:43:28 raptor P == program
16:43:35 Nothing_Much ohh.. okay
16:43:55 raptor ABI has more to do with hardware, API is software
16:43:58 raptor roughly
16:48:23 Nothing_Much ohh
16:48:25 Nothing_Much cool
17:08:45 koda it's easy to break abi in software
17:09:26 watusimoto we'll be doing all this as a compiler switchm, right?  i.e. compile with gles or ogl support?
17:09:50 koda actually abi has not much to do with hardware
17:10:09 koda it's purely software, the thing is that many hw implement different libs in different way
17:10:16 koda eg moving a function or a member name
17:10:21 koda thus breaking abi
17:15:04 raptor ^^ yes, that, thanks koda :)
17:15:47 raptor watusimoto: well, kaen had already figured out how to do the function loading with SDL (which helps a little)
17:16:54 raptor so yes, basically we'd have an #ifdef that switches between GLES/GLES2 or desktop GL and we'd only turn on the GL function loading with GLES2
17:19:44 watusimoto ok, I think that's not too bad
17:20:25 raptor it isn't, but the code is ugly
17:20:32 raptor and i'm glad someone else did the work  :)
17:20:37 watusimoto YES!!!
17:21:11 raptor oh, i wanted to ask a question
17:21:16 raptor tryign to remember...
17:21:25 raptor oh yeah, ok
17:22:32 raptor should I create an abstraction class of sorts where calls like glColor(Color, alpha) will have 2 child classes, one for GL, one for GLES2?
17:22:46 raptor then i'd include one or the other depending on the CMake flags
17:22:49 raptor OR
17:23:02 raptor one class with lots of #ifdef in it within the functions
17:23:06 raptor OR something else?
17:23:25 watusimoto well... it seems we'll be living with whatever solution for a long time
17:23:43 raptor yep
17:23:55 watusimoto the abstraction level seems the nicest
17:24:20 watusimoto but the ifdef seems to require the least level of understanding on the reader's behalf
17:24:50 raptor maybe a single compilation unit with the ifdef around the entire class?  :)
17:24:52 watusimoto and since we'll only be using one or the other, the abstraction layer is not strictly necessary
17:25:13 watusimoto well... that third option might not be too bad
17:25:36 watusimoto though, on some level, it is profoundly ugly
17:25:38 raptor so one .h/.cpp, with a parent class and 2 child classes with #ifdef around them
17:25:49 raptor worst of both worlds!
17:25:54 raptor or best of..
17:26:17 watusimoto I don't know what I like yet.. I'm just trying to get some pros and cons out there
17:26:40 raptor I like:  organization, but not having to maintain the organization
17:26:59 watusimoto yes -- maintenace "cost" is a big driver
17:28:01 watusimoto I think I persoanlly like the the big ifdef implementation... where one implementation or the other is swapped in a compile time
17:28:02 watusimoto however
17:28:24 raptor me too :)
17:28:30 watusimoto I strongly believe that if you are doing the work, you should do it the way that leaves you the most satisfaction
17:28:59 watusimoto the advantage of the ifdef that attracts me is that it is very easy to understand
17:28:59 raptor right now, satifaction == something not too hard to maintain
17:29:21 watusimoto and ease of understanding translates into ease of maintenance
17:29:26 raptor yep
17:29:33 watusimoto since I hope we won't be looking at this too often
17:29:48 watusimoto so you like the ifdef solution as well?
17:29:53 raptor yep
17:30:02 raptor around the implementation classes, in a single file
17:30:07 watusimoto yes
17:30:27 watusimoto I don't think a class with dozens of ifdefs sprinkled about would be very good
17:30:32 raptor hmmm...  this may require we start using a namespace for your gameobjectrender/OpenglUtils class
17:30:37 raptor *our
17:30:50 watusimoto that would be ok
18:02:17 Darrel Quit (Read error: Connection reset by peer)
18:02:48 Darrel has joined
19:23:02 LordDVG Quit (Remote host closed the connection)
20:25:54 Flynnn Quit (Quit: This computer has gone to sleep)
20:35:52 raptor Quit (Remote host closed the connection)
21:17:11 Flynnn has joined
21:46:31 Flynnn Quit (Quit: This computer has gone to sleep)
21:50:52 watusimoto Quit (Quit: Leaving.)
22:28:14 Flynnn has joined
22:57:39 watusimoto has joined
22:57:39 ChanServ sets mode +o
23:01:46 Flynnn Quit (Quit: This computer has gone to sleep)
23:31:18 Flynnn has joined
23:40:11 koda Quit (Quit: koda)
23:54:32 raptor has joined
23:54:32 ChanServ sets mode +o
23:54:49 raptor houston, we have a problem...
23:54:57 raptor watusimoto: did you get the e-mail from Googley?
23:55:49 Invisible has joined
23:56:13 Invisible is now known as Guest17386

Index Search ←Prev date Next date→

These logs were automatically created by BFLogBot on irc.freenode.net.

00:22:23	raptor	ah, now i see why kaen had to use those function pointers - because the functions are different between the varios opengl implementations
00:45:06	raptor	wow, kaen had it all figured out...
00:45:12	raptor	waht a mess
00:45:19	raptor	opengl function loading is bonkers
00:53:14		raptor Quit ()
01:23:15		fordcars Quit (Quit: Page closed)
04:42:51		Flynnn Quit (Quit: This computer has gone to sleep)
04:46:48		Flynnn has joined
05:17:46		Flynnn Quit (Quit: This computer has gone to sleep)
07:50:06		koda has joined
08:20:09		Darrel Quit (Ping timeout: 246 seconds)
09:00:50		Nothing_Much has joined
10:09:57		koda Quit (Quit: koda)
10:24:23		koda has joined
11:28:50		raptor has joined
11:28:50		ChanServ sets mode +o
11:34:08	raptor	good day!
11:38:26	Nothing_Much	good morning
11:38:26		raptor Quit (Read error: Connection reset by peer)
11:46:08		raptor has joined
11:46:08		ChanServ sets mode +o
11:52:42		Darrel has joined
12:40:15		kodabb has joined
12:43:24		koda Quit (Ping timeout: 264 seconds)
12:43:24		kodabb is now known as koda
13:52:29		Nothing_Much Quit (Ping timeout: 252 seconds)
14:02:34		Nothing_Much has joined
14:24:43		Flynnn has joined
14:48:16		kaen_mbp has joined
14:50:05		koda Quit (Quit: koda)
15:02:47		LordDVG has joined
15:16:00		koda has joined
15:51:49		Flynnn Quit (Quit: This computer has gone to sleep)
16:04:50		Flynnn has joined
16:30:44		Flynnn Quit (Quit: This computer has gone to sleep)
16:34:57	watusimoto1	hi
16:35:02		watusimoto1 is now known as watusimoto
16:36:06	raptor	hi
16:37:26	raptor	I ran into some really crazy stuff with opengl last night
16:37:34	raptor	disecting kaen's code
16:38:29	raptor	apparently, in order to keep ABI compatibility, not just API compabitibility, you have to do what is called opengl function loading
16:39:41	raptor	so you can't just include a header and be done with it, unless it is to use opengl 1.1 or lower functions
16:40:23	Nothing_Much	I used to have ABI compatibility issues, until I realized my GPU was over a decade old and decided to throw it out
16:40:38		Flynnn has joined
16:40:55	raptor	see this craziness: http://www.opengl.org/wiki/Getting_started#Getting_Functions
16:41:38	raptor	hmm.. maybe the ABI compatibility reason isn't strictly true
16:41:46	raptor	anyways, it's crazy
16:43:10	Nothing_Much	raptor: what's the difference between API and ABI compatibility?
16:43:21	raptor	B == binary
16:43:28	raptor	P == program
16:43:35	Nothing_Much	ohh.. okay
16:43:55	raptor	ABI has more to do with hardware, API is software
16:43:58	raptor	roughly
16:48:23	Nothing_Much	ohh
16:48:25	Nothing_Much	cool
17:08:45	koda	it's easy to break abi in software
17:09:26	watusimoto	we'll be doing all this as a compiler switchm, right? i.e. compile with gles or ogl support?
17:09:50	koda	actually abi has not much to do with hardware
17:10:09	koda	it's purely software, the thing is that many hw implement different libs in different way
17:10:16	koda	eg moving a function or a member name
17:10:21	koda	thus breaking abi
17:15:04	raptor	^^ yes, that, thanks koda :)
17:15:47	raptor	watusimoto: well, kaen had already figured out how to do the function loading with SDL (which helps a little)
17:16:54	raptor	so yes, basically we'd have an #ifdef that switches between GLES/GLES2 or desktop GL and we'd only turn on the GL function loading with GLES2
17:19:44	watusimoto	ok, I think that's not too bad
17:20:25	raptor	it isn't, but the code is ugly
17:20:32	raptor	and i'm glad someone else did the work :)
17:20:37	watusimoto	YES!!!
17:21:11	raptor	oh, i wanted to ask a question
17:21:16	raptor	tryign to remember...
17:21:25	raptor	oh yeah, ok
17:22:32	raptor	should I create an abstraction class of sorts where calls like glColor(Color, alpha) will have 2 child classes, one for GL, one for GLES2?
17:22:46	raptor	then i'd include one or the other depending on the CMake flags
17:22:49	raptor	OR
17:23:02	raptor	one class with lots of #ifdef in it within the functions
17:23:06	raptor	OR something else?
17:23:25	watusimoto	well... it seems we'll be living with whatever solution for a long time
17:23:43	raptor	yep
17:23:55	watusimoto	the abstraction level seems the nicest
17:24:20	watusimoto	but the ifdef seems to require the least level of understanding on the reader's behalf
17:24:50	raptor	maybe a single compilation unit with the ifdef around the entire class? :)
17:24:52	watusimoto	and since we'll only be using one or the other, the abstraction layer is not strictly necessary
17:25:13	watusimoto	well... that third option might not be too bad
17:25:36	watusimoto	though, on some level, it is profoundly ugly
17:25:38	raptor	so one .h/.cpp, with a parent class and 2 child classes with #ifdef around them
17:25:49	raptor	worst of both worlds!
17:25:54	raptor	or best of..
17:26:17	watusimoto	I don't know what I like yet.. I'm just trying to get some pros and cons out there
17:26:40	raptor	I like: organization, but not having to maintain the organization
17:26:59	watusimoto	yes -- maintenace "cost" is a big driver
17:28:01	watusimoto	I think I persoanlly like the the big ifdef implementation... where one implementation or the other is swapped in a compile time
17:28:02	watusimoto	however
17:28:24	raptor	me too :)
17:28:30	watusimoto	I strongly believe that if you are doing the work, you should do it the way that leaves you the most satisfaction
17:28:59	watusimoto	the advantage of the ifdef that attracts me is that it is very easy to understand
17:28:59	raptor	right now, satifaction == something not too hard to maintain
17:29:21	watusimoto	and ease of understanding translates into ease of maintenance
17:29:26	raptor	yep
17:29:33	watusimoto	since I hope we won't be looking at this too often
17:29:48	watusimoto	so you like the ifdef solution as well?
17:29:53	raptor	yep
17:30:02	raptor	around the implementation classes, in a single file
17:30:07	watusimoto	yes
17:30:27	watusimoto	I don't think a class with dozens of ifdefs sprinkled about would be very good
17:30:32	raptor	hmmm... this may require we start using a namespace for your gameobjectrender/OpenglUtils class
17:30:37	raptor	*our
17:30:50	watusimoto	that would be ok
18:02:17		Darrel Quit (Read error: Connection reset by peer)
18:02:48		Darrel has joined
19:23:02		LordDVG Quit (Remote host closed the connection)
20:25:54		Flynnn Quit (Quit: This computer has gone to sleep)
20:35:52		raptor Quit (Remote host closed the connection)
21:17:11		Flynnn has joined
21:46:31		Flynnn Quit (Quit: This computer has gone to sleep)
21:50:52		watusimoto Quit (Quit: Leaving.)
22:28:14		Flynnn has joined
22:57:39		watusimoto has joined
22:57:39		ChanServ sets mode +o
23:01:46		Flynnn Quit (Quit: This computer has gone to sleep)
23:31:18		Flynnn has joined
23:40:11		koda Quit (Quit: koda)
23:54:32		raptor has joined
23:54:32		ChanServ sets mode +o
23:54:49	raptor	houston, we have a problem...
23:54:57	raptor	watusimoto: did you get the e-mail from Googley?
23:55:49		Invisible has joined
23:56:13		Invisible is now known as Guest17386