quakeC bytecode

[DolphinsOfCydonia]

I'm curious, what are the limitations of the quakeC bytecode? There are a surprising lack of 'other' language compilers for it (with the exception of Python). Would an implemention of a feature subset of a language such as Javascript or Java -> bytecode compiler be possible?

[leileilol]

but why?

[DolphinsOfCydonia]

Datastuctures (i.e a Collection). Strings.
Structures.
Structures with functions (classes).
Inheritance.
Arrays.

While FTEQcc supports some of these things, and FTEQcc is very good, I don't think the 'bolted on' way in which these things are available is conducive to good programming. It forces much of QuakeC programming to be a hack, instead of good code.

If the bytecode supports it, then I can only view a new language parser as a positive thing for this community.

[Spike]

the basic bytecode doesn't truely support pointers (can't read from them), and doesn't support integers, there's no way to malloc blocks of memory, etc.
or in other words, if you want to compile your gamecode in java, expect to mod the engine, in which case why bother with the qc bytecode itself?

fteqcc does support an extended instruction set, which can do pointers, pointer maths, integers, etc, but to use it would be to make your mod work only in one engine, and the docs on this stuff suck.

[DolphinsOfCydonia]

[hondobondo]

[DolphinsOfCydonia]

On that topic, Spike, are Quake 2 Dlls or Quake 3 QVM viable alternatives for constructing a Quake 1 style singleplayer or multiplayer game in your engine? Is there much feature loss?

[Spike]

fte doesn't provide many extensions for q2/q3, so you're left with almost vanilla quake2/3. not sure its even able to load q1/hl maps either.

there is support for a q1 gamecode dll, which a qw mod named ktx requires. Its mostly the same as quakeworld's api, but again lacks the reimplementation of various extension builtins and fields. Builtins I'm not too concerned about, I could add them fairly easily, but extension fields are basically a real problem without making the whole thing incompatible with mvdsv. Otherwise the engine, entity, physics, etc handling is identical to QW, so it should be easy enough to convert an existing mod, as its mostly find+replace. Many of the existing qc extension builtins could easily be wrapped. I suppose fields could be implemented using get/set builtins, if needed.
But like I say, this 'q1qvm' stuff is implemented to be able to run ktx as its only goal, so at this point in time it still lacks certain features (like saved games). If you did want to use it, it should be possible to implement the parts that are missing as you need them.

Its fairly easy to gut out the qcvm to replace it with native code really. What's hard is doing it cleanly and without breaking support. Its quite viable if you're willing to fork an existing engine, and keep parts of it in sync.