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

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.

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!

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.

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