i can't seem to compile my progs anymore... sitting at 960k atm, with one qc file removed. replacing it causes the compiler to crash without any warnings. it doesn't matter which qc file is removed, any file (barring important ones like world.qc) when removed fixes the crash problem.
i'm guessing the progs.dat max size is 1024k? if so, i'm a sad panda.
is the max progs.dat size 1mb?
The engine is limited to 32767 'numpr_globals' (quakeforge, darkplaces, fteqw have a 65535 limit). It is not an actual filesize limit.
However, all QC compilers have additional limits on the other variable counts. Most QC compilers should give info on how much of each type of data was generated compared to the limit for that type of data. Go purly by that information.
By the time these limits are reached, the mod is about 1mb. But it's not a file size limit. It's mearly a coincidence.
The biggest working progs.dat I've seen is 4.44mb.
This particular mod was compiled with fteqcc and fits into the 32k globals limit. The mod itself is a bots mod. The reason it's so huge is because it contains a lot of waypoints (each map has a function containing lots of function calls to set up the waypoints). The only reason it actually fits inside the 32k globals limit is because of a specialised hack in fteqcc to use floats instead of vectors which allows for much better reuse of constants.
But yeah, it's the QCC that limits the size the most.
FrikQCC, FTEQCC and QFCC all have optimisations to reuse temps.
QFCC actually wins slightly here, but is a real pain to install... FTEQCC compiles the 125k or so globals from hexen2 down to 10k. FrikQCC isn't as good, but still optimises enough for most mods (certainly to the 2mb mark).
The facination with measuring globals in qcc compilers is because that's the lowest limit imposed by the format. It's not the only limit, but file size is totally irrelevent other than the implied quantity of data you've got and which other limits you've exceeded.
Use FrikQCC or FTEQCC and use optimisations. Your mods will be able to be twice the size, at least.
Here's the output of a mod compiled with fteqcc.
63640 strofs (of 1000000)
389754 numstatements (of 524288)
1452 numfunctions (of 16384)
2536 numglobaldefs (of 32768)
904 numfielddefs (874 unique) (of 2048)
10656 numpr_globals (of 65536)
Writing progs.dat
3304274 TOTAL SIZE
As you can see, no limits were exceeded. :p
Filesize is no limit. It's the other bits. All of which can be increased by using a different QCC.
Unfortunatly many QCCs do not correctly check limits when they create new globals, functions or whatever, resulting in compiler crashes. Unfortunatly even frikqcc has this issue at about 32k globals.
So: Make sure you're using FrikQCC or FTEQCC.
Also: Make sure you're using optimisations (frikqcc needs -O2 on the commandline for this, fteqcc defaults to enabling certain capacity optimisations).
the numpr_globals is the only limit that cannot be changed by using a different QCC (anything else, you'll run out of memory first). Unfortunatly this is also the first limit which is usually encountered.
Why? self.model = "progs/blob.mdl"; <- that creates 1 temp and requires a constant to be defined somewhere. So that's 1 to 2 globals. Multiply that by however many statements in your progs, and voila, over 32767 temps+globals+constants, and a compiler crash or error. Which is why optimisations are so important with large mods.
However, all QC compilers have additional limits on the other variable counts. Most QC compilers should give info on how much of each type of data was generated compared to the limit for that type of data. Go purly by that information.
By the time these limits are reached, the mod is about 1mb. But it's not a file size limit. It's mearly a coincidence.
The biggest working progs.dat I've seen is 4.44mb.
This particular mod was compiled with fteqcc and fits into the 32k globals limit. The mod itself is a bots mod. The reason it's so huge is because it contains a lot of waypoints (each map has a function containing lots of function calls to set up the waypoints). The only reason it actually fits inside the 32k globals limit is because of a specialised hack in fteqcc to use floats instead of vectors which allows for much better reuse of constants.
But yeah, it's the QCC that limits the size the most.
FrikQCC, FTEQCC and QFCC all have optimisations to reuse temps.
QFCC actually wins slightly here, but is a real pain to install... FTEQCC compiles the 125k or so globals from hexen2 down to 10k. FrikQCC isn't as good, but still optimises enough for most mods (certainly to the 2mb mark).
The facination with measuring globals in qcc compilers is because that's the lowest limit imposed by the format. It's not the only limit, but file size is totally irrelevent other than the implied quantity of data you've got and which other limits you've exceeded.
Use FrikQCC or FTEQCC and use optimisations. Your mods will be able to be twice the size, at least.
Here's the output of a mod compiled with fteqcc.
63640 strofs (of 1000000)
389754 numstatements (of 524288)
1452 numfunctions (of 16384)
2536 numglobaldefs (of 32768)
904 numfielddefs (874 unique) (of 2048)
10656 numpr_globals (of 65536)
Writing progs.dat
3304274 TOTAL SIZE
As you can see, no limits were exceeded. :p
Filesize is no limit. It's the other bits. All of which can be increased by using a different QCC.
Unfortunatly many QCCs do not correctly check limits when they create new globals, functions or whatever, resulting in compiler crashes. Unfortunatly even frikqcc has this issue at about 32k globals.
So: Make sure you're using FrikQCC or FTEQCC.
Also: Make sure you're using optimisations (frikqcc needs -O2 on the commandline for this, fteqcc defaults to enabling certain capacity optimisations).
the numpr_globals is the only limit that cannot be changed by using a different QCC (anything else, you'll run out of memory first). Unfortunatly this is also the first limit which is usually encountered.
Why? self.model = "progs/blob.mdl"; <- that creates 1 temp and requires a constant to be defined somewhere. So that's 1 to 2 globals. Multiply that by however many statements in your progs, and voila, over 32767 temps+globals+constants, and a compiler crash or error. Which is why optimisations are so important with large mods.
Spike owns 
he changed Parboil source to suport NNNN maps in a qwprogs.dat with fteqcc 
if u guys want to ahve a look is here
http://trinca.no.sapo.pt/temp/src375.rar
compile 375 waypoints and dont give any errors the qwprogs.dat is 5 mb
cheers!!!
spike u rock
he changed Parboil source to suport NNNN maps in a qwprogs.dat with fteqcc if u guys want to ahve a look is herehttp://trinca.no.sapo.pt/temp/src375.rar
compile 375 waypoints and dont give any errors the qwprogs.dat is 5 mb
cheers!!!
spike u rock
-
Dr. Shadowborg
- InsideQC Staff
- Posts: 1120
- Joined: Sat Oct 16, 2004 3:34 pm
Heh, spike just convinced me to switch to fteqcc. I must say, It's very nice, though the gui frontend and compiler could use a little work. (a bug or two here and there relating to maximizing and restoring windows and reporting of line numbers where an error occured, as well as a better search / goto line function, and writing of an error.log file ala frikqcc.)
Dr. Shadowborg wrote:and writing of an error.log file ala frikqcc.
Code: Select all
fteqcc >error.log