Phosphor Alpha Tech Demo 09x

While TS certainly doesn't appear to have the foresight that JC has in terms of where technology is going (or at least didn't around the Unreal timeframe...), he did manage to produce the absolute best software rendering engine ever to make it to real-time rendering on the PC.

Quake, Quake 2 and Tribes all had software renderes. What advantage did Unreal have over these?

An Unreal-engine level has always had the ability to link to another level on an arbitrary domain (i.e., not just the server you are playing on). If the content of that level is not cached on the client, it is automatically downloaded from the Unreal server on that domain. Very neat, especially for 1998.

Well when I connected to QW TF servers back in the day it downloaded maps on the fly so long as the server admin had it enabled - nothing new there.

I don't think the in game server linking was possible, however.

In any case, it's neat to have a bunch of people bouncing from server to server, but it's not so neat when you want to have a whole bunch of people fighting in one area. I'm waiting on Planetside for that one. It's unfortunate nobody came up with a mod for it.
 
Unreal's software renderer does support procedural textures, mirror surfaces, flares and some other bits and bobs. Ah yeah, and texture dithering as well to make it a little less blocky, but in reality that only made things look WEIRD in my opinion.

Not that I'd go as far as say it's the most advanced PC software renderer bar none, but it's without a doubt one of the most advanced in a shipping game. The only competitor I can think of that even comes close is the voxel engine used in Outcast, and that probably has Unreal beaten on most counts (it has true bilinear filter on world textures, antialiasing, depth-of-field effects, water reflections, tons of neato stuff really)...

Of course, that Unreal's software engine looks good matters little when other renderers running on hardware totally kicks the shit out of it, both from a speed AND visual standpoint, LOL!

*G*
 
Grall said:
Of course, that Unreal's software engine looks good matters little when other renderers running on hardware totally kicks the shit out of it, both from a speed AND visual standpoint, LOL!

*G*

Well, what I found impressive was that despite the focus on software rendering, and the earlier overall engine release date, UT's graphics managed to line up very well with other games released at about the same time (ex. Quake3). After all, the engine used in UT had some exceedingly-severe limitations, such as the fact that it could only handle 200-300 world polygons. And yet it still looked comparitive...I find that rather impressive.

I just wish it hadn't taken TS so long to rewrite the rendering engine around hardware rendering...
 
nah

nah, the engine was written for hardware rendering from the start. oh but i guess you had a pos nVidia card back then :p jk. but really now, Unreal on a Voodoo is just awesome... esp. Voodoo5 with AA, 32-bit texture (32-bit internal rendering CAN be forced in Glide, but i think it still outputs 16-bit to the framebuffer. still greatly reduces rounding errors tho)... and as for Outcast... let me just say WOW. its unbelievable how good that game looks running software rendering on a mere Pentium II 400MHz!
 
Unreal was not written for hardware from the start. If you followed the development of Quake and Unreal before the Voodoo1 came out, you'll remember that Unreal's big claim to fame was an MMX optimized software renderer that could deal with transparency.

Also, JC chose a more limited scripting engine in comparison to UT not because JC can't write an object oriented parser or runtime, but that the limited runtime that JC chose was more network efficient. Unreal took a long time before it's network play was as efficient as QuakeWorld/Quake2/Quake3. UnrealScript's network replication technique is easier to understand for developers and coders, but much more complex to get correct.


Moreover, the idea of using an OO scripting language and being able to link servers together is way older than Unreal. That was being done on MUDs for ages before. I was playing MUDs on the internet in the 80s where I could move between servers. In fact, I could move *objects* between servers.
 
Re: nah

Sage said:
nah, the engine was written for hardware rendering from the start.

No hardware rendering was implemented in the engine until very late in the development of Unreal. Glide always worked well simply because it's a lower-level API. You see, Unreal's rendering algorithm just was hell on hardware rendering, but Glide's low-level nature allowed TS to circumvent the problems seen when running through other APIs.
 
I think TS and JC are generally on par. JC is a little overrated. He's good, but he's not a god.

