[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] ANN: pyglet 1.0beta1



On Nov 12, 2007 1:24 PM, Alex Holkner <alex.holkner@xxxxxxxxx> wrote:
> OpenGL provides many ways to scale a 640x480 viewport up to a higher
> resolution, with or without aliasing (I suspect in this use-case you'd
> prefer the aliasing).
>
there's no way to get 640x480 pixel art to look right on a 1024x768
desktop unless you want to blackbox and draw at 62.5% scale. There may
be a lot of 3d apps where resolution doesn't matter, but the bluriness
of scaling 1.65 does kill small text and make crisp sharp lines look
bad, and it makes pixel art distorted.


> It will be a happy day when a Python application is fill-limited, and
> not CPU bound!
>
Congratulations Alex! Today is a happy day then!

I do motion blur in my engine. My python games in development that use
it are definitely fill-limited. Also, I want to target a wide range of
computers, including my 5 year old laptop. On that machine, I need to
turn off my motion blur, and still on those computers I only get 30fps
with most of the time is in the draw + flip (a lot is in the flip
meaning my game is waiting for GL to finish off it's command buffers)

If I ended up scaling up the 800x600 game to the 1280x1024 desktop in
fullscreen, it would take like 2.25 times as long to draw, and I would
only get like 12fps, and dip into the unplayable range.


Basically I respect not wanting to mess with people's desktops, but I
think fullscreen with changed resolution is a far too powerful thing
in terms of delivering a great game experience to not at least try to
do it well & try to solve the problems as best you can - I happen to
think it works very well on pygame with an openGL display. The fact
that currently it will never be an option in pyglet is a huge turn off
to what otherwise seems a superior library.


> pyglet provides excellent windowing support, including full mouse and
> keyboard exclusivity... a game with fixed resolution smaller than the
> display will happily run inside a window.
>
That sounds great - I'm sure it handles multi-monitor stuff
beautifully as well - I think it's great that you made multi-monitor
and multi-window part of the core feature set