A bug with the buffer

[Ti64CLi]

There is a bug, in the libs v8.3. For some ICE program, the buffer can't be showed, or it bugs (with SwapDraw for example) :(

[runer112]

Going to need more info. Source code would be good. A minimal example would be better.

EDIT: Also, since this is an ICE program, what version of ICE is this? That may have some effect.

[Ti64CLi]

It's the last version of ICE, the 2.3.0.0. There's an example:

[i]BUFFER
det(0
det(2,0
For(Y,0,10
For(X,0,10
det(31,10,Y*20+10,200
det(32,X*20+10,10,200
End
End
Pause
det(10
det(9,0
det(5,[E]FF
det(2,[E]E0
det(36,120,80,80,80
Pause
det(10
det(9,0
Pause
det(1

He's supposed to first display a 10x10 grid, then a red square, then a 10x10 grid on a red square, but there's only the red square finally :(

[PeterTillema]

How many times did you press the [ENTER] key before exiting the program? 3 times or only once? If so, what was on the screen during the first/second/third Pause?

[Ti64CLi]

I pressed the [ENTER] key three time. Before the first Pause, the grid was displayed, before the second Pause, the red square was displayed, then, before the third and last Pause, only the red square was displayed :(

[HS]I wanted to know, what does LD_IX_IMM(IX_VARIABLES); do in the parse.c file of ICE? Because if I remove it, I can use Asm( to add an icon and a description to my ICE program.[/HS]

[runer112]

I think there's a misunderstanding of how to use SetDraw and SwapDraw.

SetDraw sets the drawing target for all future drawing commands. It has no immediately visible effects.

SwapDraw is meant to be used after fully rendering a frame to the offscreen buffer. It makes this buffer visible onscreen and reclaims the previously onscreen buffer to become the new offscreen drawing buffer.

It seems like you're hoping that you can somehow mix these two to mix two buffer images together, but they cannot do this. They are meant simply for buffering/swapping independently rendered frames.

[Ti64CLi]

My problem isn't really on this code. I have a program, which works with the 2.2 version of ICE (on Cemetech), but doesn't work with the 2.3 :(

[mateoconlechuga]

Then that's an ICE problem.

[Ti64CLi]

No, because I tried the clibraries v8.2 with ICE v2.3 and I don't have this problem. It's only with libraries v8.3 :(

[runer112]

I don't fully understand what the problem is, then. In no version of GraphX has SwapDraw ever had the effect of mixing two buffer images together, so the example program you gave doesn't seem to demonstrate a regression.

[Ti64CLi]

SwapDraw copy the screen to the buffer, and the buffer to the screen. So, in my example, I display something on the screen, then I copy it on the buffer. Then I display something else on the screen, then I copy the buffer on the screen. So, before the last Pause, I should see the grid, and not the red square

[runer112]

Alright, I've finally worked out exactly what's going on here. It's technically a regression... but only because (a) SwapDraw's old documentation was kind of wrong, and (b) you're using SwapDraw in an unintended manner.

I rewrote SwapDraw recently, and in the process, I made it act more like the name implies. Previously, it swapped the offscreen buffer with the onscreen buffer, without regard to which one was the drawing buffer. As this didn't really fit the name, I changed it so it swaps the drawing buffer with the onscreen buffer. But in your case, the drawing and onscreen buffer are the same thing, so now nothing happens.

I don't believe there's ever a good reason to be using SwapDraw if you're not drawing to the offscreen buffer, so I had never considered this case you've found. You should really be drawing to the offscreen buffer if you're using SwapDraw.

[Ti64CLi]

I'm pretty sure it's a libraries bug. Try this program with libraries v8.2 ans v8.3, you should see the difference :

[i]BUFFER
det(0
det(2,0
For(Y,0,10
For(X,0,10
det(31,10,Y*20+10,200
det(32,X*20+10,10,200
End
End
Pause
det(10
det(9,0
det(5,[E]FF
det(2,[E]E0
det(36,120,80,80,80
Pause
det(10
det(9,0
Pause
det(1

[runer112]

I already explained this in my comment from 5 days ago:

Alright, I've finally worked out exactly what's going on here. It's technically a regression... but only because (a) SwapDraw's old documentation was kind of wrong, and (b) you're using SwapDraw in an unintended manner.

I rewrote SwapDraw recently, and in the process, I made it act more like the name implies. Previously, it swapped the offscreen buffer with the onscreen buffer, without regard to which one was the drawing buffer. As this didn't really fit the name, I changed it so it swaps the drawing buffer with the onscreen buffer. But in your case, the drawing and onscreen buffer are the same thing, so now nothing happens.

I don't believe there's ever a good reason to be using SwapDraw if you're not drawing to the offscreen buffer, so I had never considered this case you've found. You should really be drawing to the offscreen buffer if you're using SwapDraw.

You're using SwapDraw in an unintended/unsupported manner, so the fact that its behavior changed is not unexpected. We may elect to "fix" this, but honestly it's good that this "bug" existed because it brought to light the fact that you're not really using buffering correctly.

[Ti64CLi]

Oh, so I have to rewrite my program entirely. Thanks and sorry for my misunderstanding

[runer112]

You don't have to entirely rewrite your program. You should be able to fix your example program by putting det(10 before each Pause and removing all det(9,0 and other det(10 instances.

[Ti64CLi]

Yes thanks, it's working