jar size - packages Xith3D can live without

Engines, Libraries and Tools Xith3D Forums
#1

I have just been experimenting with removing non-essential packages from Xith3D. I was able to remove the following packages without causing the Xith3D compile to break. Note: with a few alterations of the code (for example scrapping logging etc…) I am sure you could remove many more, but these are the easy ones.

[] com/xith3d/collider
[] com/xith3d/loaders/ase
[] com/xith3d/terrain
[] com/xith3d/test
[] com/xith3d/utility/cmdline
[] com/xith3d/utility/events
[] com/xith3d/utility/exception
[] com/xith3d/utility/general
[] com/xith3d/utility/interpolate
[] com/xith3d/utility/noise
[*] com/xith3d/utility/properties

Here are the file sizes using the 1.4.2_03 Linux Javac tool with no debugging (size with full debugging info in brackets).

No optional packages - 340K (457K)
All packages - 626K (837K)
All packages bar test - 487K (657K)

Quite impressive, and as I said, I’m sure there’s more you can drop if you were happy to hack bits off the code.

The compulsary third-party libraries are JOGL and vecmath which do add a bit to the size. However, if you were using LWJGL with Xith3D and compiling with Jet - you are only looking at approximately half a meg extra for the privilege of using Xith3D.

Will.

#2

that’s a nice weight, i agree. nevertheless, when you have that, you have nothing.
Without any of the GL bindings that can be linked, you don’t have a working xith. Thus, you have to count it anyway, like it or not. (and to me adding jogl or lwjgl does not add bit, it multiplies the weight by at least two or three…)
You might remove some hundreds of KB of data by removing the debug infos, but that imho would be bad, if not stupid.
Anyway, Xith or J3D without its GM soundbank are already small enough not to have a huge impact on a game.
See, alien flux is already 11 megs and helix is 14. (btw, they don’t use xith, but it is an example of the same case…)
Cas rants about weight of 3D API, but produces games where his API is an irrevelant part of the whole download. Reminds me of the old ‘code then analyse bottlenecks’ thing.
About xith, what are 500KB more compared to the whole game weight when you are talking about the principal active and sensible part of it? What will bug reports look like if you remove debug infos?

#3

I think it’s good if Xith is as small as possible - but not smaller. :wink:

Always remember: since Xith is a modern high level 3d API (with modern I mean modern 3d effects are possible) the target platforms for our Xith games will have modern 3d cards and that means: modern drivers, which today are 10-25 MB in size… {edit: size numbers adapted}
For my ATI 3d card every month a new driver version appears.

So… size doesn’t matter - here.

#4

[quote]I think it’s good if Xith is as small as possible - but not smaller. :wink:
[/quote]
I’d add that size must be reasonably low, and you don’t have to be obsessed by it because others in the chain will ruin your efforts.

#5

Well, I also use reduced version of Xith3D.

My filesizes are:

xith3d.jar - 280K
JOGL (win32 native+jar) - 289K
vecmath - 103K
vorbis - 70K

Application sizes: from 1M (500K for game and 500K for graphics and geometry) to 50M.

Yuri

#6

Xith is looking extremely favourable from a size point of view right now. The other side of the equation is runtime memory footprint. Is it highly optimised to fit big worlds into small memory?

Btw Pepe, I usually moan about the size of things in relation to the “competition”, and that’s C++. If a Java library ends up being significantly more massive than a C++ equivalent it won’t win any hearts and minds.

Nvidias drivers are still 8MB :slight_smile:

Cas :slight_smile:

#7

[quote]Nvidias drivers are still 8MB :slight_smile:
[/quote]
No. Version: 56.64, Windows XP/2000
Release Date: March 15, 2004

U.S. English, WHQL Certified
File Size: 10.2 MB

International, WHQL Certified
File Size: 14.5 MB

The latter one is the interesting one to me, since I’m no Englishman, like so many users here.
Currently I mainly use an Ati card however and so I download a 24 to 25 MB driver regularly.

Concerning Xith’s memory footprint I can’t comment. Xith’s memory usage isn’t optimally yet. Actually currently with a few 100 transformed objects on screen I get memory problems (read: full GC) when using the client VM, but with the server VM and the free Japanese Vecmath it’s OK.

#8

Ah, latest drivers have crept up slightly. I suppose this is because they’ve got all that newfangled shader malarkey in them now and so on.

Last time I downloaded ATI OpenGL drivers they were only 6MB for my Radeon 8500! But, you have to have DX9 installed or something first :frowning:

If Xith is going to cut it for me then I’m going to have to be able to output something as complex as, say, Tribal Trouble in a runtime virtual memory footprint of around 128MB. (Comparison figures: TT actually uses around 105MB, and my ancient terrain demo from 1,000 years ago uses around 65MB)

Cas :slight_smile:

#9

There’s a lot of room for improvement in terms of memory. Both in terms of footprint and garbage. It is steadily improving however.

There are also some very nice optimisations for the graphics card such as Vertex Buffer Caching that are already in there :slight_smile:

The Japanese open source vecmath package really should be the default one - I’ll look into this (apart from anything else it’s a gray license area using the Sun one).

Will.

#10

Hi,

Just out of curiosity, I’ve been trying out the ‘pack200’ util in java5 (beta2-b51) on various jar files and with xith3d I get these numbers:

Plain jar - 702,073 bytes
Packed jar - 393,776 bytes
Packed and gzipped - 175,495 bytes

which is almost exactly 4x compression :slight_smile:
Not quite the ‘8 fold’ compression they claim but still not to be sniffed at.

JC

#11

Yes, pack200 is really good addition. Also, JWS from J2SE 1.5 supports it by default, so we should get these benefits without any effort AFAIK.

Yuri