The depth limits in the gl and glsl renderers and in the trace code really
bothered me, but then the fix hit me: at load-time, recurse the trees
normally and record the depth in the appropriate place. The node stacks can
then be allocated as necessary (I chose to add a paranoia buffer of 2, but
I expect the maximum depth will rarely be used).
These are based on the ps3dev scripts, so native qfcc and pak are built
automatically.
Note that there may be a need to replace or even just nuke bison in the
toolchain as it is too old and can't build qfcc.
While accessing short foo[2][4]; as foo[0][0..7] should work in theory, who
knows what gcc does with it when optimizing. I don't know if this will fix
johnnyonflame's bsp loading problem, but no point in having rhinodemonic
code hanging around.
After running across a question about lists of animation frames and states,
I decided giving qfcc the ability to generate such lists might be a nice
distraction from the optimizer :) Works for both progs.src and separate
compilation. No frame file is generated if no macros have been created.
Using "=" was rather confusing, so changing it to "<CONV>" seems to be a
good idea. As the string is used only for selecting opcodes at compile
time, only qfcc is affected.
Because of the way it is used, the data in the type encodings space needs
to always be correct (ie, relocated), even for partially linked object
files.
Rather, only that it is neither external nor local. The idea was to catch
myself swapping the arguments to resolve_external_def, but for some reason
I decided type encoding defs would not be global (save game reasons?).
Fixes the bogus redefined errors when entity fields are used.
Also, rename extern_defs and defined_defs to extern_data_defs and
defined_data_defs (more consistent with the other tables).
The problem was caused by add_relocs and process_loose_relocs adjusting the
reloc offset based on the reloc's space's base address. This is fine for
most relocs, but as relocs for the type space have already been adjusted by
process_type_space, those relocs must be left alone by add_relocs and
process_loose_relocs. As a bonus, the duplicate code has been refactored
into a separate function :)
Now each encoding is copied across def by def using memcpy, with the
expectation that any references to other types will be handled via the
reloc system. Unfortunately, it seems there's an off-by-4 (hmm, suspicious
number...) in the reloc offsets, but I'll look into that after I get some
sleep.
defspace_alloc_loc can cause a realloc which will break the work qfo space
data pointers, so wrap it with alloc_data, which updates the appropriate
pointers and sizes.
The field/data def handling has been moved into process_data_def and
process_field def. The code for handling external defs has been moved into
its own function (extern_def()),
In passing, rename add_space to add_data_space, since it is limited to
handling data spaces.
For now, no other change has been made, but I'll be able to split up
process_def for data def vs field def processing and add a function for
processing type encoding defs.
First, the class def needed to be created before the class type, then the
def space indices had to be set early, otherwise the relocs wound up with
space 0 instead of the correct space.
All internal structs now have "proper" names, and fit the naming convention
(eg, obj_module (like objective-c's types, but obj instead of objc). Some
redundant types got removed (holdovers from before proper struct tag
handling).
Also, it has proven to be unnecessary to build internal classes, so
make_class and make_class_struct are gone, too.
When encoding a type to a qfo file, the type's encoding string is written
and thus needs to be valid prior to actually doing the encoding. The
problem occurs mostly in self-referential structs (particularly, obj_class)
because the struct is being encoded prior to the pointer to the struct.
This is similar to the problem with infinite recursion when encoding types.
The problem is with structs with self-referential pointers (eg, struct foo
{struct foo *bar}). The solution is to copy the type data to a buffer and
mark the buffer as transfered before actually processing the type. Further
processing of the type is done via the buffer.
As id and Class do not point to real objects as such, trying to get the
class from their types doesn't work, so instead send the message to a
"null" class that skips the method checks.
