Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 10 Jun 2011
Offline Last Active Sep 30 2013 06:26 AM

Topics I've Started

Finding joy in coding Using Pascal programming language

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:




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


#include "SDL.h"

SDL_Surface *SDL_LoadBMP(const char *file);


Loads a surface from a named Windows BMP file.

Return Value

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

See Also


(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.

Super Heli Land

27 June 2013 - 03:06 PM


Do you remember flying/underwater (submarine) shmup levels of Super Mario Land? Do you miss them?

Well, me too!
That's why I've decided to make Super Heli Land. It is being written using Allegro.pas, which is Pascal binding of popular Allegro programming library.
Currently undergoing heavy development will feature:
- Highscores (with five slots available)
- Infinite gameplay (that's why it has Heli in its name - this derives from all infinite helicopter games you can find on the web)
- Setting custom seed for world generation (for use e.g. in competitions in order to take world generation out of equation and retain only pure skill)
- Ability to reskin game (using Allegro data files - planned for 1.1, initial release won't have this option)
- - Three difficulty modes: Baby Mario (Super easy, with three hitpoints - fireflower descends to shroom which descends to small mario) Marine Pop (Easy, 5 lives instead of usual 3) and Sky Pop (Hard) - each of it features AI mechanics of appropriate SML level except Baby Mario as Baby Mario doesn't star in SML. Planned for 1.1
Most of backend engine stuff is done, only things left are sound/music engine, then I will be able to implement fun stuff, game logic and AI that is.
If I won't pop onto any unexpected obstacle, I may be able to do actual build by the end of next week, maybe in a month.
You can follow current progress in following thread (more often updated than here, here I'll only push updates if something major happens, like release of game or fixing particularly nasty bug): http://www.pascalgamedevelopment.com/showthread.php?21334-Super-Heli-Land and on my online To Do list.
//edit: Following image was taken in-engine:
It has example of chunk generated by engine.
At top-left there is shown how game "sees" chunk.
Blue pixels represent destructible blocks (not shown here as they need to be generated as separate sprites, chunk consist of two big pixel-perfectly collided sprites - one that won't harm player unless it will squish him and other for spikes which harms player).
Red pixels represent spikes.
Brown pixels represent ground and green ones represents indestructible blocks that aren't ground. I may add later on random lines of indestructible blocks with spikes on top of it to make things more interesting.
That number thing on top has no meaning - it is just test of animated sprites (spoiler: they do work).