BSP2

[taniwha]

Heh, by "physics" I meant things like the logic for the physics. The progs set up parameters and select what sort of physics need to be applied to a map entity/section etc, the engine does the heavy grunt work based on that. Moving bot physics from fbxa to the engine made a huge difference when I was playing with it. My point was to make it so the map could create custom entities by providing the necessary code for those entities. I want to do similar for (eg) iqm models too.

Actually, not just want to, but plan to

[Spike]

fte has 'multiprogs' support, in that there's a builtin which can be used to add additional progs.dat files into the vm instance (and some cvars to forcibly do it right from the start too).

you need field remapping somehow, you need a unified string table (fixing up all the string offsets in the later progs), you need function number decoration (some sort of progs value in the high bits or something).
and you need some magic way to get the globals to not be broken when switching between progs. *sigh*.

theoretically its nice for adding new weapons and monsters.
but existing qc just is not clean enough. 'simple' things become immense hacks with remapping known functions to wrappers etc.
so you're basically looking at a massive rewrite of the qc code for it to really ever be used.
which will never happen.
and if it does, it'll be engine specific.
so noone will care that you've done it.

There have been mods using info_notnull since time immemorial. much simpler and more practical to just set up some entity in the map to be programmable via fields rather than qc. sure, you might need to tweak the qc code to add extra fields, but at least you know it'll work, its all your [the qc modder's] code, and not going to result in tying your entire mod to some specific engine.

[taniwha]

While what you say is true; indeed trying to do all that with progs.dat files would be... insane, there's a better way: don't use progs.dat . qfcc already does object files: compile to object, link (including libs), and even partial linking (similar to ld -r). Copy the linker into the engine and problem solved . The reason working with progs.dat won't work is that it's impossible to find all the locations that need to be relocated. qfcc's object files provide that information.

That said, there's still the problem of adoption :/

[Spike]

depends on the optimisations. fteqcc's -O2 will not break anything that would harm an addon.
-O3 will, but that's not a major issue as that's the sole difference between the two. or something like that.
The only *real* problem is that globals in different mods are stored in different places. its quite tempting to directly store a pointer in the statements section instead of a global index (at least for statements which are not jump offsets). bit slower loading but not a real issue.
the difference between ld and dl I suppose.

the point about mods actually using it still stands, however. as does the engine specifics.

[taniwha]

qfcc's relocs cover both code and data space. While an extra reloc type (or two) will be needed to store pointers > 64k directly in code (I'll assume all engines have gone unsigned by now), I believe that particular technical issue is covered.

Engine specifics: always a problem

[taniwha]

As for mods using it: I guess I'll first have to create it (and probably port the core to something like fitzquake as QF is not a good reference engine for this sort of thing)

"Build it and they will come" doesn't always work, but...
"They won't come if you don't build it" does always work.

But before I can build it, I need to get csqc done. And before csqc, client merge (making progress, though slowly).

[Spike]

why do you need relocations when your defs table already contains names? just remap the dupes at load time. full-scale relocs for everything will just make the file absolutely massive. qc isn't native code.

[taniwha]

For qcc progs, relocs may not be necessary (due to lack of structs, arrays, and pointers). ie, the globals read by instructions can never change (entity fields don't count as globals and don't matter anyway), and every global accessed does have a def associated with it (even vector_z).

However, qfcc is a little different:
The def for vector_z is not necessarily written to the progs.
qfcc supports structs, arrays and pointers. While it's possible to create defs for every member, this loses the ability to have data structs higher than 64k.
The code for patching relocs is cleaner than that for using the instructions directly (and thus easier to maintain, possibly faster too).

Yes, relocs take a chunk (16 bytes each), but they allow a lot of flexibility. And there's always gzip

qc progs is native code, just nobody has built a cpu that uses it. I once asked a cpu designer (unfortunately, I don't remember his name right now) about the feasibility of making a qc cpu and his answer was something like "very feasible". I don't know if anybody else has noticed, but GLSL feels a lot like a cleaned up QuakeC.

[Spike]

how do saved games work then?

[frag.machine]

[Baker]

I may have discovered a BSP2 compiler bug relating to the texture position of rotatable models. I need to confirm this through some tests, but the result differs from the map editor texture alignment. I'm thinking hmap2 didn't have this issue.

It isn't the kind of thing you would notice with a typical metal surface tiling texture.

Again, until I post enough information to verify this it may be user error somehow. But it isn't an engine issue, DirectQ/DarkPlaces/FTE/RMQEngine display the texture incorrectly versus the map editor. But my map may be responsible.

[taniwha]

Spike: um... if you're worrying about vector_x and friends, the base vector field covers that (iirc, the engine ignores the component fields anyway). As for structs etc: hmm, good point.

One solution is to get the progs to do the saving and loading. I have actually implemented map entity parsing in qc (QF provides a way to let the progs override the engine's parser), but I'm not sure how much testing I've given it. Since QF supports objects separate to entities, such support is needed anyway.

[Spike]

taniwha, if you get to the point where you depend upon relocations for loading a progs then you're also at the point where saved games just won't work (at least, that is if the moder doesn't regenerate all their pointers and structs based upon redundant global fields).
this is one of the bigger pains with fteqcc's arrays. a single 500 element array needs 500 defs, all with different names. this can make the progs absolutely huge.
not worried about vector_x as that doesn't have DEF_SAVEGLOBAL set anyway.

I want to get fte to the point where it can just memcpy out the vm data and reload that again later for saved games with structs+pointers, though this would impose strict versioning requirements between progs+saves, so only used if pointers+structs etc are used.
the globaldefs generally serves as the reloc section well enough, as that's the only part that can actually be initialised in advance, thus I really don't see the need for a separate reloc section. if you have a preinitialised pointer to a global then you have a non-0 ev_pointer globaldef that you fix up to match the final address of TOQC(&pr_globals[offset]) and there's no difference between same-progs and other-progs, assuming that you have both sets of globals within the same memory space.
are my concerns any clearer now?
either way, this is really getting offtopic.

Baker, which editor are you using? You should get the same result with every qbsp whether it targets bsp2 or bsp29. Try with another qbsp by all means.
bsp2 doesn't change texture mapping in any way, so this will 'hopefully' be an issue with txqbsp upon which the bsp2 qbsp is based. Could also be the editor. :s

[mh]

It sounds like a Tx problem. I have a recollection of doing a fix in the RMQ version (which was also based on Tx) but memory is foggy and night is late.

[taniwha]

Spike: yeah, I understand your concerns, and I agree this is getting off topic.

Time to head back to the drawing board, and when I have something, start a different thread .