opendemo-devel

[opendemo-devel] zlib

[Conor D. <co...@ma...>]

Hello,

I've tried to add zlib support to a test mod, but it refuses to work when
compiled in qvm mode. It either bombs out to the console or crashes quake3
altogether. If you guys want to hack at it, I can commit it to cvs even
though it is broken (all the zlib stuff is in the opendemo/game/zlib
directory). Everything else should still work if you don't try to use a gzip
file.

I'm looking into just making my own deflate/inflate routines (it's something
I've wanted to do anyway). The zlib stuff shares some functionality with
od_filebuf.c, so maybe the reimplimentation could combine the two.

-Conor

Re: [opendemo-devel] zlib

[Dr. U. G. <Uwe...@ph...>]

Hello!

> I've tried to add zlib support to a test mod,
Yes! Nobody can say any longer: your XML text files are too long!

> ... but it refuses to work when
> compiled in qvm mode.
We can find the problem, I'm sure.

> It either bombs out to the console or crashes quake3
> altogether.
Sounds interesting.

> If you guys want to hack at it, I can commit it to cvs even
> though it is broken (all the zlib stuff is in the opendemo/game/zlib
> directory).
I did not find a zlib directory in opendem/src/q3a/opendemo/game/ and we don't
have a opendemo/game directory at all. So did you check it in already?
I would prefer opendem/src/libs/zlib as a more generic place.

> Everything else should still work if you don't try to use a gzip
> file.
So you used the standard zlib interface, which reverts to the plain file
behaviour, if the file was not compressed.

> I'm looking into just making my own deflate/inflate routines (it's something
> I've wanted to do anyway).
You're brave!

> The zlib stuff shares some functionality with
> od_filebuf.c, so maybe the reimplimentation could combine the two.
I think odFread() should be replaces by gzread() and nothing more. This can
easily be done before or after the ring-buffer comes in place.

My ring-buffer comes along nicely, the code is completely typed in, compiles
without warnings with GCC and qvm and does not crash, but it doesn't do
anything useful yet. I hope for a bit more debugging time over the weekend.

Bye, Uwe

Re: [opendemo-devel] zlib

[Conor D. <co...@ma...>]

Hello,

----- Original Message -----
From: "Dr. Uwe Girlich" <Uwe...@ph...>
To: "OpenDemo Development List" <ope...@li...>
Sent: Friday, January 11, 2002 1:06 AM
Subject: Re: [opendemo-devel] zlib
> [...]
> > If you guys want to hack at it, I can commit it to cvs even
> > though it is broken (all the zlib stuff is in the opendemo/game/zlib
> > directory).
> I did not find a zlib directory in opendem/src/q3a/opendemo/game/ and we
don't
> have a opendemo/game directory at all. So did you check it in already?
> I would prefer opendem/src/libs/zlib as a more generic place.

I meant that was the layout in my working directory (full path is
opendemo/src/q3a/opendemo/game/zlib). IMO opendemo/src/libs/ should be for
code that is not quake3-specific. The stuff that is in there right now can
be used in other things, but right now it is hard for them to tell if they
should #include <stdio.h> or #include "q_shared.h" (#ifdef Q3_VM is not good
enough because "q_shared.h" should be used when compiling a native library
for a quake3 mod).

As I said in my earlier message, we could just move everything inside the
mod's game directory and use them just for quake3 mods. Is the stuff in
there really that useful outside of quake3?

> > Everything else should still work if you don't try to use a gzip
> > file.
> So you used the standard zlib interface, which reverts to the plain file
> behaviour, if the file was not compressed.

Correct.

> [...]
> > The zlib stuff shares some functionality with
> > od_filebuf.c, so maybe the reimplimentation could combine the two.
> I think odFread() should be replaces by gzread() and nothing more. This
can
> easily be done before or after the ring-buffer comes in place.

I had thought that zlib kept its own buffer for decompressed data, but it
appears that it does not.

> My ring-buffer comes along nicely, the code is completely typed in,
compiles
> without warnings with GCC and qvm and does not crash, but it doesn't do
> anything useful yet. I hope for a bit more debugging time over the
weekend.

I'll commit my code if you commit yours... :)

I'll move the zlib code over from the test mod to the opendemo tree (in
opendemo/src/libs) tomorrow.

-Conor

Re: [opendemo-devel] zlib

[Dr. U. G. <Uwe...@ph...>]

Hello!

> As I said in my earlier message, we could just move everything inside the
> mod's game directory and use them just for quake3 mods. Is the stuff in
> there really that useful outside of quake3?
You're totally right. A memory buffer, file-buffer or a XML parser aren't so
special. There are other full-featured software projects out there dealing
only with this kind of stuff.

We could equally put everything in the main game directory.

> > > The zlib stuff shares some functionality with
> > > od_filebuf.c, so maybe the reimplimentation could combine the two.
> > I think odFread() should be replaces by gzread() and nothing more. This
> > can easily be done before or after the ring-buffer comes in place.
> I had thought that zlib kept its own buffer for decompressed data, but it
> appears that it does not.
Even if it keeps its own buffer, the API is gzread() only. I'm sure zlib has
a backlog buffer; thats the base idea of decompression: pointer to already
found material some bytes ago. If you increase this window, you get better
compression but the zlib standard API is gzread() as a direct replacement for
read().

> I'll commit my code if you commit yours... :)
I have one hour this evening and maybe two tomorrow. This should be enough.

> I'll move the zlib code over from the test mod to the opendemo tree (in
> opendemo/src/libs) tomorrow.
I think you just convinced me, that opendemo/src/q3a/opendemo/game/zlib is a
better place? But it is your code and your directory layout anyway.

Bye, Uwe