pyallegro-general — General Python-Allegro-stuff

Re: [Pyallegro] Google Summer of Code

[Elias P. <el...@us...>]

On Mon, 2008-03-17 at 16:09 -0600, Luke Paireepinart wrote:
> Hello, everyone.
> I'm a Computer Science student looking for python-related GSoC 
> projects.  Is there a place where project ideas are posted for PyAllegro?
> Thanks,
> -Luke

We did not apply to GSoC as a mentoring organization (unless I'm missing
something) - so not sure how it would work. Best place to find info is
probably the GSoC pages, maybe they have something for general open
source projects without a mentoring organization.

-- 
Elias Pschernig <el...@us...>

[Pyallegro] Google Summer of Code

[Luke P. <vp...@tx...>]

Hello, everyone.
I'm a Computer Science student looking for python-related GSoC 
projects.  Is there a place where project ideas are posted for PyAllegro?
Thanks,
-Luke

Re: [Pyallegro] Compliation issue. Help?

[Grzegorz A. H. <gr...@ti...>]

On 2007-07-29, Tristan Ankerstar <tr...@an...> wrote:
> ...here's the actual attachment. Whoops.
>
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include -I/usr/include/python2.5 -c _alpymodule.c -o build/temp.linux-i686-2.5/_alpymodule.o -Wno-deprecated-declarations -Werror
> src/_alpymodule.c.in:28:20: error: Python.h: No such file or directory
> src/_alpymodule.c.in:37: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
> src/_alpymodule.c.in:74: error: expected specifier-qualifier-list before ‘PyObject_HEAD’

The first error line tells that Python.h is not found, and therefore all
python related tokens like structures will make the compilation fail.
You will need to get the python-dev package which includes Python's
development headers required to compile native extension modules.

If you already have the package you would have to find out why it is not
being included. By default you can see in the gcc commandline that
distutils is forcing an include of the path /usr/include/python2.5. If
the headers are somewhere else, I think you could create a symbolic link
to them using that path.

Probably easier than modifying distutils, though you should report a
bug to your distro about this.

Talking about packages, you will also need Allegro's development one.

Re: [Pyallegro] Compliation issue. Help?

[Grzegorz A. H. <gr...@ti...>]

On 2007-07-29, Tristan Ankerstar <tr...@an...> wrote:
> Hi. I'm part of a team putting together a game in python. We're
> in the process of try to switch our graphics/gaming library
> to allegro, and pyallegro (specifically alpy) looks like the
> perfect tool. However... I can't seem to get it to compile. I
> have python 2.4 installed, I have allegro 4.2 installed (both from
> ubuntu debs) and I'm not a complete idiot, quite.  However, well,
> "python setup.py build" seems to fail horribly. I've attached the
> output in a file.

The attachment is missing or SF ate it. If you have problems sending
the attachment try using SF's patch tracker or put it on some web.

> Thanks! And thanks for the work, guys, this wrapper theoretically
> makes decent development a whole lot more pleasant.

Not to burst your bubble but alpy is quite crude, doesn't offer much
advantage over the C api other than being used from a language more
comfortable than C. The whole api is not wrapped: there are obvious
stuff like 3d functions but others may have to be wrapped too.

Please evaluate the whole thing with detail before proceeding,
or you may have trouble later. Also, python is very bad with APIs
that have to modify lots of memory buffers, so you should expect
a slowdown from normal C code.

[Pyallegro] Compliation issue. Help?

[Tristan A. <tr...@an...>]

Hi. I'm part of a team putting together a game in python. We're in the
process of try to switch our graphics/gaming library to allegro, and
pyallegro (specifically alpy) looks like the perfect tool. However... I
can't seem to get it to compile. I have python 2.4 installed, I have allegro
4.2 installed (both from ubuntu debs) and I'm not a complete idiot, quite.
However, well, "python setup.py build" seems to fail horribly. I've attached
the output in a file. Probably I'm doing or forgetting to do something
silly, and I apologize for the harassment, but if anyone can offer any
insight, that would be fantastic.

Thanks! And thanks for the work, guys, this wrapper theoretically makes
decent development a whole lot more pleasant.

[Pyallegro] Alpy 0.1.5 released

[Grzegorz A. H. <gr...@ti...>]

Hello boys and girls. I'm not dead yet.

There's a new release on the SourceForge download page. Right now ssh
access doesn't seem to be working, so I'll update the web page later.

