AnandTech investigates the advantages and disadvantages of the new market trend: multi-core CPUs. Will dual core enhance your gaming experience? Tim Sweeney, the leading developer behind the Unreal 3 engine, was kind to answer their questions about multi-threaded development with concise answers.
Multi-core and multi-threaded gaming – Part 2
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
http://www.unrealtechnology.com/html/technology/ue30.shtml
Unbelievable.
would be os simplified the development, had it succeeded (or, if apple or microsoft purchased be os and made it the foundation of their next os?)
Not really. Most games don’t really use OS services, nor do they use the GUI API. BeOS really didn’t have any technology to make it easier to write multithreaded code, they just forced you to do it.
beos was multi-threaded throughout the OS – including the drivers, etc.
Not much different then Windows NT, with the exception that some bottlenecks were present in media performance – which is why multiple movies would stutter. Longhorn fixes this with a new driver model and other low-level changes.
Now, in terms of beos simplifying development – no. Making thread-safe programs is hard no matter how the OS is designed. Of course, it’s better if the OS doesn’t use preemptive multitasking like the old windows 3.1
Their rendering technique really is ingenious. They basically do lighting on the 2 million triangle mesh (via a normal map), but only render a 5,000 triangle mesh. Since the human brain is very sensitive to luminance, but less sensitive to detail, this works well (just like YUV).
You don’t just delete your files, you frag them!
Of course, it’s better if the OS doesn’t use preemptive multitasking like the old windows 3.1
I think you mean that Win 3.1 used cooperative multitasking.
“I think you mean that Win 3.1 used cooperative multitasking.”
Perhaps he meant non-preemptive multitasking
In some ways, multithreaded development (GUI-wise) in BeOS is easier than Windows/MFC because BeOS does it without requiring thread local storage and handle maps (at least, MFC requires this mess) while in some ways, it’s easier in Windows, because Windows supports more threading primitives.
In terms of putting an application together that really doesn’t need multiple GUI threads, however, Windows allows people that aren’t thread-capable to write applications without getting all tied up in the muck that happens with dealing with multiple threads. Unfortunately, there’s always a price to pay for dealing with more than one thread, and yes, BeOS as exists now in any available form forces you to deal with a bare minimum of 2 threads for the simplest GUI app. At first, many people that have had no experience say, “Wow, neat! Look how easily I can do multithreaded apps!” when it’s quite likely that they’ve deluded themselves as to what’s really involved, and have set themselves up for deadlocks and/or race conditions. Perhaps the complexity involved in getting a Windows app to have multiple GUI threads (having additional non-GUI worker threads isn’t as complicated) provides a sufficiently high barrier that most people that get to that point of deciphering how to do it in Windows likely have enough background experience to know how to manage threads correctly
IMHO it really depends on how You think about writing multi-threaded software. Sure it’s horrible for people used to having direct control over the flow all the time, but with message-based (in case of BeOS: BLooper+BMessenger – send message with data, and do anything else until received answer message, or if it’s needed use synchrounous messaging (but that’s not too “multithreaded” programming right?
) programming it’s not that hard, it’s even quite simple.
I didn’t write any huge application for BeOS yet, but i don’t think it would be very different from what i done so far – just more coding
. The only times i had problems with deadlocks were when i tried to control everything (i don’t know english names for those two ways of programming, but i hope You can understand me).
This is an interesting era of computation indeed. I have read about the Unreal Engine before and it quite lives up to its name. Splinter Cell 3 just coming out, is based on the previous UE 2.0 yet it looks awesome. I think the Unreal Engines are just brilliant overall and the only contender they have are the Domm engine and the Cry Engine.
Their rendering technique really is ingenious. They basically do lighting on the 2 million triangle mesh (via a normal map), but only render a 5,000 triangle mesh. Since the human brain is very sensitive to luminance, but less sensitive to detail, this works well (just like YUV).
Doom, FarCry and Half-Life 2 do pretty much the same thing, just with less polys. But D3 used dynamic lighting and shadows for all their lights while UE3 uses both static and dynamic lights and a cubemap with bluring for the “short shadows”. Not as technologicly advanced as D3, some may argue, but a lot faster. That’s why they can use more polys on the (ingame) model, while D3 has some nasty pointy heads. They also use HDR so that’s why everything looks so damn cool. But I’m more worried about how this thing will eat up the resources. They say they use a 2048×2048 normal map and a diffuse map. Add here a height map and the possibillity of using more than 1 diffuse map, so you can see how this will eat up RAM.
Also, UE3 is the first engine to use an advanced bump mapping technique called Parallax mapping which really adds a lot of detail – badicly bump mapping with selfshadowing. Plus the artists are clearly top notch.
If you like what you saw there’s a video I came across a while ago of something called Relief mapping. I don’t think if this can even be called texture mapping, but expect this to see in future games (3+ years?). You can download the video below.
http://www.paralelo.com.br/arquivos/ReliefMappingVideo2.zip
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cg…
Let’s just hope the UE3 powered game has a good gameplay.
There are other tricks that can be used with games without getting two complex. Easiest is just spawning a child process on another cpu not true multi threading but you can still take advantage of a Multi-CPU system.
Well I think personally in spite of requiring a lot of hardware resources its not as if it is because of the so called “bloat” in the software but rather because of all those advanced features that make the games based on the engine to look awesome. I think that game engines kind of lead hardware development. I mean look at all the processors, memory speeds, and powerful gpus and so on that are coming out because of engines like D3, Cry and UE.
I would not mind a resource intensive game as that would just be an excuse for me to just buy a new system hahaha. I think a Splinter Cell based on that engine is certainly what I am looking forward to most…rather than just the UE Tournament style games.