A Simple Poll About IDEs

[Josh]

Dang. Should've seen this one coming.

That was an ambiguous statement.

[Canardia]

I will be maintaining a MinGW lib then, it will be create much faster games than VS2008/2010

[Brent Taylor]

I will be maintaining a MinGW lib then, it will be create much faster games than VS2008/2010

 

Site reputable sources for this or I call bull. Hint: I've done enough research into this to already know it's bull. So be cautious.

 

EDIT: Since when have we had a swearing/word filter on these boards? Down with censorship!

[Josh]

Leadwerks.com is a family website. We're all a big family. Like the mafia, only less cool.

[Canardia]

Site reputable sources for this or I call bull. Hint: I've done enough research into this to already know it's bull. So be cautious.

You only need to make a simple test program which tests the essential speed issues: loops and memory allocations. MinGW wins VS2008/2010 by far (use the -O6 option with g++, and a few other options for even more speed).

Also the compiling time with MinGW+CodeBlocks is much faster, like 1 second vs 30 seconds, so you save a lot of development time too.

That again saves your nerves and you can produce more games and higher quality games.

[Brent Taylor]

Leadwerks.com is a family website. We're all a big family. Like the mafia, only less cool.

 

Yes yes, censorship for the sake of a "family" location. Think of the children and all that. I hate politicians. I really do. I'm not one to agree with censorship, for any reason. But that is neither here nor there. Back on topic.

[Canardia]

I vote for Ron Paul!

[Brent Taylor]

You only need to make a simple test program which tests the essential speed issues: loops and memory allocations. MinGW wins VS2008/2010 by far.

Also the compiling time with MinGW+CodeBlocks is much faster, like 1 second vs 30 seconds, so you save a lot of development time too.

That again saves your nerves and you can produce more games and higher quality games.

 

You definitely want to do some more research into optimization levels and such and precisely how they effect the resulted code performance on different architectures. As for compilation time, don't confuse VS with MSVC. MSVC itself is incredibly fast, on par with GCC and faster in certain cases. VS however slows it down significantly due to the deep inspection it does of source code at compile time.

 

You have to understand, comparing a compiler is not trivial. I'm going to quote Maciej Piechotka here:

 

"

Comparing compiler is not trivial:

• It may vary from processor to processor. GCC may better optimize for i7 and MSVC for Core 2 Duo or vice versa. Performance may be affected by cache etc. (Unroll loops or don't unroll loops, that is the question ).
  
• It depends very largely on how code is written. Certain idioms (equivalent to each other) may be preferred by one compiler.
  
• It depends on how the code is used.
  
• It depends on flags. For example gcc -O3 is known to often produce slower code then -O2 or -Os.
  
• It depends on what assumption can be made about code. Can you allow strict aliasing or no (-fno-strict-aliasing/-fstrict-aliasing in gcc). Do you need full IEEE 754 or can you bent floating pointer calculation rules (-ffast-math).
  
• It also depends on particular processor extensions. Do you enable MMX/SSE or not. Do you use intrinsics or no. Do you depend that code is i386 compatible or not.
  
• Which version of gcc? Which version of msvc?
  
• Do you use any of the gcc/msvc extensions?
  
• Do you use microbenchmarking or macrobenchmarking?
  

And at the end you find out that the result was less then statistical error

 

Even if the single application is used the result may be inconclusive (function A perform better in gcc but B in msvc).

"

 

Using a simple test application is doing yourself a great injustice and is simply naive.

[Josh]

I think MSVC compiles slower but produces faster code than GCC. That opinion is only based on a vague memory of reading something somewhere, to that effect.

[Mumbles]

I prefer smaller code over faster code anyway... 3 GHz is more than enough these days, slow downs are more likely to be caused to sloppy programming leading to huge time complexities and I doubt any compiler could really fix that for you...

 

And really, there's no need for stuffy 10 MB exe files when it comes to games, 150 KB is more than sufficient, but call it 2 MB in the case of games with a statically linked engine (which you can't with LE 2, but for those others that can/do)

[Roland]

Been thinking a bit about the discussion on installers. Actually its not Leadwerks resposibility to support any installer. I think that is something that the developer has to make him self by making a simple ZIP thing or using some installation utility as Inno Setup. In fact it would already be possible to create a Inno Setup script using the LeBuilder of there is enough interest for that (will not need any new LEBuilder just another template).

 

Leadwerks should not use the old VS2008 files with the argument that its more easy for the developer. Leadwerks should use the best tools and resources thats possible and leave the distrubution problem to the developer.

[Brent Taylor]

Leadwerks should not use the old VS2008 files with the argument that its more easy for the developer. Leadwerks should use the best tools and resources thats possible and leave the distrubution problem to the developer.

 

