This member has provided no bio about themself...
What? I'm not having trouble with anything, but I'm in the design stage for the FX system.
Yeah, but who cares? It's really not important. I don't even know why Gavin made a video of this, but it's ok.
Of course if somebody wants to step in and code a proper physics simulation for us, it would be more than welcome. Though I would prefer help in other areas of the code :)
This is just a basic physics system, and it won't get much better actually. It's supposed to be FAST, only for being able to push things such as barrels, boxes, and a few other random things. RtCW level physics really, with a few enhancements. Nothing fancy or worth a tech demo.
It was never my intention to recreate a complete and accurate simulation of rigid bodies. The idea is to keep everything as light as possible on both the server and the client systems. And to make my life easier too.
Perhaps later on, if we have enough time to spare, I may consider implementing a more accurate physics system (which needs an almost new collision system too, BTW), with all the bells and whistles that everyone seems to expect. But it's definately not a priority for us. It's not really needed for this kind of game. Gameplay in OverDose doesn't revolve around physics objects, and it's too much work to get it done right if we wanted to. And third-party physics libraries aren't just a plug-and-play thing either.
Well, when I started with this we only had CVAs (compiled vertex arrays), but yeah... people should avoid obsolete tutorials.
It was started on the id Tech 2 engine, yes. Is it still the same? Certainly not, as you can see in screenshots, heh...
A few bits of the original code still remain though. But I'm sure a few bits still remain in id Tech 5 too.
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.