Drawing a grid (with lines)
Jen
I'm just starting out with Pyglet and I'm trying to get a grasp of the
coordinate system. I'd like to display a grid in my window to aid in
placement of sprites - and to do that I need to learn how to draw (a
lot of) lines!
I'm trying to draw a line but I only see the line for a split second
before it disappears. Did I miss something?
while not window.has_exit:
clock.tick()
window.dispatch_events()
pyglet.gl.glColor4f(0, 0, 0, 1.0)
pyglet.graphics.draw(2, pyglet.gl.GL_LINES, ('v2i', (0, 0, 800,
600)))
rabbyt.clear((0,0,0,1))
mySprite.render()
clockDisplay.draw()
window.flip()
Alex Holkner
line.
Alex.
> >
Jen
overwriting the line or maybe I'm not drawing the line correctly?
while not window.has_exit:
clock.tick()
window.dispatch_events()
pyglet.graphics.draw(2, pyglet.gl.GL_LINES, ('v2i', (0, 0,
800,
600)))
clockDisplay.draw()
window.flip()
Nicolas Rougier
If your clear method clear the screen with a black color then you're
drawing a black line over a black background. Try something like
pyglet.gl.glColor4f(1.0, 0, 0, 1.0) instead.
Nicolas
Jen
> If your clear method clear the screen with a black color then you're
> drawing a black line over a black background. Try something like
> pyglet.gl.glColor4f(1.0, 0, 0, 1.0) instead.
correct that the values for each (R, G, B, A) have to be between 0 and
1? Let's say that I wanted a nice color (blue R=125, G=167, B=217 or
hex #7da7d9). I tried to clear the background color with rabbyt.clear
((125,167,217,1)). That didn't give me the results I expected so when
I looked up the documentation it stated the maximum value was 1! This
seemed very weird - I thought the documentation had a typo at first.
Wouldn't actual RGB values be easier for the developer to enter?
But anyway - my question wasn't about Rabbyt's clear method - I'm
still trying to draw the lines with Pyglet.
Here's the entire thing if you want to see the behavior that I'm
trying to describe:
import rabbyt
from pyglet.window import Window
from pyglet import clock
from pyglet import image
from pyglet.graphics import *
from pyglet.gl import *
import os.path
rabbyt.data_directory = os.path.dirname(__file__)
clock.schedule(rabbyt.add_time)
window = Window(width=800, height=600, caption='Line Test')
rabbyt.set_default_attribs()
clockDisplay = clock.ClockDisplay()
mySprite = rabbyt.Sprite("star.png")
while not window.has_exit:
clock.tick()
window.dispatch_events()
pyglet.graphics.draw(2, pyglet.gl.GL_LINES, ('v2i', (0, 0,
800, 600)))
mySprite.render()
clockDisplay.draw()
window.flip()
instant) my black line) and then everything is covered over with the
(now red) background (counter visible at bottom left).
I think I'm missing something Pyglet related to get the lines to
'stay' on the screen.
Matthew Marshall
>
> On Mar 24, 8:03 am, Nicolas Rougier <nicolas.roug...@gmail.com> wrote:
>> If your clear method clear the screen with a black color then you're
>> drawing a black line over a black background. Try something like
>> pyglet.gl.glColor4f(1.0, 0, 0, 1.0) instead.
>
> Yes, I was indeed having problems with the background colors. :( Am I
> correct that the values for each (R, G, B, A) have to be between 0 and
> 1? Let's say that I wanted a nice color (blue R=125, G=167, B=217 or
> hex #7da7d9). I tried to clear the background color with rabbyt.clear
> ((125,167,217,1)). That didn't give me the results I expected so when
> I looked up the documentation it stated the maximum value was 1! This
> seemed very weird - I thought the documentation had a typo at first.
> Wouldn't actual RGB values be easier for the developer to enter?
All colors in rabbyt (and pyglet) are in the range 0..1. That's how
they are with OpenGL. You get used to it pretty quick :-)
> while not window.has_exit:
> clock.tick()
> window.dispatch_events()
> rabbyt.clear((1,0,0,1))
> pyglet.gl.glColor4f(0, 0, 0, 1.0)
> pyglet.graphics.draw(2, pyglet.gl.GL_LINES, ('v2i', (0, 0,
> 800, 600)))
> mySprite.render()
> clockDisplay.draw()
> window.flip()
>
> When I run it I see (very briefly) a white screen - then I see (for an
> instant) my black line) and then everything is covered over with the
> (now red) background (counter visible at bottom left).
>
> I think I'm missing something Pyglet related to get the lines to
> 'stay' on the screen.
Disable texturing before drawing your lines:
glDisable(GL_TEXTURE_2D)
Rendering the sprite enables texturing, which causes your line to be
drawn using the star texture. But since you don't specify texture
coordinates, only the last texture coordinate is used. This ends up
being one of the texture corners, which is 100% transparent.
MWM
Greg Ewing
>
>>Wouldn't actual RGB values be easier for the developer to enter?
They *are* "actual" RGB values, they're just not
assuming you've got 8-bit pixels. :-)
Floats in the range 0.0-1.0 are fairly common
practice when dealing with colours in a device
independent way.
--
Greg
Bruce Smith
wrote:
> they are with OpenGL. You get used to it pretty quick :-)
depending on the API -- for example:
.../pyglet-1.1.2-docs/doc/html/programming_guide/formatted_text.html
Character styles
The following character styles are recognised by all TextLayout
classes.
color
4-tuple of ints in range (0, 255) giving RGBA text color
background_color
4-tuple of ints in range (0, 255) giving RGBA text background
color; or None for no background fill.
Before I noticed this discrepancy, I tried to modify examples/
text_input.py like this:
def ToggleColor(self):
attrVal = self.focus.caret.get_style('color')
if attrVal:
new = None
else:
new = (1, 0, 0, 1) # red
self.focus.caret.set_style({'color':new})
and the text was not visible, presumably since its alpha was 1/255!
(Or maybe it was the Label text in hello_world.py which I tried this
with, I forget.) It works correctly in this form:
def ToggleColor(self):
attrVal = self.focus.caret.get_style('color')
if attrVal:
new = None
else:
new = (255, 0, 0, 255) # red
self.focus.caret.set_style({'color':new})
(In fact, maybe this possibility of alpha == 1/255 should be listed in
the FAQ as another reason your window can be blank. And another one is
just using the same text color and bg color. How does one modify the
FAQ page, anyway?)
- Bruce Smith
Greg Ewing
> (In fact, maybe this possibility of alpha == 1/255 should be listed in
> the FAQ as another reason your window can be blank.
It would be better to fix the API to remove this
inconsistency, I think.
--
Greg
Casey Duncan
>
> On Mar 25, 7:49 am, Matthew Marshall <matt...@matthewmarshall.org>
> wrote:
>> All colors in rabbyt (and pyglet) are in the range 0..1. That's how
>> they are with OpenGL. You get used to it pretty quick :-)
>
> Actually, some pyglet colors are from 0..1 and others are from 0..255,
> depending on the API -- for example:
The statement "that's how they are in OpenGL" isn't the whole truth.
In fact OpenGL lets you specify color values as bytes, short ints,
long ints or floats. The most popular of those options is bytes and
floats. The former for vertex lists because they are compact and the
latter for immediate mode. Though you can in fact use any
representation you choose for either.
In the case of integer types, their most positive representation is
mapped to 1.0, and to further confuse the issue, it supports both
signed and unsigned integers of various sizes. Thus the answer to the
question: "what is the range for color values in OpenGL", the true
answer is "it depends" or perhaps even "what range do you want to
use?" ;^)
Pyglet chooses unsigned bytes for labels probably because under the
covers it creates vertex lists to represent text and byte values are
commonly used for vertex lists. However the choice is arbitrary and
it's easy to see how some apis might use float values instead equally
arbitrarily, though it is not ideal.
Pyglet doesn't insulate you all that much from OpenGL itself, though
it does provide some extremely useful facilities for you. So, it would
be wise for you to pick up the OpenGL Red Book so you can figure out
what's really going on.
-Casey
Tristam MacDonald
The statement "that's how they are in OpenGL" isn't the whole truth.
On Wed, Mar 25, 2009 at 6:18 PM, Bruce Smith <ore...@gmail.com> wrote:
>
> On Mar 25, 7:49 am, Matthew Marshall <matt...@matthewmarshall.org>
> wrote:
>> All colors in rabbyt (and pyglet) are in the range 0..1. That's how
>> they are with OpenGL. You get used to it pretty quick :-)
>
> Actually, some pyglet colors are from 0..1 and others are from 0..255,
> depending on the API -- for example:
In fact OpenGL lets you specify color values as bytes, short ints,
long ints or floats. The most popular of those options is bytes and
floats. The former for vertex lists because they are compact and the
latter for immediate mode. Though you can in fact use any
representation you choose for either.
--
Tristam MacDonald
http://swiftcoder.wordpress.com/
Alex Holkner
By default framebuffers have 8 bits per colour per pixel, and the
"floating point" representation you see in shaders is really a fixed
point representation of that (0 bits before the decimal point, 8 bits
after it). Newer cards can give floating point buffers for
compositing with HDR, but this is the exception.
In reply to the earlier post asking if it would be better for pyglet
to use the same colour format consistently -- yes it would. The
current setup (where pyglet.graphics uses unsigned bytes and
everything else more or less uses floats) was a design mistake. FWIW,
using unsigned bytes for colour in vertex arrays gives a measurable
performance benefit over floats (YMMV).
Alex.
Casey Duncan
Of course pyglet could simply map floating point input values to their
corresponding unsigned byte values, to keep the performance benefit
without exposing that implementation detail. Certainly not convenient
to change in the b/w compatible way now though...
-Casey
Matthew Marshall
>
> On Wed, Mar 25, 2009 at 6:18 PM, Bruce Smith <ore...@gmail.com> wrote:
>>
>> On Mar 25, 7:49 am, Matthew Marshall <matt...@matthewmarshall.org>
>> wrote:
>>> All colors in rabbyt (and pyglet) are in the range 0..1. That's how
>>> they are with OpenGL. You get used to it pretty quick :-)
>>
>> Actually, some pyglet colors are from 0..1 and others are from 0..255,
>> depending on the API -- for example:
>
> The statement "that's how they are in OpenGL" isn't the whole truth.
> In fact OpenGL lets you specify color values as bytes, short ints,
> long ints or floats. The most popular of those options is bytes and
> floats. The former for vertex lists because they are compact and the
> latter for immediate mode. Though you can in fact use any
> representation you choose for either.
>
> In the case of integer types, their most positive representation is
> mapped to 1.0, and to further confuse the issue, it supports both
> signed and unsigned integers of various sizes.
Yes, you can send the data as unsigned bytes, and the implementation
might store them as unsigned bytes, but the range 0..1 is still how
colors are worked with. You can't set the blend mode to
GL_TWO_FIFTY_FIVE_MINUS_SRC. Lighting and fog work by multiplying
colors. Etc.
In my mind, colors in unsigned bytes are still 0..1, just stored in a
tighter representation for practical implementation.
But my mind's a strange place :-)
> Thus the answer to the
> question: "what is the range for color values in OpenGL", the true
> answer is "it depends" or perhaps even "what range do you want to
> use?" ;^)
IMHO, answering "0..1" is still an accurate answer, and it's far more
useful of an answer than "it depends". :-)
MWM