code logs -> 2013 -> Wed, 03 Jul 2013< code.20130702.log - code.20130704.log >
--- Log opened Wed Jul 03 00:00:18 2013
00:01 You're now known as TheWatcher[zZzZ]
00:05 Typh|offline [Typherix@Nightstar-7dc8031d.mi.comcast.net] has quit [Ping timeout: 121 seconds]
00:05 Derakon[AFK] is now known as Derakon
00:05 Typh|offline [Typherix@Nightstar-7dc8031d.mi.comcast.net] has joined #code
00:28 Derakon is now known as Derakon[AFK]
01:04 Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving]
01:10 Turaiel[Offline] is now known as Turaiel
01:19 Derakon[AFK] is now known as Derakon
01:28 RichyB [RichyB@D553D1.68E9F7.02BB7C.3AF784] has quit [[NS] Quit: Gone.]
01:31 RichyB [RichyB@D553D1.68E9F7.02BB7C.3AF784] has joined #code
01:53 Vorntastic [Vorn@Nightstar-79f10640.sub-70-211-3.myvzw.com] has joined #code
01:59
<&Derakon>
Hmph, that whole "only strings can be keys in JSON" thing is biting me again.
01:59
<&Derakon>
This time because I have objects whose IDs are position tuples.
01:59
< Vorntastic>
...yep.
02:05
< Vorntastic>
What the heck kind of object has a position tuple.
02:06
<&Derakon>
A Cell in the map; a simple container that holds all the entities at that location.
02:06
< [R]>
One written by someone who doesn't understand multi-dimensional arrays.
02:06
<&Derakon>
Fortunately it turns out that I never actually reference the Cell's ID directly, so the fact that it has a position is in fact irrelevant.
02:07
<&McMartin>
[R]: I will admit to using a map of tuples to represent random-access sparse arrays
02:39
< [R]>
TIL: you can shebang .jar files
02:39
<@celticminstrel>
...how does that work.
02:39
< [R]>
.jar files are .zip files.
02:40
< [R]>
.zip files have footers.
02:40
< [R]>
Which is why you can have self-extracting .zip files.
02:40
<@celticminstrel>
Footers? Not headers?
02:41
< [R]>
Right
02:41
<&McMartin>
And it's a footer of variable length and the magic identifier number is at the start of it
02:41 * McMartin rages inhumanly
02:41
< [R]>
O.o
02:41
< [R]>
lolwat
02:41
< [R]>
That's horrible
02:41
<&ToxicFrog>
celticminstrel: specifically, the central directory is at the end of the file; you can append a zipfile to anything and it remains a valid zip file.
02:41
<&McMartin>
I wrote a .zip decoder a month or two back.
02:41
<&McMartin>
Pretty minimalist but did what I needed
02:42
<&McMartin>
I'm taking the C++ out of it over the next couple days, I think.
02:42
<&McMartin>
So I can have a super-minimalist libphysfs.
02:42
<&McMartin>
But seriously
02:42
<&McMartin>
The magic number should have been at the end, Mr. Katz.
02:42
<&McMartin>
Or at least a fixed distance therefrom.
02:43
<@celticminstrel>
...ah, good to know.
02:43
<@Namegduf>
Implication: You can shebang .zip files
02:43
<&McMartin>
Yup
02:43
<&McMartin>
That said
02:43
<@Namegduf>
And make Linux "self-extracting" zip files which don't contain executable code.
02:43
<@Namegduf>
I do not, however, advocate this.
02:43
<&McMartin>
You'll have to do work to make it happen, because the zip entries have offsets from the start of the file, so you'll need to update the links therein.
02:44
< [R]>
Not every distro unzips the same way though
02:44
<&McMartin>
Isn't unzip part of the base utils by now?
02:44
< [R]>
Some have `unzip`, some make you use `p7z` some saner ones name it `7z` instead, and a few very rare ones have a `zip` command that also unzips.
02:44
<@Namegduf>
No. It's often available, but like rar files .zip is actually fairly unusual in Linux stuff
02:44
< [R]>
f
02:45
<@Namegduf>
unzip is pretty standard; I doubt the ones with 7-zip often *only* have 7-zip.
02:45
<&McMartin>
7z is a different beast, yeah
02:45
<@Namegduf>
I think zip and unzip come in the same package, usually, and zip normally has a parameter to "become" unzip
02:46
<@Namegduf>
Some other stuff in Linux is like that
02:46
<&McMartin>
Yeah
02:46
<&McMartin>
VirtualBox -_-
02:46
<@Namegduf>
unwhatever OR whatever --undo-or-something
02:47
<@Namegduf>
Yeah, bzip2 with a parameter, OR bunzip2
02:47
<@Namegduf>
Those two are quite common because bz2 is
02:47
< [R]>
zip and unzip are entirely seperate packages on every distro that I've used with em.
02:47
<@Namegduf>
Hmm, they are now. Maybe I misremembered that.
02:48
< [R]>
Oh, Slackware has the info-zip version for both
02:48
< [R]>
Hmm
02:49 Karono [Karono@Nightstar-03f66622.optusnet.com.au] has joined #code
02:58 * Derakon eyes deserialization.
02:58
<&Derakon>
On the one hand, recreating game objects tends to require that they have a copy of the GameMap handy, since they interact with it while being created.
02:59
<&Derakon>
On the other hand, I want the GameMap to itself be one of the objects that the deserializer recreates.
02:59
<&Derakon>
This seems unlikely to work out...
02:59 Courage [Moltare@583787.FF2A18.190FE2.4D81A1] has quit [Ping timeout: 121 seconds]
02:59
< [R]>
Can you dummy load the GameMap, then fill it as you get data from the deserialization?
03:00
<&Derakon>
That's actually how all of the other objects work.
03:00
<&Derakon>
They have to provide two functions: one creates a "blank" object -- bare-bones and empty as possible, the other fills in the data a fter.
03:00
<&Derakon>
Er, after.
03:01
<&Derakon>
The difficulty being that I have to have a GameMap lying around before any of the "create bare-bones object" functions get called, as it's the only input to those functions.
03:02 Chutzpah [Moltare@583787.FF2A18.190FE2.4D81A1] has joined #code
03:05 Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code
03:05 mode/#code [+qo Vornicus Vornicus] by ChanServ
03:05 Vorntastic [Vorn@Nightstar-79f10640.sub-70-211-3.myvzw.com] has quit [[NS] Quit: Bye]
03:44 Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds]
03:45 Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code
03:45 mode/#code [+qo Vornicus Vornicus] by ChanServ
04:14 VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [[NS] Quit: Program Shutting down]
04:15 Kindamoody[zZz] is now known as Kindamoody
04:41 Karono is now known as Karono[afk]
04:44 Karono[afk] [Karono@Nightstar-03f66622.optusnet.com.au] has quit [Connection reset by peer]
04:45 Karono[afk] [Karono@Nightstar-03f66622.optusnet.com.au] has joined #code
04:49 Karono[afk] [Karono@Nightstar-03f66622.optusnet.com.au] has quit [Ping timeout: 121 seconds]
05:08 ktemkin[awol] is now known as ktemkin
05:13 Karono [Karono@10AAA2.FD2B33.6E253B.F190AF] has joined #code
05:13 Derakon is now known as Derakon[AFK]
05:44 Turaiel is now known as Turaiel[Offline]
05:44 Turaiel[Offline] is now known as Turaiel
06:13 Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has quit [Ping timeout: 121 seconds]
06:14 ErikMesoy|sleep is now known as ErikMesoy
07:14 celticminstrel [celticminst@Nightstar-8403057e.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
07:14 Turaiel is now known as Turaiel[Offline]
07:47 Orthia [orthianz@3CF3A5.E1CD01.B089B9.1E14D1] has quit [Ping timeout: 121 seconds]
07:50 AverageJoe [evil1@Nightstar-4b668a07.ph.cox.net] has joined #code
07:53 Orthia [orthianz@3CF3A5.E1CD01.B089B9.1E14D1] has joined #code
07:53 mode/#code [+o Orthia] by ChanServ
08:23 Kindamoody is now known as Kindamoody|out
08:25 * Vornicus should really, you know, Write Some Code.
08:53
< AverageJoe>
nah
08:53
< AverageJoe>
f that
09:09 You're now known as TheWatcher
09:24 Karono is now known as Karono[afk]
09:27 ktemkin is now known as ktemkin[awol]
09:51 AverageJoe [evil1@Nightstar-4b668a07.ph.cox.net] has quit [[NS] Quit: Leaving]
09:51 Karono[afk] is now known as Karono
09:54
<&McMartin>
f() that
09:56
<~Vornicus>
clearly, f(that)
10:03
< Syka>
that.f()
10:17
< ErikMesoy>
f().that()
10:17
< Karono>
f->that();
10:31 * TheWatcher eyes you all
10:34
< Syka>
TheWatcher.eyes(that)
10:40
<@TheWatcher>
Tsk, no. `my $channel = Irssi::active_win -> {active}; foreach my $nick ($channel -> nicks()) { $self -> eye($nick); }`
10:42
<@TheWatcher>
Wait, no. I'm not really an Irssi bot.
10:47 * TheWatcher sighs at these students
10:47
< Karono>
enraged teacher stories? I can never get enough of those
10:47
<@TheWatcher>
What do they have against checking the return values from functions?
10:51
<&McMartin>
Call-with-cthulhu-invocation!
10:51 * McMartin ponders the questionable virtues of writing a JSON parser in Scheme on pen-and-paper during his flight tomorrow.
10:52
<@TheWatcher>
For extra marks*: write it in Enochian.
10:53
<@TheWatcher>
* or possibly extra shoggoths, either way.
10:53
<&McMartin>
I'm translating this C++ to C right now
10:53
<&McMartin>
Speaking of checking return values
10:53
<&McMartin>
I tell you what, I'm missing exceptions damned hard
10:53
< Reiver>
... why would you do that McM
10:53
<&McMartin>
I want a DLL that can be linked against by others
10:54
<&McMartin>
C++ is kind of utter shit at this, even if everything you *intentionally* export is C-linker compatible
10:54
<&McMartin>
And even when you stay within C++, exceptions and DLLs don't mix without a serious chunk of Being Incredibly Fragile.
10:55
<&McMartin>
I started design on the next few levels of abstraction while playing with FFI tests and just decided the C++ game wasn't worth the candle
10:55
<&McMartin>
So I've got two source files to de-libstdc++.
10:55
<@TheWatcher>
Last night I disovered that the NewDark has been compiled with exceptions disabled. This explains some crashes I've caused >.>
10:55
<@TheWatcher>
-the
10:56
<&McMartin>
Since the only things I was making serious use of were std::list and std::map, and I've got C replacements for those now, I'm good to go.
10:56
<&McMartin>
TheWatcher: Yeah
10:56
<&McMartin>
Basically, if your DLL or .so was written including C++, stuff that links against you has to use not only the same compiler that you did, but the same *compiler options*
10:56 Karono [Karono@10AAA2.FD2B33.6E253B.F190AF] has quit [Client closed the connection]
10:57
<&McMartin>
Whereas if I write it in C my library can be loaded by anything capable of making system calls.
10:57 Karono [Karono@Nightstar-03f66622.optusnet.com.au] has joined #code
10:57 * McMartin blinks
10:57
<&McMartin>
I'd hesitate to ask anyone else, but you'd know and also not put this fact to terrible use
10:57
<&McMartin>
How's Perl's C-import interface?
10:59
<@TheWatcher>
A shitton of standard perl modules are implemented in C
10:59
<&McMartin>
Yeah. That doesn't quite answer my question though >_>
11:00
<&McMartin>
Python and Scheme both basically have a module that lets you say "here is a shared binary name, and here is a C function prototype" and get back "here is a callable Python/Scheme object, go nuts"
11:01
<@TheWatcher>
Pretty much the same
11:01
<@TheWatcher>
perl has XS
11:01
<@TheWatcher>
You write an XS file for the library, compile it, and you get some gubbings you can basically just 'use Whatever' in your perl code, and talk to the library
11:02
<@Tarinaky>
iirc in Python you have to do unintuitive stuff to make the function's arguments work.
11:02
<@TheWatcher>
the XS file deals with mapping how the c library routines are used, and the types they take/return, and the stuff the perl code sees
11:02
<@Tarinaky>
Well, I say unintuitive.
11:03
<&McMartin>
There's always going to be a certain level of bullshit regarding how storage works
11:03
<&McMartin>
Which is why Monocle is designed to never pass anything more structurally complex than an intptr_t >_>
11:05
<@TheWatcher>
(I wasn't /entirely/ joking when I said that I could write perl bindings for Monocle. As long as it's not doing anything exotic, it should actually be easy to do. Whether it's something that /should/ be done is another matter)
11:08
<&McMartin>
(Yeah, once I get something worth making the bindings for I'm going to use it as a vehicle to explore FFIs)
11:08
<&McMartin>
(My 'I actually need this to work' is basically restricted to Python and Mono, though, and I know I've got those covered~)
11:09 Karono [Karono@Nightstar-03f66622.optusnet.com.au] has quit [Client closed the connection]
11:09 Karono [Karono@Nightstar-03f66622.optusnet.com.au] has joined #code
11:20 Syloq [Syloq@NetworkAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds]
11:21 Syloq [Syloq@B4EC54.59F324.016BDA.8CB0A3] has joined #code
11:21 mode/#code [+o Syloq] by ChanServ
11:32 Karono is now known as Karono[afk]
11:37
< RichyB>
McMartin: "never pass anything more structurally complex than an intptr_t" <3
11:37
< RichyB>
Also makes Haskell bindings trivial...
11:37
< RichyB>
Also makes Javascript bindings (!) trivial...
11:38
< RichyB>
(There's a library called "js-ctypes" available to some Mozilla things.)
11:39
<&McMartin>
The Haskell bindings, sadly, aren't entirely trivial because they'll be Monadic As All Fuck
11:39
<&McMartin>
You'd want to shelter some of that away
11:40 himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Client closed the connection]
11:46
< RichyB>
Meh. Unless Monocle actually does significant amounts of stuff which is really pure computation, that's not an issue.
11:46
< RichyB>
"My entirely-IO-oriented library is stuck entirely in the IO monad!" is neither an antipattern nor a problem.
11:48
< RichyB>
There are some things that you'd want to do, like write lenses ("lenses" in Haskell are reified getter/setter pairs) for lots of attribute so that you can have nice syntax like "foo $= 2" instead of "setFoo 2" just to be idiomatic.
11:48
<&McMartin>
Hmm
11:49
<&McMartin>
So, there's an event loop. That's going to be highly monadic
11:49
<&McMartin>
One could imagine lenses
11:49
<&McMartin>
But one builds a collection of objects in Monocle and then lets them loose
11:49
<&McMartin>
It seems like that should be organizable as a non-monadic mapping function.
11:49
< RichyB>
It's actually really common in Haskell to have multi-level bindings to C libraries, where there's one package which just has the raw "foreign import ccall ..." statements in it, and another one which turns it into idiomatic Haskell.
11:49
<&McMartin>
Yeah
11:50
<&McMartin>
And there's a really obvious place to do that, for the update routines, which seem like they could reasonably be pure-functional
11:50
<&McMartin>
And then the rendering ones, which obviously would not
11:50
<&McMartin>
If you did it with lenses, then perhaps even the update routines would be monadic, dunno
11:52
< RichyB>
Oh, I might have misused the term "lens" because AIUI there are purely-functional equivalents to the concept I just named.
11:52
< RichyB>
getter/setter pairs are what I was talking about.
11:52
<&McMartin>
I still haven't thought those layers through fully
11:53
< RichyB>
Whoops yeah, I meant statevars.
11:53
<&McMartin>
But it is nearly 4AM, and I have an airplane trip tomorrow, so, z
11:53
< RichyB>
http://hackage.haskell.org/packages/archive/OpenGL/latest/doc/html/Graphics-Rend ering-OpenGL-GL-StateVar.html
11:53
< RichyB>
Sleep well, McM.
11:56 Karono[afk] is now known as Karono
11:58 * TheWatcher ughs, apparently needs more tea, just had terrible problems stopping himself spelling implementatatatation
12:01 VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code
12:08
< Reiver>
... So, uh, at what point did OpenGL become Sufficiently Awesome to be a viable replacement for ActiveX on large-scale games?
12:08
<~Vornicus>
Um
12:08
<~Vornicus>
I presume you mean DirectX
12:08
<~Vornicus>
but the Quake engine has always been opengl.
12:09
< Syka>
Reiver: since... forever?
12:09
< Reiver>
DirectX, yeah.
12:10
< Syka>
Reiver: opengl has always been on par with directx - microsoft just don't want you to know that
12:10
< Reiver>
Syka: Hardly.
12:10
< Karono>
Also, the whole thing about DirectX being more than just Direct3D and such
12:10
<@TheWatcher>
Yeah
12:10
< Syka>
Reiver: no, it more or less has
12:10
< Reiver>
Technically, it was capable of doing everything ActiveX did, but it was a hell of a lot more finicky to work right.
12:10
<@TheWatcher>
OpenGL is arguably as good as or better than Direct3D
12:10
< Syka>
...activeX?
12:11
< Reiver>
Fuuuck, my brain is miswired. Sigh.
12:11 * Karono snerks at ActiveX again
12:11
<@TheWatcher>
But DirectX includes a lot more than just Direct3D
12:11
< Reiver>
DirectX.
12:11
< Syka>
yeah, opengl is on par/better than direct3d
12:11
< Reiver>
Assume any refeence to ActiveX for the next hour or so is in fact DirectX, I'm just tired~
12:11
< Syka>
as far as sound systems, that's directsound, but I don't think anyone ever uses that directly
12:12
< Syka>
they wrap it in openal or some other thing by RAD Game Tools
12:12
< Reiver>
To put another way: OK, OpenGL could technically match Direct3D; but for a very long time game companies developed on DirectX because it was simply faster/easier on their end to get stuff shiny and performing right.
12:13
<@TheWatcher>
Well, more that with DirectX you get a bunch of things (like DirectInput) along for the ride
12:13
< Syka>
Reiver: bzzt
12:14
< Syka>
Reiver: one of the greatest graphics engines in history - iDTech - is OpenGL
12:14
< Reiver>
But as of late, it seems almost everyone and their dog will cheerfully use OpenGL - fss, Planetary Annihilation skipped DirectX entirely in favor of OpenGL to streamline development. I feel like I missed an inflection point in there somewhere, and I'm wondering when and what it was.
12:14
< Syka>
the reason they used DirectX was that it was better on *Windows*
12:14
<@TheWatcher>
The downside was that using it tied you to windows, yeah
12:14
< Syka>
OpenGL was sort of shafted by the driver developers and Microsoft
12:14
<@TheWatcher>
Reiver: the word you're looking for is "portability"
12:15
< Reiver>
... oho?
12:15
< Syka>
Reiver: opengl has critical mass now
12:15
< Reiver>
So OpenGL became king when people decided Mac/Linux were worthy?
12:15
< Syka>
Android, iOS, Mac OSX, Linux, and even Windows
12:15 * Reiver muses.
12:15
< Syka>
Reiver: DirectX also stagnated
12:15
< Syka>
DX9 was released in what, 2003
12:16
< Reiver>
Syka: Yeah, I know it does. I'm wondering when and why and how it hit that point; it seems very much a chicken-and-egg scenario and I'm trying to find the egg.
12:16
< Syka>
DX10 was released with Vista, but nothing really supported it until DX11 in 7
12:16
< Syka>
Reiver: oh yes, also
12:17
< Syka>
Reiver: PS3 is OpenGL, too
12:17
< Syka>
so Unreal supported it
12:17
< Reiver>
Even then, an awful lot of Unreal games ran on DX for an awful long time
12:18
< Syka>
that's because DirectX was better performing
12:18
< Syka>
see: MS shafting OpenGL
12:18
< Reiver>
Right, that's my point.
12:19
< Syka>
also, it's not like OpenGL was never used
12:19
< Reiver>
Be it via MS deliberately shafting or not, OpenGL simply had a hard time competing with DX for Serious Developers On Big Projects for a long time
12:19
<@Tamber>
Reiver, Serious Developers On Big Windows Projects.
12:19
< Reiver>
I mean yeah, there's always exceptions, but the general trend was DX All The Way.
12:19
< Syka>
...are you calling Doom Fucking 3 a non-Big Project
12:19
< Syka>
let me say that again
12:20
< Syka>
IDTECH WAS OPENGL
12:20
< Syka>
*iDTech*
12:20
< Reiver>
Syka: And IDTech is a rather long time ago, and failed to revolutionise the industry standards. :p
12:20
<@Tamber>
Hey, Syka; get down off the impotent raeg horse. "Had a hard time" != "Never, ever, ever used"
12:20
< Syka>
Reiver: ...
12:20 * TheWatcher blinks at Reiver
12:20
< Syka>
you're kidding, right
12:20
<@TheWatcher>
um
12:20 * Karono just, um, walks away or something
12:21 * Karono doesn't even know
12:21 * Reiver patpat TW, will stop that. Merely found Syka's exuberance a little too tempting. Moves on.
12:21
<@TheWatcher>
Uh-huh
12:21
< Syka>
I will beat you with Quake 2's legacy until you come out speaking Strogg
12:21
<@Tamber>
Don't poke the rageburd.
12:22 * Tamber hides the jabby-stick.
12:22
< Reiver>
Tamber: But I has a stick and everything~
12:22 * Azash gives everyone soothing pats
12:22
<@Azash>
What are we melting down about?
12:22
<@Tamber>
Everything.
12:22
<@Tamber>
(So, y'know, the usual~)
12:22
<@Azash>
Excellent
12:22
<@Azash>
Then I can melt down about this auto parts store's incredibly bad new webstore
12:23
<@Azash>
Actually I'm just going to implode
12:23
<@Tamber>
Azash, really want a meltdown? Have you seen what netcraft have done with their site?
12:23
< Syka>
right
12:23
< Reiver>
OK, so. Unless IDTech actually /was/ the inflection point (Which I doubt, given Unreal+DX's dominance in the market for a great many years, unless a crapload of things have been using the engine and I've just missed it somehow)
12:23
<@Tamber>
(I know, I'm late to notice again; but holy shit, it's bad.)
12:23
<@Azash>
Tamber: A couple of points
12:23
<@Azash>
First, their CS reps are entirely blocked from viewing orders by customer name
12:24
<@Azash>
Also as a friendly launch bunch, all prepaid orders are charged in advance then automatically mailed as COD
12:24
<@Tamber>
...
12:24
<@Azash>
s/bunch/bug/
12:24
< Syka>
Reiver: BTW
12:24
< Syka>
Reiver: the world's biggest game series uses iDtech
12:25
< Reiver>
As noted, sure, DX ruled supreme on Windows Projects. But there's a chicken and the egg thing there - did stuff shift to OpenGL because portability became desirable, or did portability become desirable becuse OpenGL was good enough that you'd use it in preferece, and portability came as part of the package?
12:25
< Reiver>
Syka: Call of Duty?
12:26
< Syka>
Reiver: yep
12:26
< Syka>
well it uses bits of idtech
12:26
< Syka>
they split like 10 years ago
12:26
< Syka>
(idtech is a technical base)
12:27
< Reiver>
Hum. Does it run OpenGL?
12:27
< Syka>
yes
12:27
< Syka>
CoD's primary platforms are the Xbox and PS3
12:27
< Syka>
the latter requires they do
12:27
<@TheWatcher>
Reiver: because portability became desirable, mainly. There have always been users of opengl, and pretty much all of them either were explicitly multiplatform or written with an eye to be.
12:28
<@TheWatcher>
If you were a windows-only developer, working on a project you never expected to be ported to anything else, you'd use Direct3D simply because it was there, it worked, and you got the rest of DirectX along with it (especially DirectInput).
12:29
<@Tamber>
Reiver, I suspect it was the former. OpenGL was -- and correct me if I'm wrong -- The Standard for anything other than Windows projects; so if you were doing, say, 3D rendering crud on a UNIX, chances are you'd be using OpenGL. (...which is, really, what it was *for*) But if you tried to use the same code on Windows, it'd probably hurt (Either out of lack of proper [...]
12:29
<@Tamber>
[...] hardware acceleration (Which is the biggest one. OpenGL was written assuming hardware accel. Direct3D was written assuming there wasn't any, but used it if there was.), lack of optimisation, or deliberate meddling. Pick whichever you favour~)
12:29
< Reiver>
TheWatcher: Aha, sweet, OK
12:29
< Reiver>
TheWatcher: So what brought about the Portability Revolution?
12:29 * Tamber also nods and hammers "Not Fucking With the Ecosystem" into the list of stuff. :D
12:29
< Reiver>
Is this 'when Macs started showing up on Steam' timeframe, or...?
12:29
<@TheWatcher>
Consoles
12:29
< Syka>
Tamber: yes, opengl was The Standard
12:30
< Syka>
since OpenGL was originally made by Silicon Graphics, IIRC
12:30
<@Tamber>
Yup
12:30
< Syka>
and then handed over to the Khronos Group
12:30
< Reiver>
... can't be, DX ruled for most of the XBox/XBox360 era, didn't it?
12:30
<@Tamber>
Reiver, that's the exception, surely~?
12:30
< Reiver>
Then the 360 started getting, uh, crusty.
12:30
< Syka>
Reiver: everything serious used OpenGL
12:30
<@Tamber>
(...and you really think Microsoft would give in to a competitor's standard on a flagship product? :p)
12:31
< Syka>
eg. your movie effects and shit
12:31
< Reiver>
Syka: Oh, I know that much, yes. But that wasn't gaming.
12:32
<@TheWatcher>
Reiver: I suspect that it's honestly more complicated than a single thing. The fact that the PS3 used OpenGL would have been part of it, expansition in mac and linux gaming would be another
12:32
< Syka>
well, Half Life, which pretty much invented the Good Story FPS, used a hacked together idtech 2
12:32
<@Tamber>
(Plus, if it used roughly the same software ecosystem as the PC, then *in theory* you could get your games to work on both with minimal skullfuckery. Or at least only a *small* forest of #ifdefs =)
12:32
< Reiver>
I more mean that for a long time on windows PCs, 'install a game' had 'and also update your DX' were nearly synonyms
12:32
< Syka>
Source still has bits of idtech 1 in there~
12:32
< Syka>
Reiver: that's because directx is stupid
12:32
<@TheWatcher>
Syka: LIES!~
12:32
< Syka>
and you built agianst point releases
12:32
<@TheWatcher>
(at least, that's what Valve'd like to think...)
12:33
< Syka>
TheWatcher: huh?
12:33
< Syka>
no, gaben says that directly
12:33
< Reiver>
Syka: Yes, that's nice. I'm not picking sides here, just tracking historics.
12:33
< Syka>
he says there's still bits of Quake in there :P
12:33
< Syka>
not a lot, but there's still a few Hard Problems that iDtech fixed
12:33
<@TheWatcher>
Syka: Huh, really? Last I heard they were vehemntly denying it, 'about time they admitted it though
12:33
< Reiver>
And then, in the past few years, you... don't.
12:33
< Syka>
because early Carmack was a fucking genius
12:33
<@Tamber>
Reiver, that was the most annoying thing about that. DX and other various runtimes, anyway. "Look, it's a standard runtime so you don't have to install a shittonne of runtime support crap with every game!" *has to install slightly different versions of the runtime support crap with every game*
12:34 * Tamber glares at the VC runtimes.
12:34
< Syka>
TheWatcher: "Source distantly originates from the GoldSrc engine, itself a heavily modified version of John D. Carmack's Quake engine, as is explained by Valve employee Erik Johnson on the Valve Developer Community"
12:34
< Reiver>
And then the Big Boy Games including things like PlanetaryAnnihilation (WHich granted, is a mid-scale project, but by a Serious Team), go, nearly literally, "...DirectX? Why the heck would we use that? OpenGL ftw"
12:34
< Reiver>
And I go "... whoa, when did /that/ wind shift?"
12:35
< Syka>
"John Carmack commented on his blog in 2004 that "there are still bits of early Quake code in Half-Life 2""
12:35
< Syka>
Reiver: uh
12:35
< Syka>
I don't think Planetary Annihilation counts as a Big Serious Game
12:35
<@Tamber>
Everything's all built on the crumbling, hastily-propped up remains of everything that went before it.
12:35
< Reiver>
Syka: No, but it is being built by people who tend to lean heavily on Big Serious Tools to get shit produced.
12:36
< Syka>
Reiver: most people just use an engine
12:36
< Syka>
they license Unreal, hack their shit on top, and release the game
12:36
< Reiver>
Right.
12:36
< Syka>
nowadays, they license Unity
12:36
< Reiver>
And somewhere in there, everyone stopped using DX as part of the engine stack.
12:37
< Syka>
well, no
12:37
< Syka>
they don't CARE about the engine stack
12:37
< Reiver>
Once apon a time, *not* using DX would have been noteworthy.
12:37
< Syka>
that's why they licensed it
12:37
<@Tamber>
I believe that, if you go and license one of the big engines, it's relatively* painless** to change out whether you're using D3D or OpenGL.
12:37
< Syka>
Tamber: it depends
12:37
< Syka>
I think with Unreal it is
12:37
< Reiver>
I was wondering mostly at what point this shift happened.
12:37
< Syka>
since you write your stuff in Unreal-specific stuff
12:38
<@Tamber>
* "compared to swallowing ground glass and scorpions" ** will only make you scream for months, after that, your brain is too numb to care any more.
12:38
< Syka>
Reiver: it's just always happened
12:38
< Syka>
openGL has always been *there*, because it's on the PS3
12:38 * Reiver sighs.
12:38
< Reiver>
Yes, yes, I know.
12:38
< Syka>
people just did the right thing
12:38
< Syka>
and had the engine take care of the GL
12:38
< Syka>
swappable back ends
12:39
< Syka>
if you had that, it doesn't *matter* what GL you're using
12:39
< Reiver>
Realise your arguement is coming across as Q: "Hey, when did people start actively prefering OpenGL to DirectX" A: "OpenGL was always awesome and was used the whole time"
12:40
< Syka>
your question is like "when did people start actively preferring AMD64 to i386"
12:41 * Tamber sighs, drops a lot of very heavy SGI boxes (from the department of redundancy department) on the conversation.
12:41
< Syka>
AMD64 support was pretty much always there, people just flicked GCC to use it
12:41
< Reiver>
...
12:41
< Syka>
(always as in 'since amd64 chips existed')
12:41
< Syka>
the analogy doesnt quite work
12:41
< Syka>
since technically OpenGL came first
12:42
<@Tamber>
...the worst thing is, it's better than your usual analogies.
12:42 * Reiver wanders off.
12:42
< Syka>
Reiver: OpenGL was always there, and always being used - it's just that nowadays, people go 'WHOO OPENGL' rather than putting it as a bullet point in the engine specs
12:43
< Syka>
because what people did was write an engine, and the engine would have pluggable backends for the different renderers, for targeting different platforms
12:43
< Syka>
people are going 'whoo opengl' for the /portability PR/ even though /loads of engines already did it/
12:44
< Syka>
it's like advertising that the particular model of desktop you have has USB3 built in, even though that's standard in Ivy Bridge chipsets
13:05 himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code
13:05 mode/#code [+o himi] by ChanServ
13:30 * ToxicFrog upreads
13:32
<&ToxicFrog>
Reiver: yes, for something like 2003-2010, DX-only games on PC were extremely common; at this time DX9/10/11 had pulled ahead of OGL feature-wise and mac/linux weren't seen as viable gaming platforms, so unless you were doing a PC+PS3 game - itself rare - a lot of developers went to DX.
13:32
<&ToxicFrog>
This also coincided with ATI and nV OGL support being shit, although it's hard to say what the cause/effect is there.
13:32
< Reiver>
Right.
13:33
<&ToxicFrog>
These days, OGL has caught up a lot and portability across PC platforms is seen as a bigger concern, and the driver situation has improved.
13:33
<&ToxicFrog>
Result: a resurgence in games using dual OGL/DX or pure OGL rendering stacks.
13:34
<&ToxicFrog>
I note that the 360 does not support OGL, and there are way more PC/360 games than PC/PS3 because porting between those two is so much easier; all of those games use DX.
13:34
< Reiver>
Interesting. Did anything drive this catchup, or was it more tht DX stagnated?
13:35
<@gnolam>
Correction: "pulled ahead of OGL feature-wise" "pulled ahead of /core/ OGL feature-wise".
13:35
<&ToxicFrog>
Granted.
13:35
<@gnolam>
OpenGL will always let you have accesss to the latest and greatest inventions. It's just that you'll have to write separate code paths for different vendors.
13:36
<&ToxicFrog>
Reiver: OGL 2.0 and 3.0 came out introducing a bunch of new stuff, Valve leaned on GPU manufacturers to unfuck their drivers, increasing numbers of indie developers building stuff for minimum budget and maximum portability.
13:37
<&ToxicFrog>
Wolfire Games has some interesting stuff on the OGL/DX wars; as recently as three years ago they were getting reactions of shock and dismay from both other developers and video card manufacturers when they said they used OGL for all their games.
13:38
< Reiver>
Yes, that was much the status of OpenGL for a while as I understood it, Syka's protelisations aside~
13:38
< Reiver>
(Who are Wolfire games?)
13:40
<&ToxicFrog>
(Lugaru, Receiver, Overgrowth)
13:40
< Syka>
the guys behind humble indie bundle
13:40
< Syka>
iirc
13:40
< Syka>
i think humble bundle was originally a wolfire thing
13:40
<&ToxicFrog>
The first one was, then they spun up a separate company to manage them
13:42
< Reiver>
Right.
13:54
<&ToxicFrog>
Aah, this is the artcile I was thinking of: http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX
14:20 Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving]
14:27 celticminstrel [celticminst@Nightstar-8403057e.dsl.bell.ca] has joined #code
14:27 mode/#code [+o celticminstrel] by ChanServ
14:45 * TheWatcher ...s
14:45
<@TheWatcher>
Why had I never run into mintty before?
14:55
<@Azash>
https://github.com/blog/1547-release-your-software
14:58
<&ToxicFrog>
Sweeeeeeeeeeeeeeeeeeeeeeeeet
15:18 VirusJTG_ [VirusJTG@BAD19E.09A45B.582A63.5AE998] has joined #code
15:20 VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [Ping timeout: 121 seconds]
15:21 celticminstrel [celticminst@Nightstar-8403057e.dsl.bell.ca] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.]
15:21 celticminstrel [celticminst@Nightstar-8403057e.dsl.bell.ca] has joined #code
15:21 mode/#code [+o celticminstrel] by ChanServ
15:49
< [R]>
http://xiennith.com/wtf.txt
15:49
< [R]>
(JS)
15:51
<@TheWatcher>
That appears to missing important bits
15:51
<@TheWatcher>
like the definition of a
15:52
< [R]>
Done
15:52
< [R]>
Updated rather
15:54
< [R]>
a = new Array(5)
15:54
<@TheWatcher>
Interestingly, it behaves differently for me in opera
15:55 VirusJTG__ [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code
15:55
<@TheWatcher>
http://pastebin.starforge.co.uk/572
15:56
<@TheWatcher>
actually, no, I think opera is just hiding the empty array
15:56
<@TheWatcher>
so it behaves the same
15:56 * TheWatcher shrug
15:56
<@TheWatcher>
Javascript.
15:57
<@TheWatcher>
Oh, wait, here we go
15:57
<@TheWatcher>
"callback is invoked only for indexes of the array which have assigned values; it is not invoked for indexes which have been deleted or which have never been assigned values."
15:58
< [R]>
Lovely
15:58
< [R]>
Guess I can't one-line this.
15:58 VirusJTG_ [VirusJTG@BAD19E.09A45B.582A63.5AE998] has quit [Ping timeout: 121 seconds]
15:58
< [R]>
All I wanted was an array with size X filled with values Y D:
16:03
<@Azash>
What language?
16:04
<@Azash>
Oh JS
16:09
< [R]>
Oh well, I've got it working now :)
16:09 * Azash wonders if any language has arrays that can do a binary operation over every element
16:10
< [R]>
Uhh?
16:10
< [R]>
Pretty much all of the ones that have arrays and binary operators can?
16:10
< [R]>
Unless you meant with sugar.
16:10
<@Azash>
I mean like
16:10
<@Azash>
array2 = array XOR integer
16:10
<@Azash>
For example
16:11
<@Azash>
If this is a common feature I will have the sads
16:12
< [R]>
a.map(function(n) { return n ^ 4 }) // close as JS gets. But seeing as binops are rarely called I don't see why that should be a first-class thing.
16:13
<@Azash>
It's more a thought that popped up
16:13
< ErikMesoy>
Azash: numpy
16:13
<@Azash>
Python, hissss
16:14
< ErikMesoy>
"Numpy" is a very silly-sounding name.
16:14
<@Azash>
Nincompyp
16:14
<&ToxicFrog>
Azash: a lot of languages let you implement something like that using operator overloads. APL has that as a builtin.
16:15
<&ToxicFrog>
Generally you'd just use map, though.
16:15 Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has joined #code
16:15 mode/#code [+o Alek] by ChanServ
16:15
<@Azash>
Right
16:54 Kindamoody|out is now known as Kindamoody
17:08
<@iospace>
... i have two 24 inch monitors at work... and i still feel like i need another one Dx
17:10
< Syka>
hey iospace
17:10
< Syka>
iospace: https://dl.dropboxusercontent.com/u/14290114/IMG_20130110_183110.jpg
17:10
< Syka>
:3
17:12
<@iospace>
Syka: are you doing low level development at work with a 4 data sheets open right now? ^_^
17:13
< Syka>
iospace: no, I am doing high level development in my home office with no pants on
17:13 * iospace golf claps
17:13
< Syka>
:3
17:14
<@iospace>
i'm working on an i7 BIOS right now, specifically an SMBus driver for a FPGA attached to the board
17:15 * iospace shrugs
17:21 Kindamoody is now known as Kindamoody|out
17:33 Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code
17:33 mode/#code [+ao Derakon Derakon] by ChanServ
17:36 Derakon[AFK] [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds]
17:41 Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds]
17:42 Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code
17:42 mode/#code [+ao Derakon Derakon] by ChanServ
18:32 AnnoDomini [abudhabi@Nightstar-cc35cb3c.adsl.inetia.pl] has quit [Ping timeout: 121 seconds]
18:35 abudhabi [abudhabi@Nightstar-c53de59e.adsl.inetia.pl] has joined #code
18:36 abudhabi is now known as AnnoDomini
18:44 Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has quit [Ping timeout: 121 seconds]
19:22
<&ToxicFrog>
Oh what is this nonsense
19:22
<&ToxicFrog>
They're planning a power outage this weekend
19:22
<&ToxicFrog>
I don't want to have to restart all my terminals!
19:26 Karono [Karono@Nightstar-03f66622.optusnet.com.au] has quit [[NS] Quit: ]
19:35 ktemkin[awol] is now known as ktemkin[work]
19:49 * McMartin eyes this code.
19:50
<&McMartin>
I have to choose between a function hundreds of lines long, but with like three levels of indentation max, or a dozen-odd functions with kind of arbitrary arguments, none of which are exported and all of which are called exactly once.
19:50
<&McMartin>
These are *both* bad code smells.
19:53 Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has joined #code
19:53 mode/#code [+o Alek] by ChanServ
19:54
<@froztbyte>
haha
19:54
<@froztbyte>
fun times
19:56
<&McMartin>
I think I'm going to go for the former; one of the reasons all these functions are called exactly once in the first place is that I'm trying to not cache anything and also present an incredibly simple interface.
19:57
<&McMartin>
Oh, hm
19:57
<&McMartin>
I could have the refactored functions have the interface "you pass it a file pointer and it returns success or failure. If it returned success, then the file pointer has been fseek()ed to {semantically important thing}"
19:57
<&McMartin>
... I'm honestly not sure if that's better or worse
20:06 Kindamoody|out is now known as Kindamoody
20:11
< ktemkin[work]>
Wrap the file pointer in an object, and have it maintain state?
20:11
<&McMartin>
(a) this is C, (b) that's kinda what FILE * is already
20:12
< ktemkin[work]>
b) Right, but the state is meaningful in terms of the position in the file, not in terms of your semantic tokens.
20:13
< ktemkin[work]>
a) Okay, I assumed C++, and that would make the pattern I had in mind just as ugly as the above.
20:13
<&McMartin>
Right, the reason all of these look about the same is because none of this state leaves the translation unit
20:16
<&McMartin>
(This is a thin wrapper around zlib to index into a zip file and pull out and re-inflate data into a buffer)
20:16
<&McMartin>
(So the "state" is generally "I found the indexing information for (X)")
20:16
<@iospace>
and... that's a bug knocked down
20:16
<&McMartin>
(So the API could be "seek file pointer X to (Y)")
20:22
< ktemkin[work]>
(I /should/ have assumed C, given your return scheme above; that only makes sense if you lack exception handling.)
20:25
< ktemkin[work]>
Of the options you've said above, the single long function gives you the least ability to test.
20:30 Kindamoody is now known as Kindamoody|out
20:32
<&McMartin>
Kiiinda
20:32
<&McMartin>
These steps don't exist in a vaccuum
20:32
<&McMartin>
You can't test 3 unless you have already done the work for step 2
20:33
<&McMartin>
You can thus take a set of unit tests for steps 1-5 and turn them into an equivalent set of systemic tests
20:34
< ktemkin[work]>
If you're testing based on a known piece of reference data, shouldn't your seek offsets be constants?
20:35
< ktemkin[work]>
You'd be able to test the individual pieces by manually seeking to the location of the appropriate data, and then calling the UUT.
20:36
< ktemkin[work]>
(Unless you have other side effects that are more difficult to recreate.)
20:36
<&McMartin>
I'm finding a file in a .zip archive.
20:36
<&McMartin>
So the other part of this is "this really isn't *that large a problem* beyond step 1; it's basically "read from offset, seek to that location"
20:37
<&McMartin>
Step 1 is the one that I threw a lot of insane corner cases at but it's also fundamentally unsolvable because the spec is broken~
20:37
<&McMartin>
ZIP has a footer instead of a header, to make self-extractors work.
20:37
<&McMartin>
This footer is (a) variable length, (b) has its magic number at the *beginning* of this footer, which means that you have to do a backwards scan, and (c) includes a comment field at the end that may contain arbitrary data
20:38
<&McMartin>
I am adding in the unstated requirement "ZIPfile comments are not permitted to contain the ZIP footer magic number"
20:38
< RichyB>
(*)
20:38
< RichyB>
ZIP's use of a footer instead of a header also allows you to start streaming huge ZIP files to tape without necessarily having read all of your input yet.
20:39
<&McMartin>
That initial scan is really the only part that isn't "trust libc to do its job" or "trust zlib to do its job"
20:39
<&McMartin>
RichyB: There's also tape-archive-like inter-file quasiheaders
20:39
< RichyB>
Yes.
20:39
<&McMartin>
This also makes disk-spanning work semi-well.
20:39
< RichyB>
Importantly, nothing has a "length" field except the footer.
20:39
<&McMartin>
But only semi-well.
20:40
< RichyB>
Remembering that PKZIP was designed in the days of rollicking-slow floppy disk drives...
20:40
<&McMartin>
Since I'm not writing a ZIP file *verifier* I'm using the footer exclusively.
20:40
<&McMartin>
*
20:41
<&McMartin>
(The footer includes link to a central directory structure that is traditionally kept at the end of the file but it can actually be anywhere)
20:41
< RichyB>
You can actually stream files-to-be-archived in at one end, stream output-to-tape at the other end, and have to keep only enough storage in the middle to store the current DEFLATE compressor state and the dictionary of filenames and lengths. <3
20:41
<&McMartin>
Yup
20:41
<&McMartin>
ZIP is an almost entirely sensible format.
20:42
<&McMartin>
The one thing it did disastrously wrong is not put the magic number and and link to the real data as a 12-byte fixed-length footer.
20:42 Kindamoody|out is now known as Kindamoody
20:47
<&McMartin>
Anyway, this means that the three basic components to test, at the end of the day, are "can you find the central directory", "can you find a file *in* the central directory", and "did you configure zlib properly to re-inflate things right"
20:48
<&McMartin>
I am unconvinced that one gains anything by manually seeking to the start of the central directory to test the "find a file in the central directory" portion. It seems much more sensible to me to first sort out finding the central directory and then relying on that as infrastructure for the second test.
20:52
<&McMartin>
I guess you gain the ability to test the "find start of central directory" part without moving on to the rest, but those are smoke tests.
20:53
<&McMartin>
Those happened when I sketched out the original implementation of this in C++. The part I'm doing now is more "refactoring it so I don't rely on exceptions"
20:53
<&McMartin>
Since that was the only C++ feature this part really used, except for some std::vectors of fixed size within a function call.
20:55
< ktemkin[work]>
I don't think the argument for orthogonal unit tests is only based on the idea that a failing dependency prevents you from testing dependent functions.
20:57
< ktemkin[work]>
In general, the isolation between them assures you that your dependent functions don't "rely on" side effects generated by the dependencies.
20:57
< ktemkin[work]>
In your case, what you're doing is simple enough that you're likely aware of all of the side effects, so you may not /really/ gain anything by making your tests orthogonal.
20:57
<&McMartin>
More sharply, I'm deciding on how to functionally decompose this in the first place.
20:58
<&McMartin>
By the standard you propose, this really *should* all be one function, because they're all inextricably bound.
20:58 Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has quit [[NS] Quit: bbl]
20:58
<&McMartin>
Except for "OK, deflated data begins here", but that's a boundary between not only functions but modules, and I'm trusting zlib here =P
21:01
< ktemkin[work]>
(Of course, I don't think that pointing out a benefit of any particular course of action is the same thing as advocating that course of action.)
21:02 Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has joined #code
21:02 mode/#code [+o Alek] by ChanServ
21:04
<&McMartin>
Yeah
21:04
<@Alek>
Nope
21:04
<&McMartin>
SHORYUKEN
21:06 Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has quit [[NS] Quit: brb]
21:10 Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has joined #code
21:10 mode/#code [+o Alek] by ChanServ
21:12 Kindamoody is now known as Kindamoody[zZz]
21:13 Turaiel[Offline] is now known as Turaiel
21:23 Derakon_ [chriswei@Nightstar-a3b183ae.ca.comcast.net] has joined #code
21:23 * Derakon_ eyes his serializer. Uh oh.
21:23
< Derakon_>
"RuntimeError: Attempted to serialize unrecognized object type <type 'cython_function_or_method'>"
21:37
< Derakon_>
(That is, while my serializer seems to work fine for pure-Python method and object references, it has no clue what to do about Cython methods).
21:44
< Derakon_>
Oh hm, this only happens for lambdas within Cythonized code, apparently.
21:44
< Derakon_>
And I can't serialize lambdas anyway.
22:03 Courage [Moltare@583787.FF2A18.190FE2.4D81A1] has joined #code
22:03 mode/#code [+o Courage] by ChanServ
22:05 Chutzpah [Moltare@583787.FF2A18.190FE2.4D81A1] has quit [Ping timeout: 121 seconds]
22:21 Derakon__ [chriswei@Nightstar-a3b183ae.ca.comcast.net] has joined #code
22:21 Derakon__ [chriswei@Nightstar-a3b183ae.ca.comcast.net] has quit [[NS] Quit: leaving]
22:22 Turaiel is now known as Turaiel[Offline]
22:23 Derakon_ [chriswei@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds]
22:24 Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds]
22:25 Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code
22:25 mode/#code [+ao Derakon Derakon] by ChanServ
22:37 Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds]
22:38 Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code
22:38 mode/#code [+ao Derakon Derakon] by ChanServ
22:49
<@Tarinaky>
I'm having difficulty working out how to set the 'target' for OpenGL calls in PyGlet.
22:49
<@Tarinaky>
Say if I want to rasterise something offscreen to disk and write it out as a bitmap?
22:57 Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Operation timed out]
22:57 Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code
22:57 mode/#code [+ao Derakon Derakon] by ChanServ
23:03
<@Tarinaky>
Oh sod it. I don't need to do this anyway :/
23:07 gnolam_ [lenin@Nightstar-b2aa51c5.cust.bredbandsbolaget.se] has joined #code
23:07 gnolam is now known as NSGuest7027
23:07 gnolam_ is now known as gnolam
23:07 mode/#code [+o gnolam] by ChanServ
23:09 ErikMesoy is now known as ErikMesoy|sleep
23:11 NSGuest7027 [lenin@Nightstar-b2aa51c5.cust.bredbandsbolaget.se] has quit [Ping timeout: 121 seconds]
--- Log closed Thu Jul 04 00:00:32 2013
code logs -> 2013 -> Wed, 03 Jul 2013< code.20130702.log - code.20130704.log >

[ Latest log file ]