Hello,
Does anybody know here some stable-complete gui to use with SDL?
Thanks
Reinaldo Quaresma
www.popcom.inf.br
Does anybody know here some stable-complete gui to use with SDL?
http://www.libsdl.org/libraries.php
“ParaGUI” is one that gets a lot of discussion time around here and has
several interesting features; there are others that are also quite good.
–ryan.
But the paragui.org isn’t on air at this moment. 
I will check it on google.
*********** REPLY SEPARATOR ***********On 01/07/02 at 16:37 Ryan C. Gordon wrote:
Does anybody know here some stable-complete gui to use with SDL?
http://www.libsdl.org/libraries.php
“ParaGUI” is one that gets a lot of discussion time around here and has
several interesting features; there are others that are also quite good.–ryan.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
But the paragui.org isn’t on air at this moment.
I will check it on google.
keep trying. Most of the time you cant reach it.On Mon, 1 Jul 2002, REINALDO QUARESMA wrote:
–
Roger D. Vargas | El sistema se apagara en 5 segundos.
ICQ: 117641572 | Salvese el que pueda!
Linux User: 180787 |
You can also try
http://savannah.gnu.org/projects/paragui/
For the project page on savannah.
Andrew.
— “Roger D. Vargas” wrote:> On Mon, 1 Jul 2002, REINALDO QUARESMA wrote:
But the paragui.org isn’t on air at this moment.
I will check it on google.
keep trying. Most of the time you cant reach it.–
Roger D. Vargas | El sistema se apagara en 5
segundos.
ICQ: 117641572 | Salvese el que pueda!
Linux User: 180787 |
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
Note, ParaGUI doesn’t work with OpenGL natively - it uses SDL_OPENGLBLIT.
I suggested that this would be the first thing I’d remove in favor of a
real OpenGL backend and was flamed.
If you’re using software rendering only, it’s pretty useful. If you’re
using OpenGL, it’s completely useless. You might be able to get it to
work with glSDL maybe, but in the end I think I’d rather see yet another
GUI project which supported both OpenGL and software rendering. Such a
thing is on my todo list at some point.On Mon, Jul 01, 2002 at 04:37:55PM -0400, Ryan C. Gordon wrote:
Does anybody know here some stable-complete gui to use with SDL?
http://www.libsdl.org/libraries.php
“ParaGUI” is one that gets a lot of discussion time around here and has
several interesting features; there are others that are also quite good.
–
Joseph Carter Don’t feed the sigs
when you start making only stupid mistakes that are obvious, thats
when you start getting competent
because you don’t make fundamental misunderstanding mistakes
and thats a good sign.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020702/393c5e86/attachment.pgp
Yes. Joseph.
We already know that.
BTW, Teunis Peters is currently writing the native OpenGL port.
So your warning renders itself obsolete.
AlexAm Die, 2002-07-02 um 09.18 schrieb Joseph Carter:
On Mon, Jul 01, 2002 at 04:37:55PM -0400, Ryan C. Gordon wrote:
Does anybody know here some stable-complete gui to use with SDL?
http://www.libsdl.org/libraries.php
“ParaGUI” is one that gets a lot of discussion time around here and has
several interesting features; there are others that are also quite good.Note, ParaGUI doesn’t work with OpenGL natively - it uses SDL_OPENGLBLIT.
I suggested that this would be the first thing I’d remove in favor of a
real OpenGL backend and was flamed.If you’re using software rendering only, it’s pretty useful. If you’re
using OpenGL, it’s completely useless. You might be able to get it to
work with glSDL maybe, but in the end I think I’d rather see yet another
GUI project which supported both OpenGL and software rendering. Such a
thing is on my todo list at some point.
Maybe if you hadn’t been so abrasive about it you
wouldn’t have been flamed 
(this reminds me of
something about a pot and a kettle…). Anyway,
Teunis Peters is working on a better OpenGL backend
for paragui using glSDL, at least for the moment.
It’s a work in progress, but at least it’s started.
Andrew.
— Joseph Carter wrote:> On Mon, Jul 01, 2002 at 04:37:55PM -0400, Ryan C. Gordon wrote:
Does anybody know here some stable-complete gui
to use with SDL?http://www.libsdl.org/libraries.php
“ParaGUI” is one that gets a lot of discussion
time around here and has
several interesting features; there are others
that are also quite good.Note, ParaGUI doesn’t work with OpenGL natively - it
uses SDL_OPENGLBLIT.
I suggested that this would be the first thing I’d
remove in favor of a
real OpenGL backend and was flamed.If you’re using software rendering only, it’s pretty
useful. If you’re
using OpenGL, it’s completely useless. You might be
able to get it to
work with glSDL maybe, but in the end I think I’d
rather see yet another
GUI project which supported both OpenGL and software
rendering. Such a
thing is on my todo list at some point.–
Joseph Carter
Don’t feed the sigswhen you start making only stupid mistakes
that are obvious, thats
when you start getting competent
because you don’t make fundamental
misunderstanding mistakes
and thats a good sign.
ATTACHMENT part 2 application/pgp-signature
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
[…]
If you’re using software rendering only, it’s pretty useful. If you’re
using OpenGL, it’s completely useless. You might be able to get it to
work with glSDL maybe,
Yeah - but then one would have to make glSDL cooperat nicely with “user” OpenGL code, and that’s not a high priority for me, at least. It’s beyond the scope of glSDL.
(Keep an eye on the higher levels of the “Spitfire Engine”; graphics engine of Kobo Deluxe - it’s about to get native OpenGL support.)
but in the end I think I’d rather see yet another
GUI project which supported both OpenGL and software rendering. Such a
thing is on my todo list at some point.
Same here, although I’m thinking more along the lines of a GtkCanvas/Flash hybrid, specifically designed for “weird” and flashy GUIs of the kind seen in games, media players and audio applications.
As a result of taking active part in a discussion on “audio GUIs” (VST/DX style stuff) on another list, I got contacted by the lead developer of an OpenGL only toolkit to be released soon. Might be a better idea than starting from scratch, but I can’t really tell at this point.
(Contact me off the list for details on my design, or whatever.)
//David
.---------------------------------------
| David Olofson
| Programmer
| david.olofson at reologica.se |
|---|
| Address: |
| REOLOGICA Instruments AB |
| Scheelev?gen 30 |
| 223 63 LUND |
| Sweden |
| --------------------------------------- |
| Phone: 046-12 77 60 |
| Fax: 046-12 50 57 |
| Mobil: |
| E-mail: david.olofson at reologica.se |
| WWW: http://www.reologica.se |
`-----> We Make Rheology RealOn Tue, 2/07/2002 00:18:27 , Joseph Carter wrote:
[…]
If you’re using software rendering only, it’s pretty useful. If you’re
using OpenGL, it’s completely useless. You might be able to get it to
work with glSDL maybe,Yeah - but then one would have to make glSDL cooperat nicely with "user"
OpenGL code, and that’s not a high priority for me, at least. It’s
beyond the scope of glSDL.(Keep an eye on the higher levels of the “Spitfire Engine”; graphics
engine of Kobo Deluxe - it’s about to get native OpenGL support.)
(Your lines aren’t warpping, David…)
It seems that making glSDL work with user OpenGL code wouldn’t be too
hard. I was already making the assumption that the OpenGL code in
question would simply restore the state to that which glSDL expects, but
if you want to make that an officially supported path at some point, you
can provide functions to query/save/restore OpenGL’s state. You can just
push the current transformation matrix and pop it afterward. Things like
the current color, blendfunc, etc, can be assumed to need resetting by the
user code…
Generally we tend to keep our color set to white, our frustum set to the
user’s chosen aspect/FOV, blending disabled with the blendfunc set to
alpha blending (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA), etc… If any part
of our engine changes these, it is expected that it will set them back
when it’s done. We lose a little performance because we still support
non-multitexture, so we’re always turning on and off a second TMU if
present, but it’s an acceptable (under 1% when GPU limited) tradeoff for
people who are already getting a 16% performance boost (again GPU limited,
we’re almost always CPU limited though) from having multitexture in the
first place… =)
Thankfully Neither is specced to have higher requirements. If you want to
run it, you will need ARB multitexture, texture env combine, dot3 bump
mapping, and half a dozen other things that any card worth using already
has, but which aren’t supported by idiot vendors like SiS… It’ll take us
at least another year to finish Neither. If stupid vendors don’t manage
to aquire a few clues by then, it’s Not My Problem™, buy an NVIDIA
card. Hey, by then even ATI might be stable enough - they are apparently
at least making some effort to produce a quality product for a change. 
but in the end I think I’d rather see yet another
GUI project which supported both OpenGL and software rendering. Such a
thing is on my todo list at some point.Same here, although I’m thinking more along the lines of a
GtkCanvas/Flash hybrid, specifically designed for “weird” and flashy
GUIs of the kind seen in games, media players and audio applications.
I was hoping for something very simple and clean. As with other things I
do because I’d rather not see people using the alternatives, I’d probably
BSD license the thing. (Mental reminder: actually finish the docs for
DynGL 3 and upload the thing to a site somewhere already!)
As a result of taking active part in a discussion on “audio GUIs”
(VST/DX style stuff) on another list, I got contacted by the lead
developer of an OpenGL only toolkit to be released soon. Might be a
better idea than starting from scratch, but I can’t really tell at this
point.(Contact me off the list for details on my design, or whatever.)
Interesting… =)On Tue, Jul 02, 2002 at 05:53:35PM +0200, David Olofson wrote:
–
Joseph Carter My opinions are always right
Guns don’t kill people. It’s those damn bullets. Guns just make them go
really really fast.
– Jake Johanson
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020702/a5462496/attachment.pgp
[…]
(Your lines aren’t warpping, David…)
They are here!
Another issue with this stupid web mail… (I’ll probably switch back to my real development system now, anyway.)
It seems that making glSDL work with user OpenGL code wouldn’t be too
hard.
[…]
Right; shouldn’t be a major problem - it just isn’t officially supported yet. (Or: You get to figure out what glSDL touches and depends on.
[…]
but in the end I think I’d rather see yet another
GUI project which supported both OpenGL and software rendering. Such a
thing is on my todo list at some point.Same here, although I’m thinking more along the lines of a
GtkCanvas/Flash hybrid, specifically designed for “weird” and flashy
GUIs of the kind seen in games, media players and audio applications.I was hoping for something very simple and clean.
Well, I’m aiming for something rather “simple and clean” in relation to the problem at hand. We’re not talking about some 5 different traditional widgets, but rather a dynamic structured graphics system with only a few visual objects, and some “behind the scenes” logic objects. Focus is on tools and “idea to solution”, rather than the actual toolkit or related APIs.
As with other things I
do because I’d rather not see people using the alternatives, I’d probably
BSD license the thing.
I’m an LGPL guy.
As a result of taking active part in a discussion on “audio GUIs”
(VST/DX style stuff) on another list, I got contacted by the lead
developer of an OpenGL only toolkit to be released soon. Might be a
better idea than starting from scratch, but I can’t really tell at this
point.(Contact me off the list for details on my design, or whatever.)
Interesting… =)
Well, remains to see how it turns out. They’re basically doing a traditional toolkit, but I could probably reuse their portable OpenGL layer, as well as parts of the toolkit. (I’ll still need the usual rendering stuff, event handling, etc…)
//David
.---------------------------------------
| David Olofson
| Programmer
| david.olofson at reologica.se |
|---|
| Address: |
| REOLOGICA Instruments AB |
| Scheelev?gen 30 |
| 223 63 LUND |
| Sweden |
| --------------------------------------- |
| Phone: 046-12 77 60 |
| Fax: 046-12 50 57 |
| Mobil: |
| E-mail: david.olofson at reologica.se |
| WWW: http://www.reologica.se |
`-----> We Make Rheology RealOn Tue, 2/07/2002 11:38:33 , Joseph Carter wrote:
As with other things I
do because I’d rather not see people using the alternatives, I’d probably
BSD license the thing.I’m an LGPL guy.
LGPL is a nifty license, but I like people to be able to static link these
things into their programs. If they can’t, people developing commercial
things will shy away from the library. You know how paranoid I am about
external dependencies.
The one library I want to not use, static or otherwise, is zlib. The code
is just nasty. My roommate and I have been talking about replacement zip
archive code for use in things like zziplib or PhysicsFS and BSDing it, if
for no other reason than that zlib is basically unreadable.
Well, remains to see how it turns out. They’re basically doing a
traditional toolkit, but I could probably reuse their portable OpenGL
layer, as well as parts of the toolkit. (I’ll still need the usual
rendering stuff, event handling, etc…)
That’s cool given that a traditional toolkit is all I really need. Though
I’d still prefer it to work with or without OpenGL. Not so much for
myself necessarily - I only spent 30 minutes or so looking at glSDL, after
all. You know me, I don’t blit surfaces, I emit meshes; I don’t draw
tiles, I batch polygons; etc… =)On Tue, Jul 02, 2002 at 10:16:15PM +0200, David Olofson wrote:
–
Joseph Carter If this sig were funny…
Reading computer manuals without the hardware is as frustrating as reading
sex manuals without the software.
- Arthur C Clarke
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020702/fc8394d9/attachment.pgp
As with other things I
do because I’d rather not see people using the alternatives, I’d probably
BSD license the thing.I’m an LGPL guy.
LGPL is a nifty license, but I like people to be able to static link these
things into their programs. If they can’t, people developing commercial
things will shy away from the library. You know how paranoid I am about
external dependencies.
Yeah… Still, I’d rather add an exception clause for static linking, than use the BSD license. This lack of a requirement to release the source code of derived works is a bit too liberal for my taste.
The one library I want to not use, static or otherwise, is zlib. The code
is just nasty. My roommate and I have been talking about replacement zip
archive code for use in things like zziplib or PhysicsFS and BSDing it, if
for no other reason than that zlib is basically unreadable.
bzip2?
Right, WinZip can’t read those files, bzip2 doesn’t read ZIP archives etc etc - but for the stuff I’m considering using it for, it’s perfect. (Some would probably even say it’s an advantage that the archives are a little bit hard for the average winuser to mess with.)
Well, remains to see how it turns out. They’re basically doing a
traditional toolkit, but I could probably reuse their portable OpenGL
layer, as well as parts of the toolkit. (I’ll still need the usual
rendering stuff, event handling, etc…)That’s cool given that a traditional toolkit is all I really need. Though
I’d still prefer it to work with or without OpenGL.
So would I. OpenGL is important as the chrome audio people have gotten used to these days is getting too expensive with software rendering - but applications should at least run without OpenGL.
Not so much for
myself necessarily - I only spent 30 minutes or so looking at glSDL, after
all.
Either way, I don’t think glSDL has much to do with this GUI toolkit thing. It’s either raw SDL 2D (and some nice s/w rendering code…) or native OpenGL, IMHO.
You know me, I don’t blit surfaces, I emit meshes; I don’t draw
tiles, I batch polygons; etc… =)
When it comes to 2D games, I actually prefer thinking of sprites and tiles at a much higher level than blits. As you can see in Kobo Deluxe, there are quite a few layers between the game logic and the actual rendering - some of which will eventually get native OpenGL alternatives. Sub-pixel accurate rendering, even for the tiled backgrounds.
//David
.---------------------------------------
| David Olofson
| Programmer
| david.olofson at reologica.se |
|---|
| Address: |
| REOLOGICA Instruments AB |
| Scheelev?gen 30 |
| 223 63 LUND |
| Sweden |
| --------------------------------------- |
| Phone: 046-12 77 60 |
| Fax: 046-12 50 57 |
| Mobil: |
| E-mail: david.olofson at reologica.se |
| WWW: http://www.reologica.se |
`-----> We Make Rheology RealOn Tue, 2/07/2002 13:40:07 , Joseph Carter wrote:
On Tue, Jul 02, 2002 at 10:16:15PM +0200, David Olofson wrote:
— David Olofson <david.olofson at reologica.se> wrote:
bzip2?
Bit slow for general file-access isn’t it? Even the
quake pak files are stored as uncompressed zips.
Either way, I don’t think glSDL has much to do with
this GUI toolkit thing. It’s either raw SDL 2D (and
some nice s/w rendering code…) or native OpenGL,
IMHO.
My preferred solution for paragui in OpenGL contexts
would be to have a seperate build of the library (i.e.
no fallback to 2D), and use native OpenGL. After all,
when the user is making a 3D app, there isn’t much
sense in falling back to 2D and trying to fake out the
user. glSDL, or at least parts of it, would come in
for internal library use, so that the 2D code in
paragui thinks it’s still dealing with regular 2D SDL
and doesn’t have to be rewritten. If we scavenged
parts of the glSDL code, I’m sure we could have a
native OpenGL renderer up fairly easily, since glSDL
has to do most of what’s required I’m guessing.
Andrew.__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
— David Olofson <david.olofson at reologica.se> wrote:
bzip2?
Bit slow for general file-access isn’t it? Even the
quake pak files are stored as uncompressed zips.
Doesn’t matter much when the whole archive is less than 10 kB compressed.
Either way, I don’t think glSDL has much to do with
this GUI toolkit thing. It’s either raw SDL 2D (and
some nice s/w rendering code…) or native OpenGL,
IMHO.My preferred solution for paragui in OpenGL contexts
would be to have a seperate build of the library (i.e.
no fallback to 2D), and use native OpenGL. After all,
when the user is making a 3D app, there isn’t much
sense in falling back to 2D and trying to fake out the
user.
Then, what about applications that should work with or without OpenGL?
glSDL, or at least parts of it, would come in
for internal library use, so that the 2D code in
paragui thinks it’s still dealing with regular 2D SDL
and doesn’t have to be rewritten. If we scavenged
parts of the glSDL code, I’m sure we could have a
native OpenGL renderer up fairly easily, since glSDL
has to do most of what’s required I’m guessing.
Well, it handles tiling of large textures and that sort of stuff…
Works for SFont surfaces, but someone (me!? has to implement
2D tiling as well, to handle surfaces that are too tall and too
high for the OpenGL setup at hand.
BTW, I’m working some on glSDL-0.4 now. Implemented blits from
and within the screen, and locking/direct rendering emulation,
but it isn’t working properly yet.
Speaking of which, I’m considering a “Dual Rendering” mode for
applications that for some strange reason can’t stay away from
reading the screen. The idea is basically to s/w render into
the screen shadow surface in parallel with the OpenGL rendering,
instead of using glReadPixels(). It would be very inefficient
compared to applications doing things the right way, but I’m
quite sure it can be a lot faster than reading the whole
OpenGL screen every time the screen surface is locked…
Another idea is to automatically activate Dual Rendering for
applications that do these OpenGL unfriendly things (like
locking the screen.) Just activate it as soon as a "violation"
is detected, and disable it again if no further nasty
operations are performed for a certain number of frames.
//David
.---------------------------------------
| David Olofson
| Programmer
| david.olofson at reologica.se |
|---|
| Address: |
| REOLOGICA Instruments AB |
| Scheelev?gen 30 |
| 223 63 LUND |
| Sweden |
| --------------------------------------- |
| Phone: 046-12 77 60 |
| Fax: 046-12 50 57 |
| Mobil: |
| E-mail: david.olofson at reologica.se |
| WWW: http://www.reologica.se |
`-----> We Make Rheology RealOn Tue, 2/07/2002 17:24:27 , Andrew Ford wrote:
— David Olofson <david.olofson at reologica.se> wrote:
Then, what about applications that should work with
or without OpenGL?
The main thrust behind OpenGL for paragui is in 3D
apps, in which case you probably don’t want a
fail-over.
glSDL, or at least parts of it, would come in
for internal library use, so that the 2D code in
paragui thinks it’s still dealing with regular 2D
SDL
and doesn’t have to be rewritten. If we scavenged
parts of the glSDL code, I’m sure we could have a
native OpenGL renderer up fairly easily, since
glSDL
has to do most of what’s required I’m guessing.Well, it handles tiling of large textures and that
sort of stuff…
Works for SFont surfaces, but someone (me!?
to implement
2D tiling as well, to handle surfaces that are too
tall and too
high for the OpenGL setup at hand.
This is the stuff that the OpenGL backend has to
present to the rest of paragui so that it can
transparently (to paragui) support OpenGL without
changing the rest of the source.
BTW, I’m working some on glSDL-0.4 now. Implemented
blits from
and within the screen, and locking/direct rendering
emulation,
but it isn’t working properly yet.Speaking of which, I’m considering a “Dual
Rendering” mode for
applications that for some strange reason can’t stay
away from
reading the screen. The idea is basically to s/w
render into
the screen shadow surface in parallel with the
OpenGL rendering,
instead of using glReadPixels(). It would be very
inefficient
compared to applications doing things the right way,
but I’m
quite sure it can be a lot faster than reading the
whole
OpenGL screen every time the screen surface is
locked…Another idea is to automatically activate Dual
Rendering for
applications that do these OpenGL unfriendly things
(like
locking the screen.) Just activate it as soon as a
"violation"
is detected, and disable it again if no further
nasty
operations are performed for a certain number of
frames.
Doesn’t the program have to specifically request an
OpenGL mode in glSDL, or is it your intention that the
user selects it without the program’s knowledge (as in
the backend, dga, x11, fbcon, etc…)>
//David
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
— David Olofson <david.olofson at reologica.se> wrote:
Then, what about applications that should work with
or without OpenGL?The main thrust behind OpenGL for paragui is in 3D
apps, in which case you probably don’t want a
fail-over.
Maybe, but as you know, I think software rendering is too slow for 2D as well.
[…“Dual Rendering” mode…]
Doesn’t the program have to specifically request an
OpenGL mode in glSDL, or is it your intention that the
user selects it without the program’s knowledge (as in
the backend, dga, x11, fbcon, etc…)
The idea is to provide both alternatives. Applications that are aware of glSDL can explicitly request it (like they do with the current wrapper), while other (old, binary-only etc) apps can be forced to use it through an environment variable or something.
The “Dual Rendering” hack is for the latter case. (glSDL aware applications, and in fact any applications designed for PC style hardware, should never blit from or whithin the screen, nor lock the screen surface. Touching VRAM always dog slow, and will in some cases be even slower with glSDL.)
//David
.---------------------------------------
| David Olofson
| Programmer
| david.olofson at reologica.se |
|---|
| Address: |
| REOLOGICA Instruments AB |
| Scheelev?gen 30 |
| 223 63 LUND |
| Sweden |
| --------------------------------------- |
| Phone: 046-12 77 60 |
| Fax: 046-12 50 57 |
| Mobil: |
| E-mail: david.olofson at reologica.se |
| WWW: http://www.reologica.se |
`-----> We Make Rheology RealOn Tue, 2/07/2002 21:49:47 , Andrew Ford wrote:
But Quake3’s .pk3 files are stored as compressed.On Tue, 2002-07-02 at 19:24, Andrew Ford wrote:
— David Olofson <david.olofson at reologica.se> wrote:
bzip2?
Bit slow for general file-access isn’t it? Even the
quake pak files are stored as uncompressed zips.
Yes… However, the minimum system requirements for the Q3 engine
sort of guarantees that there will be enough CPU power for some
unzipping. (That might not be the case with every 2D game.)
//David
.---------------------------------------
| David Olofson
| Programmer
| david.olofson at reologica.se |
|---|
| Address: |
| REOLOGICA Instruments AB |
| Scheelev?gen 30 |
| 223 63 LUND |
| Sweden |
| --------------------------------------- |
| Phone: 046-12 77 60 |
| Fax: 046-12 50 57 |
| Mobil: |
| E-mail: david.olofson at reologica.se |
| WWW: http://www.reologica.se |
`-----> We Make Rheology RealOn 03/07/2002 11:27:42 , DrEvil wrote:
On Tue, 2002-07-02 at 19:24, Andrew Ford wrote:
— David Olofson <david.olofson at reologica.se> wrote:
bzip2?
Bit slow for general file-access isn’t it? Even the
quake pak files are stored as uncompressed zips.But Quake3’s .pk3 files are stored as compressed.
Archive: /usr/local/games/quake3/baseq3/pak0.pk3
Length Method Size Ratio Date Time CRC-32 Name
6012 Defl:X 2111 65% 11-21-99 22:09 1510a59e !slug.cfg
5908 Defl:X 2077 65% 11-21-99 22:09 b26e1b3f ares.cfg
41 Defl:X 34 17% 11-21-99 22:09 421b4e69 atari.cfg
5031 Defl:X 1775 65% 11-21-99 22:09 993dfdb3 bg_hunter.cfg
0 Stored 0 0% 11-21-99 21:42 00000000 botfiles/
:
Indeed they are.On Wed, Jul 03, 2002 at 11:27:42AM -0500, DrEvil wrote:
— David Olofson <david.olofson at reologica.se> wrote:
bzip2?
Bit slow for general file-access isn’t it? Even the
quake pak files are stored as uncompressed zips.But Quake3’s .pk3 files are stored as compressed.
–
Joseph Carter Available in cherry and grape
“They are both businesses - if you have given them enough money, I’m
sure they’ll do whatever the hell you ask:->”
– David Welton
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020703/ccd485b8/attachment.pgp