Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualDarkhog

Posted 28 June 2013 - 06:37 PM

Don't get me wrong - C/C++ is great and has many uses, but using it can be sometimes a chore.

 

Why? Because of pointer hell. In C/C++ pointers are used literally everywhere, even where passing by value would be enough. Like here:

int WINAPI MessageBox(
  _In_opt_  HWND hWnd,
  _In_opt_  LPCTSTR lpText,
  _In_opt_  LPCTSTR lpCaption,
  _In_      UINT uType
);

That's right. This is WinAPI's message box function. LPCTSTR in case you don't have WinAPI experience, is pointer to string. WTF? This function doesn't even NEED pointer to where string is stored as it doesn't change it. It only show standard Windows message box.

 

Such quirks aren't even specific to WinAPI (which, admittedly, is poorly written). Most of C/C++ APIs I had even "pleasure" to work with are littered with things like that. Like Qt:

void QMessageBox::about(QWidget * parent, const QString & title, const QString & text)

Same sin as in case of WinAPI.

 

But we want to make games, don't we? Let look into some game API, say, SDL:

 

 

 

SDL_LoadBMP
Name SDL_LoadBMP -- Load a Windows BMP file into an SDL_Surface.
Synopsis

 

#include "SDL.h"

SDL_Surface *SDL_LoadBMP(const char *file);

Description

Loads a surface from a named Windows BMP file.

Return Value

Returns the new surface, or NULL if there was an error.


See Also

SDL_SaveBMP

(from http://www.libsdl.org/docs/html/sdlloadbmp.html)

Why it even returns pointer, when returning value (SDL surface) would be enough?

 

Such approach results in things like memory leaks and other sort of "fun" stuff. Pointers should be only used when you need write access to variable you are passing and can't afford working on a copy (passing by value).

 

Finding joy

Above thing which I've dubbed "Pointer Hell" was thing that made me chose Pascal (Object Pascal specifically) as language of choice when developing games. In Pascal you only use pointers when you actually need them. Which is almost never as most things you can do without touching them.

 

Unless, of course, you are interfacing with some c/c++ library, like I'm doing with Allegro.

 

Pascal also provide syntax that any human (or non- human ;)) being who happen to know English can read and in many cases comments aren't even needed to understand what code does. Unless you reading code from some obfuscation contest or written by first-time programmer.

 

Also when coding in Pascal you can really enjoy this. You don't have to worry about memory leaks and for the most part logic bugs are easy to fix. There is also helpful community related to game making ready to help when you happen to have some issues. It's mostly because of them I could progress so far when writing Super Heli Land.

 

Notable games and software written with Pascal:

 

- Original Jazz Jackrabbit (Turbo Pascal 7.0)

- RPG Maker 2003 (Delphi, not sure about version)

- Resource Hacker

- BlockCAD (Delphi)

- Hedgewars, the Worms clone - freepascal (engine, rendering) plus some c++ bits mainly because there was no good Qt bindings for Pascal when project was started.

- This.


#1Darkhog

Posted 28 June 2013 - 04:45 PM

Don't get me wrong - C/C++ is great and has many uses, but using it can be sometimes a chore.

 

Why? Because of pointer hell. In C/C++ pointers are used literally everywhere, even where passing by value would be enough. Like here:

int WINAPI MessageBox(
  _In_opt_  HWND hWnd,
  _In_opt_  LPCTSTR lpText,
  _In_opt_  LPCTSTR lpCaption,
  _In_      UINT uType
);

That's right. This is WinAPI's message box function. LPCTSTR in case you don't have WinAPI experience, is pointer to string. WTF? This function doesn't even NEED pointer to where string is stored as it doesn't change it. It only show standard Windows message box.

 

Such quirks aren't even specific to WinAPI (which, admittedly, is poorly written). Most of C/C++ APIs I had even "pleasure" to work with are littered with things like that. Like Qt:

void QMessageBox::about(QWidget * parent, const QString & title, const QString & text)

Same sin as in case of WinAPI.

 

But we want to make games, don't we? Let look into some game API, say, SDL:

 

 

 

SDL_LoadBMP
NameSDL_LoadBMP -- Load a Windows BMP file into an SDL_Surface.
Synopsis

 

#include "SDL.h"

SDL_Surface *SDL_LoadBMP(const char *file);

Description

Loads a surface from a named Windows BMP file.

Return Value

Returns the new surface, or NULL if there was an error.


See Also

SDL_SaveBMP

(from http://www.libsdl.org/docs/html/sdlloadbmp.html)

Why it even returns pointer, when returning value (SDL surface) would be enough?

 

Such approach results in things like memory leaks and other sort of "fun" stuff. Pointers should be only used when you need write access to variable you are passing and can't afford working on a copy (passing by value).

 

Finding joy

Above thing which I've dubbed "Pointer Hell" was thing that made me chose Pascal (Object Pascal specifically) as language of choice when developing games. In Pascal you only use pointers when you actually need them. Which is almost never as most things you can do without touching them.

 

Unless, of course, you are interfacing with some c/c++ library, like I'm doing with Allegro.

 

Pascal also provide syntax that any human (or non- human ;)) being who happen to know English can read and in many cases comments aren't even needed to understand what code does. Unless you reading code from some obfuscation contest or written by first-time programmer.

 

Also when coding in Pascal you can really enjoy this. You don't have to worry about memory leaks and for the most part logic bugs are easy to fix. There is also helpful community related to game making ready to help when you happen to have some issues. It's mostly because of them I could progress so far when writing Super Heli Land.

 

Notable games and software written with Pascal:

 

- Original Jazz Jackrabbit (Turbo Pascal 7.0)

- RPG Maker 2003 (Delphi, not sure about version)

- Resource Hacker

- BlockCAD (Delphi)

- This.


PARTNERS