This member has provided no bio about themself...
Yeah, thing is Gavin moved recently and he's still working on his new house. I could post some screenshots, but programmer screenshots suck, so... forget it, lol.
I use VS 2010, but newer versions should work if you convert the project files I suppose.
You need the Windows SDK and DirectX SDK (June 2010). The rest should be included already.
There is no weapon code in the public build yet.
You need to set "sv_pure 0" at the console every time. Then load a map with the "devMap" command.
You can add this to an autoexec.cfg file in the "base" folder so that you don't need to type it every time you run the game:
set sv_pure "0"
If you download all our files from the SVN repository, there are binaries included (tho they are debug builds, ie: a lot slower on the CPU). If you have Visual Studio you can try compiling a release build yourself with full code optimizations.
Well, both DarkRadiant and GtkRadiant should work, as well as the integrated level editor from DooM 3 (or Quake 4 for that matter). We use the same map format, however a few things are different when it comes to materials/textures. It may be a bit annoying at first, but it's not that big a deal really, and it works while we develop our own level editor. Unfortunately I'm not a mapper myself, so I don't know the exact details. I'll ask Gavin about it, maybe he can write a small doc explaining how to set things up.
1) If you use a SVN client (such as TortoiseSVN) you can use the "SVN Update" option and it will just download the new/modified files to keep your copy in sync with ours. The final game WILL have an updater that'll automatically download patches once available.
2) No bots are planned at the moment. Good AI takes a lot of time and we rather concentrate our efforts in a well balanced "humans vs humans" gameplay. It's not a feature we will never consider though, just not a priority.
Yeah, ODRadiant is being developed from scratch by Buzzard. It doesn't do anything useful ATM.
The main menu doesn't do anything ATM.
You need to set sv_pure 0 in the console before loading maps (otherwise the code only tries to load files from pk3 packs).
Thanks for the compliments. And yes, we're always looking for help.
No, you still need a modern computer, even to get a stable 30 FPS.
If it's really (and properly) supported on other GPUs, and it's not too much time and effort to port the current OpenGL code, I might consider it.
Nah, never was. It's just at times we keep quiet for a while.
I don't know. I'll probably wait til the animation system is finished, not sure.
NVIDIA has its share of bugs too, but yeah, based on my own experience ATI/AMD OpenGL drivers are buggier, but not as bad as they used to be years ago.
That card is not yet widely available over here and I couldn't find any decent brand either. The price difference is insignificant between a first-class-brand 680 and a second-class-brand 770, so I went for the 680.
It also requires a bit more juice and I didn't want a new PSU.
ATM I'm working on the FX system and other misc stuff. But yeah, the FX system would be the most important feature in the upcoming internal build.
Just a little update:
Gavin is still waiting for his internet at his new home (it's been like two months now, which is beyond stupid), so that's why there hasn't been any updates in ages.
I'm not much of a community guy, so don't expect me to post news or release some media (programmers don't take good screenshots, lol), but we're still working hard on this project, so it's definately NOT dead.
Hopefully Gavin will get his net sorted soon and post a ton of new stuff. As for me posting any of my own work, well, you can always grab the full source code from our repository at www.sourceforge.net (but do note I hate releasing dirty code, so I don't update it every day or every week).
Eight-core AMD FX, 8 GB, GeForce GTX 680.
You can of course run OD on a lower-end system, but I can't give a proper estimate of minimum and recommended specs ATM, as there is room for a lot of optimizations yet, but you'll certainly need a decent system because the dynamic lighting does take its toll.
EDIT: And yes, I run at maximum possible quality settings at a solid 60 FPS.
Yeah and my HDD died, so I'm unable to code ATM too.
Got me a new rig anyway (video card coming at the end of May, but I'm using the old one), so I'll pick up the coding again once I'm done installing all the stuff.
Absolutely not, like Gavavva said. We'll reconsider putting up a new site in the future, once the game reaches public beta state, but for now we can do with moddb and sourceforge just fine.
Hmm, perhaps. We took the site down anyway, but it will still "work" until April 27th. Dunno why it says it's filled with malicious software though.
Virtually any kind of input device should work (gamepads, joysticks, even wheels...) through DirectInput. How they work may depend on each specific device driver though, and that's out of our scope.
We also have special input code for the 360 pad (through XInput, the same API used in the consoles).
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.