This member has provided no bio about themself...
I've been working with OpenGL in one way or another since 2002. First working on our mod Quake II Evolved, then working on OverDose. I had absolutely no experience in graphics programming back then, or C programming for that matter (I came from Visual Basic, with about 2 years experience).
Where? At home. Google IS your friend, believe me :p
But seriously, you can learn A LOT by just looking at id's engines. Even the older ones.
I'm not much into console hardware, so this may be complete bollocks, but I'm not sure the PS3 hardware would support OverDose "as is". Same goes for the Xbox 360.
I'm affraid the dynamic lighting and shadowing would be too much for current generation consoles. But a toned down version of the game could run acceptably on them.
Well, we're still aiming at a late 2012 playable beta, even though it seems we won't be able to make it in time. We're still a very small team.
And no, we're not dead :-p
Hmmm, you'll have to ask Gavin about that one... lol???
Maybe he just copy-pasted from an old description page or something. We originally thought about getting a license, but we decided to go open source later.
The whole engine, game, and SDK tools source code will be open source and free, if you abide by the GPL license (http://www.gnu.org/licenses/gpl-2.0.html).
The game content won't.
That would be a cool idea... in a perfect world :p
But how is the code supposed to determine when a lower framerate is due to having more decals on screen, and not because of other factors?
Sure, you could write some pretty smart code in there to check for different situations, but framerate is affected by so many things (including outside factors such as hardware and system settings) that, no matter how clever you and your code are, you can never tell what's actually causing a framerate drop.
Speaking of decals specifically, you can't control how long they live. That's up to the designers and it varies for each decal type. However, I may end up adding a cvar that scales their lifetime so that users can get them to last longer (or fade out earlier). As for being able to disable them completely, yes, but only the dynamic ones (bullet impact marks, blood splats, etc), not the static ones which were put in the map by the level designer... these are no big deal apart from some extra overdraw.
I'm not much into laptop hardware so I can't really tell. But if you're serious about gaming, you shouldn't rely on a laptop IMHO.
Yeah a 8600 is a little low end, but should be able to run the game at a playable framerate if you disable the most expensive effects.
There is no multi-threading at all ATM, but it's something I want to add someday for a couple things. However, OpenGL drivers can make use of multiple cores, and OpenAL does all the mixing and stuff in its own thread too AFAIK.
OverDose can be very demanding, but if you can live with turning off some effects, or toning them down a bit, it should be playable on hardware that's considered "mediocre" these days.
Still lots of room for optimizations in the renderer, including use of SIMD in some places.
It will require a modern system to run properly anyway, but you can disable or lower the detail for a lot of features if needed.
Yes, anything that we find useful and doesn't require rewriting huge amounts of code will be added.
I already took some bits from it.
OverDose will be open source and 100% moddable.
What I'm saying is... erm... well I haven't played Crysis 2 so I don't know what you mean. I didn't like the first so I didn't bother with the second.
Yeah I see your point. But what game is 100% realistic anyway? :-P
As long as the effects are not overdone and very exaggerated and everywhere, that's fine for me.
They DO happen in real life, but it's not something I care about a lot TBH. I still want to support the feature and let the level designers decide if they want to use it or not. Since it's still a quite expensive feature, users can of course disable it for better performance anyway.
Unfortunately we will likely end up doing a post-process for directional lights (like the sun light), because they're huge and this ray traced approach would be stupidly slow there.
I hate it when it disappears because the light source is no longer on the screen, but I guess we'll have to live with it :-(
Depends on number of samples taken (which vary for each surface material AND viewing angle too). Generally speaking, yes, it's expensive, but it's not that big a deal. In any case, it can be disabled (it is by default).
No. We don't consider it to be worth the effort.
That's not true. You can sell it anyway, you just need to release the source code.
EDIT: this was a reply to Buzzard0... somehow, it put it up here
Actually, it won't work in the Xbox without dumbing some things down to DX9 level... That, and the fact the renderer would need to be ported to Direct3D.
No idea about the PS3, I haven't checked.
Yeah, it is possible (but not recommended!) to ignore the VIS stage completely and still get reasonable performance if you make a wise use of portals in your maps. It'll consume more network bandwidth since the server will need to transmit more stuff each frame though.
The VIS stage can take a few minutes to compile (even with multi-threading), but it's no big deal really.
The BSP stage is usually the fastest, but can take a couple of minutes for very large maps (specially if you put several foliage layers over large terrain).
The LIGHT stage, which used to be the slowest (up to a couple hours I heard), is entirely gone. All lighting is computed in real time by the engine.
The SDK is already publicly available at: Odblur.svn.sourceforge.net
The level editor (ODRadiant) isn't done yet, but mappers can use GtkRadiant or derivatives meanwhile.
Not really, they use the same resolution.
Point lights are actually slower than directional (sun) lights in most cases since they require up to 6 shadow maps.
The display will show actual game information, but ATM it is just a placeholder.
No, I never worked on anything outside Quake 2 Evolved and OverDose.
I haven't checked qfusion in ages, but I don't remember it using any Q2E code really.
LOL, yeah.... it will work on everything from XP.
Well yeah, that's a by-product of the rim lighting. Unfortunately, I don't know any cheap way to "fix" it.
Yes, free and open source. Why? Are you willing to pay for it? :D
And to answer your second question: "When it's done" :p