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). attachment: winmail.dat
Re: [hlcoders] Constructors
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
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
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
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
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