quakeC bytecode

Discuss programming in the QuakeC language.
Post Reply
DolphinsOfCydonia
Posts: 21
Joined: Tue Nov 08, 2011 4:01 am

quakeC bytecode

Post by 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
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: quakeC bytecode

Post by leileilol »

but why?
i should not be here
DolphinsOfCydonia
Posts: 21
Joined: Tue Nov 08, 2011 4:01 am

Re: quakeC bytecode

Post by 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
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: quakeC bytecode

Post by 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
Posts: 21
Joined: Tue Nov 08, 2011 4:01 am

Re: quakeC bytecode

Post by DolphinsOfCydonia »

Spike wrote: but to use it would be to make your mod work only in one engine
Well hey, that's 50% of the engines that most modern Q1 based games should be targeting. The other being Darkplaces.

However FTEs support for Quake3/ Quake 2 would make the whole process pointless.

Darkplaces should support DLLs. : )
hondobondo
Posts: 207
Joined: Tue Sep 26, 2006 2:48 am
Contact:

Re: quakeC bytecode

Post by hondobondo »

DolphinsOfCydonia wrote:
Spike wrote: but to use it would be to make your mod work only in one engine
Well hey, that's 50% of the engines that most modern Q1 based games should be targeting. The other being Darkplaces.

However FTEs support for Quake3/ Quake 2 would make the whole process pointless.

Darkplaces should support DLLs. : )
fte cant play superduper quake
DolphinsOfCydonia
Posts: 21
Joined: Tue Nov 08, 2011 4:01 am

Re: quakeC bytecode

Post by 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
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: quakeC bytecode

Post by 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.
Post Reply