Speed gain by combining Sprite Displaying and Game Logics?

[Kapslok]

Hello,

I've tried to figure out one basic thing about PureBasic sprites...

In Purebasic, on DirectX or OpenGL, does displaying sprites hang up the CPU until the sprite is displayed?

This would clear one fundamental issue.
Which approach would be better for a cpu-intensive game:

1)
- Do game logics - loop
- Display Sprites - loop
- Flip

Or

2)
- Buffer Sprite coordinates of previous frame - loop (nothing is displayed yet)
- Do game logics and display sprites from the buffer in the same loop
- Flip

[Rook Zimbabwe]

In Purebasic, on DirectX or OpenGL, does displaying sprites hang up the CPU until the sprite is displayed?

in every game ther is issues edpending on the size of the grphics card, its speed and buffer aare key elements on how much it can draw quickly...

if yuo are animating as well as drawing you will ee a slowdown with over 1999 sprites on most low end cards... The medium gade: 3999 is pretty easy. As far as the high end 500+ dollar cards I have no idea as I can't afford one so I don't worry about it.

[Kapslok]

in every game ther is issues edpending on the size of the grphics card, its speed and buffer aare key elements on how much it can draw quickly...

Yes. It seems to come down to that quite often. But ofcourse the program decides how to build up the display etc. I was wondering about the possibility to render sprites and calculate game logics simultaneously, so that when the graphics card is displaying a sprite cpu is already figuring out new stuff to draw... And especially with Sprite3D commands.

[djes]

You could. It is especially needed with network games, as the latency is so big that you have to do calculations in parallel.

[Thorium]

I was wondering about the possibility to render sprites and calculate game logics simultaneously, so that when the graphics card is displaying a sprite cpu is already figuring out new stuff to draw... And especially with Sprite3D commands.

Yes it's possible but can result in lower speed if you do it wrong or if the CPU does not have to do much work anyway. Thats because of the sycronization overhead.
One little trick is to use the time FlipBuffers is waiting for screen syncronization to calculate CPU stuff for the next frame. And thats easy to do with threads without a noticeable overhead.