It seems the dag creation algorithm doesn't like "a = a op a", so use
"b = a op a" instead. Since I plan on fixing temp leaks anyway, this won't
be a problem (also, few people even use qfcc's v6 float modulo :P).
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.
Now the classes are built "properly" (using the same tools as the parser
itself), and the structs (obj_object, obj_class and obj_protocol) are built
separately, but using the class ivars.
Even just before, type_obj_object, type_obj_class and type_obj_protocol
were a bit bogus (still are), but now the arrays used to list their ivars
are correct. I plan to create the above mentioned types using
class_to_struct to do it properly.
Type names are cleaned up, as is the creation. Also, the class pointer in
the type encoding now gets emitted. However, Still need to actually create
_OBJ_CLASS_Class and fix the type encoding reloc handling in the linker.
With the previous commit, the structures were being created before a valid
source file name was available and thus qfcc would segfault when trying to
generate a tag. Now, the tags look better anyway :).
Now, for each compilation, or before linking, only InitData needs to be
called. Fixes the double chaining internal error when compiling and linking
in the same command.
This required throwing out the primary rules that snax did up to help me
with conflicts many years ago, but they were now getting in the way. Now
the productions from primary are merged in with unary_expr.
It turns out no code was being generated for x = *y. Ouch. I suspect I need
to take a better look at expr_deref at some time in the not too distant
future.
Conflicts:
tools/qfcc/source/statements.c
The base of the type encodings block is given by the .type_encodings def.
The block begins with a "null" type (4 words of 0), followed by the first
type encoding.
At some stage, I will need to add information for extended def information
(32 bit offset, type encoding, other?), but this is good for initial
testing.
Structures (especially hard-coded ones) can be really nasty as they can
refer to themselves. Avoid the recursion by setting the type_def field of
the type before doing the recursive encodings in the structure encoder.
The encodings of static types were getting corrupted because their defs
were not necessarily in the same places between compilations when compiling
multiple files.
The result of parse_params needs to be passed through find_type before
actually being used. I guess I'd missed this back when I got things working
for qc.
Since gnu bison and flex are required anyway, no harm in using their api
prefix options. Now, qfcc can compile both QC/Ruamoko and Pascal files
(Pascal is (currently?) NOT supported in progs.src mode), selecting the
language based on the extension: .r, .qc and .c select QC/Ruamoko, .pas and
.p select Pascal, while anything else is treated as an object file (as
before).
smart leak files now produce many points, not just one per portal. Normal
leak files now center the trail on the portal (instead of some weird
weighted average).
There is no error checking, texture alignment or support for non-point
lights, but it's a start. Also, it's assumed all brushes are convex and
manifold.
Blender doesn't support multiline text or word wrapping, so the tooltips
were rather ugly. The double spacing used by layout.label() is still a
little ugly, but the resulting text box just below the entity classname is
much more usable.
All of the nastiness is hidden in bspfile.c (including the old bsp29
specific data types). However, the conversions between bsp29 and bsp2 are
implemented but not yet hooked up properly. This commit just gets the data
structures in place and the obvious changes necessary to the rest of the
engine to get it to compile, plus a few obvious "make it work" changes.
The qc source path is specified via the dirpath property in the QF Entity
Classes panel of the scene data. The scanned entity classes are stored in a
plist in a blender text file for persistent storage (so the directory
doesn't need to be scanned every time). Also, so the data doesn't have to
be parsed every time, the data is stored in a normal python class hanging
off the properties class (evil hack?).
Slightly cleaner EntityClass building, and now the directory scanner is
part of the EntityClassDict class, which also supports reading/writing
plists (for persistent storage in blender).
They are written as normal string items, so anything using the plist later
on will need to know the context, but at least now there's no need to first
convert int or float data to strings before writing a plist.
More or less.
This is a bit of an experiment (which seems to work nicely) in that qfcc
and pak are build natively in one build tree, then the full system is
cross-built in another tree using the natively build qfcc and pak. Both
trees are created by cross-configure.sh as sub-directories of the current
directory. However, cross-configure.sh still assumes it is being run in a
subdirectory of the main quakeforge directory.
cross-make.sh checks if the native tree is in the current directory and if
so, builds it, otherwise it just runs make for the cross-build tree (this
allows for running cross-make in a sub-directory for things like sorting
out build issues).
CC_FOR_BUILD is the recommended name these days (HOST_CC was from an old
gcc version, and is confusing anyway). Also, CC_FOR_BUILD should be set by
configure.
Unfortunately, just because the header is there doesn't mean anything will
actually work :(. Also, the check is based on the host vendor/os for now.
Yes, it's rather lame but it will do for now.
With this, QF will build on an almost fresh ps3toolchain install. Only two
"fixes" are needed:
o In $PS3DEV/ppu/powerpc64-ps3-elf: ln -s ../include sys-include
o libsamplerate cross-built and installed.
One common use for a mesh having multiple UV maps is when combining several
mesh objects into one: the base UV map is the result of joining the meshes
(and will be a right mess of overlapping UV islands), but an additional UV
map is then setup as a copy of the first but with the islands re-packed so
nothing overlaps. The export script now searches for the active UV map and
uses that for both UV coordinates and the skin texture (when none is
specified).
If there's no export script, or the export script has no frame information,
animation data will be collected by running through blender frames 1 to the
current frame (inclusive). Each frame will be exported as a single frame
rather than as members of a frame group.
I'd forgotten I hadn't implemented exporting vertex normals. While I've
modified things for making better use of blender's tools and avoiding the
unnecessary use of objects, the code is taken from the ajmdl blender 2.4
export script.
