Jump to content
  • entries
    422
  • comments
    1540
  • views
    490590

Miscellaneous Update

Sign in to follow this  
jollyjeffers

132 views

Got a phone call about an hour ago saying my new PC will be despatched today and should be delivered tomorrow. Yay [grin]


(click to enlarge)


Did a little bit more work on my water renderer but as far as I'm concerned its still both poor looking and incomplete.

The main difference from last time is that I now render a "depth texture" that computes the depth of the water across its surface. This can then be used as an input into the rendering of the actual water effect; the basic idea being that I can use it to scale any effects/contributions based on how deep the water is.

The problem, as shown on the right-hand image is that it now looks like theres "stuff" floating on the surface. Might just be because of the current implementation (just alpha scaled by depth) but it might prove to be a rather ugly artifact.

At a 512x512 texture (shown above) I get a 30fps hit (150fps down to 120fps) due to having to re-render all the geometry. Its a bit of a heavy-weight process but it is completely dynamic. Drop some objects in or change the landscape and the depth texture will update accordingly. I was thinking about having some fish (or a submarine) floating around underwater and this would Just Work(TM).




In other news... I found an unfortunate problem with smart pointers and the DXUT framework [headshake]

You may have noticed that, upon memory leaks, the DXUT framework will pop-up a message saying that the device was released with a non-zero reference count. If you've got the debug runtimes enabled you then get the 1000's and 1000's of lines of stack traces.

Now, if you declare a smart pointer at the global scope it doesn't always seem to get cleaned up before DXUT but it does get cleaned up eventually. Presumably just a characteristic of C/C++ scope rules.

Anyway, DXUT throws up a message complaining about memory leaks when, in truth, there aren't any. This is a bit annoying.

You can always hack away at the DXUT code and remove the warning but thats not so pretty. I've emailed MS about it to see if they have any insight but I doubt theres anything to be done to "solve" this.

In a related bit of profiling it seems that using smart pointers to make a defensive copy of the swap chain (see my original entry for details) is 22% slower. A difference of a whole 6 microseconds [smile]

That is all for now.
Sign in to follow this  


7 Comments


Recommended Comments

I currently calculate the depth by rendering the terrain AS my water plane. Since the terrain VBs have the terrain height, I get easy access to the depth (waterheight - vertexheight). Then I just override the Y component and transform as normal.

While this isn't as flexible as your system, it only takes one pass [smile].

OTOH, I've decided to completely scrap both this system and the terrain renderer and start over [headshake].

Share this comment


Link to comment
Quote:
Now, if you declare a smart pointer at the global scope it doesn't always seem to get cleaned up before DXUT but it does get cleaned up eventually. Presumably just a characteristic of C/C++ scope rules.

Yes, there's nothing dictating a specific order of construction and destruction of global objects, so you always have to be careful with these.

Why are you using a global smart pointer in the first place?

Share this comment


Link to comment
Quote:
Original post by remigius
Care to share why Sirob? It sounded like a useful plan...

I'll be using large areas of water. I've decided to use a frutum shaped plane in front of the camera, that turns with the camera, so you've always got an infinite looking plane ahead of you. Since all water calculations are done relative to world pos, this shouldn't be an issue, but I can't use the terrain's quadtree structure for my water.
As for the terrain, it's designed for a very big patch of terrain, but I've decided to place small islands in my infinite water plane. It doesn't work well with the current design (I must have terrain underwater everywhere, which isn't too smart).
Quote:
Original post by Muhammad Haggag
Why are you using a global smart pointer in the first place?

I blame C style voodoo for that... [lol]

Share this comment


Link to comment
Quote:
While this isn't as flexible as your system, it only takes one pass [smile].
Depending on later results I might well adopt something similar to what you described. I know of a few ways that I can simplify the generation of my depths but all at a loss to the final quality - fairly standard trade-off really!

Quote:
Why are you using a global smart pointer in the first place?
Force of habit when messing around with DXUT-based code. All the samples tend to declare stuff globally so I just got used to doing the same and then I just went and replaced all my "pure" declarations with smart pointers. Then it went bang [headshake].

Maybe I'm just being stupid, but I'm not aware of any other place you can really declare them AND use DXUT. As far as variable declarations go you don't have much concept of lifetime - DXUT just raises callbacks when appropriate and theres little knowledge of what happens in between...

Jack

Share this comment


Link to comment
I've not used the C++ DXUT at all, and have only looked at it a long time ago, so take this with a grain of salt:

Wrap them all in a struct or class, allocate an instance of it when the device is created, and destroy that instance when the device is destroyed. That way, you have to explicitly manage (i.e. allocate and deallocate) a pointer to that global object instead of having to explicitly manage all the COM objects you create.

Share this comment


Link to comment
That is an interesting idea... its still not quite as clean-n-tidy, but I suppose managing one object/pointer is a definite improvement. Would be pretty obvious if you forgot to clear that up - the whole world would collapse [lol]

Cheers,
Jack

Share this comment


Link to comment

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
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!