RE: [hlcoders] Models and sequences

2002-01-23 Thread Leon Hartwig

The only circumstance in which this is handled in 8 bits is network
transmission, which can be changed by modifying delta.lst.  That's what
it's there for.  Surprise or no surprise, it's not hard coded in the
engine and the engine will happily handle as many sequences as you like.
You should be able to witness this personally within a few days; DoD 2.0
will have  256 sequences.


 -Original Message-
 From: David Flor [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, January 23, 2002 8:17 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [hlcoders] Models and sequences
 
 
 I believe pev-sequence is handled as 8 bits, or maximum of 
 256. Also,
 since I see that inside studiomdl.exe it uses a hard-coded array, I
 wouldn't be surprised if a limitation like that does exist in 
 the engine
 because of coding practices. As much as I have the utmost 
 confidence and
 trust in the Valve development team, there are many bad practices and
 programming no-nos that are common to every programmer... I use fixed
 length arrays without range checking sometimes; the horror! :)
 
 And, Pat, there are 32 maximum weapons, not 35. 32x4 = 128. ;)
 
 Besides, 256 animations is almost ungodly, isn't it? Your 
 animator must
 be going crazy... We had well over 77 animations in our mod 
 (I think at
 last count we had over 160 of them).


attachment: winmail.dat

Re: [hlcoders] Constructors

2002-01-23 Thread Jeff Fearn

  It's bugging me, what where the names of those methods to emulate
  constructors and destructors? Which classes should they be used for?
Which
  classes should they not be used for?

 Constructors and Destructors should not be used for anything that inherits
 from the CBaseEntity class (since the cbase.h file overrides the C++ new()
 function).

 If you create a brand new class (separate from CBaseEntity), you should be
 able to use Constructors and Destructors for it.

I know that, but I remember ages ago there was a discussion on how to
emulate this, and someone mentioned a method that could be overridden. Well
at least I remember that, by my memory may just be making things up ;)

Jeff.
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




Re: [hlcoders] Constructors

2002-01-23 Thread Ken Birdwell

Repeat of destructor/constructor C++ discussion.  TFC uses them.  HL
doesn't.  Read why and how below.

-Original Message-
From: Ken Birdwell 
Sent: Thursday, September 13, 2001 2:31 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [HLCoders] CBaseEntity Memory Mgmnt Q.


I guess an important point to remember is that there is NO C++ in the
engine.  It's 100% C and assembly*.  The only C++ portions are the game
(server) and client dll.  Their interface to the engine is 100% C, that's
what all the Dispatchblah functions are for in cbase.cpp; they resolve the
C interface to their C++ counterparts.

During initialization, the engine calls the game dll's GetEntityAPI()
function.  This returns a structure filled in with function pointers to all
the game dll's dispatch functions, functions that the engine can then call
at the appropriate time.  Half-life implemented its game DLL in C++, though
you don't have to. At an early stage of the project the game dll was in fact
written completely in C - it was quicker to convert the original Quake 1 QC
code to C first instead of directly to C++ - your game dll could also be
written completely in C, but I can't think of why you'd ever want to.

Besides calling GetEntityAPI() during initialization, the engine also calls
the function GetEntityAPI2(), in which the game dll can return back another
list of dispatch functions, most notably containing the function
OnFreeEntPrivateData.  This function is called by the engine whenever it is
going to free up an edict, it's basically giving the game dll an opportunity
to do something - such as calling a local destructor on the private data -
before that memory becomes invalid.