TS and JC don't have the same vision and they don't try to implement their games in the same way. That doesn't mean "JC is right" and "TS is wrong", anymore than Nvidia's form of Aniso is "right" and ATi's is "wrong". They're just different.

Take Q3 vs UT. JC tried to make Q3 all cutting edge and everything. Meanwhile UT was just an evolution of Unreal. Technically UT was less advanced, but in the end the graphics were pretty much just as good as Q3. Sure it didn't have curved surfaces, but other than that...

Now we're in the same situation again with UT2003 and Doom3. JC is once again pushing the envelope by completely rewriting his engine, meanwhile TS is slowly moving his engine forward. Other developers seem to license both engines equally, so both certainly have their pros and cons (for example those who use UT always have access to the latest code, so they can stay current, meanwhile Q3 is not being worked on since JC is just starting over with Doom3). As I understand it the scripting system for UT is also designed to be easier for developers to work with.

So both TS and JC are good programmers. They both know what they're doing. I think the only reason JC is considered to be better is because he was around in the 3d scene first.
 
Moreover, the idea of using an OO scripting language and being able to link servers together is way older than Unreal. That was being done on MUDs for ages before. I was playing MUDs on the internet in the 80s where I could move between servers. In fact, I could move *objects* between servers.

MUDs are likely the only games that are more addictive than Civilization. In any case what code bases would allow this, I've never heard ROM, Diku, Merc code bases doing this?
 
IMHO, the Quake derived engines always had superior control and network play. No non-quake derived FPS I play with massive numbers of players feels as "smooth" as the Quake engines. Moreover, I doubt that the Unreal engine has as many licenses as the the various Quake engines. Add up the licenses of Q1/Q2/Q3 vs Unreal/UT, it doesn't compare.

Tim Sweeney is the better artist and toolmaker, putting nice touches on special effects within the engine and the scripting APIs to use them, and lots of content creation tools, but I believe JC is the better scientist/engineer. JC spends way more effort on the research and engineering implementation of better visibility and lighting algorithms, which, aren't as exciting or gimmicky as caustics/procedural textures/etc, but lay the foundation for a much more powerful engine.

While TS is messing around with making models with facial animation, adding flamethrowers, and fog effects, JC is revolutionizing the way FPSes deal with lighting algorithms. (I'm not saying Carmack invented the algorithms he is using) IMHO, Sweeney seems to make better icing to put on the cake, but Carmack bakes a better cake.

I'm frankly not impressed by UT2k3 or Unreal 2. It just looks like the same engine, but with much higher polycounts and special effects. An engine with a unified lighting model, full realtime shadows everywhere, and models created with hi-res normal maps simply looks way better and totally changes the atmosphere of the game. Lighting is the most important thing in 3D graphics, and UT2k3 simply doesn't improve the state of the art. Once you walk around in a game with full shadowing, walking around in Unreal2/UT2k3 will seem a flat experience.

Moreover, JC shows that his prowess doesn't just extend to graphics, but his problem solving skills are good in other areas as well, like network programming, which ID got right very early after JC took over the network code. JC even network gaming issues down to buffering problems in Cisco routers and modems, and his comments/findings were used to modify the routing algorithms used in some routers.

ID doesn't make good games, but when 3rd parties license the D3 engine, like Rogue, etc, the resulting games will probably look incredible. Epic seems to have better artwork out of the gate.


I don't want to lionize JC too much, but I think he is much more of an engineer than TS. TS has talent, but it's a different kind. JC is the kind of guy I imagine to invent something cool, implement it, but hand it over to others to make it pretty. TS on the other hand, I think is better at making lots of little tools and enhancements all over the whole engine.

I guess I would sum it up like this:

JC = Depth in one area (e.g. visibility, lighting)
TS = Breadth in many areas, modeling, animation, special effects, tools, etc
 
Saem said:
Moreover, the idea of using an OO scripting language and being able to link servers together is way older than Unreal. That was being done on MUDs for ages before. I was playing MUDs on the internet in the 80s where I could move between servers. In fact, I could move *objects* between servers.

MUDs are likely the only games that are more addictive than Civilization. In any case what code bases would allow this, I've never heard ROM, Diku, Merc code bases doing this?

Those are adventure MUDs. The social MUDs were the real innovators in terms of scripting: Ubermud, UnterMUD, CoolMUD, LambdaMOO, LPMUD (actually associated with adventure), and there are a few others.

UnterMUD and CoolMUD were the primary MUDs allowing distributed objects, but nearly all of the Tiny* MUD derivates allowed "portals" to be created where you could exit a room, and it would signal your client (if you were using something more advanced than Telnet) to connect to another server and log you in transparently.

Diku's were hardcoded back when I played them and there was no scripting language to extend them at runtime without recompiling the server.

I wrote a MUD myself back then, and a couple of bots, including a Cleric bot for Diku that would group up with me and follow me around. It would watch my character in battle and whenever I got hurt to a certain level, it would cast heal. :)
 
