Archived

This topic is now archived and is closed to further replies.

dg5pt

PR - tutorial - reality - future

Recommended Posts

Hi, I''m currently asking myself if PR is really usable. Let''s see: PR has the ability to start the engine for itself using wintul.c and devdlg.c ... but which game do such a thing? I have badly need of a tutorial ''How to integrate PR in a existing base system''. Don''t say that this would depend on the base system. That wouldn''t be right. To make it clear what I''m thinking about: I don''t want to call hundreds of functions. I just want to have one thing like this: PR_Setting SetSettings() { // set the settings here } PR_Initialize (SetSettings()); and then a PR_Shutdown(); This should be enough. Of course you have to offer a more complicate methode for doing that stuff but you need also a easy one. I would add some things to the PR_Settings struct: unsigned short Resolution_X, Resolution_Y; And there should be the ability to integrate the PR messages into the base system like this: struct MessageReport { unsigned short NoOfMessages; char** Messages; }; MessageReport PR_GetMessages(); PR is currently to incompatible in many aspects (think about file formats). It''s a Win32 engine but there are still bad, old elements of version 2.x in it. To say the truth: PR will have no chanche in the future if there won''t be some changes to a more modular engine. The will have to be a system which allows somebody to add features to the engine without understanding or having the complete source code. PR has to become a real SDK. bye

Share this post


Link to post
Share on other sites
You seem to be mistaken about many parts of power render.

The wintutil source file contains the basic windows setup, any windows application has to do this. Having PR automate this would limit anyone designing power render applications far too much. Chris provides the wintutil to simplify things for people who don''t care to much about the windows setup and for the examples.

The devdlg is for a device selection dialog box. It''s used mainly so that the examples can be run on any computer. The only thing in this file you ever need is the PR_ChooseDDraw_Driver to tell power render what DD rendering device should be used. Everything else is to program the dialog box for choosing the power render settings.

It seems like your complaining about PR because you have to actually know basic windows programming. Don''t be lazy. Learn how to program a basic windows application before you try for a 3D windows application. If you already have a basic windows setup than power render takes almost nothing to integrate into it.

"The will have to be a system which allows somebody to add features to the engine without understanding or having the complete source code."
You will always have to understand the system to add to it. As for adding to PR without the source, this is not really a problem at all (at least I''ve had no problem adding anything).

Don''t expect PR to write your program for you.

Gary

Share this post


Link to post
Share on other sites
I do not agree.

In PR there is no alternative to Winutil.c .

Where is decribed how to init it without using Winutil.c?

It took me nearly two hours until I have modified Winutil.c to make it usable to the base system. That can''t be true.

Share this post


Link to post
Share on other sites
Please don''t blame this guy... he''s right.

It''s under everyone''s eyes: PR is programmed with a very "old" style of programming, and not near also a "good" C programming.

So it''s not difficult to think about the future of PR.
There are many open source projects, well detailed and designed, and also full of features.
They still lack glue code and tools, which PR has, but that''s only a matter of time.
PR has some very nice ideas in it.. but has to be completely redesigned or will become junk code in 1 year.

I _have_ now to use it to substitute my game engine... and it''s a lot of work just trying to dodge all PR clumsyness.

Bye

------------------------------
Stefano ''Panda'' Baraldi
Lead Programmer @ Tremens
www.tremensgames.com
------------------------------

Share this post


Link to post
Share on other sites
Currently PR is the base for a application. You use Winutil.c and then you just can begin to write a game.

This was good a far years ago but today you have a very complex base system. The engine should not be more or less than the networking, AI or game module of a game.

To say it clear: The engine is only a small part of a game and not the kernel. Your engine is too much. We, as the game developer, develops the base system and the hierachy between the modules and not you.
So I have to be able to integrate the engine in nearly any hierary structure. And that is our big problem we''re currently having with PR: it is very, very hard to integrate it in our module hierarchy.

And it is too hard to make modification. Split PR into modules like:

- big file handling (.wgt file format)
- object file handling
- texture file handling
- landscape deformation system
- light system
- sound system
- etc.

And then make clear interfaces between them so that anybody is able to add features (like .zip file support, loading bryce files or .mp3 file format support) to PR using the interfaces you will have defined.

Share this post


Link to post
Share on other sites
I think your problem is you already have part of a game done and you''re trying to incorporate PR into your existing code.

If you''re going to use Power Render, start using it from the beginning and add the rest of the things you want like networking and mp3 playing.

I can''t make interfaces for everything that you want. How are you supposed to add features using the interfaces I designed in C? It''s not like you derive new classes and just tack on more code.

Share this post


Link to post
Share on other sites
You don''t understand. That''s the sense of the complete thing: every part can be replaced.

One axample: I wrote a 2d sound system. Now Creative release their EAX. In the best case you just have to add to the sound system module. The new functions will automaticly get the information which are needed.

You cannot write such a big project like a game if everybody will has to change the code just for adding one feature.

I have to be able to add perhaps mp3 suppoprt not to the game itself but to the music (or sound) module.

I know it isn''t as easy as in C++ but there is no workaround.

And I think you can define a struct with functions in it. You just have to put all in it.

Share this post


Link to post
Share on other sites
Yes, this is one possibility.

Perhaps when you make a .dll file which handels the big file format (.wgt files) I could replace it with one which is able to handle .zip files. I only need to know the interface you defined between this and the other .dll files.

For our system .dll files are not enough, we need many classes. For your engine it might be enough.

To give you an example of our hierarchy structure:

JN_main.dll JNSystem, JNConsole, JNStuff, JNDatabase, JNGame, etc.
/
+-> JN_client.dll JNClient, JNGameClient, JNNetworkClient, PR
/ /
/ v
+->carrier.exe
/ ^
/ /
+-> JN_server.dll JNServer, JNAI, JNGameServer, JNNetworkServer
/ /
/ v
+->carrierds.exe

Share this post


Link to post
Share on other sites
Yes Chris.

We are not saying 100% of PR is bad, absolutely.
We are saying: some areas have been left "old" while you''re adding some cool stuff which don''t get enough focus (you don''t document new functions).
Also, the biggest clumsyness is:

1) old code and new code: you are using D3D now, but there is a lot of old dos code which screws things up and makes them unreadable... please get rid of it and keep d3d!
2) the "hunt for global variables": they should be (D3D ones mainly) be in just one struct.
3) lack of object hierarchy/simple scene graph: that is a rather common feature, linking an object to another. It should be made on the entity interface, not the segment one so you could keep existing interfaces.
Otherwise you end up with very simple object, or have to use character system to do simple things.... or have to roll your own as i''m about to do 8(

4) DLL''s are good as long as the code is HIGLY modular, look at FMOD libraries/dlls they''re well designed.

