Tremulous Forum
Mods => Modding Center => Topic started by: JP on February 14, 2008, 06:53:04 am
-
Tremulous is quite impressive, you guys did a great job with it. I'm working on a standalone GPL Quake3-based game of my own (albeit not as ambitious as Tremulous, and very different besides) and was wondering if the devs could give a general estimate of how difficult it would be to merge the particle system code (particles defined in text files, trail-style effects, etc) into the current icculus.org Q3 codebase. Looking over the source, it seems like there aren't many changes to the renderer, the biggest changes seem to be in cgame. How cleanly separated out is this system, and are there any really nasty surprises waiting for me should I attempt this? Obviously I wouldn't be merging in anything gameplay related, and I'm not using anything like Q3A's gameplay, so this would be a strictly tech-level feature merge.
Thanks in advance, and congrats on Tremulous. Wish I was better at it :/
Edit: just to be clear, if I did integrate Trem's particles into my project, you guys would get mad tall props should my little project ever amount to anything. It's implicit with the GPL, but I have zero intention of taking credit for you guys' hard work.
-
i'd suggest asking @ irc, chances to get an answer are better there ;-)
-
In-progress. I'm keeping detailed notes on everything I have to do to get this working, and I'll post it here once I'm done, just in case anyone is ever interested in doing this too.
I've just completed the main part of the merge. Code compiles with no errors or warnings. The particles seem to be working - I spawn one when one of my custom projectiles hits a wall and it shows up in-game.
The trails, not so much. My quick ugly test code to spawn one looks like this:
tsh = CG_RegisterTrailSystem( "gfx/puls_trail" );
ts = CG_SpawnNewTrailSystem( tsh );
if( CG_IsTrailSystemValid( &ts ) ) {
CG_SetAttachmentCent( &ts->frontAttachment, cent );
CG_AttachToCent( &ts->frontAttachment );
}
This happens in cgame/cg_ents.c, during the render function for my custom projectiles. I know the code runs because the MD3 I set for the projectile shows up, and indeed the trail is considered "valid". It just doesn't show up. There are no invisible polys that show up with r_showTris 1, either.
The trail effect and the shader it uses are identical to the Tremulous trail effect called "missileTS", so I'm pretty sure things are fine on the data end.
Any ideas on what could be wrong? Am I forgetting to do something really basic? I realize I'm not using Trem's weapons system, so the code is a little junky and not part of a nice system.
-
Hmm, when I changed the above test code to use CG_SetAttachmentPoint and CG_AttachToPoint instead, it worked. Not sure if that means attaching to centities in general is borked, or if it's something I'm doing wrong.
Without further ado, here's the semi-giant list of things I changed in stock icculus.org Quake3 (svn 1267) to integrate the Tremulous particle and trail systems:
add new files:
cg_animation.c
cg_attachment.c
cg_particles.c
cg_trails.c
add "outline" shader to one of your .shader data files
Makefile
-------------------
add lines to compile these new files
cgame/cg_local.h
-------------------
forward declaration for particle_t
add struct definitions:
- attachmentType_t
- attachment_t
constants labeled "particle system stuff", eg MAX_PARTICLES
struct definitions:
- pMoveType_t
- pDirType_t
- pMoveValues_t
- pLerpValues_t
- baseParticle_t
- baseParticleEjector_t
- baseParticleSystem_t
- particleSystem_t
- particleEjector_t
- particle_t
constants labeled "trail system stuff", eg MAX_TRAIL_SYSTEMS
struct definitions:
- trailBeamTextureType_t
- baseTrailJitter_t
- baseTrailBeam_t
- baseTrailSystem_t
- trailSystem_t
- trailBeamNode_t
- trailBeam_t
add members to centity_t definition:
lerpFrame_t lerpFrame;
particleSystem_t *entityPS;
qboolean entityPSMissing;
qboolean valid;
qboolean oldValid;
add members to cgs_t definition:
qhandle_t gameShaders[MAX_GAME_SHADERS];
qhandle_t gameParticleSystems[MAX_GAME_PARTICLE_SYSTEMS];
add to cgMedia_t definition:
qhandle_t outlineShader;
add to list of cvars:
- cg_depthSortParticles
- cg_bounceParticles
- cg_debugParticles
- cg_debugTrails
- cg_debugPVS
- cg_drawBBOX
prototypes for functions in the 4 new files (cg_animation, etc)
prototype for trap_FS_GetFileList, which Trem uses on the client side
cgame/cg_main.c
-------------------
add to list of cvars, and to list of default values:
- cg_depthSortParticles
- cg_bounceParticles
- cg_debugParticles
- cg_debugTrails
- cg_debugPVS
- cg_drawBBOX
to end of CG_RegisterGraphics, add code marked by comment "register all the server specified particle systems"
to CG_Init, add calls to CG_LoadTrailSystems and CG_LoadParticleSystems just before line that reads:
CG_LoadingString( "sounds" );
cgame/cg_ents.c
-------------------
add new function definitions:
- CG_DrawBoxFace
- CG_DrawBoundingBox
- CG_CEntityPVSEnter
- CG_CEntityPVSLeave
to CG_AddPacketEntities, add:
all code that references the "valid" var of a centity
cgame/cg_marks.c
-------------------
rename particle_s (type particle_t) and MAX_PARTICLES to something else, to prevent conflict with their definition in new code
cgame/cg_players.c
-------------------
rename CG_RunLerpFrame to CG_RunPlayerLerpFrame, in declaration and all usages within this file (there are only 3 or 4), to prevent conflict with their definition in new code
cgame/cg_public.h
-------------------
add CG_FS_GETFILELIST to cgameImport_t definition
cgame/cg_syscalls.c
-------------------
add trap_FS_GetFileList definition
cgame/cg_syscalls.asm
-------------------
add trap_FS_GetFileList to list with a unique number
cgame/cg_view.c
-------------------
add calls to CG_AddParticles and CG_AddTrails in CG_DrawActiveFrame, just ater CG_AddViewWeapon
client/cl_cgame.c
-------------------
add CG_FS_GETFILELIST case to large switch statement in CL_CgameSystemCalls
game/bg_lib.c and bg_lib.h
-------------------
add definition for util function "rint"
game/bg_misc.c
-------------------
add definitions for util functions:
- atof_neg
- atoi_neg
game/bg_public.h
-------------------
add constants: CS_SHADERS, CS_PARTICLE_SYSTEMS, CS_PRECACHES
add definitions for util functions:
- atof_neg
- atoi_neg
qcommon/q_math.c
-------------------
add definitions for util functions:
- VectorMatrixMultiply
- GetPerpendicularViewVector
qcommon/q_shared.h
-------------------
define MAX_GAME_SHADERS and MAX_GAME_PARTICLE_SYSTEMS
add definitions for util functions:
- VectorMatrixMultiply
- GetPerpendicularViewVector
changes to new files (from stock Tremulous version)
cgame/cg_particles.c
-------------------
rename "particles" (type particle_t) and function CG_AddParticles in declaration and all usages within this file to prevent conflict with their definitions in old code
Hope this is useful to someone!
-
I figured out why attaching particles to centities wasn't working... I needed to merge the code that sets the "valid" flag in cg_ents.c, and some of Trem's PVS stuff that goes along with it.
So now I've got trails attached to players, etc etc. Still a lot of placeholder art, but it looks kinda neat:
(http://img104.imageshack.us/img104/9514/playertrailsfirst2bb0.jpg) (http://img104.imageshack.us/img104/9514/playertrailsfirst2bb0.jpg)
-
Looks like some good work there JP. Any way you have a clean patch against ioq3 with just the particle system? I know this will be useful to many others as it's quite nice.
Khalsa
-
Sadly no, I don't have a single changelist or patch for it - I was rigging up some test code and unrelated gameplay stuff as I was doing this. However it wouldn't be tough for me to generate one from the notes I took (and be a bit more neat and tidy about it besides). If my project is successful and/or I have some time in the future, I'll create a patch.
Lately I've been contemplating, as a "someday" project, creating a branch of ioQ3 aimed at indie developers, with all the Q3A content and gameplay removed, just vanilla movement and physics and maybe a few example bits like a simple weapon, world object, avatar etc. Some of the features Tremulous has added would be great additions to this sort of platform. Still roughly within the same generation of rendering capabilities, unlike Xreal which is very focused on being modern and super-l337. Only features like MD5 support that make it easier to make content for... I think it's actually liberating in some ways to work with 2001-era poly counts, no normal maps, etc.
Anyway, I'll definitely promote it if I ever undertake such a project. I'm totally concerned with getting my game out and awesome first.
-
I hope you do, I was planning on putting your patch HERE (http://ioquake3.org/patches/)
Good Luck
Khalsa