Re: [pygame] MMX Transform for Win32

[Greg Ewing]

Brian Fisher wrote:

The C++ feature AGG uses the most is templating


Which is also the one most likely to lead to code bloat,
unless it's used extremely carefully.

If you use templates in the obvious way to implement
e.g a List, and then instantiate List and
List, you end up with two copies of the code,
despite the fact that the same code *could* be used
to implement both, since they're only slinging pointers
around.

(Unless compilers have got a lot smarter since I last
played around with templates, which is possible.)

--
Greg

Re: [pygame] MMX Transform for Win32

[Greg Ewing]

Brian Fisher wrote:


I think gcc supports C++ as a rule. Aside from interfacing the C++
code from the C code with extern "C" statements, what would be the
difficulty there?


Depending on what features of C++ it uses, the effects
can spread beyond just the code in question -- e.g.
introducing dependencies on C++ runtime libraries,
requiring the main program to be linked as C++ (so that
static constructors get called), and so forth.

If things can be arranged so that just the one module
is compilable as C++, and the module is optional, it's
not so bad.

--
Greg

Re: [pygame] MMX Transform for Win32

[René Dudfield]

Slower compilation, less platform support, faster changing ABI, bigger
binaries, and a more complex language.  Compilation of C++ python
extensions is a bit harder on windows too - because mingw & vc don't
share the same ABI (but maybe this has changed with the upcoming 4.x
gcc for mingw, and new VC release).

It's definitely something we need to discuss for the next pygame
releases... weather we choose SDL_gfx, cairo, tinyGL, opencv, or AGG
(or some combination of them).  Note that the SDL_gfx author has
expressed interest in working with us, which is nice.




On Tue, Mar 11, 2008 at 9:46 AM, Brian Fisher <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 10, 2008 at 3:30 PM, Marcus von Appen <[EMAIL PROTECTED]> wrote:
>  >  Many small devices ship with rather slim compilers, which often either
>  >  do not support C++ or use e.g. the 2.95 G++ backend, which is known to
>  >  be not the best ;-).
>  >
>  any small devices pygame supports that are that way? my understanding
>  with the gp2x and the nokia are that they have perfectly fine c++
>  support through GCC (though I don't build for them so I don't really
>  know)
>
>
>
>  >  I do not say, let's drop agg, but please keep it optional and seperate
>  >  it in a way we can build the rest of the modules still with a C
>  >  compiler. Changing the whole build system to C++ would be a bad idea in
>  >  my opinion and really limits it.
>  >
>  Gotcha. Except for the "optional" part, I agree with all that. In my
>  mind I was imagining that agg and the agg using files would be c++ but
>  declare some extern "C" functions that all the actual extension code
>  would call, and the extension code would compile with the C compilers.
>
>  I still seriously doubt that requiring a C++ compiler to build pygame
>  would be any noticeable problem or difficulty on any platform pygame
>  is currently built for.
>
>
>
>  >  Besides that there's only the 2.4 version of agg we can stick to, which
>  >  is another bad thing due to features and stuff later versions (will)
>  >  have. But I guess we just have to live with it then.
>  >
>  I can see how that would be a bit scary - but as it has turned out,
>  Maxim has done almost no developing on the 2.5 code (I think he got a
>  new job making HW accelerated vector and compositing stuff), so 2.4 is
>  very complete and just as good as 2.5. If, however, 2.5 ends up
>  getting something neat and cool, I'm sure Maxim would be willing to
>  license the code differently for the sake of inclusion in an open
>  source lib like pygame (he says he's open to that on his news page)
>
>
>
>  >  I do not really get what you say here, but anything mentioned above
>  >  (scoping, declare, bool) is also covered by C compilers implementing the
>  >  C90/C99 subsets (so nearly any except the really old ones and the MS C
>  >  compilers up to at least VS.NET 2005) :-).
>  >
>  I was saying that for C code, C++ compilers are the most portable and
>  consistent. Using C compilers (and not C++ ones) causes portability
>  issues now for pygame. In particular visual studio compiling has been
>  broken in svn a small number of times by code that expected those C
>  subsets to be supported. But that is really kind of small beans
>  compared to the core question for me - which is how will using C++ as
>  part of the pygame build make "everything just a bit harder"?
>

