Inside3D!
     

Reasons QuakeC is better than C++ for Quake-based games
Goto page Previous  1, 2
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> QuakeC Programming
View previous topic :: View next topic  
Author Message
FrikaC
Site Admin


Joined: 08 Oct 2004
Posts: 947

PostPosted: Fri Aug 25, 2006 12:26 am    Post subject: Reply with quote

Spike! Where you been! You missed the expo!
Back to top
View user's profile Send private message Send e-mail
LordHavoc



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

PostPosted: Fri Aug 25, 2006 6:31 am    Post subject: Reply with quote

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 Smile
Back to top
View user's profile Send private message Visit poster's website
ceriux



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

PostPosted: Sat Feb 27, 2010 8:37 am    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger
LordHavoc



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

PostPosted: Sun Feb 28, 2010 12:50 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Swift



Joined: 26 Jan 2010
Posts: 44

PostPosted: Fri May 14, 2010 11:24 am    Post subject: Reply with quote

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
View user's profile Send private message
Swift



Joined: 26 Jan 2010
Posts: 44

PostPosted: Fri Jun 04, 2010 4:36 am    Post subject: Reply with quote

Impossible? Y/n.

How limited is the bytecode.
Suggested titles:
QuakeC++ or QuakeC# : ]
Back to top
View user's profile Send private message
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Fri Jun 04, 2010 2:57 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    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