It's the engine I'm going to be using for www.daretobedigital.com I was curious to know if anyone here has experience in it.

[This message has been edited by Faith_Warrior (edited May 29, 2007).]

------------------
Visit my portfolio (and check out my projects):
http://Jestermax.googlepages.com/

quote:

---

Originally posted by jestermax:
hmmmm, i don't suppose that means that they'd consider giving it away for free without a license would they?

---

No But the studio that made the engine released a free game using it called Cellfactor.

www.cellfactorrevolution.com

------------------

Well, i tried. if you don't ask, you never know

[This message has been edited by jestermax (edited May 30, 2007).]

quote:

---

Originally posted by gump:
The biggest thing to know about RE is that for a project of any major size AVOID using the C#-based Scripting System. C# is dead slow for a complex game. Let's put it this way...the processing time for the C# gameplay code can take 4-5 times as rendering a complex scene with many shaders and dynamic lights. So write your gameplay code in C++.

---

Wow. That's a bummer. So are you guys having to rewrite all of your C# code in C++ now? I thought before that you guys were looking for C# programmers, so I was assuming that's what you were doing gameplay scripting in.

--clint

One of our team members is friends with one of the development workers. Free Commcericial License for the competition *cough*

"The biggest thing to know about RE is that for a project of any major size AVOID using the C#-based Scripting System."

I'm glad our project isn't major then. Shaders and Dynamic lighting are out of the picture anyway.

quote:

---

Originally posted by gump:
The biggest thing to know about RE is that for a project of any major size AVOID using the C#-based Scripting System. C# is dead slow for a complex game. Let's put it this way...the processing time for the C# gameplay code can take 4-5 times as rendering a complex scene with many shaders and dynamic lights. So write your gameplay code in C++.

---

I don't know much about RE nor do I have a complex game written in C# however what you're saying doesn't make much sense to me. I'm not going to put in doubt that statement that C# is slower than C++ however I seems to me that using C# in a [b]complex[b] project can be actually a smart chose. Taken the speed at which cores are being stuffed into processors it seems that the big challenge has shifted from optimizing the code to reduce the processing time to getting the game use everything the CPU has got.
C# does a great job when it comes to clean code IMO, which is key in a big project.
As I said I didn't had the chance to write complex games so it might be just my nativity.

------------------
Check my C# libraries

------------------
Visit my portfolio (and check out my projects):
http://Jestermax.googlepages.com/

quote:

---

Originally posted by jestermax:
well when it comes to professional projects, i'm 99% sure that they use ASM, C or C++. I'm pretty sure that professional console dev.s used ASM mostly until fairly recently (i think PS3 uses a form of C now).
Not that i'm arguing that C# can't yield good code. but it's like comparing Java to C++ in terms of processing speed.

---

*shrug* Engines certainly are written in C/C++/ASM, but that doesn't mean that gameplay code shouldn't be written in an interpreted (slow) scripting language. For Quake, Carmack developed his own interpreted (I.E. not fully compiled) language called QuakeC. To be sure, the Quake engines are written in C/ASM, but they're still controlled by an interpreted scripting language. If writing your gameplay code in C# is slowing your game engine down, then that's an indication to me that too much of the engine is being offloaded into the gameplay scripting area, and some additional functionality needs to be included in the core engine.

--clint

quote:

---

Originally posted by HanClinto:
*shrug* Engines certainly are written in C/C++/ASM, but that doesn't mean that gameplay code shouldn't be written in an interpreted (slow) scripting language.

---

I agree with that but i was under the impression that the conversation got turned into a "User C# for the engine code as well" deal. I have nothing against interpreted or scripted languages for some stuff. Of course i'm not a master so take what i say with a grain of salt as usual

------------------
Visit my portfolio (and check out my projects):
http://Jestermax.googlepages.com/

quote:

---

Originally posted by jestermax:
well when it comes to professional projects, i'm 99% sure that they use ASM, C or C++. I'm pretty sure that professional console dev.s used ASM mostly until fairly recently

---

Ever hear of the Unity game engine? You can buy a SDK for the Wii. Unity supports several interpreted languages such as Boo. Parts of the Unity engine might we written in ASM/C++ but your game doesn't have to be.

------------------
All Your Base Are Belong To Us!!! chown -r us ./base
"After three days without programming, life becomes meaningless.'' -- Tao of Programming Book 2

"Oh, bother," said the Borg. "We've assimilated Pooh."

"Socialism works great... if there are no people involved." -- Pastor David Ginter, Union Church of Guatemala.

My Programming and Hacker/Geek related Blog

------------------
Check my C# libraries

It's hard to tell if you are saying C# is slow in general, or if you are talking specifically about the Reality Engine itself. BTW, that's lame you guys had to figure that out. Sorry to hear it.

