45 New Screen Shots of Half-Life 2!


Recommended Posts

I disagree here. I wouldn't say HL2's graphics are any worse then Doom 3's, just different. In fact I think HL2 looks more realistic and natural; the characters look better too imo.

Makes me want even more for the modding community for Doom 3 to really kick into gear, but I guess they still need the SDK for that. It would show a lot of people that the engine basis for both Doom 3 and Half Life 2 is the Quake Engine. I know Valve say that Source is written from Scratch, but it is at least "inspired" from their earlier modification of the Quake engine.

Doom 3 is capable of brightly lit areas and is not confined to claustrophobic corridors, it is just how iD implemented this engine for their game of the same name.

Graphically, Half Life 2 may prove a better game than Doom 3. But as it stands it is near impossible to compare the game engines. Hopefully some Doom 3 mods will assist comparisons.

(idea for mod makers: Port a Half Life map into Doom 3. Then we will be able to near perfectly compare the games)

It's not that I'm saying HL2 will be bad. Hell no. It may well be better than Doom 3 (I am quite sure about that), it's just the constant slagging of doom 3 by HL2 fanbois (who, haven even played the finished game yet) which is ****ing me off. For example see below:

Lol! So you're allowed to make all these judgements without even TESTING HL2? Come on...

Nice screenies. Thanks.

It is obvious through both legal and questionable sources that parts of Quake Tech are still inside the Source engine.

Legal: Console commands remain near identical....too identical. Plus the general "feel" of the engine (as played in Counter Strike: Source Beta) feels like a Quake engine. I know the last one isn't too technical, but it's hard to explain so I just ask that you trust me.

Questionable: A quick peruse of :ninja: code reveals a heck of a lot of Quake tech still in the engine at that stage. I would be willing to believe that they were using old parts of the engine just as placeholders, but analysis of CS: Source Beta reveals that the main executable for the game is not only the exact same filesize as the stolen build, but even shares the same created/modified date. This indicates that any modifications to Source since E3 2003 were not to the main executable itself (where the Quake tech still is).

It may only share some basic mapping concepts and DirectInput calls, but the common components are obvious. This isn't a bad thing, as there is no point in re-inventing the wheel. Their customisations to the Quake engine they used in Half Life 1 were still graphically viable for use in a modern game engine. Heck, even when programming god John Carmack started Doom 3 they took Quake 3, removed all the graphics components, and started from there. Any other modifications they made as they went.

I mean, Valve have done a great job in creating Source (or rather, it appears they have...won't know till we all play the game) but it still shares common roots with Doom 3. It could be said that they were close cousins.

Edited by Chode

I'm sure there's some clause in the licensing of game engines. Something about if more than 50% of the code is modified/custom code then it can be called a unique engine. I'm positive this is the story with the game engine used by Ion Storm for Deus Ex 2/Thief 3. Originally built on Unreal Tech, but modified to such a degree that it is considered it's own unique game engine.

In fact, I'm positive that enough of the Quake engine was modified for Half Life 1 that it was never referred to as the Quake Engine but the Half Life engine.

Or I'm talking crap....either way is good. :)

I'm sure Valve did base at least some of Source off of the Quake engine, but 90% or more of it has been written from scratch. The engine doesn't feel at all similar to Doom 3 imo.

Oh agreed. Doom 3 doesn't even feel like Quake 3, a lot has changed. Though I suspect that Half Life 2 may ultimately feel a lot like Half Life 1 (though a lot better, of course)

Allow me to attach a speculative diagram:

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Microsoft's fast coding model MAI-Code-1-Flash comes to Copilot Business and Enterprise by Karthik Mudaliar Microsoft’s recently announced MAI-Code-1-Flash model is now generally available to GitHub Copilot Business and Copilot Enterprise customers. With this support, organizations can have more centralized policy controls and billing while finally being able to use Microsoft’s lightweight, first-party coding model. According to GitHub’s announcement, Business and Enterprise plan administrators must enable the MAI-Code-1-Flash policy in Copilot settings before developers can access the model. Microsoft says that MAI-Code-1-Flash is for fast, iterative coding work rather than the most demanding architectural or debugging tasks. GitHub’s official model comparison page says that the model is great for "general-purpose coding and writing," while it excels at fast, accurate code completions and explanations Microsoft introduced MAI-Code-1-Flash on June 2 as part of a broader collection of internally developed MAI models. GitHub subsequently expanded support to Copilot CLI, the Copilot cloud agent, GitHub.com chat, GitHub Mobile, Visual Studio, JetBrains IDEs, Eclipse, and Xcode, but said support for managed Business and Enterprise customers was still on the way. In Microsoft’s own benchmark testing, MAI-Code-1-Flash scored 51.2% on SWE-Bench Pro, compared with 35.2% for Anthropic’s Claude Haiku 4.5. Microsoft also claimed that the model used up to 60% fewer tokens on SWE-Bench Verified. Do note that these are vendor-run results rather than independent measurements. The model is billed at provider list pricing under GitHub’s usage-based system. GitHub currently lists MAI-Code-1-Flash at $0.75 per million input tokens, $0.075 per million cached input tokens, and $4.50 per million output tokens. For organizations, the main incentive to use MAI-Code-1-Flash is likely to be efficiency rather than maximum capability. A smaller model that responds quickly and limits unnecessary output is quite useful for repetitive agent tasks at scale, especially after GitHub Copilot’s move toward usage-based billing. The "Flash" model is recommended for fast work and not necessarily for huge repositories with loads of context. It's better if teams compare their output with other larger models, especially if they're working on security-sensitive changes and complex, multi-file work.
    • yes AND no the "original" or plain/normal Optiplex 7010 won't be getting any more new firmware updates BUT the Optiplex SFF/SFF Plus {small form factor}, Micro/Micro Plus & Tower/Tower Plus 7010 editions DO get new updates such as this new one   and here are similar guides from the Dell web site for Dell systems: https://www.dell.com/support/kbdoc/en-us/000390990/secure-boot-transition-faq https://www.dell.com/support/kbdoc/en-us/000347876/microsoft-2011-secure-boot-certificate-expiration
    • AT&T has been spying on US citizens with the NSA for decades.. they just know how to keep it more under wraps.. the evil level is still there.
  • Recent Achievements

    • One Year In
      bernmeister earned a badge
      One Year In
    • Week One Done
      Scoobystu earned a badge
      Week One Done
    • Week One Done
      tuben earned a badge
      Week One Done
    • First Post
      OffsetAbs earned a badge
      First Post
    • Reacting Well
      OffsetAbs earned a badge
      Reacting Well
  • Popular Contributors

    1. 1
      +primortal
      462
    2. 2
      +Edouard
      212
    3. 3
      PsYcHoKiLLa
      158
    4. 4
      Steven P.
      71
    5. 5
      FloatingFatMan
      71
  • Tell a friend

    Love Neowin? Tell a friend!