Re: [pygame] MMX Transform for Win32

[Brian Fisher]

On Mon, Mar 10, 2008 at 3:30 PM, Marcus von Appen <[EMAIL PROTECTED]> wrote:
>  Many small devices ship with rather slim compilers, which often either
>  do not support C++ or use e.g. the 2.95 G++ backend, which is known to
>  be not the best ;-).
>
any small devices pygame supports that are that way? my understanding
with the gp2x and the nokia are that they have perfectly fine c++
support through GCC (though I don't build for them so I don't really
know)


>  I do not say, let's drop agg, but please keep it optional and seperate
>  it in a way we can build the rest of the modules still with a C
>  compiler. Changing the whole build system to C++ would be a bad idea in
>  my opinion and really limits it.
>
Gotcha. Except for the "optional" part, I agree with all that. In my
mind I was imagining that agg and the agg using files would be c++ but
declare some extern "C" functions that all the actual extension code
would call, and the extension code would compile with the C compilers.

I still seriously doubt that requiring a C++ compiler to build pygame
would be any noticeable problem or difficulty on any platform pygame
is currently built for.


>  Besides that there's only the 2.4 version of agg we can stick to, which
>  is another bad thing due to features and stuff later versions (will)
>  have. But I guess we just have to live with it then.
>
I can see how that would be a bit scary - but as it has turned out,
Maxim has done almost no developing on the 2.5 code (I think he got a
new job making HW accelerated vector and compositing stuff), so 2.4 is
very complete and just as good as 2.5. If, however, 2.5 ends up
getting something neat and cool, I'm sure Maxim would be willing to
license the code differently for the sake of inclusion in an open
source lib like pygame (he says he's open to that on his news page)


>  I do not really get what you say here, but anything mentioned above
>  (scoping, declare, bool) is also covered by C compilers implementing the
>  C90/C99 subsets (so nearly any except the really old ones and the MS C
>  compilers up to at least VS.NET 2005) :-).
>
I was saying that for C code, C++ compilers are the most portable and
consistent. Using C compilers (and not C++ ones) causes portability
issues now for pygame. In particular visual studio compiling has been
broken in svn a small number of times by code that expected those C
subsets to be supported. But that is really kind of small beans
compared to the core question for me - which is how will using C++ as
part of the pygame build make "everything just a bit harder"?

Re: [pygame] MMX Transform for Win32

[Marcus von Appen]

On, Mon Mar 10, 2008, Brian Fisher wrote:

> On Mon, Mar 10, 2008 at 2:40 PM, Marcus von Appen <[EMAIL PROTECTED]> wrote:
> >  C++ adds a lot of unnecessary overhead, limits the portability and makes
> >  anything just a bit harder.
> >

[...]

> goals of templating using just C. What specific overhead would someone
> expect to be added simply by using C++ compilers?

Due to my experience, several C++ compilers take much more time to
compile the code and create bigger binaries. Additionally several C++
compilers lack a good optimization due to C++'s nature, especially when
it comes to stuff like advanced classes, operator overloading,
templates, etc.

> In terms of portability, in terms of agg code, it's already highly
> tested and developed to be portable, and it doesn't use stl or other
> c++ portability pitfalls. So the issue would just be the portability
> of C++ in general - so what platforms don't have c++ compilers that
> are readily available if not already built in to the same package that
> provides C compiling?

Many small devices ship with rather slim compilers, which often either
do not support C++ or use e.g. the 2.95 G++ backend, which is known to
be not the best ;-). 

I do not say, let's drop agg, but please keep it optional and seperate
it in a way we can build the rest of the modules still with a C
compiler. Changing the whole build system to C++ would be a bad idea in
my opinion and really limits it.

