Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix issues with GLScissorStack #229

Open
wants to merge 2 commits into
base: GLES2-AnchorCenter
Choose a base branch
from

Conversation

nazgee
Copy link
Contributor

@nazgee nazgee commented Jun 9, 2013

There were two issues in current implementation:

  • original clip rects where kept on stack, instead of clipping intersections
  • when popping topmost frame nothing happened (we should return to previous
    clip intersection)

nazgee and others added 2 commits June 19, 2013 18:24
There were two issues in current implementation:
- original clip rects where kept on stack, instead of clipping intersections
- when popping topmost frame nothing happened (we should return to previous
clip intersection)
This resulted in strange artifacts
@nazgee
Copy link
Contributor Author

nazgee commented Jun 28, 2013

GLScissorStack.java is basically worthless without these fixes.

y = (int) yMin;
width = (int) (xMax - xMin);
height = (int) (yMax - yMin);
final int currentX = this.mScissorStack[this.mScissorStackOffset + GLSCISSOR_X_INDEX];
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this get a value that's not set?

I.e. when the stack has been pushed once, this.mScissorStackOffset is at 4. Any value >= 4 is an uninitialized value, isn't it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it will be fine. Indeed, after glPushScissor is called once this.mScissorStackOffset equals 4, but this is where the scissor rectangle is stashed (indexes 4-7).

After each push this.mScissorStackOffset points to the values that were just stashed, instead to the empty space on stack. As a result, when we new value is pushed (i.e. in case of ClipEntity attached another ClipEntity) we're intersecting it with previously pushed rectangle (perfectly valid value)

Without these fixes code is pushing/popping like this: 123/321
It should be done like this: 123/21X (where X means no scissors)

Regular stack behaviour is of no use here.
After calling glPushScissor n-times and glPopScissor once we do not want to have n-th value, but (n-1)
After calling glPushScissor n-times and then glPopScissor n-times, we do not want to have the first value that was pushed. We want to have an infinite rectangle instead.

Just have a look at "detailed call stack" below. It will be a little bit more apparent.

glPushScissor rectangle A pushed; mScissorStackOffset is 4 after this method; no intersection done, A is saved at 4-7
glPushScissor rectangle B pushed; mScissorStackOffset is 8 after this method; proper intersection taken, B' is saved at 8-11
glPushScissor rectangle C pushed; mScissorStackOffset is 12 after this method; proper intersection taken, C' is saved at 12-15

glPopScissor rectangle B' is restored (it is read from 8-11); mScissorStackOffset is 8 after this method
glPopScissor rectangle A is restored (it is read from 4-7); mScissorStackOffset is 4 after this method
glPopScissor no scissor is used (it is read from 0-3); mScissorStackOffset is 0 after this method; this IS nasty since nothing was pushed at this position, and this value is uninitialized, but bear with me, please.

Right now It works fine, because glDisable will disable scissors anyway, so it does not matter what we read here. We might want to change behaviour to read something explicit, but I have no idea what should be considered as a default/empty/no_clip value for scissors. Maybe (-inf,-inf, inf, inf)? Or (0, 0, 0, 0)? I do not have any idea. If you'll come up with a good no_clip values they should be stored to the bottom (0-3) of the stack in the constructor- it does not matter for ClipEntity, however.

@nazgee
Copy link
Contributor Author

nazgee commented Jul 1, 2013

Do you want me to create an example project for this one?

@nicolasgramlich
Copy link
Owner

Yes, please create a test in https://github.com/nicolasgramlich/AndEngineTest so that we can agree on what this class is supposed to do =) because I think we are thinking a little different.

@nazgee
Copy link
Contributor Author

nazgee commented Jul 1, 2013

Done: nicolasgramlich/AndEngineTest#2
Hope it helps :)

@nazgee
Copy link
Contributor Author

nazgee commented Jul 10, 2013

ping?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants