PJPlib - 2D Game Library

[pjpdev]

Development can finally begin on PJPlib... To find previous posts on this lib go to http://www.pascalgamedevelopment.com...p?topic=5687.0

My current aim with this is:
- To make use of components compatible with both Lazarus and Delphi.
- Use JEDI-SDL for graphics and controls, and use OpenAL for sound & music.
- Make it cross-platform (currently Windows and Linux)
- To act as an game development introduction for new developers

PJPlib will be making use of an Open Source license, but it can still be used in commercial projects. Thanks to the LGPL (GNU Lesser General Public License).

More posts will be made here at PGD and at the official PJP Dev forums - http://forum.pjpdev.co.za

[Wizard]

Great Please consider making an install file which will install everything automatically...a lot of libraries doesn't have this unDelphix has such an installation feature

[pjpdev]

Great Please consider making an install file which will install everything automatically...a lot of libraries doesn't have this unDelphix has such an installation feature

I actually want to do it this way... Just have to do the research on it first. It would simplify the installation process instead of you sitting for quite some time setting path settings and manually installing components.

[pjpdev]

Grrrrr... This component idea just exploded in my face . So now I'm gonna toy around with components and make a decision if I should actually make use of it or not.

[pjpdev]

I had to drop the component idea. It will still be object orientated by means of derived classes... This is the basic concept I have...

type
 TMyApp1 = class(TPJPApp)
 private
  {Private Declarations}
 public
  {Public Declarations}
  procedure LoadContent(); override;
  procedure GameLoop(); override;
 end;

var
 MyApp1: TMyApp1;

The implementation...

procedure TMyApp1.LoadContent();
begin
 //Place your code here
end;

procedure TMyApp1.GameLoop();
begin
 //Place your code here
end;

This is what I currently have... Using a class derived from the TPJPApp class which makes use of routines that overrides the originals in TPJPApp.

[pstudio]

I like it this way. This is basically the way XNA does it. As long as you have some good documentation/tutorials I don't think any beginners will have trouble using this method

Is GameLoop() both for checking input, update sprites... and render graphics? I would personally go for two methods. One for updating whatever needs updating and one for all the drawing.

[pjpdev]

Is GameLoop() both for checking input, update sprites... and render graphics? I would personally go for two methods. One for updating whatever needs updating and one for all the drawing.

It depends on how the developer utilises it. He could jam all his update routines in there or he could code routines which will be called from within GameLoop()...

A good example:

A basic routine for updating the player...

procedure UpdatePlayer();
begin
 Case App1.KeyDown of
  KEY_UP: sprPlayer.Y := sprPlayer.Y - 1;
  KEY_DOWN: sprPlayer.Y := sprPlayer.Y + 1;
  KEY_LEFT: sprPlayer.X := sprPlayer.X - 1;
  KEY_RIGHT: sprPlayer.X := sprPlayer.X + 1;
 end;
end;

The UpdatePlayer() routine will be called from within GameLoop()...

procedure TApp1.GameLoop();
begin
 UpdatePlayer()
 UpdateEnemies()
 
 //And whatever needs to follow after that...
end;

I also plan on adding a "Best Practices" section to the documentation where recommended methods will be discussed. And the above method will definitely feature in it.

I recently started coding on the lib and the input routines shown is just a basic "sketch" of what I'm trying to achieve...

[pstudio]

Funne you should mention "Best practises" cause this is exactly what I'm concerned about. Usually (all the time) you'll want to seperate your game logic from the drawing of the game. IMO you might as well force the developers to do it this way by having a method for game logic and another method for rendering.
The way it is now, some persons (my self included) may feel a bit lazy and just put it all (logic and rendering) in the GameLoop method as a single chunk. However by having two methods you force them to a bit more organized, and it's not gonna hurt them at all. It's still the same code they'll have to write.

Out of curiosity. How do you plan to handle timing in the lib? I consider this to be a tricky thing to learn for a new developer. How to make the game run at the same speed at all computers.

[pjpdev]

The way it is now, some persons (my self included) may feel a bit lazy and just put it all (logic and rendering) in the GameLoop method as a single chunk. However by having two methods you force them to a bit more organized, and it's not gonna hurt them at all. It's still the same code they'll have to write.

Thats true... I also tend to get lazy sometimes... So I'll split it into two methods, namely Render() and UpdateLogic()... or something like that.

Out of curiosity. How do you plan to handle timing in the lib? I consider this to be a tricky thing to learn for a new developer. How to make the game run at the same speed at all computers.

Timing is always a complicated subject. I seriously need to find a way to make it easier for new developers. Last time I checked, JEDI-SDL's timing methods don't work very well. I don't know if they have fixed that yet. So I'm looking at other alternatives.

I'm gonna do a bit more coding to get more of the basics ready, write the documentation and upload it to SF.net to show you all what I've done so far.

Thanks again for the advice pstudio...

[pjpdev]

Hey I got a few things running with the lib, there is still a lot of work to do before the first release. Here's a list:

- Design a better sprite engine that updates movements, etc...
- Implement the sound system... Not even a single line of code for this yet...
- Get the input system running... This might take a while.
- Figure out how to handle timing...
- Finish the documentation...
- Do a few illistration demos

I also have to get things a bit more organised in the source code, it's a warzone.