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/
That reminds me: I noticed that humblebundle.com is apparently involved in the purchase transactions for the recently released 'English Country Tune'. So maybe there's more afoot than just the bundles themselves:
For the sake of completeness, here is where I read that: http://www.ode.org/old_list_archives/2004-December/014735.ht...
From looking at the game code, I see odd things like rolling barrels animating their rotation as though the physics engine itself doesn't handle rolling contact.
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.
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).
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.
You don't. It's only implemented for Win32 (see neo/tools/edit_stub.cpp).
Surprising? I wouldn't say that; C# is used in lots of non-Microsoft places these days: http://www.fastchicken.co.nz/2011/09/15/c-its-just-not-porta...
Unexpected, but not without precedent. XNA on Xbox/Windows Phone 7/Windows, Unity3D across its range of supported platforms; it'll be interesting to see with Sony come up with.
You can get a pretty good idea from looking at the mod sdk code, which is available from here: http://iddevnet.com/doom3/
There's quite a lot available in the game code; the physics system at least, maybe also the script interpreter? I haven't looked in a while.
He may be referring to Scaleform (or another Flash GUI library; I don't think he specifies), but he's also talking about his experience with scripting in Doom 3- which I'm fairly sure didn't use Flash.
RAD game tools, purveyors of lots of 'middleware' for games, have developed their own Flash playback engine called Iggy. I don't know how it rates, but its an option: http://www.radgametools.com/iggy.htm
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).
This isn't new news if you've been following this business since the start: http://news.ycombinator.com/item?id=2552563
As a complement, Chris Hecker has kept some of his notes regarding OpenGL vs. Direct3D around:
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.
Reportedly, it isn't restricted to just in-app purchase: http://twitter.com/#!/jamesthomson/status/70095343605391360
I'm not an IP lawyer, but according to this other post the patent at issue was filed in August 1992: http://www.lodsys.com/1/post/2011/05/q-opinion-in-several-bl...
Won't that expire in August 2012?
It was recollection on my part; not backed by empirical evidence. For this exact case, though: wouldn't you better handle this with floating point exceptions?
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).
Digital Foundry has a series of interesting articles about measuring input lag in console games; I think this is the first: http://www.eurogamer.net/articles/digitalfoundry-lag-factor-...
Another excellent resource is the archive of Erin Catto's GDC presentations (Erin is the author of Box2D). Box2D was first presented in 2006; the 2005 presentation is about an iterative method for constraint solving in 3D.
Zips are here: http://code.google.com/p/box2d/downloads/list
Spot on, I think; I would add that as well as being a subject matter expert, you will also need to be intimately familiar with the hardware architectures of the Xbox 360 and PS3, since 'optimized' solutions for these platforms will need to be one of your selling points.
To my knowledge, this is actually the second such fund being made available since late last year. I guess the first one was oversubscribed, which (I hope at least) augurs well. If you're in Ireland and you didn't hear about the first round or this round, they were certainly advertised in the Sunday Business Post newspaper (and I assume others), as well as online. Announcements appear to generally be posted here http://bestconnected.enterprise-ireland.com/
I have no association aside from being an interested observer, FWIW.
Also, Java as a language is - unless I've missed something in my experience of it - a very bad fit for interacting with the OpenGL API. In particular specifying data in tightly packed or otherwise specifically arranged (interleaved, in particular) forms is next to impossible to achieve without making your code look like a dogs dinner (if you can do it at all). Much easier to do in C, so that's another reason to go native on Android.
You might also find this useful: http://jet.ro/2007/08/13/immediate-mode-graphical-user-inter...
I'd read up on the concepts behind Immediate Mode GUIs; here's a handy tutorial: http://sol.gfxile.net/imgui/
You trade some flexibility and input latency for a simple imperative structure that is easy to implement.
"Stupendously inefficient" is a bit of a stretch for me in regards to Unity; I think it has a fairly well thought out - if admittedly rudimentary - GUI system (in its second iteration, upon which the editor application interface is also built). "Efficiency" is typically not the foremost concern for the interface in a 3d game, anyway; though in that regard I also don't consider Unity to be a slouch.
Broadly speaking, simpler is better on modern CPUs and GPUs. Testing an array of spheres against a view frustum is cache friendly, can be sped up considerably using SIMD instructions and is easily parallelizable. Submitting superfluous data to a GPU is not generally impactful; GPUs are clever at not drawing stuff that doesn't actually contribute (with clipping and depth buffer rejection) and extremely fast in their own right.
"I'm a little embarrassed to admit that until seeing the first photo just a few minutes ago, it never really occurred to me that they would have had to film the opening crawl that way."
I recently discovered (from browsing around the bonus material on the DVD on a lazy Sunday, naturally) that the multi-layer CG starfield effects created by ILM for Star Trek III were put on film by pointing a camera at a computer monitor and recording the output.
Whether it was a mistake is rather a matter of perspective: I'm sure the Microsoft folks didn't think it was wrong. But that aside: I realize that it may not have read that way, but I think what Mono does is an elegant solution to an unfortunate problem so I'm not knocking the approach. For something so fundamental (and obtuse), I just found that it was skirted a little too broadly in the docs that I read (I also searched around mailing lists for a while, where this particular topic seems to have been an intermittent source of confusion over the years).
Nonetheless, thank you for taking the time to address my observation.