[JimKurth]

I've read some articles in C about double-buffering and I have a question. I'm programming in QB 4.5, and I'm using an SVGA screen mode (320x200 with 32-bit color = 4 bytes per pixel). Currently, I draw my results to a different bank of video memory and then use an interrupt to swap banks to display. Now this goes fast but is this the same speed as drawing to the screen itself (since it's video memory)?

I understand that drawing to the screen is slow and you can draw to regular memory a LOT faster and just copy the memory data to the screen when you're ready to render the screen.

My question is this: if I use a 3 arrays of 64kB each to hold what I draw, and then use an assembler routine to move the data over to the screen. DO you think it would be faster or slower than writing the way I currently am?

[BadMrBox]

Everything you do with ASM in QB is faster than the regular ways.

Here is some text from QB Cult Magazine about the matter:

http://petesqbsite.com/sections/tutorials/zines/qbcm/1-page_flipping.html

http://petesqbsite.com/sections/tutorials/zines/qbcm/2-get_put.html
_________________

[JimKurth]

i know that any assembly is better than QB or C++ or whatever you want to say since it's the core language. What I'm asking is about the way you write to the screen. I know that putting data in MyArray%(32000) with POKE is faster than putting data on the video screen with POKE. But what I'm asking is if I should make 3 arrays (to grab the full screen of 320x200x32) or use video memory of a bank not shown. Of course whatever routine i have will be in assembly to copy the data to the screen or use an interrupt. But does anyone know from experience if storing 256,000 values across 3 64kB arrays (omitting 4th Byte of color) would be faster than drawing 256,000 values on a video page (not displayed yet) and then switch banks to display it?

[tcaudilllg]

Think about it: you're using direct memory writes to write array information as opposed to using variable assignment. When I realized that this was the norm in high-performance QB programming, I set aside my QB hat for good.

Two years of struggle with that damn compiler... and all of it wasted.

[BadMrBox]

No, I dont really think anyone here can answer you question. The QB hardcorers are an extincted race nowaday's. The only time I ever used hicolor in QB was with Future.Library. I suggest that you try that first. It doesn't work with XP (XMS stuff) but neither does QB very well so that's probably not a problem for you. The only way I had doublebuffering in screen13 was various versions of that CALL ABSOLUTE code (rellib and such). Neither that works well with XP and QB doesn't work at all with Vista (except screen 0 as far as I have heard). What I did was to say goodbye to QB and hello to FB and now I'm doing what you are trying to do without any problems at all.
I can't see why it would be very much faster doing that way thought. Would'nt mind being proved wrong thought :).
_________________

[Nodtveidt]

You are going to have better performance if you utilize two pages. Draw to one, display the other, and toggle back and forth with each successive frame. A triple array is not only horribly wasteful (giving up 192KB of conventional memory!?) but adds overhead that you don't need, especially since you're already using a video card that undoubtedly has more than 1MB of VRAM (if you're using a 32BPP mode, your card is guaranteed to have more than 1MB of VRAM). You'd have the overhead of copying 192KB of data to the video card, which is a rather expensive operation in and of itself, especially considering you've already drawn out the frame beforehand in memory, which will take up some cycles too. Skip the memory mess and just draw directly to VRAM.
_________________
If you play a Microsoft CD backwards you can hear demonic voices. The scary part is that if you play it forwards it installs Windows. - wallace

[JimKurth]

I just wrote a program to time the routines: plotting a pixel on the screen 256,000 times and filling integer arrays totaling 256,000. Using all the same commands and replacing the memory segment/offset, the program told me the timer response after each:
Data Arrays: 0.04 seconds
Video Memory: 0.7 seconds
on a P3 1.4 GHz machine with WinXp running in the background and priority on QB above normal.

These are the averages out of 3 tests each. Each test slightly differed by 0.0x seconds.

Guess this just proves (on my computer at least) that storing data arrays are faster than direct video memory addressing. However, the problem also is that eventually the data array has to be copied over. That is something I have yet to work on with an ASM copy routine (i've seen one on the net) and time that with the data arrays to test if storing in an array and then copying the data over to vram is faster than a regular qb vram POKE routines.

-jim

[Hajo]

Isn't it best to have your sprites/graphics in vram already and use vram-vram blits? Graphics cards have hardware for just that. If you go asm anyways ...

[Bjorn]