On Tue, Jan 6, 2009 at 10:59 PM, Jake b <ninmonk...@gmail.com> wrote: > @OP: for file saving, have you messed with pickle? > > On Tue, Jan 6, 2009 at 6:10 PM, Patrick Mullen <saluk64...@gmail.com> 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.
