WingNews logo WingNews GitHub [2]

barrettcolin's comments

barrettcolin | 14 years ago | on: Adobe Introduces Premium Features for Gaming with Flash Player 11.2

I see this new note on the Adobe Alchemy labs page: "Domain memory (used by Alchemy) and Stage3D hardware acceleration – when used in combination – will be part of a premium tier of capabilities for gaming in Flash Player, enabling a new generation of immersive online games."

So it's "when used in combination" (with Stage3D from my read of it). Here's the page: http://labs.adobe.com/technologies/alchemy/

barrettcolin | 14 years ago | on: Build Doom3 on MacOSX with XCode4

The slightly longer and more correct answer is the source release contains the game engine source and the Doom 3 and RoE game DLL source. The Doom 3/RoE game data is still required.

barrettcolin | 14 years ago | on: Build Doom3 on MacOSX with XCode4

It includes the source code for the expansion pack game dll (in d3xp). You'll still need the original RoE assets (when I went to install them on Windows, the installer crapped out because I wasn't on Windows 2000 or XP, but you can just copy them from a directory on the CD- they're in a d3xp directory or something like that).

barrettcolin | 14 years ago | on: Doom 3 source released

I'm not sure where I picked up the info, and I haven't looked at the code to confirm it, but I believe the physics engine implementation is tied tightly to both the collision detection system and the entity update, both of which are quite specific to Doom (in particular, each entity steps physics independently, rather than a whole simulation advancing at once as is common in 'pluggable' physics engines like ODE, Havok etc).

Also, and this is subjective I suppose, I don't remember Doom 3 doing anything that 'felt' or looked better than even what the contemporaneous engines did (such as the version of Havok used in Half-Life 2).

So I guess, there probably aren't valuable additions, but I imagine there is much to tinker with.

barrettcolin | 14 years ago | on: An iOS Developer Takes on Android

My understanding is, "drawing" (in-view composition) is largely, if not completely, software (Quartz2D). Composition between views is (can be, at least) handled by the GPU; and that may well include animation of views. I don't know how absolutely accurate it is to say that such composition 'uses OpenGL'. It may use hardware that provides OpenGL functionality, but that isn't quite the same thing (Quartz composition could talk directly to the GPU using it's native command format for instance).

barrettcolin | 14 years ago | on: The Tale of OpenGL vs. Direct3D

As a complement, Chris Hecker has kept some of his notes regarding OpenGL vs. Direct3D around:

http://chrishecker.com/OpenGL

It seemed quite important at the time that he- who begat WinG, which begat DirectX, some of which is covered in Renegades of the Empire, which someone else mentioned, which is certainly worth reading- went on to agitate for OpenGL over Direct3D. Now there's kind of a scrapheap of history vibe off of the whole thing.

barrettcolin | 15 years ago | on: Why floats suck - accurate galaxy-wide coordinates in 128 bits

I've had fairly heated arguments about this in the past and I'm curious to know if anyone else holds the same opinion: I contend that a normalize function is a really bad place to put an assert. Chances are the normalize will be called frequently and the assert check, in debug mode, will have an impact on performance (this goes for assert checks inside other frequently called functions too). The cumulative effect is a debug build that becomes unusably slow relative to the optimized build without the asserts, which rather defeats the purpose of having it in the first place: if you can't use it to find problems, then what's the point? (I'm remembering this being the case more often than not when working on games for the Xbox 360 or PS3).
page 1
more