For me UT was a better game than Q3. In Q3 all you did was run around with your finger on the fire button. In UT you had a lot more strategy, with all the different types of game play.

I play on a lot of LAN's and in UT the BOT support was simply amazing compared to Q3. This is what mattered most to us. Realistic BOT's.

I think that will be a major plus in UT2K3.
 
--U(T) and the Quakes, TS and JC

JC = Depth in one area (e.g. visibility, lighting)
TS = Breadth in many areas, modeling, animation, special effects, tools, etc

I agree on the whole, but I would change one thing. Carmack seems to take a will it run well approach while TS takes a software engineering approach of compilers do all the low-level optimzation just fine, computers are fast enough and favour scalable design vs performance. Now these are merely leanings more than profiling the two folks. It just seems to me that TS makes an engine for the developer while Carmack makes an engine that performs really well.

IMHO, the Quake derived engines always had superior control and network play. No non-quake derived FPS I play with massive numbers of players feels as "smooth" as the Quake engines. Moreover, I doubt that the Unreal engine has as many licenses as the the various Quake engines. Add up the licenses of Q1/Q2/Q3 vs Unreal/UT, it doesn't compare.

I couldn't agree with you more. I'm not sure what it is exactly, but in all other FPS I've played I feel disconnected. In all Quakes it feels like my feet are hitting the ground and that I'm actually in the situation. The "smoothness" factor is definately there, having played some big games in Tribes, played the UT demo when Quake3 had been out for a some months it just didn't feel right. That and the pings seem to be a fair bit worse -servers on the same ISP as me and in about the same area. I suppose it's all in my head, but it seems to be the difference between the same suspension system in two cars one tuned for sport and the other for ride, it definately is different. Maybe it stems from the fact that I've played TOO much Team Fortress - the for men version in QuakeWorld - during my younger years.

--MUDS

Diku's were hardcoded back when I played them and there was no scripting language to extend them at runtime without recompiling the server.

About the only scripting they had if you call it scripting was the areas were text files, of course if you hand edited them, you're a freak.

I wrote a MUD myself back then, and a couple of bots, including a Cleric bot for Diku that would group up with me and follow me around. It would watch my character in battle and whenever I got hurt to a certain level, it would cast heal.

I actually started on a MUD code base written in Java, didn't get to finish. Maybe I'll do it for the sake of completion. It had a formalized event system, so no more hacking stuff in where it would work. The storage system would be done with serialization. I was thinking of possibly using JDBC and interfacing it with PosgreSQL all on Redhat with the "new" 1.4 JVM. I hadn't formalized a scripting model.
 
I was looking through the Q3 source code with a view to doing a mod. Just to get an idea of the structure, I was using a web-site which had tutorial type of things to show people how to alter things like speed of projectiles, splash damage etc.

I got to one bit of the code and the tutorial guys had put a comment about it, the code was a shift instruction (I think it was by 10 but can't remember), they claimed that the usage of a shift instruction as a multiply by a power of two was evidence of John Carmacks 'Guru level programming skill'. :)
I think it was more a case of their lack of understanding basic concepts.

Never did get that mod done.

CC
 
After talking with Tim S at the UT mod summit I have a deeper respect for him. He told us that his game will not look as good as Doom3. But he said that was not the goal. The goal was to improve on UTs faults with UT2k3 and from what I have had a chance to see and play around with they have done just that. Remember UT started out nothing more than an add on to Unreal that happen to grown into its own thing. They only did minor tweaks to the engine and most of it was in the netcode. The rest including the rendering part stayed pretty much the same. And as someone else said Epic is constantly updating their engine. Tim has already started to work on the new stuff :)