Besides that there's only the 2.4 version of agg we can stick to, which
is another bad thing due to features and stuff later versions (will)
have. But I guess we just have to live with it then.

> As far as the idea of C++ making anything just a bit harder - I
> completely disagree in that C++ is a much better C compiler (scoping
> of variables, declare them anywhere you want, a bool type) so
> everything is easier until you run into a C++ construct you just
> haven't learned yet.
[...]

I do not really get what you say here, but anything mentioned above
(scoping, declare, bool) is also covered by C compilers implementing the
C90/C99 subsets (so nearly any except the really old ones and the MS C
compilers up to at least VS.NET 2005) :-).

Regards
Marcus


pgpJ26lNr1YS7.pgp
Description: PGP signature

Re: [pygame] MMX Transform for Win32

[Brian Fisher]

On Mon, Mar 10, 2008 at 2:40 PM, Marcus von Appen <[EMAIL PROTECTED]> wrote:
>  C++ adds a lot of unnecessary overhead, limits the portability and makes
>  anything just a bit harder.
>
with respect to unnecessary overhead, if you don't use a C++ feature
it doesn't add any overhead at all to the compiler output over
compiling the same code as C (that was one of Stroustrop's key design
goals when making C++). The C++ feature AGG uses the most is
templating (it almost never uses virtual functions), which adds no
overhead at all, and is far superior to trying to achieve the same
goals of templating using just C. What specific overhead would someone
expect to be added simply by using C++ compilers?

In terms of portability, in terms of agg code, it's already highly
tested and developed to be portable, and it doesn't use stl or other
c++ portability pitfalls. So the issue would just be the portability
of C++ in general - so what platforms don't have c++ compilers that
are readily available if not already built in to the same package that
provides C compiling?

As far as the idea of C++ making anything just a bit harder - I
completely disagree in that C++ is a much better C compiler (scoping
of variables, declare them anywhere you want, a bool type) so
everything is easier until you run into a C++ construct you just
haven't learned yet. But specifically in the case of agg, it uses
templates which can be confusing and awkward at first - but using
agg's configurable graphics pipeline system to do rendering stuff is
ultimately way easier than trying to write C code to do the same stuff
because it's so flexible and easy to adapt (basically it's a solution
that front loads some early complexity for huge productivity gains).
What specifically do people think they'd find harder in this case?

Re: [pygame] MMX Transform for Win32

[Marcus von Appen]

On, Mon Mar 10, 2008, Brian Fisher wrote:

> On Mon, Mar 10, 2008 at 2:04 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> >  It sounds amazing, but according to the web site,
> >  it's C++. Do we really want to make pygame dependent
> >  on C++ code?
> >
> I think gcc supports C++ as a rule. Aside from interfacing the C++
> code from the C code with extern "C" statements, what would be the
> difficulty there?

C++ adds a lot of unnecessary overhead, limits the portability and makes
anything just a bit harder.

Regards
Marcus


pgpf74XczeNmJ.pgp
Description: PGP signature

Re: [pygame] MMX Transform for Win32

[Brian Fisher]

On Mon, Mar 10, 2008 at 2:04 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>  It sounds amazing, but according to the web site,
>  it's C++. Do we really want to make pygame dependent
>  on C++ code?
>
I think gcc supports C++ as a rule. Aside from interfacing the C++
code from the C code with extern "C" statements, what would be the
difficulty there?

Re: [pygame] MMX Transform for Win32

[Marcus von Appen]

On, Sun Mar 09, 2008, Brian Fisher wrote:

> If  were going to have something like that (a warping function) in
> PyGame, I would definitely want it to use anti-grain-geometry
> (http://antigrain.com ) rather than use a newly coded up function. AGG
> has been around for a very long time, is highly tested, and once you
> code up the basic integration issues a huge world of completely
> awesome 2d software rendering falls out fairly easily (gaussian blur,
> vector shape rendering, textured lines, etc. etc.)

We can only use versions up to 2.4 from it due to its licensing.
And we'd have to rely on C++ instead of C which is a big backdraw.

Regards
Marcus


pgpqf4Ew7hIgz.pgp
Description: PGP signature

Re: [pygame] MMX Transform for Win32

[Ian Mallett]

Our motto:  "Takes the "C++" out of "Game Development""

Re: [pygame] MMX Transform for Win32

[Greg Ewing]

Brian Fisher wrote:

If  were going to have something like that (a warping function) in
PyGame, I would definitely want it to use anti-grain-geometry
(http://antigrain.com )


It sounds amazing, but according to the web site,
it's C++. Do we really want to make pygame dependent
on C++ code?

--
Greg

Re: [pygame] MMX Transform for Win32

[Lenard Lindstrom]

Jason Ward wrote:


The assembler code is in SVN. The code is in routines:
filter_shrink_X_MMX, filter_expand_X_MMX, filter_shrink_Y_MMX and
filter_expand_Y_MMX.

--
Lenard Lindstrom
<[EMAIL PROTECTED] >


I looked through it but I don't think I'm gonna be able to be much help.

Thanks for the offer though. This project is too big to tackle before 
the 1.8 release anyway. An MinGW compiled transform.pyd module can be 
used in the Windows binaries. And I have an idea that the translation 
can be aided by compiling the AT&T code, then disassembling it as Intel 
statements. But that is for another day.


--
Lenard Lindstrom
<[EMAIL PROTECTED]>

Re: [pygame] MMX Transform for Win32

[Richard Goedeken]

Ian Mallett wrote:
On Sun, Mar 9, 2008 at 9:22 AM, Richard Goedeken 
<[EMAIL PROTECTED] 
> wrote:


But be warned that it will be quite a bit
slower than a pure scaling function.

Why?  3D engines like OpenGL can do this operation for thousands of 
quads each frame while maintaining a great framerate.  Doing it for one 
quad shouldn't be too hard.


Because I wrote vector assembly code in MMX to accelerate the smooth scaling 
function, plus I used some algorithmic simplifications.  But this warping 
operation requires rasterization, which is a more complicated algorithm, and I 
was only planning to write it in C.  The execution time would be proportional to 
the size of the transformed quad, so for a few small quads it would be fast. 
But scalar C code can't get close to the performance of hand-written vector code 
running on dedicated hardware (GPUs); not even MMX code can get close.


Richard

Re: [pygame] MMX Transform for Win32

[Ian Mallett]

On Sun, Mar 9, 2008 at 9:22 AM, Richard Goedeken <
[EMAIL PROTECTED]> wrote:

> But be warned that it will be quite a bit
> slower than a pure scaling function.

Why?  3D engines like OpenGL can do this operation for thousands of quads
each frame while maintaining a great framerate.  Doing it for one quad
shouldn't be too hard.

Re: [pygame] MMX Transform for Win32

[Lenard Lindstrom]

Deciding how to handle assembly code in future Pygame releases will 
probably take up its own mailing list thread. But when I do a Google 
search on the topic of Intel assembly code and gcc I get this, 
http://www.acm.uiuc.edu/sigmil/RevEng/ch02.html , which claims the GNU 
assembler 'as' "takes input as an AT&T or Intel syntax asm file". 
Pygame's assembly routines will likely end up in there own libraries and 
be linked in, possibly dynamically, as needed. So gcc C will no longer 
be a factor for assembly language compatibility.


Lenard


Richard Goedeken wrote:


A good portion of the work that I do in my day job involves writing 
MMX/SSE2 code, most of which needs to run in both Win32 and Linux, and 
on both 64-bit and 32-bit systems.  So I deal with this problem a 
lot.  To my knowledge, there is no effort to add an Intel-style inline 
assembly capability to GCC.  If someone knows of such an effort then I 
would be very interested to learn about it.  I agree that writing, 
testing, and supporting 2 or 3 implementations of the same routine 
with #ifdefs really sucks.


The other way I deal with this problem at work is to use an external 
assembler such as NASM.  This can be made to work under both Linux and 
Win32 with the same assembly source code quite easily.  The 
disadvantage with this approach is that it introduces another tool 
dependency.

Re: [pygame] MMX Transform for Win32

[Jason Ward]

>
> The assembler code is in SVN. The code is in routines:
> filter_shrink_X_MMX, filter_expand_X_MMX, filter_shrink_Y_MMX and
> filter_expand_Y_MMX.
>
> --
> Lenard Lindstrom
> <[EMAIL PROTECTED]>


I looked through it but I don't think I'm gonna be able to be much help.

Re: [pygame] MMX Transform for Win32

[Brian Fisher]

If  were going to have something like that (a warping function) in
PyGame, I would definitely want it to use anti-grain-geometry
(http://antigrain.com ) rather than use a newly coded up function. AGG
has been around for a very long time, is highly tested, and once you
code up the basic integration issues a huge world of completely
awesome 2d software rendering falls out fairly easily (gaussian blur,
vector shape rendering, textured lines, etc. etc.)

On Sun, Mar 9, 2008 at 9:22 AM, Richard Goedeken
<[EMAIL PROTECTED]> wrote:
> Are there other people interested in adding this kind of function to the 
> pygame
>  library?  If there is significant interest in a 'warping' function like 
> this, I
>  can take the time to code it up.  But be warned that it will be quite a bit
>  slower than a pure scaling function.
>
>  Richard
>
>
>  Ian Mallett wrote:
>  > On Sat, Mar 8, 2008 at 8:03 PM, Richard Goedeken
>  > <[EMAIL PROTECTED]
>
>
> > > wrote:
>  >
>  > Regarding your previous message, I presume you are referring to
>  > transforming a
>  > rectangular pixel map into an arbitrary quadrilateral?
>  >
>  > Yes.
>

Re: [pygame] MMX Transform for Win32

[Lenard Lindstrom]

As interesting as this tool may be, it is too late to include in Pygame 
1.8. At this point only bug fixes should be considered. As to whether or 
not the next Pygame release should support more elaborate 
transformations, and to what uses they would be put, deserves its own 
discussion.


Lenard


Richard Goedeken wrote:
Are there other people interested in adding this kind of function to 
the pygame library?  If there is significant interest in a 'warping' 
function like this, I can take the time to code it up.  But be warned 
that it will be quite a bit slower than a pure scaling function.


Richard

Ian Mallett wrote:
On Sat, Mar 8, 2008 at 8:03 PM, Richard Goedeken 
<[EMAIL PROTECTED] 
> wrote:


Regarding your previous message, I presume you are referring to
transforming a
rectangular pixel map into an arbitrary quadrilateral?

Yes.

Re: [pygame] MMX Transform for Win32

[Richard Goedeken]

Lenard Lindstrom wrote:
Giving this more thought it is too late in the Pygame release cycle to 
add an Intel translation of the assembly code to Pygame 1.8.0. This 
would lead to four versions of each of four subroutines. The resulting 
conditional expressions will be ungainly. Also the Intel translations 
will need properly tested. The AT&T assembly code has been out for 
awhile and shows no problems. For the moment a MinGW compiled 
transform.pyd can be used in the Windows binaries for Pygame 1.8.0. But 
it is desirable to translate the AT&T assembly code to Intel at some 
point in the future. If the gcc x86 C compiler truly handle VC style 
inlined assembly, including C identifiers within assembly code, then the 
AT&T code can be entirely replaced. Otherwise separate AT&T and Intel 
versions will need to be maintained. It has also been discussed to 
reintroduce the original SSE versions of the routines. But this will 
involve a rethink on how MMX/SSE support is provided.


A good portion of the work that I do in my day job involves writing MMX/SSE2 
code, most of which needs to run in both Win32 and Linux, and on both 64-bit and 
32-bit systems.  So I deal with this problem a lot.  To my knowledge, there is 
no effort to add an Intel-style inline assembly capability to GCC.  If someone 
knows of such an effort then I would be very interested to learn about it.  I 
agree that writing, testing, and supporting 2 or 3 implementations of the same 
routine with #ifdefs really sucks.


The other way I deal with this problem at work is to use an external assembler 
such as NASM.  This can be made to work under both Linux and Win32 with the same 
assembly source code quite easily.  The disadvantage with this approach is that 
it introduces another tool dependency.


Richard

Re: [pygame] MMX Transform for Win32

[Lenard Lindstrom]

Lenard Lindstrom wrote:

Richard Goedeken wrote:
I think I posted it on this email list when it was done; maybe noone 
merged it into the SVN tree?  I don't think I have write access to 
SVN, otherwise I would have merged it.


I have attached a zip file with the code.

Richard

Jason Ward wrote:

I just looked in transform.c and I haven't seen any asm code at all.
maybe point me to a function name or a code line number
The assembler code is in SVN. The code is in routines: 
filter_shrink_X_MMX, filter_expand_X_MMX, filter_shrink_Y_MMX and  
filter_expand_Y_MMX.


Giving this more thought it is too late in the Pygame release cycle to 
add an Intel translation of the assembly code to Pygame 1.8.0. This 
would lead to four versions of each of four subroutines. The resulting 
conditional expressions will be ungainly. Also the Intel translations 
will need properly tested. The AT&T assembly code has been out for 
awhile and shows no problems. For the moment a MinGW compiled 
transform.pyd can be used in the Windows binaries for Pygame 1.8.0. But 
it is desirable to translate the AT&T assembly code to Intel at some 
point in the future. If the gcc x86 C compiler truly handle VC style 
inlined assembly, including C identifiers within assembly code, then the 
AT&T code can be entirely replaced. Otherwise separate AT&T and Intel 
versions will need to be maintained. It has also been discussed to 
reintroduce the original SSE versions of the routines. But this will 
involve a rethink on how MMX/SSE support is provided.


--
Lenard Lindstrom
<[EMAIL PROTECTED]>

Re: [pygame] MMX Transform for Win32

[Richard Goedeken]

Are there other people interested in adding this kind of function to the pygame 
library?  If there is significant interest in a 'warping' function like this, I 
can take the time to code it up.  But be warned that it will be quite a bit 
slower than a pure scaling function.


Richard

Ian Mallett wrote:
On Sat, Mar 8, 2008 at 8:03 PM, Richard Goedeken 
<[EMAIL PROTECTED] 
> wrote:


Regarding your previous message, I presume you are referring to
transforming a
rectangular pixel map into an arbitrary quadrilateral?

Yes.

Re: [pygame] MMX Transform for Win32

[Ian Mallett]

On Sat, Mar 8, 2008 at 8:03 PM, Richard Goedeken <
[EMAIL PROTECTED]> wrote:

> Regarding your previous message, I presume you are referring to
> transforming a
> rectangular pixel map into an arbitrary quadrilateral?

Yes.

Re: [pygame] MMX Transform for Win32

[Richard Goedeken]

The pygame.transform.smoothscale.__doc__ gives the usage information.  It scales 
 an image smoothly (and quickly, with the MMX code) using a bilinear filter for 
upsampling and a novel area-based filter for downscaling which minimizes moire 
patterns on highly downscaled images.  Each axis can be scaled independently 
(ie, there's no requirement to keep the same aspect ratio).  My goals in writing 
this routine were to achieve high image quality and high speed.


Regarding your previous message, I presume you are referring to transforming a 
rectangular pixel map into an arbitrary quadrilateral?  It would be easy enough 
to write a C function to do this but it would be slow.  Writing accelerated 
(MMX) code for this type of routine would be time-consuming, and it wouldn't 
achieve the same level of speedup that I got with the smoothscale function.


Richard


Ian Mallett wrote:

Thanks.  How can one use this with Python?

Re: [pygame] MMX Transform for Win32

[Lenard Lindstrom]

Richard Goedeken wrote:
I think I posted it on this email list when it was done; maybe noone 
merged it into the SVN tree?  I don't think I have write access to 
SVN, otherwise I would have merged it.


I have attached a zip file with the code.

Richard

Jason Ward wrote:

I just looked in transform.c and I haven't seen any asm code at all.
maybe point me to a function name or a code line number
The assembler code is in SVN. The code is in routines: 
filter_shrink_X_MMX, filter_expand_X_MMX, filter_shrink_Y_MMX and  
filter_expand_Y_MMX.


--
Lenard Lindstrom
<[EMAIL PROTECTED]>

Re: [pygame] MMX Transform for Win32

[Ian Mallett]

Thanks.  How can one use this with Python?

Re: [pygame] MMX Transform for Win32

[Ian Mallett]

Can we add a transform feature to stretch a rectangle to a new size--but not
necessarily rectangular?

Re: [pygame] MMX Transform for Win32

[Richard Goedeken]

Marcus von Appen wrote:


The code first needs to be brought into shape (there are some minor
issues, if I remember correctly) and be sync'ed with the latest changes
in SDL_gfx. At least the parts taken from it.

Regards
Marcus


I added a new function to the transform module called 'smoothscale'; it's all 
computed in software and doesn't use anything from SDL_gfx.  Do you have a list 
of the problems encountered with this function?


Richard

Re: [pygame] MMX Transform for Win32

[Jason Ward]

I just looked in transform.c and I haven't seen any asm code at all.
maybe point me to a function name or a code line number

Re: [pygame] MMX Transform for Win32

[Marcus von Appen]

On, Sun Mar 09, 2008, Richard Goedeken wrote:

> The code is in src/transform.c in the pygame tree.  The task at hand is to 
> translate the 32-bit MMX code (I think there's 4 sections of code, each 
> about 40-60 lines) from the AT&T syntax used by GCC to the Intel style used 
> by VC. The Intel format is compatible with masm, nasm, yasm, etc.  It's 
> pretty easy to read.  The AT&T style is quite powerful but very strange 
> looking, and if you don't have an inclination to learn a bit about it then 
> the translation would be very hard.  Take a look at it and let me know if 
> you want to take a crack at it.  I could always proof-read it.

The code first needs to be brought into shape (there are some minor
issues, if I remember correctly) and be sync'ed with the latest changes
in SDL_gfx. At least the parts taken from it.

Regards
Marcus


pgpgWEETAm5gt.pgp
Description: PGP signature

Re: [pygame] MMX Transform for Win32

[Richard Goedeken]

The code is in src/transform.c in the pygame tree.  The task at hand is to 
translate the 32-bit MMX code (I think there's 4 sections of code, each about 
40-60 lines) from the AT&T syntax used by GCC to the Intel style used by VC. 
The Intel format is compatible with masm, nasm, yasm, etc.  It's pretty easy to 
read.  The AT&T style is quite powerful but very strange looking, and if you 
don't have an inclination to learn a bit about it then the translation would be 
very hard.  Take a look at it and let me know if you want to take a crack at it. 
 I could always proof-read it.


Richard

Jason Ward wrote:

what is this MMX discussion about and the transform function?
If this is to do with pygame source I may be interested. but not to 
solely do it, just to give a rather small helping hand.
I know intel asm but I haven't really gotten into MMX so this would be a 
great opportunity for me to get into it.

So I might be able to help you do it Richard.

Just direct me in exactly what it is :)

Re: [pygame] MMX Transform for Win32

[Jason Ward]

what is this MMX discussion about and the transform function?
If this is to do with pygame source I may be interested. but not to solely
do it, just to give a rather small helping hand.
I know intel asm but I haven't really gotten into MMX so this would be a
great opportunity for me to get into it.
So I might be able to help you do it Richard.

Just direct me in exactly what it is :)