Is that there were *far* fewer booth babes this year compared to last year. Except for the increasingly ghetto-ized world of hardcore FPS people (ie, the Dallas/Austin crews), I don't think there was terribly much skin happening at all. What skin there was looked as painfully juvenile as one would expect.
Well, we certainly did a ton of work on SDL when we worked there. Almost all of the API decisions were driven by our work. I wrote the initial OpenGL code for HG2 specifically, etc., etc.
But, yes, as mentioned elsewhere, Sam owns most of the copyright.
FWIW, we Fed Ex'ed pressed CDs to people who ordered the game from us as soon as humanly possible--about two weeks after the Win32 CDs were pressed (I think less, actually). So it was hardly months.
Retail penetration of the boxes is a whole different situation, though, and is of course something we'd like to improve on.
Your comments on superheroes' innocence and gifts seems slightly bizarre, especially when you reference Batman, a character who is not gifted, per se--he's the quintessential self-made man of comics, unlike other characters such as Superman, who were simply born/whatever with their powers.
And while I'll admit Golden Age heroes had a feeling of innocence, the definitive work involving Batman, Miller's Legend of the Dark Knight, is hardly a study in guiltlessness. It's about demons and the willingness to commit acts which many people would consider not only criminal but morally wrong. Even the recent Golden Age reprisal treatments of DC superheroes by Mark WAid and Alex Ross (Kingdom Come, etc.) contain all sorts of exciting modern angst with heroes like Superman and Wonderwoman.
In the same vein, the slight intimation on your part in the introduction text makes it sound like people who like comics == people who like superhero comics.
In addition to the question "can seriousness and comic books mix" is "can comics books and films mix". I can't think of a movie off the top of my head that dealt with comics in an interesting way... aside from the "franchise films" like X-Men and The Crow, we have Chasing Amy and Mallrats, but the former just didn't do it for me, and the latter's Stan Lee fanboy-ism is sickening to anyone who's aware of the legacy of Kirby in everything named...
I use daily Mozilla snapshots and IE regularly. I prefer Mozilla by an order of magnitude. IE is always asking me to install stupid cursors, playing awful music (which I finally figured out how to turn off), crashing the whole system, it doesn't have a first order accessible "Go" menu, can't middle click to spawn (what the hell is that weird scrolly thing that pops up?), I can't seem to find a way to turn off Java and JavaScript, etc. Mozilla ain't perfect, but its infintely preferable for the way I want to experience the web.
When I don't use Mozilla, I use links (no, not lynx), a very excellent text-mode browser that supports frames and tables very very well.
Quake{1|2}'s software renderer used a pipelined FDIV for texturing that was critical for performance. Later iterations of the Quake2 engine used MMX to do single-pass 16-bit RGB lightmap blending, which also was helpful for speed.
Suffice to say the hardware renderers don't use any of this. I think there is a small bit of asm in Q3 for the VM stuff (like 5 lines).
I'm from Bethlehem, right near Lehigh, and while I won't pretend I'm anyone like ESR or RMS, I was asked by the Lehigh LUG to come speak last year. It would have been great because I could have stayed with my family and visited while on some company business.
Unfortunately, the fellow from the LUG who emailed me never replied to my followup./me shrugs. I suggest emailing your prospective speakers as a useful way of getting them interested/to show up:)
Because of things like page flipping? Because most Linux users routinely have tens of processes running in the background while using their systems? Because, as good as the NVIDIA drivers are, they are still new (labeled as Beta, even)?
Because a good Linux driver should perform some minimal input checking to enforce security (I don't know if NVIDIA does this--more of a DRI-ish thing)?
To an extent Matt does deal with this--you'll note the absence of the G400 and ATI cards from certain tests because, as Matt noted, they are not stable enough to be considered reviewable.
As to the NVIDIA drivers, it is my experience that their stability is inversely proportional to how crappy your AGP chipset is. My work box has never had a problem running any of our games, my flatmate's box with an AVi chipset has occasional crashes during games for no explicable reason.
As a counterpoint, the Win32 TNT setup I'm using right now incorrectly renders triangle strips for some reason...
> Fraid not. There's maybe 1% of the original Quake code still in Half Life (the File handling mostly).
This is silly. I heard Yahn Bernier describe the "new networking" in Half-Life at GDC, and guess what? It was the same old Quake II networking. I think many game companies have a little too much pride to say "oh, yeah, this is mostly Quake II with a modded software rendering engine and a big new bolted on scripting engine". NIH and all that.
> MFC's don't port nicely..
In the simplest case they could just use Wine, which has a very liberal license. If you actually want to port it, it's not too hard, just a lot of gruntwork. I ported 28k lines of MFC UI code in a few months.
All 13 (or is it 12?) episodes. Probably the best anime series ever produced, IMNSHO, Akira being the best single movie.
I was renting two or three of these a night for a week, and almost didn't write my undergraduate thesis because of it... a very powerful, even with its bildingsroman trappings, story that mixes technology, religion, human need, etc. Great stuff.
> Of course, it's a little less cool that we're > getting games way way past their release.
There are two large problems:
1) Most Windows developers aren't interested in the overhead of co-development. I don't know if there's much we can do about this. As long as a Linux port is an afterthought to a developer, we can't possibly ship on time. 2) These ports can be very hard. Heavy Gear II, for example, required alterations to:
- gcc (local static objects in DLL register destructors with atexit, various other issues) - glibc (new version of atexit to handle fixes above) - Mesa (FX driver initiates atexit handlers even if manually dlopen()) - Glide (never unmapped PCI address space until process exit) - gdb (didn't properly reload symbols after dlclose()/dlopen(), making debugging very difficult)
Finding these problems in the toolchain and then solving them have been very challenging. Hopefully the changes we made can be leveraged in future titles that will get to market faster. Also, all of the above fixes were folded back into the master tree. I'd like to thank the various people involved in those fixes: Mark Mitchell of CodeSourcery, Joseph Kain of 3DFX, Brian Paul of Mesa, and our own Sam Lantinga for the gdb fixes, which were given to HJ Lu.
Every day I work with the code of developers who think that classes/interfaces are the way to go for APIs. The stuff is *horrid*. When I'm done converting a piece of Direct3D code to OpenGL, it is far and away obvious which piece of code is
a) easier for me to write b) easier for me to maintain c) easeir for my peers to read and understand, and thus maintain
OpenGL is a beauty of an API for several reasons, from a stricly syntactic point of view because it is data-type neutral. When I need to port Direct3D code to OpenGL, I can almost always make the data structures work the way I need them, despite the best efforts of the minds at Microsoft to introduce D3DTLVERTEX and the FVF flags (ye gods).
The part about "orientation" isn't true at all. The first thing we did was appraise the current standardizations effort--basically look at the IASIG guidelines. The level 1 stuff is fairly straightforward: attenutation, panning, radiation cones, etc. No bones on that.
The level 2 stuff is the environmental reverb. This is approved by a whole host of companies, which you can see by visiting the IASIG website, including Aureal. You'll also note that this isn't currently a core part of the API--it's an extension (AL_ENVIRONMENT_IASIG, etc.), as we felt this might not be the Right Way to do environmental reverberations, etc., for the forseeable future.
Geometry specification is nice and clean from an API standpoint, but doesn't reflect what's really happenning on the card. When 3D sound boards are doing these geometry calculations in hardware, we can talk about the OpenAL 1.1 API or whatever.
There is also an issue of how to represent "materials". This is far from an easy task to decide.
OpenAL was a lot harder to specify than, say, OpenGL--they already had IrisGL, and they had a very straightforward silicon path--textured triangles.
Actually, there is no CD API. We felt it had no place inside of a 3D spatialized audio API if we wanted to keep things clear and consistent.
Support for MP3, etc., is planned, as an optional parameter for specifying a Buffer waveform. There is an issue of canonicalization though (stereo sound doesn't make sense for noise in a three dimensional space... it's just a sound).
I don't really see how you could say that. While we worked on the Linux software mixer and wrote a chunk of the API, the NPO actually will administer the licensing, etc. We'll just have one chair on that committee.
Yes, there was a previous API, but it never really got past a header/specification. We took up the name and worked with some of the original people behind the first two iterations.
I would assume that the networking aspect would live below the core API, or at the very least you would specify this sort of thing at the context level. I've actually talked to Jim Gettys about this stuff at Linuxworld, and the ESD people. We're looking into it...
Slashdot Mirror
The real question is: why is it so hard to spell?
Sam LaNtinga.
Sheesh.
m.
Is that there were *far* fewer booth babes this year compared to last year. Except for the increasingly ghetto-ized world of hardcore FPS people (ie, the Dallas/Austin crews), I don't think there was terribly much skin happening at all. What skin there was looked as painfully juvenile as one would expect.
m.
Well, we certainly did a ton of work on SDL when we worked there. Almost all of the API decisions were driven by our work. I wrote the initial OpenGL code for HG2 specifically, etc., etc.
But, yes, as mentioned elsewhere, Sam owns most of the copyright.
m.
Yes, it's worth noting that Loki does not own SDL, Sam owns most of the copyright. He had started it before working at Loki.
;) )
m.
(who was the lead on SoF, thanks for the compliments
David 'Zoid' Kirch. Now works at Retro Games, a 2nd party developer for Nintendo.
m.
FWIW, we Fed Ex'ed pressed CDs to people who ordered the game from us as soon as humanly possible--about two weeks after the Win32 CDs were pressed (I think less, actually). So it was hardly months.
Retail penetration of the boxes is a whole different situation, though, and is of course something we'd like to improve on.
m.
Loki Software, Inc.
> Now, Loki obviously doesn't(and in some cases,
> can't) release source code in a Free manner
For most games this is true, although Quake-derivatives have partial source released (SoF, for instance), and there is OpenUT, etc.
More importantly, though, all our tool/library source is availble, usually through GPL or LGPL. http://cvs.lokigames.com is our public CVS server.
m.
Loki Software, Inc.
Your comments on superheroes' innocence and gifts seems slightly bizarre, especially when you reference Batman, a character who is not gifted, per se--he's the quintessential self-made man of comics, unlike other characters such as Superman, who were simply born/whatever with their powers.
And while I'll admit Golden Age heroes had a feeling of innocence, the definitive work involving Batman, Miller's Legend of the Dark Knight, is hardly a study in guiltlessness. It's about demons and the willingness to commit acts which many people would consider not only criminal but morally wrong. Even the recent Golden Age reprisal treatments of DC superheroes by Mark WAid and Alex Ross (Kingdom Come, etc.) contain all sorts of exciting modern angst with heroes like Superman and Wonderwoman.
m.
Loki Software, Inc.
In the same vein, the slight intimation on your part in the introduction text makes it sound like people who like comics == people who like superhero comics.
In addition to the question "can seriousness and comic books mix" is "can comics books and films mix". I can't think of a movie off the top of my head that dealt with comics in an interesting way... aside from the "franchise films" like X-Men and The Crow, we have Chasing Amy and Mallrats, but the former just didn't do it for me, and the latter's Stan Lee fanboy-ism is sickening to anyone who's aware of the legacy of Kirby in everything named...
/me goes back to Maakies and Sock Monkey
m.
Loki Software, Inc.
Uh, those are just threads--they share the same address space.
It's just using 25M.
m.
Loki Software, Inc.
I use daily Mozilla snapshots and IE regularly. I prefer Mozilla by an order of magnitude. IE is always asking me to install stupid cursors, playing awful music (which I finally figured out how to turn off), crashing the whole system, it doesn't have a first order accessible "Go" menu, can't middle click to spawn (what the hell is that weird scrolly thing that pops up?), I can't seem to find a way to turn off Java and JavaScript, etc. Mozilla ain't perfect, but its infintely preferable for the way I want to experience the web.
When I don't use Mozilla, I use links (no, not lynx), a very excellent text-mode browser that supports frames and tables very very well.
m.
Loki Software, Inc.
Quake{1|2}'s software renderer used a pipelined FDIV for texturing that was critical for performance. Later iterations of the Quake2 engine used MMX to do single-pass 16-bit RGB lightmap blending, which also was helpful for speed.
Suffice to say the hardware renderers don't use any of this. I think there is a small bit of asm in Q3 for the VM stuff (like 5 lines).
m.
Loki Software, Inc.
I'm from Bethlehem, right near Lehigh, and while I won't pretend I'm anyone like ESR or RMS, I was asked by the Lehigh LUG to come speak last year. It would have been great because I could have stayed with my family and visited while on some company business.
/me shrugs. I suggest emailing your prospective speakers as a useful way of getting them interested/to show up :)
Unfortunately, the fellow from the LUG who emailed me never replied to my followup.
m.
Loki Software, Inc.
Because of things like page flipping? Because most Linux users routinely have tens of processes running in the background while using their systems? Because, as good as the NVIDIA drivers are, they are still new (labeled as Beta, even)?
Because a good Linux driver should perform some minimal input checking to enforce security (I don't know if NVIDIA does this--more of a DRI-ish thing)?
Etc.
m.
To an extent Matt does deal with this--you'll note the absence of the G400 and ATI cards from certain tests because, as Matt noted, they are not stable enough to be considered reviewable.
As to the NVIDIA drivers, it is my experience that their stability is inversely proportional to how crappy your AGP chipset is. My work box has never had a problem running any of our games, my flatmate's box with an AVi chipset has occasional crashes during games for no explicable reason.
As a counterpoint, the Win32 TNT setup I'm using right now incorrectly renders triangle strips for some reason...
> Fraid not. There's maybe 1% of the original Quake code still in Half Life (the File handling mostly).
This is silly. I heard Yahn Bernier describe the "new networking" in Half-Life at GDC, and guess what? It was the same old Quake II networking. I think many game companies have a little too much pride to say "oh, yeah, this is mostly Quake II with a modded software rendering engine and a big new bolted on scripting engine". NIH and all that.
> MFC's don't port nicely..
In the simplest case they could just use Wine, which has a very liberal license. If you actually want to port it, it's not too hard, just a lot of gruntwork. I ported 28k lines of MFC UI code in a few months.
m.
(who does not speak for his employer)
--
All 13 (or is it 12?) episodes. Probably the best anime series ever produced, IMNSHO, Akira being the best single movie.
I was renting two or three of these a night for a week, and almost didn't write my undergraduate thesis because of it... a very powerful, even with its bildingsroman trappings, story that mixes technology, religion, human need, etc. Great stuff.
> Of course, it's a little less cool that we're
> getting games way way past their release.
There are two large problems:
1) Most Windows developers aren't interested in the overhead of co-development. I don't know if there's much we can do about this. As long as a Linux port is an afterthought to a developer, we can't possibly ship on time.
2) These ports can be very hard. Heavy Gear II, for example, required alterations to:
- gcc (local static objects in DLL register destructors with atexit, various other issues)
- glibc (new version of atexit to handle fixes above)
- Mesa (FX driver initiates atexit handlers even if manually dlopen())
- Glide (never unmapped PCI address space until process exit)
- gdb (didn't properly reload symbols after dlclose()/dlopen(), making debugging very difficult)
Finding these problems in the toolchain and then solving them have been very challenging. Hopefully the changes we made can be leveraged in future titles that will get to market faster. Also, all of the above fixes were folded back into the master tree. I'd like to thank the various people involved in those fixes: Mark Mitchell of CodeSourcery, Joseph Kain of 3DFX, Brian Paul of Mesa, and our own Sam Lantinga for the gdb fixes, which were given to HJ Lu.
Regards,
m.
Programmer, Loki Software
Every day I work with the code of developers who think that classes/interfaces are the way to go for APIs. The stuff is *horrid*. When I'm done converting a piece of Direct3D code to OpenGL, it is far and away obvious which piece of code is
a) easier for me to write
b) easier for me to maintain
c) easeir for my peers to read and understand, and thus maintain
OpenGL is a beauty of an API for several reasons, from a stricly syntactic point of view because it is data-type neutral. When I need to port Direct3D code to OpenGL, I can almost always make the data structures work the way I need them, despite the best efforts of the minds at Microsoft to introduce D3DTLVERTEX and the FVF flags (ye gods).
m.
The part about "orientation" isn't true at all. The first thing we did was appraise the current standardizations effort--basically look at the IASIG guidelines. The level 1 stuff is fairly straightforward: attenutation, panning, radiation cones, etc. No bones on that.
The level 2 stuff is the environmental reverb. This is approved by a whole host of companies, which you can see by visiting the IASIG website, including Aureal. You'll also note that this isn't currently a core part of the API--it's an extension (AL_ENVIRONMENT_IASIG, etc.), as we felt this might not be the Right Way to do environmental reverberations, etc., for the forseeable future.
Geometry specification is nice and clean from an API standpoint, but doesn't reflect what's really happenning on the card. When 3D sound boards are doing these geometry calculations in hardware, we can talk about the OpenAL 1.1 API or whatever.
There is also an issue of how to represent "materials". This is far from an easy task to decide.
OpenAL was a lot harder to specify than, say, OpenGL--they already had IrisGL, and they had a very straightforward silicon path--textured triangles.
m.
Actually, there is no CD API. We felt it had no place inside of a 3D spatialized audio API if we wanted to keep things clear and consistent.
Support for MP3, etc., is planned, as an optional parameter for specifying a Buffer waveform. There is an issue of canonicalization though (stereo sound doesn't make sense for noise in a three dimensional space... it's just a sound).
m.
We actually looked at a bunch of audio libraries:
DirectSound*
Apple GameSprockets
QSound
BeOS Media Kit
EAX
A3D
IASIG Specifications
etc. Insofar as EAX is a set of extensions to DirectSound, I guess that doesn't count so much.
m.
I don't really see how you could say that. While we worked on the Linux software mixer and wrote a chunk of the API, the NPO actually will administer the licensing, etc. We'll just have one chair on that committee.
:).
I mean, come on, it's LGPL
m.
Yes, there was a previous API, but it never really got past a header/specification. We took up the name and worked with some of the original people behind the first two iterations.
m.
I would assume that the networking aspect would live below the core API, or at the very least you would specify this sort of thing at the context level. I've actually talked to Jim Gettys about this stuff at Linuxworld, and the ESD people. We're looking into it...
m.