Re: Progress Update

[Pierre Phaneuf <pp@ludusdesign.com>]

Christian Reiniger wrote:

> > Very few things are not serializable. Sometimes, the serialization code
> > can be awful, but it is doable most of the time. I assume the
> 
> What's better, a simple data structure plus awful serialization code or a
> little more complex data structure plus nice serialization code?
> 
> As said before, the algorithms we use now were simple to write and took
> only little time, yet they make the system cleaner and much faster.

I agree, what work has been done I am confident is good work and I do
not suggest ripping them out. I am only suggesting for further works to
accelerate development.

Use the bazaar. For this, you have to release *working* code. That's the
only requirement by the way. It might get redesigned and rewritten no
less than a few times during the course of its life, but that is no
problem, isn't it? :-)

See
http://tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar-9.html
for some thoughts on this (you probably already read this, but a refresh
doesn't hurt sometimes!)...

To answer your question about simple data structure versus a little more
complex data structures: both of the data structures and serialization
code are nicely tucked and hidden in well-encapsulated classes, right?
You know my answer.

IMHO, it is worth it investing a *bit* more time on the interface, then
crap out on the implementation to get a working one, possibly littering
in comments about ideas you'd have done if you didn't crap out. Then, as
time permit, you or another contributor (helped by the ideas in your
comments) go back over the code and fix it.

> >We need *lot* of action. Not simple action. :-)
> 
> Want to help? ;)

Yes, maybe I could! I don't know yet if the licensing will please my
Ludus colleagues (we'd prefer something like the MPL rather than the
LGPL, but this is still better than the GPL).

Quadra's resource file are going to be definitely left as they are, as
we declared no further work than minor improvements and bug fixing would
be done. We have to work on our next generation stuff (Quadra was more
of a test of development methods than anything else, but it has already
proven its addictiveness in its previous DOS-only incarnations).

But maybe PFile could be used as the resource file engine in our next
generation library toolkit. And we also need a better sound engine.

> > Where is PenguinDraw, PenguinSound, PenguinEverythingElse?
> 
> Do you miss them? BTW PenguinSound is well alive and progressing nicely.
> See one of the notes below.

Not that I miss them especially, I never had them. :-)

Where can I get *all* the sources to the current working code base?

> > You'd KNOW only if you build a game using PenguinFile, wielded a
> > profiler at it and looked at actual profiler output. Now you actually
> > THINK it wouldn't be sufficient, which is a *lot* different than
> > KNOWING.
> 
> Well, measuring times with a profiler would give bad data in this case.
> True, file access won't dramatically affect the average frame rate, but you
> sure noticed those situations where the frame rate seriously drops for
> perhaps 1/2 second while the HDD led flashes?

It could show up in a "time passed in a function". For example, XSync
makes the count go true the roof, that's rather expected. But the stuff
right next to it is the interesting stuff I look into.

> PenguinPlay was planned to be a complete game lib back when it started, but
> it never took off. Not because people were discussing too much on doing it
> properly, forever improving designs etc, but because people hesitated to
> invest time into the project.

This is too bad, I work nearly 8 hours a day on Ludus Design, and that
could easily be taken under Ludus Design stuff. We'll see, it will
depends on what you have and if it proves usable or fixable for our
tasks.

> > code path won't make anybody lose sleep.
> Well, would you add some code to your game to make it slower?

No, I would never do that. But I could omit adding code that would make
it faster. Depends on what it is.

> Just as space exploration benefits us (even if it just means discovering
> some planets rich on prescious elements), optimizing PenguinPlay and
> spending time on improving its design benefits its users.

Yes. Can I have it now? Can I? Now? 8-)

> Of course infinite optimization is bad, just as no optimization is. Now
> where is a good point to say it's optimized enough? Well, I'd say that
> point is after the best possible algorithms are applied and before the code
> is optimized line for line. Choosing the right algorithms made
> PenguinFile's file lookup from about 100% to several 1000% faster,
> depending on the situation.

Look, just release now and put a 0.1 version number or something to that
effect. Release early and release often, as one guy said. Then, when it
makes sense, slap on a 1.0 version number and be happy! Then, add some
features and make that a 1.1, and so on...

-- 
Pierre Phaneuf
http://ludusdesign.com/