Page 1 of 3 123 LastLast
Results 1 to 10 of 26

Thread: New language features have a place in game code?

  1. #1
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25

    Question New language features have a place in game code?

    Hey everyone, I'm just wondering with all these new language features appearing in the new Oxygene language and future versions of Delphi and other Object Pascal based tools, is there a place or a purpose for them in game code? What types of game engine systems or features could be enhanced by using these types of language features in your code?

    Off-hand here is a short list of the newer features I can think of: (in no intended order of importance or indication of usefulness)
    • Generics
    • Duck Typing
    • Oxygene's await keyword
    • nested classes
    • for .. in loops
    • final methods


    What are your thoughts or experiences with any of these or other new language features? Did I miss any major ones?
    Jason McMillen
    Pascal Game Development
    Co-Founder





  2. #2
    Generics are obviusly very useful for saving the trouble of copy-pasting code that is exactly the same in function, but intended to be used with different types. Operator overloading allows to write shorter code (although sometimes the overloads can be vague and not so obvious if one looks at the code after a long time).

  3. #3
    Operator overloading and "for...in" loops are huge space/time savers and help to improve the readability of your code.

    However, I would advise to stay away from using generics. In most situations they are time savers on short-term, but they actually hurt the readability of the code and indirectly reduce non-functional quality attributes of the software you are working on. I personally avoid them like a plague.

    Quote Originally Posted by Super Vegeta View Post
    Generics are obviusly very useful for saving the trouble of copy-pasting code that is exactly the same in function, but intended to be used with different types.
    I don't agree. You can avoid copy-pasting by using refactoring properly, with the common techniques like class inheritance among others. Using generics is mostly a quick and dirty approach to a problem, so that you can quickly achieve something without proper architectural design and ignoring any existing software design patterns that may apply.

    I think generics were introduced to Pascal languages for marketing reasons, they were not really necessary. This is a similar issue to exceptions. I also rarely use exceptions myself and consider them unnecessary, similar to Joel Spolsky's opinion (he's co-founder of Stack Overflow).

  4. #4
    Of modern language features only generics are really useful.
    As it is really boring to copy/paste the same code just to create a hash map with different key/value types.
    From the other side, in Delphi generics are achievable without language support - there is an include-based approach compatible with older versions of Delphi and FreePascal.
    So I wrote a library with generic collections and algorithms based on the approach and have no need in a language support of generics.

  5. #5
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    Sorry for the potentially ignorant question, but how much of that is/will be supported by FPC?
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  6. #6
    Generics are very useful for containers, they help maintain strong typing and reduce the number of casts. Outside of that, they can get a bit obtuse (IME). The built-in Delphi generics are quite inefficient though, so those are probably not a good idea in game code (not to mention the compiler isn't very good with them, and you can end up with weird internal compiler errors or huge executables).
    For simple containers, they compete with arrays (dynamic or not), which typically have less overhead, and can be just as strongly-typed. So for games, I would say they're good outside performance-critical code, and the with caution.

    Duck-typing I'm not a fan of, it's just too easy to let a dragon that can quack & walk into the pond (with devastating outcome).
    Also many terms (in human language) are just too ambiguous, a good deal of programming is about removing the ambiguity to express what needs to be done clearly.

    Await and asynchronicity are both useful and impractical for games, useful because it means you can use multi-core more easily, and impractical because unless you're on a console, you can't assume a certain number of cores are at your disposal, nor how much time it'll take to do something. So they can only be used for stuff peripheral to the game (like pre-loading textures, reducing wait between levels, etc.), but can't be used for anything time or frame-critical (unless you bump the requirements to things like "quad-core CPU required and I mean a real quad-core not just a dual-core with hyperthreading")

    Nested classes, well the only practical use seems to be for enumerators, apart that, they just get too verbose and too specific.

    for..in loops, they save some typing and improve clarity, I use them whenever I can

    final methods & sealed classes: I use them mostly to guarantee a class isn't subclassed, which means you can do "if obj.ClassType=TSealedClass" rather than having to use "in". It's a micro-optimizations though, and may not be relevant in general, but it can have its uses.

    anonymous methods: can be quite useful and reasonably efficient, though in the case of Delphi, be wary of compiler internal errors.

  7. #7
    Hmmm, most of these new features seems complete new to me.
    Generics must be the C++ equivelant for function templates, right? You can save some typing, but nothing more. Really, besides the max and min functions where else can I use it? I'd prefer to rewrite some code.
    Oxygene's await keyword and nested classes...., well, I don't know what are these, really!
    For..in loops. Come on, this is javascript, not pascal! Besides I'm trying not to use for loops at all, instead I like writing while loops using for the exit-loop-contition some pointer checking (perhaps a bit faster code).
    final methods: Unfortunatelly I don't know what's this.

    Even when I'm using forms, not only in games, I'm trying to stay 'procedural", without using objects/classes. Also as an old school programmer I 'm not used to some newer features. The only, let's say, year 2000 era feature I'm using are the optional parameters with default values.

  8. #8
    I never used any new feature since delphi 7. Some time ago I migrated some customer applications to delphi 2007, just to improve UI with that fancy glass stuff on windows 7. I stay away from generics, anonymous and unicode, we don't need that. For loops, I like while/repeat ones 'cause they are flexible, you define elegantly when they must exit and didn't breaks readability as the break clause in for loops, it's ugly as using goto... yuck!

  9. #9
    Quote Originally Posted by Jimmy Valavanis View Post
    Even when I'm using forms, not only in games, I'm trying to stay 'procedural", without using objects/classes. Also as an old school programmer I 'm not used to some newer features. The only, let's say, year 2000 era feature I'm using are the optional parameters with default values.
    Do you know that each form, control, component is objec/class? So while you think that you don't work with objects/classes you are. The only difference is that you only use existing predefined classes and don't define new ones by yourself.
    But object/classes are whats making object orineted programing language to what they are. When used properly they can be verry powerful.
    For instance. Lets say that you have your own class defining some ingame character. This class can contain various properties and even methods.
    Properties act similar to variables but the main difference is that you can assign special so caled getter/setter methods to each property. In setter method you can for instance validate that new value of this property is valid before you change it to a new value. In getter mehod you can even calculate the result from several different variables. The best thing is that all this is being done automaticly.
    Methods can be used for executing some special parts of code wich is related to this class.

    For more info on classes I recomend reading:
    http://delphi.about.com/od/oopindelp...elphi_oop4.htm
    http://delphi.about.com/od/oopindelp...elphi_oop6.htm

    Or even better go trough all Object oriented tutorials staring with
    http://delphi.about.com/od/oopindelp...elphi_oop1.htm

  10. #10
    Quote Originally Posted by SilverWarior View Post
    Do you know that each form, control, component is objec/class? So while you think that you don't work with objects/classes you are. The only difference is that you only use existing predefined classes and don't define new ones by yourself.
    Obviously, if someone uses forms and components is working with classes. But I prefer to write the core/functionality of each program without using oo and just use the VCL for the user interface. It's, let's say, my personal way of programming. In most cases when I'm using classes is when I have to make a component, in fact I'm still using components I've made a long-long time ago, some of them are still in my old page (http://www.geocities.ws/jimmyvalavan...phi/index.html). But as I said, I prefer "procedural" programming.

    Quote Originally Posted by SilverWarior View Post
    But object/classes are whats making object orineted programing language to what they are. When used properly they can be verry powerful.
    Sure, but on the other hand there is nothing you can do using classes that can not be done procedurally. I'm talking on problem solving / solution aspect.

    Quote Originally Posted by SilverWarior View Post
    For instance. Lets say that you have your own class defining some ingame character. This class can contain various properties and even methods.
    Properties act similar to variables but the main difference is that you can assign special so caled getter/setter methods to each property. In setter method you can for instance validate that new value of this property is valid before you change it to a new value. In getter mehod you can even calculate the result from several different variables. The best thing is that all this is being done automaticly.
    Methods can be used for executing some special parts of code wich is related to this class.
    Data validation can be done as well as without using classes. An, well, nothing is being done automaticaly, you still have to write the code for the class. Instead of writting a procedure that evaluates a result from different variables you write the "getter" function. Instead of writting a "setter" funcion for your class, you write a validation function before setting the data. It's the same thing.

    Now imagine that you have a few hundred available fuctions to define the behaviour of you character. What will you do? Write a class with hundreds of member functions, all in the same unit, having a 1MB source code unit, or using functions and split the source code into more units? From my point of view the second solution seems easier to maintain.

Page 1 of 3 123 LastLast

Bookmarks

Posting Permissions

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