Questions to Engine Developers

[MadGypsy]

How complicating is it to completely change the language that your engine interprets? I believe for Quake its ?pcode?.

Is there a faster/superior/more flexible language that could be used instead?

How could your engine gain from this (if at all)?

I'm working on something completely unrelated and I had to ask myself very similar questions. For me, these were very valid questions and I thought they may be valid here as well.

[Spike]

Firstly, anything that removes support for the (qw)progs.dat would basically be suicide. All of a sudden the only thing you can run is mods made explicitly for you.
The only way an engine project could survive is if the mod the incompatible changes are for was a really good mod, or that the engine project was so awesome that the mod didn't matter, or if the mod was standalone.
That said, you don't always need to remove qc support to add another sort of gamecode.

The server itself is strongly tied to the layout of the gamecode's data structures. From physics to networking, it all requires a known layout in order to avoid the engine crawling through.

FTE is able to run Quake2, Quake3, and arguably halflife gamecode. None of these are based upon QuakeC, but the thing they have in common is that they all use completely separate builtins, collision, physics, and networking from quake gamecode. Sadly its fairly significant code duplication, all of which needs testing etc... Bitrot is a significant issue.
In the form of a compromise, mvdsv does support QVM/DLL-based gamecode in order to run the quakeworld mod 'ktx'. While the physics and networking code is mostly unaffected, it is non-trivial to utilize extensions and thus the FTE implementation of the API will always be a second class citizen.

If you're compiling your mod with fteqcc, you can use a '#pragma target fte' line, and you will gain access to the extended instruction set. Pointers, ints, direct array lookups, etc. It all works. But only with FTE at this time. Sure, its not lua, but it is much more flexable.

Lua is the 'fashionable' choice for gamecode nowadays, it seems. But what they don't tell you about it is that its non-strongly-typed nature means that a simple misspelling can leave you scratching your head for days. Its lack of strict binding also means that lookups and things are much less efficient than is QuakeC.

Native code is a possibility. There's some old post by LordHavoc on inside3d about why this is not a good idea in the context of quake.
Certainly non-sandboxed native code is not really a possibility with clientside gamecode, so the stark contrast between C/C++ for server-side and some other language for client-side would be too weird for my liking. Quake3-derived QVM compiled from C code is an option, of course.

Long story short, quake uses hard-coded struct layouts. Your gamecode would need to be able to match those structs via some compile-time or load-time mechanism, or you'll just not get any speed from it. Matching the structs also means you don't have to edit the engine instead, reducing code duplication and keeping it as still 'quake'.

If you're forking for a mod, you're better off just adding builtins for the functionality that you desire.

[Spike]

there's some pascalesque 'reacc' program that was used for nehahra, if I recall correctly. This program predates the release of id's qcc sourcecode and is based upon a decompiled progs.dat, the result is a language that mimics quakec only through the necessity that it have the same featureset.
It compiles to the same instruction set without engine modifications.
FTEQCC is meant to support the syntax additions, if you add the three arguments -Facc -Fcaseinsens -Flax
FTEQCC attempts to implement it as a superset, hence why its 3 separate arguments to enable different parts of the 'functionality', so if you can get the defs+fields set up correctly it'll still accept regular qc mixed with reacc code.

Regarding compiling other languages to quake's (vanilla) opcode set, the lack of pointers, the lack of arrays, the lack of true inheritance, and the lack of string refcounts will really limit the sorts of language you can program it with.
Its simply not object oriented, and that's the source of most of the limitations.

/me wonders what would happen if quake ran java bytecode.

[golden_boy]

awesome posts.

[MH]

If the language compiled down to the same bytecode and interfaces as Quake uses it's trivial - the engine doesn't need to change at all (the qcc does, however).

The key thing is that a faster/superior/more flexible language does not always equal "better". QC as is stands has several advantages, one of which is that's it's quite accessible, and another is that it's quite robust (id themselves discovered this when porting to C for Q2 - see The John Carmack Archive - plan archive for more on that). A third is that it's nicely sandboxed off so you can't do anything (too) crazy with pointers or native API calls from game code. Quake 2 by comparison suffers in this regard.

That doesn't make QC the best option for game code either, it has it's own set of weaknesses too, but it's all a balancing act.

[Spike]

one nice thing about (vanilla) qc is that saved games 'just work' with no huge chunks of code to read+write data that forgets some key datum, and are not directly tied to any offsets in the progs so saved games work with updated progs.dat too.
Muuuch better than Q2's native code saving. Q3 can't even save a level in progress.

[MH]

...saved games 'just work' with no huge chunks of code to read+write data that forgets some key datum, and are not directly tied to any offsets in the progs so saved games work with updated progs.dat too.
Muuuch better than Q2's native code saving...

As I discovered recently.

[Seven]

... so saved games work with updated progs.dat too.

Hello Spike,

I am no engine coder, so I really do not know too much about it.
But I think that Q1�s save games do not work with modified progs.dat�s.
As you maybe know, I am working on a SSQC mod.
I tested it many times:
When I save a game with version X and change the progs.dat and load the X save I get serious glitches.
I mostly hear strange noises.
Example:
When I jump, I hear the pain sounds.
Or wall torches become ammo boxes.
And things like this.

So I am almost sure that Q1 save games do not work with different progs.dat�s.
But my knowledge is limited and I maybe wrong...
Or I misunderstood the meaning of your post.

Best regards,
Seven

[MH]

It depends on what you change in the progs.

[Spike]

if you add/remove precache_model/precache_sound calls then yes, things will still get weird.
But if you're just tweaking a little logic in some touch function or something, you can do so without the saved game becoming completely unusable.
Wrong models is an annoyance, yes, but the level can still be completed or at least restarted without issue. Q2 on the other hand will refuse to load the saved game completely.
(the dp precache-any-time extension has identical issues with saved games as modified progs do, and both can be fixed with the same saved game format update).

[MadGypsy]

Excellent answers! I can tell you guys have a huge passion for engine development. I respect the hell out of that. Thanks for taking the time to answer my lil questions.