As I've mentioned elsewhere, I am porting a Borland application over to MFC and C#. Strangely, the OpenGL performance is SIGNIFICANTLY (neglible time vs. 30 seconds to render in some cases) faster in Borland than the same exact code in MFC. Do I assume Borland is therefore better? Of course not. I am having to optimize the MFC code and understand what it is we are currently doing in the Borland code. I have been able to bring things down to a normal level.

BTW, C# and Java are not really interpreted languages. They get compiled in real-time, just in time (JIT). And .NET even has an option to deploy a pre-compiled executable so there is no live compilation at all. Just wanted to mention this as it sounds like people are describing C# and Java as slow due to interpretation.

[This message has been edited by ssquared (edited May 30, 2007).]

However i think its time to be silent; i've been beaten to death by a misunderstanding (i'm guessing i sounded like i said all game code should be written in ASM/C). Anyways, Cheers.

------------------
Visit my portfolio (and check out my projects):
http://Jestermax.googlepages.com/

quote:

---

Originally posted by jestermax:
However i think its time to be silent; i've been beaten to death by a misunderstanding (i'm guessing i sounded like i said all game code should be written in ASM/C). Anyways, Cheers.

---

Oh, don't feel bad, Jake! For being a mistake, at least it's an understandable misunderstanding. Please don't take my response to your comments personally. For the record, I think you're a swell guy who's fun to talk to, and who with some good insights in development.

In case anyone's interested, I took a few minutes to dig up the old C sharp versus C plus plus speed tests that Steveth45 did last year. He wrote a small sample program that read in a large Scrabble word list, added it to a hash, and did a million lookups and recorded the time it took. We tested with C++ and C#, each compiled/run on Windows and Linux (for a total of 4 test runs). I don't feel like copy/pasting/explaining, so if you're interested, the results and circumstances are all in that thread.

Cheers!

--clint

[This message has been edited by HanClinto (edited May 30, 2007).]

quote:

---

Originally posted by HanClinto:
He wrote a small sample program that read in a large Scrabble word list, added it to a hash, and did a million lookups and recorded the time it took. We tested with C++ and C#, each compiled/run on Windows and Linux (for a total of 4 test runs). I don't feel like copy/pasting/explaining, so if you're interested, the results and circumstances are all in that thread.
[This message has been edited by HanClinto (edited May 30, 2007).][/B]

---

Hmm. Interesting. Mono on Linux is naturally slower than .Net, but C++ is almost equal on both platforms. Of course the difference is in milliseconds so it won't matter much even for those larger programs. I see why programs that need to be very fast and acurate in miliseconds/nanoseconds are written in assembly.

Now the true Linux vs Windows test: How much faster is Firefox on Linux than on Windows? (in Milliseconds).

------------------
All Your Base Are Belong To Us!!! chown -r us ./base
"After three days without programming, life becomes meaningless.'' -- Tao of Programming Book 2

"Oh, bother," said the Borg. "We've assimilated Pooh."

"Socialism works great... if there are no people involved." -- Pastor David Ginter, Union Church of Guatemala.

My Programming and Hacker/Geek related Blog

quote:

---

Originally posted by skynes:

I'm glad our project isn't major then. Shaders and Dynamic lighting are out of the picture anyway.

---

So, they are using C# for the rendering engine? Hmmm… kinda like Axiom, eh?

quote:

---

Gump, I'm interested in knowing WHY the C# is slower. Did that information come from the developers of the engine? Did they focus more on C++ than C#? Do they truly feel they optimized the C# code as best they can? What about comparing managed DirectX in C# to OpenGL in C++?

---

We, along with a bunch of other devs. learned this afterwards. You'll notice in CellFactor how poor the performance is, it's not because your lacking a physx card for the most part. It's because of the C# code being used. I'm sure that if the game was coded in C++ the performance would be greatly enchanced.

quote:

---

It's hard to tell if you are saying C# is slow in general, or if you are talking specifically about the Reality Engine itself. BTW, that's lame you guys had to figure that out. Sorry to hear it.

---

It's slow in RE itself. We and other devs found this out the hard way, yay. We've been working on a few different solutions that fixes the problem, so we should be back up and running hopefully soon. If you're wondering how Nightmares is going it's mainly the art pipeline that's been taking forever. It takes months for artists to design a next gen. model and it's super expensive. I can get (x10) current gen. models done for the price of (x1) next gen. model. It'll be worth it though, right....right?

For your demo using C# should be fine, I'd still recommend C++ however. What build version are you using? 15.1?

------------------

------------------

I'm really not sure yet. I won't know all the final details until we actually get our hands on it.

Rewriting the whole engine in managed code isn't an option nor is keeping the C# Scripting System as is. We realized this over a year ago but it took a while for us to realize just how bad things were until our project reached a significant level of complexity. Yet at the same time rewriting everything in C++ is unappealing to us considering the time already put into it so we're working with another game dev in developing an internal C# interpreter. We'd obviously not support EVERYTHING that .NET does but just enough so that our coders can produce C# like normal and have RE read it in without using .NET.

