Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Reasons QuakeC is better than C++ for Quake-based games Goto page Previous 1, 2

| Inside3d Forums Forum Index -> QuakeC Programming

View previous topic :: View next topic
Author | Message
--- | ---
FrikaC Site Admin Joined: 08 Oct 2004 Posts: 947 |

Posted: Fri Aug 25, 2006 12:26 am Post subject: |

Spike! Where you been! You missed the expo!

Back to top |

LordHavoc Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA |

Posted: Fri Aug 25, 2006 6:31 am Post subject: |

Spike wrote:
Yeah, seperate entities for seperate weapons is a bit messy to maintain, especially if you want to be able to transfer weapons over map changes (eg, single player...). If you're putting a reload timer on stuff, then you shouldn't be allowed to use anything else anyway, so really it makes little difference how you use it.
Sure, duel wielding will be awkward, but meh, that'll be awkward anyway.
So yeah, entities are overkill. Don't bother with them.

When you have a lot of data to maintain per item (such as enchantments/modifications, current loaded ammo type and amount, etc), you pretty much have to use entities as otherwise you make the entity struct huge with tons of information on a set of limited 'slots'.
The other reason to use entities is when you don't want to enumerate all your weapons in the code but instead have a general plugin system that only enumerates them on parm encode/decode, which is what dpmod does. Basically it has only one function for each weapon, so adding more weapons is easy, just call the register function and pass it a pointer to the weapon function, and it adds it to its own list. (Naturally this list of registered weapon types is entities)
dpmod encodes/decodes all the inventory items in a fixed order based on the inventory item types registered with the system, the item type is never stored in the parms, and it stores this using a bit packing system to use all 16 parms to their fullest extent possible (only using as many bits as an item quantity's upper limit variable allows, etc).
Since the dpmod item system does not store the item type but only a quantity of each item, it's basically just the Quake2 system (variable quantities of each possible item), not a proper RPG-style slot-oriented system where you have a limited number of slots that can hold items but the items can be quite diverse.
I actually intended the inventory system in dpmod to be such a slot based system but it kind of mutated into a Quake2 style quantity system, adapting back to the needs of Quake rather than the RPG mode I was trying to make in dpmod.
Naturally this weapon list and inventory item type list is kind of superfluous if you don't have to enumerate them for level changes, such as if you use a persistent character system with FRIK_FILE (like Prydon Gate multiplayer), then you can write out full descriptions of each item including its type (which you can pass to a hub function for manipulating this item along with a request ID and the item entity pointer), and use only a few very configurable item types to describe all your RPG items.

Spike wrote:
Anyway, back to the qc/c/c++ thing... LordHavoc, if you've rewritten about 7 different inventory systems in qc... how many times have you had to rewrite the DarkWar inventory system? :p

Hasn't been written yet, I have laid the basic starting point for the weapon system though

Back to top |

ceriux Joined: 06 Sep 2008 Posts: 968 Location: Florida, USA |

Posted: Sat Feb 27, 2010 8:37 am Post subject: |

im not sure if this has been brought up or not, but... these people who want c++ or c which ever the engine is coded in ( i really dont know) it can all just be done engine side which the source is available for that as well... the QuakeC language is EXTREMELY easy to learn, i have 0 coding knowledge at all and iv learned a great deal just by repeating tutorials and reading through the .qc source. i believe these people already have what they want. but like lordhavoc already said are far too lazy to skim through and learn a little bit of the .qc thats there. anything they want to do they could probably easily code engine side, downsider has done some cool stuff for cobalt runner using engine side coding mixed with .qc if these people really want this. they should just get off their asses and do it their selfs and not complain about it.
_________________
QuakeDB - Quake ModDB Group

Back to top |

LordHavoc Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA |

Posted: Sun Feb 28, 2010 12:50 pm Post subject: |

ceriux wrote:
they should just get off their asses and do it their selfs and not complain about it.

Agreed.
Real Code > Arguments

Back to top |

Swift Joined: 26 Jan 2010 Posts: 44 |

Posted: Fri May 14, 2010 11:24 am Post subject: |

If everything just compiles down to bytecode anyway, wouldn't a better alternative to C++ would be to just extend the language paradigm? For instance, handling of java style objects (that are not entitys). Inheritance. Polymorphism. Last edited by Swift on Fri Jun 04, 2010 4:38 am; edited 1 time in total

Back to top |

Swift Joined: 26 Jan 2010 Posts: 44 |

Posted: Fri Jun 04, 2010 4:36 am Post subject: |

Impossible? Y/n. How limited is the bytecode. Suggested titles: QuakeC++ or QuakeC# : ]

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Fri Jun 04, 2010 2:57 pm Post subject: |

fteqcc attempts to implement classes+inheritance. Its all based upon entities though. class fred : entity { float foo; void func();
};
void() fred::func = {};
fred myfred = spawn(fred);
entity ent = myfred;
myfred = (fred)ent;
fields being valid only within the class type for the reference.
There's a 'this' keyword which is an alias to 'self', but with the relevent class type of the containing function.
the ftev7 opcode set is probably sufficient to run C/C++ code. But I'm not going to target gcc at it any time soon, if only because it would break on fteqw's field remapping :)
_________________
What's a signature?

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> QuakeC Programming | All times are GMT Goto page Previous 1, 2
Page 2 of 2

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group