Quoted:


How's your math?

Quoted:


Quake is open source now.



I suggest you take a look at how Carmack built that.



There's also a slew of books on the topic.



Start with your basic D3D / OpenGL renderer first, then your worldspace structure (BSP, subtractive solid geometry, importer mesh, etc), and only add the gameplay stuff after you have visuals and a world running like clockwork.



You're kind of diving into the deep end to start with.  Do you have any 3D or interactive programming experience already?

Quoted:


I do have interactive programming experience but have never worked with 3D. At least not yet!

Do you have any idea where to get the source files for Quake?
 

Quoted:


Let me preface this by stating that I am a full-time Software Engineer, specializing in soft-realtime simulation with an emphasis on graphics.



Writing an engine by yourself will take many years of work. Hell, the best engines still take a couple of years with a team of programmers.



I have been working on a D3D-based realtime (soft) engine for the past several years. Most of it is being scrapped in a major refactor I am undertaking to provide a far greater degree of flexability, modularity, and forward-support.

Quoted:


So you're saying that you'd be surprised if I could learn this from scratch, reinvent the wheel, and get the project finished by the end of the month?

Seriously though, I am not expecting to get this completed quickly nor am I working on it alone. I have a piece of custom hardware that I am working on completing. It will need its own software programmed. That software will need to behave VERY similarly to that of a 3D interactive computer game.
 

Quoted:
Seriously though, I am not expecting to get this completed quickly nor am I working on it alone. I have a piece of custom hardware that I am working on completing. It will need its own software programmed. That software will need to behave VERY similarly to that of a 3D interactive computer game.
 

Quoted:



It'd be FAR easier for you to grab something like Quake and create either a wrapper or firmware that uses the quake engine to do what you need.  Unless there's a very specific reason to do so, writing your own D3D engine just for that piece of hardware would truly be reinventing the wheel.

Quoted:



Oh shit. Are we talking embedded software here? That's even more complicated.



If this is completely new proprietary hardware, you won't be able to use an off-the-shelf renderer, but will have to write a completely new one from absolute scratch. Which will add even further complications.

Quoted:
It'd be FAR easier for you to grab something like Quake and create either a wrapper or firmware that uses the quake engine to do what you need.  Unless there's a very specific reason to do so, writing your own D3D engine just for that piece of hardware would truly be reinventing the wheel.

Quoted:



Except that, depending on the hardware, that might be even more work, or produce unacceptable results. Consider porting 32-bit code down to a 16-bit architecture or similar. This would entail not only writing new drivers for a common rendering API, but also creating an entirely new implementation of that API for access by the actual engine (which itself would also have to be converted to properly run on the new architecture).



Depending on the specific requirements, this may actually take longer than just writing a renderer for the new hardware (i.e., if you don't need 50% of the functionality of some current renderer, why bother coding up all of the necessary support - even if they are stub no-op functions - if you don't have to?)



ETA - So, OP, what are we talking here? Is it at least running on a common hardware base? (e.g., an x86, x86-64, x64 or even IA64 core? ATI/AMD or nVidia GPU-derivative? etc...)

Quoted:


The computer itself will be running XP Pro 64 bit edition.

It will also be running 4 video cards (dual output).



They run a series eight displays. The trick is that the "game" will need to render and output to each display. The monitors will be arranged in a circle around the operator. The environment needs to be viewable continuously in all 360 degrees. I am not sure if there is currently a solution available to make this possible, thus the willingness to begin on my own. Of course if you know of one... all the better!

Quoted:
The computer itself will be running XP Pro 64 bit edition.
It will also be running 4 video cards (dual output).

They run a series eight displays. The trick is that the "game" will need to render and output to each display. The monitors will be arranged in a circle around the operator. The environment needs to be viewable continuously in all 360 degrees. I am not sure if there is currently a solution available to make this possible, thus the willingness to begin on my own. Of course if you know of one... all the better!

Quoted:
I saw a helicopter simulator at IGUG in 2001 that was very similar to this.  Had some pretty serious hardware behind it for the time, and the graphics weren't anywhere near the state of the art.

Quoted:


Let me preface this by stating that I am a full-time Software Engineer, specializing in soft-realtime simulation with an emphasis on graphics.

Quoted:

OT: You sound like a really smart guy. Why did you pick such a ghey user name?

 

Quoted:
OT: You sound like a really smart guy. Why did you pick such a ghey user name?





 

Quoted:







How exactly are the winged warrior maidens of norse mythology - those who carry the slain to valhalla - "ghey"?

Quoted:


The lack of diaeresis threw me off. I guess it's not that ghey after all.
 

Quoted:



Uh, yeah. That's nothing super-special in the sim industry (though going a full-360 is not typical... normally, it will be >180 and <360 in horizontal swath around the simulator). Partial and full domes have been around for a long time.



When you said you had "custom hardware" that needed software written specifically for it, I assumed that you meant this was new hardware that required embedded software (e.g., a video game console, portable device, etc). Just running a bunch of displays isn't hard.



Repurposing an existing engine for multi-display usage would be almost trivial. Well-written modern engines already have this support.

Quoted:



Graphics in *real* sims (not this so-called "sim" bullshit that's really just a game) are rarely, if ever, anywhere near the cutting edge. The reason is that the bulk of the hardware is tied up doing the necessary simulation components. In addition to the many, many rack mounts being utilized for simulation, the visual systems do typically have several boxes as well. However, due to the emphasis on performance and simulation over graphical prowess, producing high-end graphics is one of the lowest priorities. Additionally, the big players farm out most of the core graphics work, as it is considered to be prohibitively expensive to have it developed in-house (due to the higher-on-average wages of engineers working for these firms compared to those received by the coding monkeys working at the places they farm out the work to) - though I keep telling them how much better (in both graphical performance and $$) it would be in the very-long run for us to do it ourselves.




Running 8 displays off of a single box will indeed be taxing. I hope that there is at least a quad-core CPU in there to help delegating the work between the four GPU cards - and it would likely be best to utilize dual-GPU cards if at all possible, if you are really powering high-resolution displays (1900+). Also, if this is a canned scene (i.e., portions are prerendered or at least heavily optimized), then you won't need to worry as much.