View Full Version : PGSDK issue.

28-12-2008, 07:09 AM
I downloaded the most recent package, and took a look at the demo executable, it looks like quite a reasonable package.

But I cannot load up the demo testbed in the D2007 IDE (it spits a bunch of errors along the lines of bds.bds line 100, CoreIde.Bpl.SomeJibberish + 33 etc)

There is about 30 lines of similar errors.

Is there anyway to get it to work? Perhaps it was made in an incompatible version of the Delphi IDE.

28-12-2008, 09:21 AM
I am not entirely sure, but I think I might have to re-install Delphi, it looks like it may be the problem.

EDIT: Tried a clean install, but same issue arising.

30-12-2008, 04:57 PM

The oop layer in PGSDK only works with Delphi 2009. If you wish to use a prev version of Delphi you must use the API layer (PyroApi.pas). Sorry about that. There has been changes to TObject that makes working with the oop layer not compatible with prev versions.

I hope to come out with a version that will work across all 32 bit versions of delphi in a consistent oop manager.

The api layer is a flatten version of the oop layer so it works the same (look and feel) just no oop.

feel free to PM and/or email me and I can explain in more detail (beta test new version too if you like).

31-12-2008, 09:48 AM

If you are going to make it possible for it to fully function in the D2007 IDE, I will wait till then. It's much easier to work with visual components than plithering about through source files (unless there is good documentation).

While I am here, how realistic is it to create say an RPG Engine using this package (either now or in the future), 2D of course.

I wanted to create a 1024x768 Windowed and Full screen RPG game, I was not going to bother with scrolling and such at first, but rather the main window being the map and if the map is bigger it just loads up like entering or leaving a location etc.

I was going to use Asphyre and I still muck about with it, but there is Main package, SpriteEngine by a user and things like this and the versions mismatch and make it difficult, that and it is a runtime package.

It's a bit confusing basically lol.

31-12-2008, 02:10 PM

If you mean be a component, I don't mean this. It's never been a component. I just mean this:

1. Right now there is full oop support with d2009. You can take a class from one of the units and fully extend it on the client side. The con: there is a tight run-time agreement that must exist on both the client side and the dll side. The end result is that in D2007 for example, you can not access the classes in oop fashion because TObject has changed to the point where it's no longer possible.

2. To make this work with basically all versions of Delphi, there will be an API layer of which classes will wrap this layer on the client side. Thus in theory any 32 bit version of Delphi will work in oop. The con: some of the higher order features of d2009 version will not work. For example, you will not able to derived your own version of TPyroStream class and then be able to pass this new version to any existing TPyroStream used through the SDK. You will however be able to advantage of the TPyroMemory interface and wrap this to derive your own stream type for example. The API layer is there now, you can easily start wrapping the oop layer if you want to get started NOW (See PyroApi.pas).

3. PGSDK has lots of great features to assist you to make basically any type of 2D game. It's what I consider a game application framework in that you have all the low-level features plus high level features to make gamedev much easier. For example you have graphics, audio, sprites, actors, ai, basic networking (that can persist objects) all out of the box. If youou want to work at the low level, use the api, if you want to work at a higher level use the classes. It's all there. The goal for me in making PGSDK is to have a robust engine that allowed me to make 3-4 smaller games per year before a major update. To do this I need all the features or the basic framework to code in the features needed.

4. No docs, sorry, but feel free to contact any time and I can help you. I know I have to make good docs and that has always been a problem with time and such. But as you work with it you will find that it's easy to use once you get use to how it works.

31-12-2008, 10:57 PM
True that.

Full documentation does not need to be rushed, especially when it is likely updated too often to keep up.

But some starter information or examples (I can't remember if there were any or not), would help more to get started and give people an idea of how to work with it.

I will have to give it a try some time soon and see if it can do what I need. I like the idea of being able to use the DLL directly also.

01-01-2009, 03:58 PM
The TestBed example shows:

* The StartupDialog
* Setting program options via INI and the TPyroConfigFile class. This class lets you define variables that will automatically save/load to the INI.
* The lightweight TestCase framework. You can use this for quick prototyping
* Loading resources from an archive (standard zip file)
* Music (with streaming from within an archive)
* Entities
* Swap chains
* PolyPoint collision detection
* Multiple viewports
* Rendering textures & images including tiling textures across the viewport
* Basic physics example
* And more..

Yes, the goal was to be able to take standard win32 DLL and be able to use and extend the classes like you can do with packages (Too much overhead with packages at least for gamedev). I got it to work but because the way Delphi is designed in order for it to work without hacks and undocumented calls, TObject must be the same on both the DLL side and the client side. In order for it to work with each version of Delphi you would have to have to compile a DLL for each version of Delphi. I started to do this, but it was too much work in maint. So for now full oop is only for D2009 with support for other version via the API layer.