[Pyallegro] [ pyallegro-Patches-1687412 ] OpenGL support

[SourceForge.net <no...@so...>]

Patches item #1687412, was opened at 2007-03-24 07:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376094&aid=1687412&group_id=22470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Alpy (C version)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Grzegorz Adam Hankiewicz (gradha)
Summary: OpenGL support

Initial Comment:
Here's a small conceptual patch to allow using OpenGL from Python. Is something like that interesting to AlPy? (Requires AllegroGL and PyOpenGL.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376094&aid=1687412&group_id=22470

[Pyallegro] [ pyallegro-Patches-1658954 ] Add tostring(), topil(), fromstring(), frompil()

[SourceForge.net <no...@so...>]

Patches item #1658954, was opened at 2007-02-13 13:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376094&aid=1658954&group_id=22470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Connelly (connelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add tostring(), topil(), fromstring(), frompil()

Initial Comment:
I added tostring(), topil(), fromstring(), frompil() methods to the Bitmap class.  Then I noticed that there is a from_string() method which already exists in the Bitmap class (I didn't see it because it didn't show up in the documentation).  This patch is also diff'ed against the "post-templated" source and text files as opposed to the "pre-templated" source and text files (as I didn't realize that the C file was the output of a templating process).  In general frustration, I am submitting this patch, so that either (a) You can tell me, "No this API is entirely wrong; here's how to change it" and I can resubmit; (b) You can use this code as a reference to develop your preferred API; or (c) You can remove the undocumented from_string() and just incorporate the patch as-is.  Let me know what your preferences are.

>From the patched documentation:

 * fromstring(str, mode, w, h, s, stride=-1) -> Bitmap
   Static method, creates a bitmap from a string of raw color data.  Here mode
   should be one of 'RGB', 'RGBA', 'ARGB', 'BGR', 'BGRA', 'ABGR', w and h are
   the size of the raw image, and s is a string with the contents of the raw
   image.  By default, it is assumed that rows are packed in without any extra
   padding; to change this, supply the stride argument, which specifies the size
   in bytes of each row.
 
 * frompil(img) -> Bitmap
   Static method, creates an alpy Bitmap from a Python Imaging Library (PIL)
   Image.Image instance.  The conversion is done in RGB format, so any alpha
   channel will be lost.

   PIL is only required if this method is called; it is not required in general
   for alpy.

 * tostring(mode='RGB', stride=-1) -> str
   Converts a bitmap to a raw string of color data.  Here mode should be one of
   'RGB', 'RGBA', 'ARGB', 'BGR', 'BGRA', 'ABGR'.  By default, it is assumed that
   rows are packed in without any extra padding; to change this, supply the stride
   argument, which specifies the size in bytes of each row.
 
 * topil() -> Image.Image instance
   Converts a bitmap to a Python Imaging Library (PIL) Image.Image instance.
   The conversion is done in RGB format, so any alpha channel will be lost.
   
   PIL is only required if this method is called; it is not required in general
   for alpy.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376094&aid=1658954&group_id=22470

Re: [Pyallegro] [ pyallegro-Feature Requests-1532836 ] Precompiled Windows Binary

[Grzegorz A. H. <gr...@ti...>]

On 2006-08-01, "SourceForge.net" <no...@so...> wrote:
> Feature Requests item #1532836, was opened at 2006-08-01 20:51
> Message generated for change (Tracker Item Submitted) made by Item Submitter
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=376095&aid=1532836&group_id=22470
> Submitted By: ACE91 (ace91)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: Precompiled Windows Binary

For those not monitoring the thread, I've managed to make windows
prebuilt binaries. I'll be making a new release in the near future
for them.

Re: [Pyallegro] Diet Python uses alpy

[Grzegorz A. H. <gr...@ti...>]

On 2006-07-27, Andrew Fine <ete...@ho...> wrote:
> I'm making a cutdown version of Python that is very strongly
> Allegro focused.

Your project looks very interesting. Shame I don't see how to use
it under Linux, and I don't have any Windows boxes. There's no web
page I can see though. Would you like to join the pyallegro.sf.net
site? Or at least get a link to the SourceForge downloads from it.

> I'm using your _alpymodule.c, but I've reworked the alpy.py script
> into Allegro.py to present a hopefully more elegant interface.
> Would you be interested in it?

