Pages: [1]
  Print  
Author Topic: Overall architecture: coupling between game, cgame, etc?  (Read 12716 times)
bbmario
Nub


Cakes 0
Posts: 21


« on: January 11, 2015, 06:53:04 PM »

I have decided to rewrite most of the code inside cgame, by slowly deactivating old code and migrating to newer code. However, i'm not completely sure about the Quake 3 architecture. Is there any other dependency between cgame and the engine, other than the vmMain and the events it receives?

There seems to be some tight coupling with other parts of the system, and i'm afraid about global variables and shared global state. Or is it really completely isolate and i should just care about vmMain and drawing the current frame properly?
Logged
andrewj
Member


Cakes 24
Posts: 584



« Reply #1 on: January 11, 2015, 09:13:46 PM »

Any "global" variables in cgame will not be accessible from the game vm, UI vm or the engine, and vice versa.

(Especially when using QVMs -- when using DLLs then it may be possible for one part to access variables in another part, so if that matters to you then be careful not to use the same global variable names)

The VMs communicate with the engine mainly through the trap_XXXX functions, though I don't know if any actual memory areas are shared.

Some of the structures are shared between the VMs and/or engine, like entityState_t, so you cannot modify that without also recompiling the engine too.  Stuff in game/bg_public.h cannot be modified without recompiling all the VMs (but that one is not used by the engine I think).
Logged
bbmario
Nub


Cakes 0
Posts: 21


« Reply #2 on: January 12, 2015, 04:40:59 AM »

Are data structures like entityState_t used by other VM's? I wanted to delete everything inside cgame and slowly start to replace code, rewriting everything with better code (i intend to use C++ and OOD).
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #3 on: January 12, 2015, 04:20:56 PM »

Are data structures like entityState_t used by other VM's? I wanted to delete everything inside cgame and slowly start to replace code, rewriting everything with better code (i intend to use C++ and OOD).
If you want to use C++ you will need to drop vm's and just natively compile the whole game. Or you could add a q3vm-target to a C++ compiler (that would be really cool). The modules game, cgame and q3_ui uses C and the lcc-compiler as sort of scripting language.
Logged

There are nothing offending in my posts.
Pages: [1]
  Print  
 
Jump to: