Slashdot Mirror


E3 Doom III Preview

Warped-Reality writes "GameSpy has a new Doom III Preview covering aspects of the storyline and how Doom III will be different from the rest of the FPS genre. It includes some pictures of the E3 Doom III demo booth. As the article says, "This is DOOM III, and it's going to scare you to hell."" Looking at these images, I can only say two things: Wow and Cool Toilets. Update: 05/22 19:55 GMT by M : There's also an interview with Carmack giving a few more details about the game.

2 of 401 comments (clear)

  1. Nice, but... by JavaJones · · Score: 5, Interesting

    While there's no denying this looks stunning, particularly the environments, I can't help but notice the characters are all pretty low poly. They're hardly better than Quake 3 level it seems. At first, sure, they look pre-rendered almost, but you can see poly edges around the sihlouettes first, and then on closer inspection you can start to see sharp angles elsewhere within the models.

    Carmack's trick of using high poly models for lighting and shading calculations and then projecting that onto lower poly models may make for some amazing visuals, great damage effects, and much better facial animation, but IMO the low poly in game models need to have maybe 2x the detail just to make a good base for the higher poly lighting/shading calculations. That or hope that all the next gen cards have N-patch support or some other form of HOS support *and* that it can be used with Doom 3. Otherwise it looks like it's going to be an incredible engine that will be let down a bit by low poly characters. No doubt the in game assets and performance are still being tweaked of course.

    - JavaJones

  2. Okay, if I had a chance to interview Carmack by Sludge · · Score: 5, Interesting
    Here is what I'd ask. (Yes, I know he will probably read this, and yes, this is pre-meditated in the chance of an opportunity arising.)

    You've expressed your opinions on using Java as the language to replace DLLs in the past. Two of the reasons you gave for not using Java were the bleeding edge nature of the APIs which added more chaos to the already chaotic Quake stew than you were willing to give, and the speed of execution. Although it isn't as efficient as straight C code, what are your impressions with Perl since you learnt it a while back? Would you consider writing the client and server game logic modules in a multiplayer oriented game in a different language from each other?

    Early during the development of Quake 2, Brian Hook said in an interview once saying that you said that you would most likely be a leader in the real time gaming graphics field until around 2004. If this is an accurate recollection of something you said at that time, what did you foresee happening that might raise the question of your respectable dominance in the realtime gaming graphics field?

    Doom is going to be using hardcoded DLLs again, since the move to C++ negated your ability to use LCC retargeted to bytecode. This has, most likely caused you to see the significance of standardizing the bytecode instead of the language. Are there any plans in the future for retargeting compilers of other languages for the purpose of security and cross platformism wins with using virtual machines? If so, will they use the same bytecode as Quake 3 did?

    You have expressed enthusiasm many times for the NeXT STeP environment and how you might still be developing under it if there was support for target hardware. Have you looked at the functionality of GNUStep, which is a project attempting to close the functionality of NeXTSTeP?

    In every Id product, the bugs that have crept up are rarely related to the renderer and therefore rarely likely to be code you wrote. Do you feel that you produce few uncaught or unreproducible bugs in general compared to most developers, or is it because the renderer is so throughly tested in the development of idgames due to it's fundamental placement in the games architectures?