[pygsear] questions

[Gerrit Holl]

Hi,

I am new on this list. I have been using Python for years now, and
recently I discovered Pygame. Only _very_ recently I discovered
pygsear, and for both it's a pity that they live so far away in
a dark corner of Humanity. I want to use those to create a game, Brian,
which will officially be a compeletely new game but which will,
in reality, be heavily inspired by Commander Keen. I had already
started creating a platform lib (I was very disappointed by
Pyplatform, because it lacks functions or classes), when I discovered
Pygsear. I hope Pygsear can help me in solving my two main problems:
scroll speed and background (for large levels, 8000x8000 pixels, scaling
is not an option). I don't think Pygsear can do a lot for me on this,
but if I find a solution myself, I do want to share it. I hope I can
do this through Pygsear, I hope there is a place for e.g. scrolling
code (I have currently solved it with a 'viewport').

I have some questions about pygsear. Maybe some of the questions are
dumb, but I only recently discovered pygsear. I hope you don't mind.

    * Is there a pygsear-dev list? If so, this questions reside better
      there.

    * What is the purpose of Cursor.AbstractClassError? It isn't used
      anywhere and it is not an exception since it is not a subclass
      of Exception.

    * Wouldn't properties be useful in the following places:
        * Cursor.Cursor.hotspot
        * Path.Path.position
        * Path.Path.{x,y}
        * Drawable.position

    * Isn't conf.WINSIZE a bad idea? I think for subclasses of Window,
      it can be a good idea to have a default winsize, but wouldn't
      an explicit size for the base class be better for readability,
      portability and maintainability? The same applies to a window
      title.

    * What is the exact status of pygsear?

    * Why don't Widget.SpriteTextButton, Widget.TextInput and others
      use *args instead of those messy argument lists? Is this because
      the defaults may change? Won't we need a more clean way to
      do this?

    * How about keeping track of the 'frame number' in the Game class,
      so certain timings (reload time, life time) can me measured? This
      should be done in frames, not in seconds, because a delay may
      otherwise mess things up.

    * How many members does pygsear-users have?

    * I am *very* impressed by Path.py! Just wanted to say :)

    * How does pygsear cope with backward incompatibities? I don't think
      pygsear has a large user base yet, so it shan't be a major problem.

    * Does pygsear use Python 2.3 features?

    * Would it be an idea to load multiple images from one file? Many games
      have hundreds of sprites for moving monsters, and all files with
      40x40 images is not practical. Loading and saving animated images
      according to a protocol would be a worthy feature.

    * Does pygsear have a detailed goal apart from 'making it easier to
      program'?
    
    * Does pygsear think large projects can be written in python + pygame
      + pygsear (Freeciv-alike)?

    * Does pygsear handle speed well?

    * What is the history of pygsear?

Well, that's all for tonight. Tomorrow, I will have a thorough deeper look
into pygame. I hope I can contribute to pygame; I have already posted two
patches, and more will definetely follow. One migrates old-style to new-style
classes, and the other fixes some bugs in Screen.py Maybe some CVS-w access
can be granted in the forseeable future ;)

yours,
Gerrit Holl.

-- 
Asperger Syndroom - een persoonlijke benadering:
        http://people.nl.linux.org/~gerrit/
Het zijn tijden om je zelf met politiek te bemoeien:
        http://www.sp.nl/