Pyrogine2D‚Ñ¢ API 2

[Pyrogine]

Hmmm... that's strange. I was able to download ok. Can you please try it again. Any one else having this problem? Please let me know so I can get it sorted out.

Thanks

[chronozphere]

Ah i'm back from school and the download appears to be working

I tried to download it with my laptop during my biology lessons (they were really boring :lol: ). I guess the my bad wireless connection prevented me from finishing my download succesfully.

[Pyrogine]

ahhh (exhaling).... ok good to know.

Thanks

[chronozphere]

I tried the samples and they worked fine.
I like your coding style very much because it's very consistent and structured. I also liked the naming conventions you used.

I have a few questions regarding the API?

1. Why have you flattened your API to a series of exported routines instead of keeping it OOP and use interfaces?

2. Why did you use dynamic linking instead of static linking for your DLL's? (Just curious)

3. I see that you use integer types as resource identifiers. But how do you use them inside your engine? Are they just indices into a resource list (starting 0, 1, 2 etc) or are they more complex?

4. About the application related routines? Do they wrap up the windows messaging system and window control?

5. How come your code looks so neat? :razz: are you using code templates alot?

6. How do you handle errors? I may have overlooked them, but i didn't see any error handling routines?

Can you elaborate a little more on these topics. I could learn from it

Thanx in advance.

[Pyrogine]

Ah good to know it runs ok on your system and thanks for your comments. BTW what is your system configuration?

1. a) The core API (PyroGine) I eventually want to work with more than just Delphi. I found that it's much easier using a consistent API of exported routines. If you look at the event system you will notice I have a aReciever param. This feature allows for a simple way to do callbacks to your class methods in other languages. There is no "of object" in C++ for example so how can this event fire to a method in your c++ class? Well when you define your event you pass the pointer of the class that will handle the event. In the event procedure (a normal procedure with stdcall convention), this object is passed in via the aReciever param, there you can typecast and call the method to handle the event. Simple, elegant and can work with most all modern languages. b) Having a consistent API prevents the need of having to deal with multiple Delphi versions and language inconsistencies. As is I can use the Delphi version that is most efficient for my needs and the end user can take advantage of the API via any Delphi version starting from version 2. Since its in standard API form it is much easier to create additional language bindings. Yes I can use interfaces, but in the case of languages that does not support them the API will still work. Now, you can build on top of this API in your language of choice. You can see this is what I've done in the PyroFramework unit.

2. With dynamic linking you open up all sorts of possibilities. I can check if the DLL exists, if the proper routines are exported and handle errors properly. I can bind to routines based on the OS or environment I'm running in. For example if a certain feature exists or does not exist then I can bind based on this. The idea when coding a system is to keep as much control as you can. With static linking, if the DLL can not be found or the routines does not exist it aborts and you really do not have much control over the process.

3. All the resources created are actual class objects on the back end. This allows me to do OOP even with the API. For example, you can destroy any object with Pyro_Object_Destroy or close any stream with Pyro_Stream_Close because all the classes on the back end are derived from a common base class. At present I support zip archives. If I add a new archive format in the future, Pyro_Archive_OpenFile will continue to work because of the polymorphic interface.

4. On the backend I have a TPyroApplication class that's global, akin to the TApplication class in Delphi. Functionality related to application are handled by it. Also, rather than dealing with a singleton I keep my "only one instance" objects there such as DisplayDevice, RenderDevice and so forth. You will only have one RenderDevice so why go through all the motion of dealing with a singleton? The application class keeps everything nice and neat and when the application object goes away everything it owns goes also so you don't have to worry about cleaning up these resources. I've found that having a single entry/exit point works good. What I mean is when the DLL is loaded the very first time the Application object is created and it persists until the DLL is finally unloaded. This way the resources that need to always be available are guaranteed to be so. Using the unit initialization/finalization does not always work as expected in this case.

5. Thanks. Well, its just years of trial and error and discipline. I like things to be consistent. In my minds eye I see it as reducing the complex to simple or as simple as possible. Simple yet elegant is the theme you will see throughout the SDK. I have a certain way I like to format my code as you see. Over the years I've tried many different ways of formating and what I do currently just seems to work for me.

6. PyroGine supports and uses exception handling. If a routine does not return a result it will most likely generate an exception and most likely will be fatal. You can check YourApplicationName.log for any errors generated during run-time. So the idea is that the routine should a) just work as expected, b) return a result which informs you of the success or failure or c) it's really bad, then log the error, generate an exception,which then gives you a chance to clean up your own code and then terminate the app.

Thanks for the questions. If I can assist please feel free to ask.

[chronozphere]

Thank you for your explanations

My specs are:

AMD 64X2 5400+
2GB Ram
Club3d Geforce 8600GT
Soundblaster Audigy SE
Windows vista ultimate

I have some questions about the things you explained:

3. So all your resource int types are actually pointers to objects in your DLL. Do you perform any kind of validation on a resource pointer when the user passes it to a routine, or will an AV pop up?

6. Are exceptions safe over an App-DLL boundary. I alway's thought that raising an Exception in a DLL and handling/destroying it in the app causes even more trouble. :? And are you sure that exceptions are handled the same way in different languages?

Thanx in advance

[Pyrogine]

Thanks for the specs.

3. There is no validation and if you pass something that is not correct bad things will happen. This is no different than passing a wrong param to any routine. In this case it will either work of fail since it's a pointer to a live object instance.

6. Generally you always have to be careful with this. In my case when the application can not continue Pyro_Abort is called which will clean things up on the back end and the application will terminate. I only use them in this specific way to signal the app that it's about to terminate. This has been a core feature the past 7 years and in the languages that I've tested it works (or seem to work) without issues (Delphi, C++ Builder, MSVC).

[Pyrogine]

Some site updates:

1. Simple Render Target Tutorial
2. Simple Swap Chain Tutorial
3. PyroGine SDK page updated + new screen shots

[Pyrogine]

[=] Updated PyroTestBed to display the startup dialog showing the source code for the running example.

[+] Added DisplayDevice, RenderDevice, Database, Sprite and Entity tutorials.

[+] Added new pfXXX framework units that wrap up the APIs and add new and enhanced features. Now you can access the SDK in a total oop manner.

[-] Removed PyroFramework unit

[F] Fixed a problem where audio would not be restored when app regained focus

Download

Note: I got a few emails about problems downloading. I tweaked some setting. If you have any issues, please let me know ASAP.

Thanks in advance.

[blackvoid]

Do you have more sample programs for the engine? I downloaded and the samples do nothing, just switch to D3D mode.

We are currently working with DelphiX, but the lack of alphabending is a big problem. How easy/hard would it be to convert our code to Pyrogine? We have lots of sprites on the canvas, all animated at the same time and we do only movement and scrolling with a fixed large map.