• Advertisement

Archived

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

Point Sprite included example in DX SDK.

This topic is 5096 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In the point sprite example of the DX SDK, a vertex buffer is created 2048 particles big when the program will only be using 512. Thats 4x the size. The app then fills the buffer full of 512 particles using D3D_NOOVERWRITE. It then moves the current buffer position ahead 512 vertices. It does this for 3 frames, and on the 4th frame, it switches to D3D_DISCARD and resets the buffer position to 0. Does this type of swapping create an altogether faster drawing app at the cost of a more memory intensive one? Or is there another purpose I'm missing? [edited by - GroZZleR on March 6, 2004 8:50:20 PM]

Share this post


Link to post
Share on other sites
Advertisement
I''ve been looking at the point sprite example and have also be wondering about the swapping that is does with the vertex buffer. Does anyone know if this method is worth while?

Share this post


Link to post
Share on other sites
It should, at least in theory
I saw lots of programming documents which propose that kind of rendering, not only for point sprites, but always when using dynamic buffers. I didn`t test it really so I can`t say is it worth it, but if you can implement it, it surely won`t hurt...

Share this post


Link to post
Share on other sites
I''m still a newbie at DirectX but I think I know the reasoning behind this so i''m gonna have an attempt at answering it...

If you transfer all 2048 particles at once directx waits until all have been transferred and then starts to render them. Therefore the Graphics card is idle while you copy all of the particles in.

If you do it the way you described you can start rendering the first 512 particles while you put the next 512 particles into the vertex buffer and so on... thus ensuring the graphics card isn''t just sitting there doing nothing waiting for you to finsih.

I believe thats the reasoning behind it...

Hope that helps



Mrs Kensington http://www.mikeditum.co.uk

Share this post


Link to post
Share on other sites
Hrm...

As far as I know, it only renders 512 at a time though, and it seems to just be mimicing the data from before. I understand your theory though, but I believe they''re only using 512 at a time regardless of the size of the VB.

Share this post


Link to post
Share on other sites
quote:

If you transfer all 2048 particles at once directx waits until all have been transferred and then starts to render them. Therefore the Graphics card is idle while you copy all of the particles in.

If you do it the way you described you can start rendering the first 512 particles while you put the next 512 particles into the vertex buffer and so on... thus ensuring the graphics card isn''t just sitting there doing nothing waiting for you to finsih.

I believe thats the reasoning behind it...



Yep, you got it.

If you just stick it all into the vertex buffer and render it, you CPU does a lot of work while your video card does nothing. This is bad, as it wastes valuble time your video card can use to render. This way, you are rendering 512 of them while your CPU is preparing the next 512. The end result is that your video card is doing nothing for the first 512, but is rendering while the CPU is preparing the rest of them. Your video card will get the rendering done in less time so your frame rate will increase.

Share this post


Link to post
Share on other sites
quote:
Original post by GroZZleR
Hrm...

As far as I know, it only renders 512 at a time though, and it seems to just be mimicing the data from before. I understand your theory though, but I believe they're only using 512 at a time regardless of the size of the VB.


I've had a look at the SDK Sample and I think I've got it sorted in my head...

(This is all in CPointSystem's Render method in PointSprites.cpp) It renders each sprite a couple of times but I shall ignore that here...

1. It first of all locks the first m_dwFlush (in the sample 512) vertices of the vertex buffer (Line 1043)

2. It then goes through filling the vertex buffer with particles keeping track of the number of particles added (Lines 1051 to 1078, and the first part of the if on 1080)

3. When the number of particles reaches m_dwFlush (in the sample 512) It..
    a) Unlocks the vertex buffer (1085)
    b) Sends the particles in the VB to the GFX Card to render... (1087)
    c) Increments the offset into the vertex buffer by m_dwFlush (dealing with wrapping round) (1094 to 1097)
    d) Locks the next 512 vertices, clearing the VB if its wrapped round (1099)
    e) Resets the number of particles to render variable to 0

4. It then goes back to 2 and stays in this loop until all of the particles have been added to the VB

5. It then sends any particles that haven't been rendered yet to the GFX card (1115 to 1122)

Doing it this way it renders the particles in batches of 512 thus keeping the Graphics card busy while the next load of particles are being added in.

Hopefully that helps... it makes sense in my mind but who knows what that means




Mrs Kensington http://www.mikeditum.co.uk

[edited by - mrs kensington on March 10, 2004 4:40:54 AM]

Share this post


Link to post
Share on other sites

  • Advertisement