I agree with this. However, I don't think having an officially supported process for creating an installer is a bad idea either.

[Roland]

I agree with this. However, I don't think having an officially supported process for creating an installer is a bad idea either.

Yes. But in that case that process must be designed dependent on whats in Leadwerks Engine. This strange way of going the other way is something I dont understand. Cant see the idea of letting the engine be dependent on the installer, thats making things backwards.

 

Making some installation procedure for any Leadwerks 3, 4 or 5 should not be any big problem although I really not have any knowledge on how to do that on a Mac, but surely that cant be any showstopper.

 

My 10 cents goes to .... First design and implement the engine and THEN make some installation procedure that supports that, absolutely not the other way.

[Rick]

Just support Lua and be done with it already

[Canardia]

No Josh, you remember now GCC from BlitzMax times, where Mark always hardcoded -O2 into g++ and added some stupid GC to BlitzMax. A pure g++ program with -O6 is the fastest you can find on this planet.

[Brent Taylor]

No Josh, you remember now GCC from BlitzMax times, where Mark always hardcoded -O2 into g++ and added some stupid GC to BlitzMax. A pure g++ program with -O6 is the fastest you can find on this planet.

 

Seriously, start pointing to some real data on this or you're just spouting bull.

[L B]

That was an ambiguous statement.

That means I'll be the one maintaining the VS2010 C# project for .NET 4, I guess.

But think of all the functions that have optional parameters in L3D. You can't have that with VS2008 C#.

 

EDIT: You can make overloaded functions with less parameters, of course, but it's annoying, long and useless when you could use the proper technology.

[Josh]

That means I'll be the one maintaining the VS2010 C# project for .NET 4, I guess.

But think of all the functions that have optional parameters in L3D. You can't have that with VS2008 C#.

 

EDIT: You can make overloaded functions with less parameters, of course, but it's annoying, long and useless when you could use the proper technology.

This discussion isn't related to C#. C# requires additional packages be installed no matter what, so I am not as strict with it. 2010 or 11 is fine.

 

For the record, I won't support any language or OS if there isn't an actual employee here with the capacity to manage it. Your help is most welcome, and will speed things up, but ultimately it's our responsibility to make sure languages are properly supported.

 

All my wild promises are based on the idea that sales will be good so that we can afford to provide everything, but I think Leadwerks3D does a good job of meeting people's needs that were ignored in the past, and I'm optimistic about adoption rates.

[Brent Taylor]

That means I'll be the one maintaining the VS2010 C# project for .NET 4, I guess.

But think of all the functions that have optional parameters in L3D. You can't have that with VS2008 C#.

 

EDIT: You can make overloaded functions with less parameters, of course, but it's annoying, long and useless when you could use the proper technology.

 

Keep in mind, that I don't think he's mentioned anything about a C interface to the engine. For .NET support, you're going to have to write a full on wrapper via C++/CLI as P/Invoke won't be an option.

[Josh]

There's a C DLL right now. That's how I am calling the engine from the editor.

[Brent Taylor]

There's a C DLL right now. That's how I am calling the engine from the editor.

 

My mistake then.

[L B]

There's a C DLL right now. That's how I am calling the engine from the editor.

And how C# is supported.

[Brent Taylor]

And how C# is supported.

 

Again, I wasn't aware he was writing a C interface for Leadwerks 3D.

[Naughty Alien]

VS2008 should be dropped dead..VS 2010 should be used (if LE doesn't take long enough to next VS release) .. reason is simple...horrid intelisense/autocompletion in VS2008 (working like a charm in vs2010), 2010 has IntelliSense rewritten from scratch. It now uses an EDG-based parser for source validation and gives online compiler errors (underlining while you type), and a completely different storage system for the data. Also there is .NET 4.0 support, and most important reason to set VS2010 as a default (if Josh really thinking about developers) is threads coding mentioned many times..profiler and debugger in VS2010 are real beauty (supersuck in VS2008)...but then, if you still believe in VS2008..okay then....just a tip..

[Roland]

VS2008 should be dropped dead..VS 2010 should be used (if LE doesn't take long enough to next VS release) .. reason is simple...horrid intelisense/autocompletion in VS2008 (working like a charm in vs2010), 2010 has IntelliSense rewritten from scratch. It now uses an EDG-based parser for source validation and gives online compiler errors (underlining while you type), and a completely different storage system for the data. Also there is .NET 4.0 support, and most important reason to set VS2010 as a default (if Josh really thinking about developers) is threads coding mentioned many times..profiler and debugger in VS2010 are real beauty (supersuck in VS2008)...but then, if you still believe in VS2008..okay then....just a tip..

Could not better expressed. I totally agree on each word.