That would explain weird problems people have had with my code...
David wrote:
Do you have an algorithm as to how to automatically divide an
arbitrary rectangle into a near-optimal set of smaller power-of-two
rectangles?
For an exact subdivision, decompose each of the coordinates
into powers of 2 (which is easy, just look at the bits) and
take all the pairwi
On Thu, Feb 14, 2008 at 5:42 AM, David <[EMAIL PROTECTED]> wrote:
> Do you have an algorithm as to how to automatically divide an
> arbitrary rectangle into a near-optimal set of smaller power-of-two
> rectangles?
>
I've never written one myself - I've seen somebody else's code (I
think it might
On Wed, Feb 13, 2008 at 10:10 PM, Kris Schnee <[EMAIL PROTECTED]> wrote:
> So, if I wanted to draw a GUI window across the screen, and I'd normally
> want it to be, say, 800x200, I'd have to either split it and draw two
> textures, or make the texture 1024x256, or just draw a polygon with
> sha
Ian Mallett wrote:
Strangely enough, I've never had problems using textures which are not a
standard size. Any idea why?
Some OpenGL implementations support non-power-of-2 sizes
(I believe it's one of the officially sanctioned extensions)
but not all. You're probably lucky enough to have one t
Brian Fisher wrote:
On Feb 13, 2008 3:43 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
Have you seen the Lamina code?
http://pitchersduel.python-hosting.com/browser/branches/Lamina/
I would guess that it would perform poorly if you
wanted a lot of moving/animating pygame surfaces drawn all ove
On 2/13/08, Brian Fisher <[EMAIL PROTECTED]> wrote:
> 2. spread images across multiple textures and draw all of them (so the
> 24x12 image would be spread across 4 textures, a 16x8, an 8x8, a 16x4
> and an 8x4) which lets you draw more polys in order to not waste so
> much video memory
Do you hav
On Thu, 14 Feb 2008, Brian Fisher wrote:
> support for non-power of 2 texures is pretty much standard for recent
> graphics cards
Note that there can be a *significant* performance penalty when using some
cards / drivers.
Richard
On Wed, Feb 13, 2008 at 10:16 PM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> Strangely enough, I've never had problems using textures which are not a
> standard size. Any idea why?
>
I assume by "standard size" you mean non-power of 2... you probably
have no problem with it because all the machines
Strangely enough, I've never had problems using textures which are not a
standard size. Any idea why?
Brian Fisher wrote:
... Also, I have to say that at first I thought it would be a "Royal
Pain" to have to deal with rendering 2d stuff in openGL - but it
actually turned out to be much easier than I thought and kind of a lot
of fun (although I may have more pain later I suppose). The only thing
t
On Feb 13, 2008 4:02 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> In my experience, doing anything in 3D is very hard work,
> and if you don't tackle the most important parts first,
> there's a danger of running out of steam before you
> get it finished.
>
Greg is correct. Do the most important
yeah, I think there are a couple of approaches.
Lamina takes the first approach... which is to make almost everything
work - just by updating dirty rects. So you render to an offscreen
surface. As long as you are careful with dirty rects - it should be
fairly fast, and not very complex. Mainly
On Feb 13, 2008 3:43 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> Have you seen the Lamina code?
> http://pitchersduel.python-hosting.com/browser/branches/Lamina/
>
I hadn't seen it before - It appears to take the approach of
maintaining a single full-screen overlay which is created from a
pygame
On Feb 13, 2008 4:28 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> There's also
>
> 4. Scale the texture image so that it has power-of-2 sizes
>
> which may work well enough for photographic images and such
> like where you're not too concerned about the appearance of
> fine details.
>
I've heard tha
Brian Fisher wrote:
textures have to be a power-of-2 in
width and height - so you have to deal with that to upload say a 24x12
image for blitting. The 3 basic approaches are:
There's also
4. Scale the texture image so that it has power-of-2 sizes
which may work well enough for photographic im
Kris Schnee wrote:
Maybe I'm answering my own question here. I'm basically looking for eye
candy instead of focusing on the gameplay concepts I want to develop.
It's probably better to focus on getting the gameplay right
before going after eye candy. Maybe prototype the whole
thing in 2D first
Very cool :)
Have you seen the Lamina code?
http://pitchersduel.python-hosting.com/browser/branches/Lamina/
btw, I had to comment out this line, which seems to be fcked on
pyopengl cvs. Otherwise it segfaulted.
#print glGetString(GL_EXTENSIONS)
I also get this on exit:
Exception except
attached is an example of one way to draw pygame surfaces in OpenGL.
It's originally a piece of a larger library, so I tried to rip out
dependencies on that library. It exports a "Display" class which takes
over creating the pygame display and can blit objects which have 4
attributes on them - surf
Also note most of the nehe tutorials have been translated to python in
the pyopengl Demo directory.
chairs,
On Feb 14, 2008 7:49 AM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> If you really want to make something nice, even if it is a 2D
> background, your best option is to render a 3D image.
>
> T
If you really want to make something nice, even if it is a 2D
background, your best option is to render a 3D image.
The image you're looking at doesn't look like it was created with a
heightmap, the simplest way of making 3D terrain, because the texture
does not appear to stretch.
You can somethi
Richard Jones wrote:
On Wed, 13 Feb 2008, René Dudfield wrote:
Apart from Richards shameless self promotion of pyglet, here's some
other things to look at...
It was more an attempt to dispel the "even in Python" statement :)
Heh. Thanks, both of you.
It looks like with Pyglet I'd need to le
On Feb 12, 2008 1:51 PM, Richard Jones <[EMAIL PROTECTED]> wrote:
> On Wed, 13 Feb 2008, René Dudfield wrote:
> > Apart from Richards shameless self promotion of pyglet, here's some
> > other things to look at...
>
> It was more an attempt to dispel the "even in Python" statement :)
>
Can't it be b
On Wed, 13 Feb 2008, René Dudfield wrote:
> Apart from Richards shameless self promotion of pyglet, here's some
> other things to look at...
It was more an attempt to dispel the "even in Python" statement :)
Richard
Apart from Richards shameless self promotion of pyglet, here's some
other things to look at...
Have a look in the Demo directory of pyopengl for many goodies. It's
an often overlooked place of python opengl code.
If you want to render text in 3d: http://ttfquery.sourceforge.net/
soya, openglco
On Wed, 13 Feb 2008, kschnee wrote:
> Loading images and
> displaying those and text is a royal pain in OpenGL, even in Python.
The "even in Python" is a little out of date now :)
from pyglet import image, font
# display an image
im = image.load('image.png')
im.blit()
# display some text
t = fo
I don't exactly recommend the NeHe tutorials for their nice code, but
there are some nice clear enough python examples.
http://www.pygame.org/gamelets/
Has nehe tutorials 1-10.
I'll write some OpenGL basecode sometime too.
On Tue, 12 Feb 2008 23:23:49 +1030, fragged <[EMAIL PROTECTED]>
wrote:
> Hey guys,
>
> I've been searching for some decent examples of PyOpenGL to help me port
> my current application to OpenGL to speed things up on my perty new
> 1920x1200 LCD (Getting about 20fps, using no acceleration whatsoev
Hey guys,
I've been searching for some decent examples of PyOpenGL to help me port
my current application to OpenGL to speed things up on my perty new
1920x1200 LCD (Getting about 20fps, using no acceleration whatsoever),
however I've been unable to find any decent guides on the net that
simp
29 matches
Mail list logo