I can see how using inheritance much typing could be avoided,
but I don't like this style myself very much because you end up
with a sort of really big class in your main program, and it gets
confusing if you want to otherwise use your own stuff in the class.

I imagine it could also be problematic for software divided in
modules. Would they instance also themselves as children of the
Allegro class? What happens with global resources like screen? Do
they get shared correctly?

With regards to the module online help, is it of any use to you? Is
it true that windows IDEs show the help when you hover over some
function? I only use it from the interactive shell (ipython) and
works quite well, but hopefully other people find it useful too!

[Pyallegro] [ pyallegro-Feature Requests-1532836 ] Precompiled Windows Binary

[SourceForge.net <no...@so...>]

Feature Requests item #1532836, was opened at 2006-08-01 20:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376095&aid=1532836&group_id=22470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: ACE91 (ace91)
Assigned to: Nobody/Anonymous (nobody)
Summary: Precompiled Windows Binary

Initial Comment:
I have had no end of trouble compiling this extension
under Windows--I have tried with both Visual C++ 6 and
Visual C++.NET 2005, and with both the .NET Framework
1.1 and 2.0, and none of them have worked. I would
appreciate it if a precompiled Windows binary similar
to those available for most other Python extensions was
available for this one, so that developers would not
have to compile it from source.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376095&aid=1532836&group_id=22470

[Pyallegro] Diet Python uses alpy

[Andrew F. <ete...@ho...>]

Dear Grzegorz,

I'm making a cutdown version of Python that is very strongly Allegro 
focused.

I'm using your _alpymodule.c, but I've reworked the alpy.py script into 
Allegro.py to present
a hopefully more elegant interface.   Would you be interested in it?

Thanks,

The Eternal Squire
www.sourceforge.net\projects\dietpython

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

[Pyallegro] alpy 0.1.4 released!

[Grzegorz A. H. <gr...@ti...>]

Hello there.

I've finished (or hope so) the Python unicode string support. The
new exunicode examples show how easy it is to show Unicode characters
in Python compared to the Allegro C version.

Enjoy!

Re: [Pyallegro] Re: Python binding for jpgalleg

[AKX <th...@gm...>]

> Have you heard of somebody using it?
Unfortunately, as of yet I think I'm the only one. ;) I guess a
full-blown example game (somewhat in the works *shrug*) would help.

> It makes me wonder why people don't turn to such solutions.

They don't know?

*yaaawn* Good night :)

Re: [Pyallegro] Re: Python binding for jpgalleg

[Grzegorz A. H. <gr...@ti...>]

On 2006-04-27, AKX <th...@gm...> wrote:
> Actually a modified version of JPGAlleg is included in my
> wrapper. The wrapper supports png, jpeg and animated gif
> loading out of the box, provided you have the libpng library
> available. Other loader libraries are included.

I guess you are right in that including the libraries with the
python version (instead of the other way round) is easier for
users. So basically you offer Allegro + popular addons + higher
level language. Have you heard of somebody using it?

It makes me wonder why people don't turn to such solutions. Just
today I had to write a program which modifies images, and it would
have taken me ten times more to do it in C rather than python.

[Pyallegro] Re: Python binding for jpgalleg

[AKX <th...@gm...>]

Actually a modified version of JPGAlleg is included in my wrapper. The
wrapper supports png, jpeg and animated gif loading out of the box,
provided you have the libpng library available. Other loader libraries
are included.

On 4/26/06, Grzegorz Adam Hankiewicz <gr...@ti...> wrote:
> I wrote a really simple python binding for
> http://www.ecplusplus.com/index.php?page=3Dprojects&pid=3D1 which I
> already sent to Angelo. Just to test, I'm posting it here. I think
> it should work with the pyrex wrapper too.
>
>

[Pyallegro] Python binding for jpgalleg

[Grzegorz A. H. <gr...@ti...>]

I wrote a really simple python binding for
http://www.ecplusplus.com/index.php?page=projects&pid=1 which I
already sent to Angelo. Just to test, I'm posting it here. I think
it should work with the pyrex wrapper too.

[Pyallegro] Alpy 0.1.3 released!

[Grzegorz A. H. <gr...@ti...>]

Many documentation improvements and a bugfix for Bitmap.polygon().
Get it from:

  http://sourceforge.net/project/showfiles.php?group_id=22470&package_id=163640

Re: [Pyallegro] Bitmap.polygon() patch

[Grzegorz A. H. <gr...@ti...>]

