NewsForumsCodeLogsGallerySpecsSearch

Scissoring problem

BlitzMax Forums/BlitzMax Programming/Scissoring problem

N(Posted 2004) [#1]
I'm planning on using scissoring (GL thingy, if you don't know what it is then a quick explanation is that it basically restricts rendering to a rectangular portion of the screen) for input boxes (e.g., list/combo/text/treeview/etc. boxes) so that I can render without worrying about crap like the text going past borders or drawing outside boxes and such.

Anyhow, problem I'm having is how to use it.

Basically, this doesn't work the way I expect it to:

glEnable(GL_SCISSOR_TEST)
glScissor(X,Y,Width,Height)
..draw stuff..


Where width and height would be at the start of the portion where the window is being drawn to, it doesn't look like it's restricting drawing to that part of the window. It looks like like it's making it wider and taller and such than it should be.

So if anyone knows how to use scissoring properly, I'd be grateful if they could explain it to me.

Thanks in advance.


skidracer(Posted 2004) [#2]
You mean like the SetViewPort command does?


N(Posted 2004) [#3]
skid: Are you referring to glViewport or something home-brewed? If it's some part of Max2D, I'd prefer to avoid it because of possible changes at a later date (and in case anyone decides to mess with the modules themselves).

Only parts of Max2D I use, at the moment, are the ones that I can't see anyone rewriting ('cept DrawText, which needed optional alignment arguments (something I already added, obviously)).

Anyhow, your question makes not one bit of sense to me.


John Pickford(Posted 2004) [#4]
He's saying SetViewPort does exactly what you are trying to do. Hardly like to change seeing as it does what it says on the tin.


N(Posted 2004) [#5]
Got glScissor working fine now- my mistake was using coords that started at the upper-left corner instead of the lower-left corner.


ImaginaryHuman(Posted 2004) [#6]
Ahhhhh, there you go. For those who were a bit confused, maybe a bit of an explanation. BlitzMax currently runs it's graphics using the OpenGL rendering library. Part of OpenGL are two features, one is viewports and the other is scissoring. I'm not exactly sure on this but I think a scissoring is part of the function of a viewport wherein the `scissor area` defines an area that drawing is clipped inside, while the viewport is clipping plus definition of viewing transformations? Something like that.

Anyway, glad you got it working. Everything in OpenGL has an origin in the lower left corner of the screen, not the top left, and it renders from the bottom up.


N(Posted 2004) [#7]
That would explain alot in regards to where the raster position is every other millisecond.


Michael Reitzenstein(Posted 2004) [#8]
By skipping past Max2D, your GUI won't be instantly able to use 2D drivers other than OpenGL when they're written for Max2D - have you considered this?


N(Posted 2004) [#9]
Yes. It -needs- OpenGL. If someone can't use OpenGL on their PC, it's far too outdated to be worth supporting anyways.


Michael Reitzenstein(Posted 2004) [#10]
PCs that can't use OpenGL are far too outdated to be worth supporting - but PCs that don't have OpenGL drivers installed are incredibly common.


N(Posted 2004) [#11]
Too bad for them, then.


LarsG(Posted 2004) [#12]
Stick a note on it which says that it needs OpenGL drivers (version x.x).
It's just like any other software..


Michael Reitzenstein(Posted 2004) [#13]
That's not necessarily a solution. It's a trivial task for you or I to install OpenGL drivers, but for lots and lots of people it isn't. Depending on your target audience, GL reliance is a major problem.


Hotcakes(Posted 2004) [#14]
Stick a note on it which says that it needs OpenGL drivers (version x.x).

Or say a recent version of DirectX is required, like Doom3 did... that covers the major two brands anyway ;]


N(Posted 2004) [#15]
Depending on your target audience, GL reliance is a major problem.


I'm not selling anything, so I'll let whoever is deal with it.


ImaginaryHuman(Posted 2004) [#16]
I think Michael had an interesting point ... if you use the higher-level BlitzMax routines, and at some point BlitzMax routines suddenly support more than one kind of driver ie something other than OpenGL, you wouldn't instantly get support. It depends on your priorities and how willing you are to get closer to the hardware I guess. The closer you get or the more low-level you get the more you are locked in since all abstraction takes place on a higher level.

However, for all intents and purposes, OpenGL does seem to be pretty awesome and at least for modern Mac's they all have good OpenGL support and I'm sure the other platforms have it too. It would be good to know what BlitzMax's requirements are so that when we start distributing software written with it we can inform our audience appropriately. Maybe someone can come up with some documentation.

I would especially like to know what is required to get OpenGL installed on other platforms that I might not be developing on but which I want to target - ie windows and linux. With no experience with those platforms I wouldn't know where to start with getting it up and running.