It wouldn't make sense for those pointers to change, because it would imply the Present call could somehow magically change your local variables, which isn't usually possible in C++.

What normally happens in situations like this is that the meaning of the buffers is being changed internally, and DirectX changes which buffers it will be reading from and displaying next.

Backbuffers are never displayed on-screen - that is the front buffer. DX9 doesn't give you direct front buffer access, I believe.

the best way to understand it is that

GetBackBuffer( ) returns the backbuffer which was set at that location, it doesn't return the back buffer which Present( ) has switched to.

Yes back buffers and the front buffer pointers are switched in a circular buffer manner whenever you call Present( ), here is an analogous bit of pseudo DX9 code that i've just knocked up for your enlightenement ?

//pseudo
const int num = 3
byte* buffers[num]
byte* fb = buffers[0]  // lets say fb is aaaaaaa
byte* b1 = buffers[1] // lets say b1 is fffffff
byte* b2 = buffers[2] // lets say b2 is ccccccc
int n = 0

map<int, byte*> my_bbuffers

void init_back_buffer(slot, buf)
{
 my_bbuffers[slot] = buf
}

byte* get_back_buffer(slot)
{
 return my_buffers[slot]
}

byte* get_front_buffer()
{ 
  byte* new_buffer = new byte[ .... ]
 // copy contents of fb (depending on u called get_fron_buffer, 
 // this is a copy of what is fb is currently pointing to)
  memcpy(new_buffer, fb, ...) 
  return new_buffer 
}

//  if n == 0 then fb_idx = 0, b1_idx = 1, b2_idx = 2
//  if n == 1 then fb_idx = 1, b1_idx = 2, b2_idx = 0
//  if n == 2 then fb_idx = 2, b1_idx = 0, b2_idx = 1
// etc...
// present will switch pointers everytime it is called
present()
{
	n++
 	fb_idx = (n + 0) % num
 	b1_idx = (n + 1) % num
 	b2_idx = (n + 2) % num
 	
  fb = buffers[fb_idx]  // fb could now be fffffff
  b1 = buffers[b1_idx]  // b1 would then be ccccccc
  b2 = buffers[b2_idx]  // b2 would then be aaaaaaa
  
  API will now do its magic to display fffffff contents onscreen
}

main()
{
  init_back_buffer(0, b1) // this is when b1 is ffffff
  init_back_buffer(1, b2) // this is when b2 is cccccc
  loop
  {
  	get_back_buffer(0) // will always return fffffff 
  	get_back_buffer(1) // will always return ccccccc
  	
  	present() // switch pointers
  }
}

so u see, even though b1 and b2 are changing in Present ( ), the internal map remembers which one was set on each back buffer location. That is why it doesn't change when u call GetBackBuffer( )

Also do not confuse “flip”'s meaning in the olden days which literally changed the Video Graphic Memory Addresses which were used to display graphics on, for example VGA address 0xA000 would be flipped with 0xA100 to show what is on this new memory address.

DirectX 9 uses the word “flip” to mean present / show and not as flip Video Graphic Addresses etc…

Hope this helps a bit ?

Have fun ?

ah lovely, it runs -lol- i wrote it from the top of my head untested ?

nevertheless, the so-called “switch” of pointers is not an actual pointer switch per say ?; in this code above i was only showing u the principle of such a switch:

In reality, the switch is, as far as I remember, a DMA controlled memory-to-memory buffer copy (so the CPU can initiate it, but will not actually do the copy), this can take place, for example, during the monitor's vertical retrace event (vsync). This means that the graphics card can also initiate the copy and run the DMA copy when it is told to by this ^^^^ algorithm about what to copy, from where and where to. So the actual memory addresses never change.

For the DMA controller to do the copying, it needs those memory addresses to remain set, so when we say that the backbuffer2 is now the FB, we're saying that the DMA controller will copy from bbuffer2 contents from its memory address to fbuffer's memory address space., etc… so the data at those locations WILL change, but not the memory addresses themselves ?

Today it gets even more complicated -lol- with modern cards, there's all sorts of controllers, they may have more than just DMA controller, RDMA, GPUDirect or whatnot … but the long shot of it all is that at the application level your memory addresses are unchanged, but under the bonnet (in the API, or in the driver or on the card itself) all these memory locations interchange data via these algorithms and controllers.

And when vsync is not enabled, the story changes slightly, but I leave it as an exercise for u to work out ?

Anyway, I hope this clarifies it a bit more… .

Don't try to fix this example without access to some DMA ?

That's it … all the best ?