On 2006-03-21, Connelly Barnes <con...@ya...> wrote:
> I don't know if you guys check your SF patches regularly.

Uh, actually I wasn't doing this. I've modified now all forums to
notify this mailing list when something new is posted.

> Anyway, I patched Bitmap.polygon() so it works (it's a trivial
> patch), so you may wish to check the SF patch site.

Cool, already commited into SVN.

Since I'm at it, do you actually use pyallegro for something
useful? Do you use the last release of the SVN version?

[Pyallegro] Bitmap.polygon() patch

[Connelly B. <con...@ya...>]

Hi,

I don't know if you guys check your SF patches regularly.  Anyway,
I patched Bitmap.polygon() so it works (it's a trivial patch),
so you may wish to check the SF patch site.

 - Connelly Barnes


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Pyallegro] PyAlleg 0.1.3.6b Win32/2.4 Binaries

[AKX <th...@gm...>]

Hello again,

I just added the long overdue Win32 binaries of the current PyAlleg
version to the file release system, with and without alleg42.dll...
They're built with MingW on Windows XP (ANSI and all) for Python 2.4.
Don't know when I'll get around to adding more features to PyAlleg, though.

Re: [Pyallegro] Re: Switching to SVN?

[Grzegorz A. H. <gr...@ti...>]

On 2006-03-16, AKX <th...@gm...> wrote:
> Right. I'll abandon updating the CVS now, if that's OK - mostly
> because I like SVN a lot more...

Sure, that's the idea.

> so if you want to do some deleting/archiving (attic? dunno)
> or other stuff for the CVS, perhaps some notice that further
> development will be in SVN, or something, go ahead :)

It doesn't hurt keeping it there, at least for a few months.

Re: [Pyallegro] Re: Switching to SVN?

[AKX <th...@gm...>]

Right. I'll abandon updating the CVS now, if that's OK - mostly
because I like SVN a lot more... so if you want to do some
deleting/archiving (attic? dunno) or other stuff for the CVS, perhaps
some notice that further development will be in SVN, or something, go
ahead :)

I'll try to wrap a couple new functions in the near(ish) future, for
example background_mode is a good thing to have.

AKX.

On 3/15/06, Grzegorz Adam Hankiewicz <gr...@ti...> wrote:
> On 2006-03-15, AKX <th...@gm...> wrote:
> > Well, I don't really care.
> > Do what you think is best.. I just want to do commits and updates ;)
>
> Done. Root is http://svn.sourceforge.net/viewcvs.cgi/pyallegro/,
> with alpy and pyrex subdirectories. In order to work with pyrex
> you would do:
>
>  svn co https://svn.sourceforge.net/svnroot/pyallegro/pyrex/trunk pyrex
>
> I could do all the structure reshuffling in a single commit without
> net access. Really cool. I just wish there was some kind of log
> cache, because I use that feature quite often.
>

Re: [Pyallegro] Re: Switching to SVN?

[Grzegorz A. H. <gr...@ti...>]

On 2006-03-15, AKX <th...@gm...> wrote:
> Well, I don't really care.
> Do what you think is best.. I just want to do commits and updates ;)

Done. Root is http://svn.sourceforge.net/viewcvs.cgi/pyallegro/,
with alpy and pyrex subdirectories. In order to work with pyrex
you would do:

 svn co https://svn.sourceforge.net/svnroot/pyallegro/pyrex/trunk pyrex

I could do all the structure reshuffling in a single commit without
net access. Really cool. I just wish there was some kind of log
cache, because I use that feature quite often.

[Pyallegro] Re: Switching to SVN?

[AKX <th...@gm...>]

Well, I don't really care.
Do what you think is best.. I just want to do commits and updates ;)

On 3/15/06, Grzegorz Adam Hankiewicz <gr...@ti...> wrote:
> >     Subversion Server:  https://svn.sourceforge.net
> >     Path to Repository: /svnroot/pyallegro
> >
> > I wonder about the /svnroot/ part, since you already access
> > svn.sourceforge.net...
>
> So they are using https and wonder about poor SVN
> performance... anyway, the import is done I believe the first
> thing should be to reorganise the hiearchy. Since both projects
> are different, instead of the typical branch-trunk-tag/project we
> could move it to project/branch-trunk-tag.
>
> Is that ok?
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Pyallegro-general mailing list
> Pya...@li...
> https://lists.sourceforge.net/lists/listinfo/pyallegro-general
>