Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 21 of 173 FirstFirst ... 1119202122233171121 ... LastLast
Results 201 to 210 of 1724

Thread: OpenGL 3 Updates

  1. #201
    Junior Member Regular Contributor
    Join Date
    Aug 2007
    Location
    Adelaide, South Australia
    Posts
    206

    Re: OpenGL 3 Updates

    Just use whatever is appropriate for the task, i use a combination of languages, ObjectPascal for most of the procedural stuff, a logical language for AI, with a few small assembly routines thrown in if i really need them.
    Quote Originally Posted by Korval
    while I'm sure you could write games in Pascal, why would you want to?
    1. Object pascal can do anything C++ or C can do.
    2. Every C/C++ API header file gets translated into pascal very quickly. (by www.delphi-jedi.org and others)
    3. The compiled code executes just as fast as C (as long as you dont make methods virtual when you dont need to, which is a common mistake)
    4. Silly mistakes like invalid typecasting or using an invalid GL constant are detected at compilation.
    5. It is easier to find bugs because the code is more explicit, you dont have the problem of a single missing character producing valid code that does something completely different to what you intended.
    6. Is is much easier to read & understand someone else's code.

    Really though, the choice of language is more of a personnal choice, most people simply use the language that they are most comfortable with.

    As for execution speed, if the compiler is good enough and you dont overuse the more complex features when you dont need to, then there should be no difference.
    Most speed differences are usually due to the quality of the library routines supplied with it, not the actually language.

    A program can be written in any language that runs first time and has no bugs, its just a matter of using the proper software engineering techniques, but its a lot easier to do with pascal than with C because all of the typo's are caught by the compiler.
    Garbage Collection is slower than managing the memory yourself
    Quite true, fortunately my compiler lets you replace the memory manager they supply with your own.

  2. #202
    Senior Member OpenGL Pro Zengar's Avatar
    Join Date
    Sep 2001
    Location
    Germany
    Posts
    1,932

    Re: OpenGL 3 Updates

    @modus: This is true that for super-performance 3d engines there is little choice besides C++. But that is not the point. Not everyone needs this kind of performance. If we take Java as an example -- it is a perfect platform for implementing MMORPGs. You have pretty decent performance (about 80% of C++ analogue), multiplatform support out-of-the box (with webstart), rich network API.

    LINQ seems nice, and surely can make database (and not only) programming easier.

    P.S. Garbage collection is slower only in several szenarious (if you need only few big chunks of memory). When you are dynamically allocating and freeing lots of objects, nothing beets a garbage collector. Of course, collecting itself may be a minor slowdown, but I've never noticed any when working with Java or .NET

    P.P.S. The tradeoff is programming efficiency vs. performance. There was that presentation from Epic Games about future of game programming, where they analyse UT3 engine and Gears of War and propose some language features they find usefull (quote: "would gladly trade 10% performance for 10% programming efficiency"). The language he describes inthe end is somehow similar to OCaml. An interesting read, if you haven't seen it before (http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt )

  3. #203
    Junior Member Regular Contributor
    Join Date
    Aug 2007
    Location
    Adelaide, South Australia
    Posts
    206

    Re: OpenGL 3 Updates

    Quote Originally Posted by modus
    P.S. My this thread has meandered... :-)
    Yes, perhaps we should get back to "Things we would like explained in the next Pipeline newsletter".

    It must turn up soon, after all its the "Summer" edition and its going to be 35C (95F) all this week, summer is here at last.
    Just in time for my birthday...

  4. #204
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: OpenGL 3 Updates

    it is a perfect platform for implementing MMORPGs.
    No, it is not.

    On the client side, memory performance is crucial. MMO's already recommend 1GB of RAM on machines. Try doing them in a GC environment, and you're looking at 1.5-2GB, which is pushing the Win32-bit limit. Now you're in danger of running out of memory due to fragmenting the virtual address table. Even if you're not, you're still taking up lots more memory to do basically the same job. You cut your userbase down by doing so.

    On the server side, you can't accept a 20% performance penalty. Servers are already choked as is; you can't afford to make them slower just because you want to use a newer language. 20% speed reduction means that a 50 man raid can only be a 40 man raid.

    Garbage collection is slower only in several szenarious (if you need only few big chunks of memory). When you are dynamically allocating and freeing lots of objects, nothing beets a garbage collector.
    At what? Not leaking memory? Because the price you pay for not calling "free" at the moment you need it is that "free" will be called "later". When, you can never say. Game's like to have consistent performance, and that's where GC runs into big problems.

    where they analyse UT3 engine and Gears of War and propose some language features they find usefull (quote: "would gladly trade 10% performance for 10% programming efficiency").
    Isn't Epic being sued for the quality of their engine? I'm not sure I'd take their advice.

    Things we would like explained in the next Pipeline newsletter
    We know what we would like explained: GL 3.0. Either finished, or an explanation of why it isn't.

  5. #205
    Intern Newbie
    Join Date
    Oct 2007
    Location
    Toronto, Canada
    Posts
    40

    Re: OpenGL 3 Updates

    Man, my intent wasn't to start one of these holy wars.
    The details are trivial and useless;
    The reasons, as always, purely human ones.

  6. #206
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    352

    Re: OpenGL 3 Updates

    Man, my intent wasn't to start one of these holy wars.
    Too late now... But can you think of a better way to keep ourselves occupied until OpenGL3 is ready?

    @Korval:
    On the client side, memory performance is crucial. MMO's already recommend 1GB of RAM on machines. Try doing them in a GC environment, and you're looking at 1.5-2GB, which is pushing the Win32-bit limit.
    So you are saying that the GC magically increases memory usage? Sorry for expressing it like this, but that's nonsense.

    On the server side, you can't accept a 20% performance penalty.
    Yeah, that's why all server applications are written in x86 assembly. No wait...
    (in reality, it's all Java, with .Net, Ruby, Python to a lesser extent)

    At what? Not leaking memory? Because the price you pay for not calling "free" at the moment you need it is that "free" will be called "later". When, you can never say. Game's like to have consistent performance, and that's where GC runs into big problems.
    Agreed. That's one of the biggest issues people have with XNA and related toolkits, which you can only eliminate by manually taking care of memory management (using object pools for example). This strips away one of the biggest advantages of GC languages, but such is the price of performance. You still benefit from faster memory allocations though.

    However, it is possible to perform deterministic object allocation/de-allocation in .Net (and presumably other GC environments), using the Disposable pattern. The differences aren't as large as you make them sound.

    Isn't Epic being sued for the quality of their engine? I'm not sure I'd take their advice.
    Yeah, I'm sure you know better than the Epic team

    (please, Khronos, get OpenGL3 out of the door before things start becoming violent here! )
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

  7. #207
    Senior Member OpenGL Pro
    Join Date
    May 2000
    Location
    Naarn, Austria
    Posts
    1,102

    Re: OpenGL 3 Updates

    Garbage Collection is slower than managing the memory yourself.
    This statement is not true.

    Ok, there may be usage patterns where manual memory management is faster. But there are also usage patterns where garbage collection is much faster.

    With manual allocation, the cost is proportional to the number of allocations and deallocations. With copy collection, the cost is proportional to the number of living objects. Allocation is extremely cheap (a single pointer increment), and deallocation is free.

    So if you have a lot of allocations of small, short living objects, garbage collection is a clear winner.

    Constructing a test case where garbage collection is twice as fast as manual memory management is not so hard, and this test case is not so exotic that I would bet on it not appearing in real world applications.

    That being said, games or 3D engines usually don't have the memory usage patterns necessary to make copying garbage collection more efficient than e.g. reference counting. But I didn't want to leave such an absolute statement uncommented when it's false in general

  8. #208
    Member Regular Contributor
    Join Date
    May 2001
    Posts
    348

    Re: OpenGL 3 Updates

    Please, this isn't a direction a thread called "OpenGL 3 Updates" should take. Just stop here.

  9. #209
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: OpenGL 3 Updates

    Allocating and deallocating memory is always slow, no matter, whether it is GCed or not. So, you are always good advised to use things like free-lists, which might be the fastest possible solution. Even in garbage-collected languages no one prevents you from doing it, and even there you will benefit from its use.

    The difference is, that in non GCed languages you need to handle deallocation EVERYWHERE. That's a big source for memory-leaks and that makes your software unreliable. Well experienced programmers will use RAII a lot (e.g. using the STL) and thus code becomes pretty reliable. Still, a huge part of my engine is only responsible for resource-management, including proper deallocation and detection of ill usage patters, e.g. forgotten objects. With GC at least some of the code could be shortened quite a bit.

    In the end, what it comes down to, is that with GC you can usually do all the optimizations, that you can do in C++, that actually make sense. However, for all the small stuff, you can be sure, that you don't need to worry, there will be no memory leaks, that make your app crash after it runs for x days (e.g. servers). That's most certainly a good reason, why many people prefer C# and Java over C++ for such tasks. No matter how good your programmers, when you have software running for weeks or months, it still needs to be reliable.

    And usually we have enough to worry about already. I wouldn't mind getting a garbage collector in the C++ core language. Though that won't happen.

    Jan.
    GLIM - Immediate Mode Emulation for GL3

  10. #210
    Junior Member Regular Contributor
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    163

    Re: OpenGL 3 Updates

    Quote Originally Posted by Xmas
    Please, this isn't a direction a thread called "OpenGL 3 Updates" should take. Just stop here.
    Yep, time to change the subject.

    Will GL3 support multi-sample textures (FBO only has mulit-sample renderbuffers)?

    This is something D3D 10 has and GL should have as well!

    Having the ability to read samples of the multi-sample FBO is tremendously useful. Obvious example is the Stencil Routed A Buffer paper for order independent transparency.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •