Re: [pygame] Working on Retro 80s Game SDK, Looking for general support

["Patrick Mullen" <saluk64007@xxxxxxxxx>]

On Tue, Jan 6, 2009 at 10:59 PM, Jake b <ninmonkeys@xxxxxxxxx> wrote:
> @OP: for file saving, have you messed with pickle?
>
> On Tue, Jan 6, 2009 at 6:10 PM, Patrick Mullen <saluk64007@xxxxxxxxx> wrote:
>>
>> Also, automated testing is really important when building a framework.
>>  I had to throw
>> out my own framework and start over because the code was bad enough it
>> would
>> have taken too much time to fix all of the problems, and I had no
>> tests to verify
>> that my changes weren't breaking things.  Every fix I did broke
>> something else that I
>> didn't know about.  Now that I have a huge test suite, I am more
>> flexible in adding
>> new features or subtly changing the code.
>
>
> Do you mean using: doctests and Unittests ? [
> http://docs.python.org/library/doctest.html,
> http://docs.python.org/library/unittest.html ]
>
> Or do you do more? I'd like to know more information.
>
> --
> Jake
>
Yeah, I'm talking about unit tests basically.

Well, I use my own testing suite I wrote, because I didn't feel like learning
the others.  It somewhat resembles unittest though, and that's probably
a good thing to learn.  Doc tests might be worth looking into as well.
I actually wrote the tests first.  For instance, one of my tests
creates an animation
object, with a "play_3_times" behavior.  Then, I continually call
next_frame() on the
animation, to tell it to go to the next frame.  After what should have
been 3 times
through, I use the "assert" statement to make sure that the frame counter is no
longer progressing.  Later, if I change some of the animation code
somewhere that
might mess up the play_3_times behavior, when i run the tests that
test will error,
and I'll know I broke something.

Much more could be said about tests, look for test-first development,
which is basically
what I am experimenting with.  After a history of numerous codebases
that are very
difficult for me to work on due to not knowing what might break if I
change or add
anything, I decided to try something different.  It's difficult to
know what to test and how
to test, but I think it pays off.

Oh, one thing that was VERY difficult was how to test any of the
drawing code.  I found
a program called "perceptualdiff" which can compare images even if the
colors or filetypes
or bytes differ, but from a human perspective they look the same.  So
I have a reference
image and the test produces a secondary image to compare with the
reference.  It's
far from ideal, but it's the best I could find.  My engine supports
software or opengl
backends, so checking the drawing was a pretty high priority.  Doing
ad-hoc tests (where
you run some toy program and fiddle with it to check that its working,
like I used to do) was
a nightmare because I always forgot to go back and check the other display mode.

TheMusicGuy wrote:
> Generally, though, I am trying to make sure that the engine works in a
> way that will allow XML to work. With that much settled, the editors
> shouldn't be too difficult. As soon as I finish the menu module I can
> begin work on the image/animation editor, then I'll be able to make
> better judgments.

Sounds like you are thinking about these issues, so that's good.  I was thinking
more of the logic editor than the image editor, but maybe you are not that
ambitious for that :)

> Well...three things:

The problem with draw speed comes more from the fact that software drawing is
slow at higher resolutions.  Since you are focusing on 8/16bit, this
isn't so bad,
but if you want anything better than that, you really want to talk to
the graphics
card's powerful rendering hardware.  Most of which is not used in 2d drawing.
If graphics are a bottleneck, and with the exception of collision
detection usually
are the primary bottleneck, switching to opengl is a much greater gain than
converting code to C.  Since you have already abstracted away surfaces, you can
add in an opengl draw model at a later time if it is needed, so that's
good.  I have
had good results doing a similar thing in my engine.

You may not need it though.  Don't rewrite anything in C unless you know where
the slowdown is coming from :)

Event manager - doubtful to need any optimization
Physics - yeah, this probably needs it, depending on how complex it
is.  Might be
better, since there are so many of them out there, to find an existing
one.  Last Summer
of Code a pygame physics engine was started, I don't know if it was
completed.  This
adds a dependancy, but better than trying to tackle such a difficult
subject when you
have so many other things.

> Thanks. I was afraid people were going to tell me not to bother with
> something like this since there are already several projects that
> resemble this one. I just hope I can take it to the next level before
> school starts up again--only two short weeks left!

As many frameworks as we can get in my opinion!  Plus, if it's
fun/educational for you, why not.