Sign in to follow this  
Absolution

A little bit about design

Recommended Posts

I'm designing a model viewer type application (standard 4 view split window) in MFC. I was wondering how people approach modeling this viewer to allow for different renderer APIs to be used. I.e., I want to be able to use OpenGL, DirectX, software, WinAPI, etc... with as little hassle as possible. What I've been thinking about is having an abstract view interface, which I can then use to define any kind of view of the document data that I like. These views will then use a display interface to do the drawing. This display interface will basically be implemented for each type of renderer I want to use. The appropriate display implementation will then be supplied by a factory class, which will select the appropriate implementation depending on the compatibility and user specifications. In this way, I insulate my view classes from the display and can make changes to my display functions for each renderer without recompiling the views. I can also add as many display implementations as I like with little hassle. How have you implemented this design in the past? Also, I know MFC is a bit old school now, but I'm familiar with it. What are you guys using these days for tool/viewer design?

Share this post


Link to post
Share on other sites
Quote:

Also, I know MFC is a bit old school now, but I'm familiar with it. What are you guys using these days for tool/viewer design?

C# and Windows Forms.

Quote:

I want to be able to use OpenGL, DirectX, software, WinAPI, etc... with as little hassle as possible.

Ew, why? You're making a model viewer, not a rendering API abstraction. Why not just pick one API and use that? It's a huge waste of time to support others.

Share this post


Link to post
Share on other sites
If you're making a Windows only application (considering MFC), then you'll use DirectX. That one will provide all the 3D support abstractions you'll need.

If you're making a portable application, then you're in a world of hurt in the first place. Java would be your best bet here using one of OpenGL APIs, but even there there's plenty of problems.

Share this post


Link to post
Share on other sites
Quote:
Ew, why? You're making a model viewer, not a rendering API abstraction. Why not just pick one API and use that? It's a huge waste of time to support others.


Because it won't be just for me and I have no guarantees that everybody will have the same rendering API installed or the appropriate version.

Share this post


Link to post
Share on other sites
Quote:

I have no guarantees that everybody will have the same rendering API installed or the appropriate version.


Install it for them, then. This is what pretty much all sane software does. You don't write software that can handle any possible combination of installed dependencies. You write software that uses dependencies, and you either ship the dependency installers with your product (ideal) or you make the user install them manually (less than idea).

You're basically trying to write code in a situation where you are assuming the user might not have any dependencies installed, and that you will not ship dependencies, for whatever reason. This means you will be reinventing everything you cannot statically link (and if you're avoiding shipping the dependencies due to file size, you can't statically link). I mean, damn, what if they don't have an OS installed?

Any major software package that depends on a rendering API will make you install the runtimes for that API; the only viable exceptions to this are products that had legacy support for other APIs (e.g., software rendering) prior to the existence of a newer API (e.g., Direct3D). But your application is not legacy.

Just pick an API, use it, and ship the runtime installers. Otherwise you will never finish your model viewer.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this