As to constructors and destructors, we never used them.  The reasons are
mostly historical, there's no fundamental reason why we didn't, it's just
that the during the conversion from C to C++ they were never needed and we
just got into the habit of not using them.  Well, that's not totally true,
you may also notice that there's not a single** call to new in the entire
game dll, it (was) 100% written to just use the engine's memory management
system.  The driving force behind that coding standard was that the game
needed to run on a 16MB console machine with no virtual memory, and you
should also note that there's no (okay, hardly any) explicit CBaseEntity
pointers in any of the base classes since in some configurations (that you
don't have to worry about) the engines garbage collection memory system can
(could) move the addresses of everything on you between calls to
DispatchThink().  Not really something that's very clean to do on a real
free form C++ system, so avoiding calls to new and calls to destructors and
constructors made it a lot simpler to avoided bugs when that happened,
though I don't think the code works perfectly in its current configuration
(ie the GearBox guys had to beat on it some to make in run on a machine like
the PS2 again).

So who cares, call new all you want, make your mod run on a system that
needs 128MB of ram and go for it, you don't need to make sure it runs on all
the computers that people bought in 1995 like we had to (boo hoo, now I'm
just whining).  If you want your destructors called, do this:

NEW_DLL_FUNCTIONS gNewDLLFunctions =
{
OnFreeEntPrivateData,   //pfnOnFreeEntPrivateData
NULL,   //pfnGameShutdown
NULL,   //pfnShouldCollide
};

int GetNewDLLFunctions(NEW_DLL_FUNCTIONS *pFunctionTable, int
*interfaceVersion)
{
if(!pFunctionTable || *interfaceVersion !=
NEW_DLL_FUNCTIONS_VERSION)
{
*interfaceVersion = NEW_DLL_FUNCTIONS_VERSION;
return FALSE;
}

memcpy(pFunctionTable, gNewDLLFunctions, sizeof(gNewDLLFunctions));
return TRUE;
}

void OnFreeEntPrivateData(edict_s *pEdict)
{
if(pEdict  pEdict-pvPrivateData)
{
((CBaseEntity*)pEdict-pvPrivateData)-~CBaseEntity();
}
}

*okay, technically there's C++ in the engine for VGUI and audio stuff, but
it's very small and only went in the last year or so and it wasn't there
last time I worked on it.
**not sure if that's true anymore, it was true last time I checked.

-Original Message-
From: Soul Sounds [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 12, 2001 10:10 AM
To: [EMAIL PROTECTED]
Subject: [HLCoders] CBaseEntity Memory Mgmnt Q.



Should You Check Your Credit Report? Of course! We all check
our credit card statements for inaccuracies and we should do
the same for our credit history. Click here now to check
yours FOR FREE at ConsumerInfo.Com!
http://click.topica.com/caaadcTclvXIra2kxuha/ConsumerInfo


Hello,
 
I tried adding a destructor to a class I derived from CBaseEntity and 
got the following error:
 

RE: [hlcoders] Models and sequences

2002-01-23 Thread Ken Birdwell

Leon is mostly correct, though the engine IS limited to only supporting
4,294,967,296 sequences. :P

In any case, the whole business of needing the sequence to line up is ONLY
if you're displaying a different model on the client than the one the server
is using.  Since HL and TFC allow clients to replace models locally, it's
important to mention that for authoring purposes the sequences are
referenced on the client by index number, not animation name (which is only
looked at on the server).

If you're always using the SAME model on both the client and server for any
given player, then they automatically line up (since they're the same, duh)
and you can ignore the all models must have the same animations, etc. etc.
issue, cause, well, they're the same on both.

-Original Message-
From: Leon Hartwig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 23, 2002 12:46 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Models and sequences


The only circumstance in which this is handled in 8 bits is network
transmission, which can be changed by modifying delta.lst.  That's what
it's there for.  Surprise or no surprise, it's not hard coded in the
engine and the engine will happily handle as many sequences as you like.
You should be able to witness this personally within a few days; DoD 2.0
will have  256 sequences.


 -Original Message-
 From: David Flor [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, January 23, 2002 8:17 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [hlcoders] Models and sequences
 
 
 I believe pev-sequence is handled as 8 bits, or maximum of 
 256. Also,
 since I see that inside studiomdl.exe it uses a hard-coded array, I
 wouldn't be surprised if a limitation like that does exist in 
 the engine
 because of coding practices. As much as I have the utmost 
 confidence and
 trust in the Valve development team, there are many bad practices and
 programming no-nos that are common to every programmer... I use fixed
 length arrays without range checking sometimes; the horror! :)
 
 And, Pat, there are 32 maximum weapons, not 35. 32x4 = 128. ;)
 
 Besides, 256 animations is almost ungodly, isn't it? Your 
 animator must
 be going crazy... We had well over 77 animations in our mod 
 (I think at
 last count we had over 160 of them).

___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




[hlcoders] new model skeletons

2002-01-23 Thread Christopher Long



I haven't actually looked into this yet so i can't 
really say i have had a go but i was just wondering what is involved when 
changing a players skeleton to one that doesn't use the standard default valve 
skeleton. Is any coding involved at all or should it all be handled already 
properly, providing animation lists are adhered to.

This is the first time i have actually thought 
about it so i have absolutely no clue about it. Can someone clear it up and 
limitations on new skeletons and whats involved in them?

thanks peoples.


RE: [hlcoders] Models and sequences

2002-01-23 Thread Adrian Finol

 One thing to remember is that any transformation applied to the model
client side has to be duplicated on the server in order to mantain hit
detection in order.

 We had this problem with CS, where the client was doing all the blendings (
9 to be exact ) while the server had no idea about what was going on. Hence
the old CS hitbox problem.


-Original Message-
From: Ken Birdwell
To: '[EMAIL PROTECTED]'
Sent: 1/23/02 4:26 PM
Subject: RE: [hlcoders] Models and sequences

Leon is mostly correct, though the engine IS limited to only supporting
4,294,967,296 sequences. :P

In any case, the whole business of needing the sequence to line up is
ONLY
if you're displaying a different model on the client than the one the
server
is using.  Since HL and TFC allow clients to replace models locally,
it's
important to mention that for authoring purposes the sequences are
referenced on the client by index number, not animation name (which is
only
looked at on the server).

If you're always using the SAME model on both the client and server for
any
given player, then they automatically line up (since they're the same,
duh)
and you can ignore the all models must have the same animations, etc.
etc.
issue, cause, well, they're the same on both.

-Original Message-
From: Leon Hartwig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 23, 2002 12:46 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Models and sequences


The only circumstance in which this is handled in 8 bits is network
transmission, which can be changed by modifying delta.lst.  That's what
it's there for.  Surprise or no surprise, it's not hard coded in the
engine and the engine will happily handle as many sequences as you like.
You should be able to witness this personally within a few days; DoD 2.0
will have  256 sequences.


 -Original Message-
 From: David Flor [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, January 23, 2002 8:17 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [hlcoders] Models and sequences
 
 
 I believe pev-sequence is handled as 8 bits, or maximum of 
 256. Also,
 since I see that inside studiomdl.exe it uses a hard-coded array, I
 wouldn't be surprised if a limitation like that does exist in 
 the engine
 because of coding practices. As much as I have the utmost 
 confidence and
 trust in the Valve development team, there are many bad practices and
 programming no-nos that are common to every programmer... I use fixed
 length arrays without range checking sometimes; the horror! :)
 
 And, Pat, there are 32 maximum weapons, not 35. 32x4 = 128. ;)
 
 Besides, 256 animations is almost ungodly, isn't it? Your 
 animator must
 be going crazy... We had well over 77 animations in our mod 
 (I think at
 last count we had over 160 of them).

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders