Announcement

Collapse
No announcement yet.

Quake Live Now Available To Linux Gamers

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #76
    Originally posted by Dragonlord View Post
    Which brings us back to what I say all the time. The number crunching has to be done in C/C++ code ( therefore the game engine itself )
    This is possible in any JITed environment with the right features for number crunching. Keep in mind that there is no reason why C++ couldn't be JITed. Whether a language is JITed or not doesn't really say a whole lot.

    Hey, that may be a cool idea: a JITed C++ for the web.

    <script type="text/c++" src="bla.cpp"></script>

    But Js is obviously no C++, JITed or otherwise. That can change though.

    Comment


    • #77
      Originally posted by mirv View Post
      Anybody who thinks assembly or C will go away....has never done embedded programming.
      Neither assembly nor C are going away. There are many, *many* jobs where these are the best tools (or where there's no alternative) and I've programmed enough ARMs, MIPSes and even 8085s (shudders) to have gotten rid of any such delusions.

      However, let me ask you a question: do you consider the iPhone or the Android platforms as embedded? Because none of those can be programmed in assembly or C (there's some work for C on the Android, but it's current API uses Java.)

      There's little technical reason why C# couldn't run on such environments with a suitable native compiler (obviously without the whole framework). Indeed, both Microsoft and Novell provide versions of their .Net stacks for embedded platforms and there's a lot of developer interest in those. Just check the MonoTouch mailing list (Mono's iPhone stack) or the main mono-dev list - there's definite interest in embedded programming with managed languages, despite the limitations.
      Last edited by BlackStar; 08-28-2009, 06:04 PM.

      Comment


      • #78
        Originally posted by Remco View Post
        This is possible in any JITed environment with the right features for number crunching. Keep in mind that there is no reason why C++ couldn't be JITed. Whether a language is JITed or not doesn't really say a whole lot.
        You mean C++/CLI?

        Hey, that may be a cool idea: a JITed C++ for the web.

        <script type="text/c++" src="bla.cpp"></script>
        Now that's a scary thought!

        Comment


        • #79
          Originally posted by BlackStar View Post
          Neither assembly nor C are going away. There are many, *many* jobs where these are the best tools (or where there's no alternative) and I've programmed enough ARMs, MIPSes and even 8085s (shudders) to have gotten rid of any such delusions.

          However, let me ask you a question: do you consider the iPhone or the Android platforms as embedded? Because none of those can be programmed in assembly or C (there's some work for C on the Android, but it's current API uses Java.)

          There's little technical reason why C# couldn't run on such environments with a suitable native compiler (obviously without the whole framework). Indeed, both Microsoft and Novell provide versions of their .Net stacks for embedded platforms and there's a lot of developer interest in those. Just check the MonoTouch mailing list (Mono's iPhone stack) or the main mono-dev list - there's definite interest in embedded programming with managed languages, despite the limitations.
          Actually, I consider Android and iPhone too powerful to be considered embedded. I do have fond memories of the 68HC11 series from Motorola though (accumulator based) - embedded chips have become much more powerful since then.
          I was under the impression that you could use C++ for the iphone (or that the development was based on C++) - wonder what Carmack used with doom there.

          Comment


          • #80
            Originally posted by Dragonlord View Post
            JIT simply means to compile code "on demand". This has nothing to do with the compiler knowing about who the code is used. This is like having a static compiler and just compiling the code where needed instead of running it through an interpreter. The end result is though still the same. Both compilers can not figure out the logic behind the code and therefore are unable to do the optimizations a human brain can do by structuring the code properly.
            You're wrong. Well, you're right that that is the minimum, but wrong that it's the maximum. Wasn't one of the very first Java JIT optimizations to count how often particular methods were called and dynamically inline them when it was often? Even if no current JIT compiler does this, there's absolutely no reason one in the future couldn't, and that was what I was talking about anyway. I have no illusions that the current JS or other compilers are suitable, I'm just saying that someday they could be.

            Comment


            • #81
              Originally posted by BlackStar View Post
              However, you can get much larger benefits by improving your algorithms, writing hardware specific paths (e.g. different shaders for radeons and geforces) or just plain optimizing your level layout and assets.
              I never said something else. Nevertheless at some point you need raw power no matter how neat your design is and this is where things break. What you need is good design and number crunching code. You have to use the right thing at the right place.

              In fact, the lower-level you go, the harder your life becomes: bugs, memory leaks, unportable code, slower compile times, ABI issues (try exporting C++ code from a dll - nice, huh?). A higher level language will help you write more maintainable code with less bugs and less effort. You can then spend the time you saved optimizing the parts where it actually matters and that's why using a managed language can result in better performance.
              The key is design. If you write messy C code and blaming C for it then you do something wrong. Managed languages are not less error prone. They just remove memory related errors replacing them with higher level problems. But why arguing with somebody who thinks a managed language is the cure-all for everything instead of using the right tool at the right place...

              Comment


              • #82
                if a might add some noob talk here.

                Originally posted by http://www.microsoft.com/express/product/default.aspx

                Visual C#
                A great combination of power and productivity for the Windows developer.

                Visual C# 2008 Express with SP1 is the ideal tool for productively building object-oriented applications for Windows on the .NET Framework.

                Visual C++
                Horsepower with a finer degree of control than other Express Editions.

                Visual C++ 2008 Express with SP1 provides a powerful and flexible development environment for creating native Windows and cool 2D and 3D games.
                on the 2005 edition they recommended both c++ and c# for games. Now seems its just c++.

                But I could be getting a totally different drift then what you guys are on. This is totally beyond me.

                Comment


                • #83
                  Originally posted by Dragonlord View Post
                  The key is design. If you write messy C code and blaming C for it then you do something wrong. Managed languages are not less error prone.
                  Sorry, but that's just delusional. Writing correct, safe C code is significantly more difficult than Ocaml or Python. Writing verifiable code is nigh impossible.

                  They just remove memory related errors replacing them with higher level problems.
                  I'll take higher level problems over memory related errors any day.

                  Memory management is the single largest issue plaguing any sufficiently large program and anything that simplifies it will result in large gains in the long run. C doesn't really offer in the way of memory management. C++ is marginally better with smart pointers and other constructs that can be used to implement semi-automatic reference counting.

                  C#, or any other language with a non-conservative GC, simplifies memory management by an order of magnitude, at the very least. In the common case, you can simply forget about it. For games, you might have to use pools or explicit stack allocations, but that's still simpler than juggling with reference counts.

                  But why arguing with somebody who thinks a managed language is the cure-all for everything instead of using the right tool at the right place...
                  Have you even read my posts? I've said more than once that you should use the right tool for the right job. Surprisingly enough (or not, depending on your background), this could mean using something other than C/C++ in parts of your engine.

                  Unity3d (commercial engine for the Wii, iPhone, Windows, Mac), Second Life (cross-platform title) and several other games embed the Mono runtime directly. Most 3d engines nowadays ship with .Net bindings. The only way you can develop for the XBox is to use C#, unless you are a large, proven game studio. If managed languages were so unsuitable for games as you claim, why are they used to such an extent in actual, shipping games?

                  Besides, you still haven't managed to list even a single concrete example of a hack you have performed in C/C++ but couldn't in C# - which kinda undermines your point.

                  Comment


                  • #84
                    Originally posted by BlackStar View Post
                    Most 3d engines nowadays ship with .Net bindings.
                    M$ and c# for 360. If you couldn't figure that one out your lost.

                    BTW building a game using .net off an engine written in c++ is a whole new ball of wax.

                    Comment


                    • #85
                      Originally posted by L33F3R View Post
                      BTW building a game using .net off an engine written in c++ is a whole new ball of wax.
                      Ear wax, bee wax, car wax, or candle wax?

                      Comment


                      • #86
                        the kind shrek used for his candles

                        Comment


                        • #87
                          Originally posted by L33F3R View Post
                          M$ and c# for 360. If you couldn't figure that one out your lost.
                          Please explain, you are not making any sense. What do Delta3d, Ogre3d, Irrlicht3d, CrystalSpace3d, Unity3d, Torque have to do with Microsoft (or the 360 for that matter)?

                          BTW building a game using .net off an engine written in c++ is a whole new ball of wax.
                          Speaking from experience, or just speculating? Because it is not any more difficult than building a game in Python or Lua using a C++ engine.

                          Guess what language(s) Crysis is written in.

                          Comment


                          • #88
                            Originally posted by BlackStar View Post
                            Please explain, you are not making any sense. What do Delta3d, Ogre3d, Irrlicht3d, CrystalSpace3d, Unity3d, Torque have to do with Microsoft (or the 360 for that matter)?
                            nothing. If i wanted to specify Delta3d, Ogre3d, Irrlicht3d, CrystalSpace3d, Unity3d or Torque would have. I specified c# and the 360, Not the above. Both c# and xbox are Microsoft technologies. If you couldn't achieve that thread of thought im sorry. I think where you are confused is how i poorly organised my post, the quote was in direction of my second line. What i should have done was quote this 1 first.
                            The only way you can develop for the XBox is to use C#, unless you are a large, proven game studio.

                            Originally posted by BlackStar View Post
                            Guess what language(s) Crysis is written in.
                            I know they use lua for NPC scripting. Correct me if im wrong tho.

                            Comment


                            • #89
                              I've been playing Quake Live on Ubuntu Jaunty for two days now, and all I can say is that until now, I had a lot of fun.

                              While it may still be the good old quake 3 arena, the new envelope/package it comes in adds a great deal of motivation to play and explore the competitive richness of quake. A friends manager, stats, awards, and way more finally united in one shiny, perfectly designed place. Another sweet feature I like is how Quake Live evaluates your skill and tells you which server and opponents suit you best. Yep, I like it.
                              Now as much as I love Nexuiz as a game and admire the work behind it, in my very humble opinion Quake Live is superior (if you ignore the fact that Nexuiz is free as in freedom).

                              All in all, I think Quake Live is a cool and clever attempt to revive a legendary game and its unique competitive scene. Id software was so kind and offered Linux users another chance to show off their potential value in the gaming market. I think there's no better opportunity than with having some quick, clean, fun an hour or two on weekends for free.

                              By the way, does anybody know what changes were made to id tech3 for QL? It does look quite better than projects using ioquake3. The new/improved art assets probably contribute a lot to it though...

                              Comment


                              • #90
                                So, is it better then to use a managed programming language instead of a plain one, nowadays?? Or does it depend on the situation? For games specifically. BTW, i cant seem to find other managed ones besides .net/c# and .mono.

                                Comment

                                Working...
                                X