Ok 8)

------------------------------
Stefano ''Panda'' Baraldi
Lead Programmer @ Tremens
www.tremensgames.com
------------------------------

Share this post


Link to post
Share on other sites
Thought I''d throw in my experience with Power Render to this discussion... I evaluated many different engines and 3D libraries before choosing to buy PR. In working with PR, I''ve found the sample code to be very readable and the engine easy to work with. Compared to other engines, even highly modularized ones like Genesis3D, PR''s learning curve was much less steep.

I purchased PR3 at the beginning of May and am just a couple of weeks from a beta test of my 3D Racing Game. I have modified winutil.c and devdlg.c to load settings from the registry after calling the dialog once, added joystick support (including steering wheel devices), and wrapped my car objects in a class (that wraps the PR_Object and PR_Entity structs) that is subclassed to create a Player-controlled car vs. an AI-controlled car. I did not feel that PR was fighting against me to do any of these things. In fact, for all but the steering wheel support, most of the code was borrowed from various samples.

For the power and usability, PR is the best I''ve found, Object-oriented or otherwise.

Joseph Ellis (daywalker)
Level 13 Studios

Share this post


Link to post
Share on other sites
Chris, here''s my opinion.

I never learned C programming, I started from C++. I can design and write code on C++. I can''t imagine writing huge projects in C. PR doesn''t have to be rewritten in C++ to be good, it has to allow us to easily wrap it into C++, that''s all. Here are my suggestions.

1. Get rid of all the junk macros, dos code, 3dfx code, etc. No need to have that junk if all you''re using is D3D, which isn''t going anywhere any time soon.
2. Document new functions. Your samples are great, the best I''ve seen, but they don''t replace documentation.
3. Try to wrap all global variables into as little structures as possible. Global variables really limit us.
4. Let us write our own "winutil" file. Don''t expect us to define input functions, etc. Expect us to define as little as possible.
5. Redesign PR so it would use subsystems. Make them dll''s, give us the interfaces, so we could change the implementation. In fact, this will help you later on to extend PR.
6. Set up a strict interface update policy. We need to know the exact difference between the newer and older versions. We need to know that when a new version comes out, we won''t have to change any of our code to port it to the new version.

These are the comments I could think of from the top of my head. If anyone has something to add, I''d love to hear it, just to know what I missed.

Share this post


Link to post
Share on other sites
The suggestions made, may be valid, but PR is very good for what it is supposed to do. Alot of this conversation reminds me of all the hype about how Microsoft''s MFC was supposed to save time and headaces of many programmers. Wrong! It has done the oppisite.

For years to come, alot of programmers will think their ad-hoc programming conventions are the best way to do everything, yet they are very mistaken! Leave the code/libs open-ended, as PR has done, and modify for your own personal taste!

Share this post


Link to post
Share on other sites
I think there are several programmers around here not willing
to take the time to investigate the winutil.c file and figure out
that it is easy to make it fit into any code base. I''ve managed to throw most of it away, successfully integrating what was needed into a 30k+ line game development project. I think if anyone out there is serious enough about using PR in a game, they might want to either know Win32 coding really well, or spend some time learning that before jumping in head first.

Share this post


Link to post
Share on other sites
Hi,
I agree with Icestorm, I mean, I know very little about win32 programming, but I can still work out whats going on with winutil.c & devdlg.c and modify these to suit my projects.
The reason Chris has done this (I presume), is to make it easy for those out there who want to write cool 3D stuff, but don''t want to worry about win32 programming, to write their own stuff.

Cheers
Darrin

Share this post


Link to post
Share on other sites
I have changed stuff in both winutil.c and devdlg.c over the years depending on what kind of application I''m writing.

For example the windowed utilities (PRO Edit and new CHR Edit) needed slightly different code for the icon bar along the top.

Screensavers typically don''t need the input functions and can be stripped down.

I don''t plan on wrapping or hiding any of that because then it would require a source code license to modify it. I tucked it all away in a couple of files and most people won''t have to look at it, but unique applications other than the typical full screen 3D type may require some modifications.

I think it''s pretty simple. Devdlg has one function that PR calls to get the device and driver from the user. You can remove this, or add more stuff like a resolution selection. Winutil has the main window creation and input stuff.

Share this post


Link to post
Share on other sites