Re: Progress Update

[Christian Reiniger <warewolf@mayn.de>]

Pierre Phaneuf wrote:

>> There are atleast a couple of issues I couldn't have forseen if I had just
>> implemented HashTable as a linked list. Its not just as simple as "find this
>> entry for me". HashTable also knows how to serialize itself, its members,
>> and its DynHashTable alteration technique surely wouldn't have found its way
>> into a linked list.
>
>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.

>> No. The reason PenguinPlay died out was that there was alot of talk, but no
>> action. That is not the current situation: we have alot of talk, but we
>> *also* have action. That's how it IMHO works best.
>
>We need *lot* of action. Not simple action. :-)

Want to help? ;)

>> In other words, it doesn't slow down other parts of PenguinPlay, and I
>> actually think PenguinFile is well ahead.
>
>Where is PenguinDraw, PenguinSound, PenguinEverythingElse?

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

>> > and fix it. Heck, it could prove to be totally sufficient and I'd just
>> > spare me the whole trouble!
>> 
>> We knew that wouldn't be the case.
>
>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?

Another thing - how can I predict what games will use PenguinFile? How
these games behave?
As it is now it doesn't matter for PFile - it is fast enough no matter what
kind of game you use it in. That's how it should be for a library.

>For PenguinPlay, the danger isn't in requiring powerful machines or
>being a problem to port (because you're doing the ports yourself), but
>it is in being overtaken by other projects.

Sure. But it will be overtaken easier if it has too little functionality,
too few benefits.

>I think PenguinPlay started before ClanLib and SDL (as far as I
>remember), but as "properly done" PenguinPlay might be when it is
>finished, it will be IRRELEVANT, as one (or the two) of ClanLib or SDL
>(or others) will become widely available on Linux distributions and

LibPenguinPlay is in no rivalry to Clanlib, SDL etc - it tries to
*complement* them, to add the missing pieces and to partly provide better
versions of some selected specific parts.
LibPenguinPlay is *not* a complete game library, and that's good.

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.

Now the chance to write a complete game sdk has passed, and so PenguinPlay
has changed.

>> Well, its quite simply that PenguinFile offers alot of benefits (which will
>> improve with time), almost without any drawbacks. All you have to do is
>> replace the standrad fopen() with the PFile fopen(), fwrite() with the PFIle
>> fwrite() and so on. Very simple. Only real alteration is the mount/unmount
>> process, but that can, in some cases, be handeld by ONE line of code (ok, a
>> little more perhaps, but not much).
>> 
>> Something so simple gives you a whole range of benefits. If you are creating
>> the right kind of game, PFile will be a given. In many other cases too. I
>> think even programs that are not games, but use alot of static data, could
>> benefit from PFile.
>
>No doubt about that. Why is Quake3 not using PenguinFile? Or Myth 2?
>There is no such facility in SDL, they could have used PenguinFile, no?

No. Because PFile wasn't ready for it. And - SDL will propably adopt PFile
for that. Sam Lantiga (the main SDL author) contacted me about that some
time ago.

>> I doubt alot of people would use PFile if it actually degraded their game's
>> performance...
>
>How can you possibly *degrade* the performance over
>fopen/fread/fwrite/fclose? And a little overhead in a little-frequented

Simple. Some levels of indirection, inefficient data structures etc.

>code path won't make anybody lose sleep.

Well, would you add some code to your game to make it slower?


-------

I read the worse-is-better text, and I agree with it to about, say, 95%.

Perhaps you have a wrong impression of what we're doing here (?).
Anyway, I *do* aim for perfection, but I also know that this goal is
impossible to reach, just as it is impossible to explore all of the
universe. But does that mean starting with it is futile?

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. 

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.


	Christian
-- 

Drive A: not responding...Formatting C: instead