Re: [Prboom-devel] current state and the future

[Florian 'P. S. <flo...@gm...>]

> > 4.4. Maybe another way for saving, because the savegames can't be as big on
> > the DC memorycard. Maybe we can get away with zlib compression.
>
> Also for in-game joining, which is what would make the client/server stuff
> interesting, we want *tiny* savegames so the state can be transmitted
> to new clients fast. There are huge savings to be made, I've been planning
> this for a while; and zlib will be a useful last stage. How small does DC
need?

The Standard DC memory card has 128kb. I have just made a Savegame of a fairly
big level (Artifact - The Return by TeamTNT) and it's 450kb, zipped it's 65kb.
That's really big. Maybe we should add a mechanism to allow one savegame where
everything is saved and more others where only the start of the level is saved.
So we can get away with a few stats like ammo, health, time and which level
(with which WAD-File for DC, because there everything is on a CD and the content
can't be changed).

> > 4.5. Ingame switching between different IWADs and PWADs.
>
> Reloading the table of lumps in w_wad.c is the easy bit; forcing other parts
> of the code to reload cached data is the hard part. I've simplified a few
> bits of code with this in mind in the past, but there's a way to go.

Things like the font and statusbar etc., maybe we only have to seperate the
loading functions for them.

> Also, the interface for choosing WADs from the in-game menus would be
> a significant amount of work.

We can do some simplifications I think.

> > Now to the questions. Should we do a new development branch for it, so we
can
> > easily fix bugs in the current version?
>
> Yes, I would, the networking in particular will be a massive overhaul.

Do you know how to do that best in CVS? I haven't done that before, just read
about it in the manual etc.

> >What about the version numbering, as far as I understand it, the version
> > 2.1 is a development version, because 1 is an odd number.
>
> This is a widely used convention in open source projects (which lxdoom
> followed).
>
> > Should we release a 2.2 version and then work on the 2.3 version...
>
> I would go for this option.
>
> I say we finish the sparc fixes (I've done all but one of those I took), then
> make a new release. Then hopefully we can begin the overhaul :-)

I think we should do a 2.1.2 release, ask if all bugs till now are fixed, and
then make a 2.2.0 release. The development branch is then 2.3.0.

> > Colin: What about the new cvs directory for the editing docs? I would like
to
> > see them ;)
>
> The docs source is in CVS, module "doc". It's in SGML. I'll put an HTML
> version on the website as http://prboom.sourceforge.net/editing/ for you
> to take a look.

I will take a look.

> I'd say the first steps of the overhaul would be:
>
> - rip out current networking
> - redesign the ticcmd_t structure (dump chatchar, add jump flag and
>  field for look up/down) (with the old version kept around and translated
>  for old demos)
> - reduce savegame size, implement zlib for savegames

Ok, it seems like you know most about that part of the Doom source. If I can
help you in any way, tell me.

Proff
--
Florian 'Proff' Schulze - flo...@gm...
Homepage:               - http://proff.fly.to
PGP-Key available from  - http://www.keyserver.net/en/