re-use of View and Controller

Hi all,

I just wanted to write a little blurb about recent work that I've been doing.

All of my games on hUb except for Astro-Creeps (that is UfoPilot 2, Bloom, and Sentry) all currently use really old and deprecated DirectX interfaces for graphics, namely DirectDraw from DirectX version 3.

I know there have been problems on some chipsets and / or OS-versions that MAY have been related to my use of these old interfaces, but I've tended to ignore this... Smiling However, hObbE recently found that Bloom no longer worked on his Vista 64, and more testing revealed that NOTHING except Astro-Creeps worked (which is D3D9).

Bite the bullet time... Sad

I'm hoping however that things will work out really well, as I managed to quickly implement a replacement based on D3D9. All of these games previously used "software rendering" to a 16-bit (R5G6B5) backbuffer and then used DirectDraw to "flip to screen". I managed to replace this by just changing the "flip to screen" parts to a 565-format texture and then a single quad rendered using fixed function DrawIndexedUserPrimitive().

Big kudos to Microsoft for having such a flexible API! Smiling

One interesting thing about all of this is that I have re-used all parts of Model, View, and Controller in these games. Model was already in a separate library in most cases, and I have now moved View and Controller to another library in each case.

All of this works simply because the interface to "rendering" that the games see is still the software backbuffer. This in itself encapsulates everything View-related. From there the choice between DirectDraw3 and Direct3D9 is a question of deployment.

There are now parallel applications for each game, one for DDraw and one for D3D, which simply consist of an Application object that sets everything up, runs the game, and then displays the software backbuffer in an API-specific way.

We are still doing testing, but I fully expect the D3D versions to replace the legacy DDraw versionos currently on hub, hopefully with much better compatibility across the board.

Granted, I'm not really taking advantage of the power of the GPU; I'm still doing all software rendering and just using D3D to actually get the pixels to the screen.

However, I'm very happy to be able to just do a straight port like this without having to rip apart the Controller / View parts of all three apps. Since these apps are basically "finished", this is what I wanted.

I can of course easily envision some nifty "special effects" that could grow out of the new D3D support, for example full screen "grading" by playing with the vertex colors of the full-screen quad in conjunction with different color ops (like the trusty old MOD2X). Another cool thing might be to flash the screen in this way when an explosion occurs.

Oh well, maybe it's better to work on all the new games that are in the pipe instead... Sticking out tongue

users avatar

If nothing else this shows

If nothing else this shows the power of MVC and that if you do it right you can exchange fundamental code pretty easily.

What do you mean by library? You actually make different projects and compile separate static libs or something?

---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)

users avatar

yes, static libs...

That's basically where the re-use comes from.

For example UfoPilot II now consists of the following projects:

static lib: ufopilot_draw
static lib: ufopilot_editor
static lib: ufopilot_megamap
application: up2 (builds the exe currently on hUb)
static lib: up2_model
static lib: up2_vc (the new lib, interfaces with the software rendering stuff)
application: up2d3d (builds the new d3d replacement exe)

The "ufopilot" stuff exists because there are a great number of spinoff projects based in some way on the up2 stuff, and I got tired of making the same changes over and over each time I copied the source.

Other than that, the two exes depend on the following "common" static libraries:

core (very basic stuff, datastructures, networking, etc)
ddvideo (the directdraw stuff)
dxut (the D3D9 stuff)
softdraw (software rendering)
sound (directsound)

I am also currently using a single MSVC solution called ÜberSolution which includes all my "actively maintained" source (52 projects). I have been trying this for about a month and have found that it really helps me both identify opportunities for re-use and also to make sure that I don't break anything (since I have so much common code).

Also I've become somewhat of a namespace-fascist, with each library in its own namespace, which in turn is often encapsulated in the project namespace (so I get things like WinMain referencing bloom::d3d::App...).

/johno
"you can't stop the change"

users avatar

Post new comment

Please solve the math problem above and type in the result. e.g. for 1+1, type 2.
The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <h1> <h2> <h3> <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Textual smileys will be replaced with graphical ones.
  • Images can be added to this post.

More information about formatting options