To give you guys an idea on performance, I was running a test last night where I enabled 6 bots in a map and positioned the camera so pretty much everything had to be rendered. This is a complex scene yet the processing time for 3d rendering each frame was often 1/5 to 1/8 that of the processing time for C#, physics, and AI combined. The CPU is ALWAYS the bottleneck even with multiple cores (RE automatically splits up the major divisions of the engine for using multi-cores) and a PhysX card.

We also heard back from another RE dev who made the jump from using C# to converting to C++ only. They wrote their code in C# and a particular scene ran at 10FPS. After the rewrite in C++ and some optimization of their scene they're now getting 100FPS.

BTW, check out the January 07 issue of game developer magazine where they discuss managed code in games. In their own test the "framerate dropped from 160FPS to 60FPS and the memory usage jumped from 29MB to 34MB". I like working in C# but that's just unacceptable. If you think it's just a matter of lack of knowledge or some needed optimization... Let's put it this way, an experienced engine coder from Raven software tackled RE and nothing could be done (although his focus was mostly on the other components of the engine [renderer, etc]). .NET just has to go.

[This message has been edited by gump (edited May 31, 2007).]

MS isn't supporting C++ -> C# (calling C# from C++) on the XBox? Ouch. That seems like functionality built right into .NET. I use it a lot.

"If you think it's just a matter of lack of knowledge or some needed optimization..."

No, I didn't mean it that way. I am the last one to say something of the sort as I hardly know grahpics at all. One of my pet peeves is when someone states they like or don't like something, or something doesn't work, without backing up the statement. I like asking questions and finding out the root of a problem. I was just asking a bunch of questions to get a better all around understanding of what had been done and how you came to the conclusion you did. Your response really covered what I wanted to know. Thanks.

The thing that surprises me is XNA. If managed code is so bad, then XNA will eventually be a flop. I have not read about poor issues with XNA, but I do tend to stay on the pro-XNA sites. What is MS doing with XNA to maintain speed and framerates? This is a managed PC and XBox solution.

quote:

---

MS isn't supporting C++ -> C# (calling C# from C++) on the XBox? Ouch. That seems like functionality built right into .NET. I use it a lot.

---

Exactly. Far as I know RE is the ONLY engine really using that functionality. When Artificial talked to Microsoft it was like a collective shrug. That's why their title Monster Madness switched over to Unreal 3.0, since that was a console gamer oriented title. From a business perspective they needed to move quickly on developing MM. It was actually quicker/cheaper to move to UE 3.0 than it was to remove the .NET Scripting System and do the X360 port of RE.

quote:

---

The thing that surprises me is XNA. If managed code is so bad, then XNA will eventually be a flop. I have not read about poor issues with XNA, but I do tend to stay on the pro-XNA sites. What is MS doing with XNA to maintain speed and framerates? This is a managed PC and XBox solution.

---

From what I understand XNA is oriented toward apps that are pure managed code. Part of our problem may be that C++ -> C# interops are simply not a very optimized part of .NET. After all, I believe RE stresses that functionality way beyond any other app so perhaps it's not a high priority for Microsoft.

[This message has been edited by gump (edited May 31, 2007).]

quote:

---

Originally posted by gump:
Exactly. Far as I know RE is the ONLY engine really using that functionality.

---

Would you count the Unity engine as a serious engine? I don't think it has console support, but it's cross-platform Mac/Windows, and it has an embedded Mono interpreter to allow C# as a scripting language. I wonder how it handles its interops.

Oh, and supposedly they're porting Unity to the Wii.

EDIT:

And, no, we haven't tried using Mono, although Tim Johnson, one of the original programmers for RE, suggested using it way back.

[This message has been edited by gump (edited May 31, 2007).]

quote:

---

Originally posted by gump:
Part of our problem may be that C++ -> C# interops are simply not a very optimized part of .NET. After all, I believe RE stresses that functionality way beyond any other app so perhaps it's not a high priority for Microsoft.

---

Interops, in general, are an extremely expensive hit. You can optimize up to a point, but by their nature, they are slow. They require marshal/unmarshal of information to translate from one language structure to another and that is a big time waster. This can really add up if when writing managed code, you call an unmanaged function and that unmanaged code turns around and calls managed again.

Anyone who has used Java Native Interface (JNI), CORBA, and even COM recognizes the pain involved in writing stubs/proxies/marshal/unmsarshal/etc. This is what blows me away with Visual Studio. Microsoft did a really terrific job of taking all the pain away from the developer. The marshal/unmarshal is done under the hood from you and you don't need to deal with it in code. I have found writing that middle layer to be one of the BIGGEST development time wasters and is open to potential errors and mistakes.

This is another factor of what makes .NET and CLI very appealing. They take care of cross-language issues ridding the need to cross boundaries. Java is nice for its cross-OS implementation, but with people now writing Python, Ruby, C, C++, C#, Java, etc. having better cross-language support appears to be on the rise.