After coding mods for Q2/Q3/UT I find that all have their good/bad points. However what Tim did with UnrealScript is a godsend. You have all source code from day one and its super easy to use work with. It make developement flow much quicker. I found Q3 stuff to have better looking effects but they were a pain, UT was much more easliy to deal with.
 
Captain Chickenpants said:
they claimed that the usage of a shift instruction as a multiply by a power of two was evidence of John Carmacks 'Guru level programming skill'. :)

LOL :LOL:

While we're on it, here's a piece of code that supposedly was written by Carmack, it has a lot more guru-factor than a bit-shift. I does a quick 1.0f / sqrtf(v) approximation, usually the error lies around 1% or so. I think I have a fairly good idea how it works :)

Code:
float rsqrtf(float v){
    float v_half = v * 0.5f;
    long i = *(long *) &v;
    i = 0x5f3759df - (i >> 1);
    v = *(float *) &i;
    return v * (1.5f - v_half * v * v);
}

(Today 3dNow/SSE can do it much better though ... )
 
DemoCoder said:
IMHO, the Quake derived engines always had superior control and network play. No non-quake derived FPS I play with massive numbers of players feels as "smooth" as the Quake engines. Moreover, I doubt that the Unreal engine has as many licenses as the the various Quake engines. Add up the licenses of Q1/Q2/Q3 vs Unreal/UT, it doesn't compare.

Personally, I always had a much harder time playing the Quake games' netcode than I did with Unreal. On the crappy connection I had at the time, Quake2 and Halflife were continually disconnecting me from the server, whereas with Unreal/UT I could keep on going. Even when I got better 'net connections later, UT just felt right...Quake3 didn't. It's because of this that I have doubts about people who think that Quake's network code is better...I think it's more a point of personal preference.

As for the number of licenses, you can't compare it in that fashion, because Quake has simply been around longer.
 
Well, I'm not sure that this is what the thread was supposed to be about... but I've played both Q3 and UT quite a bit, and to me the only thing that really matters is gameplay.

UT has that in spades, and wins hands down IMO.
 
Then just compare Q3 licenses and # sales.

Unreal's net-code was very bad for a long time. No way could you compare 16 or 32 player Unreal to Q1, Q2, or Q3. It improved over time after a boat load of patches, and UT's net code now works, but it still doesn't work as well as Q3. Try comparing both on a 56k and on broadband.

Unreal's netcode is based on a state replication paradigm which makes it very easy to program, but which makes it also very easy for mod makers to screw up by replicating too much or inappropriate information. It also isn't as efficient as hand coded packets.


Why are Half-Life mods (including Counter-Strike, TF, Action HL, etc) getting the vast majority of players online? It's such an old engine and making mods for it is hard (Q1/Q2/Valve hybrid), yet, there are probably over a hundred thousand of people playing it at any given moment.

I just don't buy it. I've been playing ID games since Doom had modem play, and there was always something better and smoother about the control of ID engines. 3DRealms is the only ones who matched the experience with Duke3d. Anyone remember Rise of the Triad? Ugh.
 
DemoCoder said:
I just don't buy it. I've been playing ID games since Doom had modem play, and there was always something better and smoother about the control of ID engines. 3DRealms is the only ones who matched the experience with Duke3d. Anyone remember Rise of the Triad? Ugh.

This is where I think this is based on personal preference. The first game that I was able to play acceptably online was Unreal (Including Quake, Quake2, Halflife), probably mostly due to the fact that I only had a crappy 28.8 connection at the time.

I personally just prefer the prediction scheme that is setup in Unreal/Unreal Tournament, and find it much easier to deal with. Because you're more used to the id way of doing things, you think it's better. If you can show an objective reason why id's way is better, maybe I'll buy it. Right now, it's all subjective.
 
Back
Top