Forum

[SOLVED][FTE]Is #CLIENTONLY define really works?

Discuss programming topics for the various GPL'd game engine sources.

Moderator: InsideQC Admins

[SOLVED][FTE]Is #CLIENTONLY define really works?

Postby toneddu2000 » Sat Mar 10, 2018 9:48 am

Hi engine masters! I'm trying to build updated version of FTE (v5224) using preprocessor define #CLIENTONLY .
I put it on top of client/quakedef.h but, when I try to compile it, it gives tons of errors because it searches for server structs / functions that, obviously, it can't find.
Am i missing a step?
Could you please help? Because I'd really like to compile FTE only client as 1° step, then second step would be more ambitious, but just go step by step for now! :)
Huge thanks guys!!
Last edited by toneddu2000 on Sat Mar 10, 2018 11:32 am, edited 1 time in total.
toneddu2000
 
Posts: 1318
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: [FTE]Is #CLIENTONLY define really works?

Postby toneddu2000 » Sat Mar 10, 2018 10:50 am

UPDATE: I also tried to define #clientonly in common/bothdefs.h but also lots of errors. It seems that some files don't have the #ifndef CLIENTONLY part where server parts are used
toneddu2000
 
Posts: 1318
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: [FTE]Is #CLIENTONLY define really works?

Postby toneddu2000 » Sat Mar 10, 2018 11:31 am

ok, I made it work.

client/cl_plugin.inc line 1248
Code: Select all
#ifndef CLIENTONLY
      Terr_GetTerrainFuncs
      #endif

client/textedit.c line 1018
Code: Select all
#ifndef CLIENTONLY
            NET_Sleep(20/1000.0, false);   //any os.
         #endif


server/sv_phys.c line 2196
Code: Select all
case MOVETYPE_FLY:
      #ifndef CLIENTONLY
      if (svent)
      {   //NQ players with movetype_fly are not like non-players.
         if (!WPhys_RunThink (w, ent))
            return;
         if (ent->xv->gravitydir[2] || ent->xv->gravitydir[1] || ent->xv->gravitydir[0])
            gravitydir = ent->xv->gravitydir;
         else
            gravitydir = w->g.defaultgravitydir;
         WPhys_CheckStuck (w, ent);
         WPhys_WalkMove (w, ent, gravitydir);
         break;
      }
      //fallthrough
      #endif


common/bothdefs.c line 248
Code: Select all
#ifndef CLIENTONLY
         #if defined(_WIN32) && !defined(FTE_SDL) && !defined(WINRT)
            #define SUBSERVERS   //use subserver code.
         #elif defined(__linux__) && !defined(ANDROID) && !defined(FTE_SDL)
            #define SUBSERVERS   //use subserver code.
         #endif
      #endif


common/bothdefs.c line 271
Code: Select all
#ifndef CLIENTONLY
         #define RAGDOLL
      #endif


common/bothdefs.c line 288
Code: Select all
#ifndef CLIENTONLY
         #define SVCHAT         //serverside npc chatting. see sv_chat.c
         #define Q2SERVER      //server can run a q2 game dll and switches to q2 network and everything else.
         #define Q2CLIENT      //client can connect to q2 servers
         #define HEXEN2         //mostly server only, but also includes some hud+menu stuff, and effects
      #endif


common/bothdefs.c line 303
Code: Select all
#ifndef CLIENTONLY
         #define WEBCLIENT      //http clients.
      #endif


common/bothdefs.c line 585
Code: Select all
#ifndef CLIENTONLY
   #if defined(HAVE_WINSSPI) || defined(HAVE_GNUTLS)
      #define HAVE_SSL
   #endif
#endif


and finally, in common/bothdefs.c add, at line 24
Code: Select all
#define CLIENTONLY


yay! Next step will be to remove sv_phys and engine menu and re-do all this stuff in craFTEr! :biggrin:
toneddu2000
 
Posts: 1318
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: [SOLVED][FTE]Is #CLIENTONLY define really works?

Postby Max_Salivan » Sat Mar 10, 2018 9:08 pm

compile engine with make sv-rel CFLAGS=-DCLIENTONLY ???
Sorry for my english :)
Max_Salivan
 
Posts: 93
Joined: Thu Dec 15, 2011 1:00 pm


Re: [SOLVED][FTE]Is #CLIENTONLY define really works?

Postby Spike » Mon Mar 12, 2018 1:32 am

if you're trying to strip out lots of stuff, you might want to use wastes/TW as a base.
cp common/config_wastes.h common/config_myconfig.h && make m-rel FTE_CONFIG=myconfig
causes it to read a custom config header based upon eukara's wastes config with a number of config options that strip out optional/vanilla stuff that simply isn't needed in (eg) The Wastes, which disturbingly makes it smaller than the no-server 'minimal' builds... I blame 3rd-party libraries.
I ought to split the minimal and standard configs into seperate config files too, if only to make the different configs easier to diff.

There are too many options for me to really care about every single combination of options, so yeah, expect it to bug out (usually by failing to compile) unless other stuff is also disabled too. :(
I probably also ought to go through and change the NOFOOs to FOOs instead, and all sorts of other cleanups, but gah. I don't much like cleaning code, usually I just end up breaking and not having the enthusiasm to hunt all the new bugs so I tend to do it only when there's a purpose beyond the code itself.

side note: building a server using only a client is a little folly.
Spike
 
Posts: 2883
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: [SOLVED][FTE]Is #CLIENTONLY define really works?

Postby toneddu2000 » Mon Mar 12, 2018 6:45 am

The Wastes you say, huh? Definately I'll try it, thanks. I'll sure post it here.

Would it be possible to add a new "game" profile with the same options of The Wastes?
Because I'd suggest to create a "General modern game" profile with just the "game" folder as game folder and a neutral icon(I'd do it for you in no time, if you need it), so, people like me could use it to make non-quake games.
I personally just use:iqm,tga,particles,dynamiclight_add,and a single .bsp hull of 6 walls as map.

Spike wrote:I probably also ought to go through and change the NOFOOs to FOOs instead, and all sorts of other cleanups, but gah.
Yeah, I noticed everywhere #ifndef CLIENTONLY...
Yesterday I really tried to understand how engine works, which parts are called at start, but it's for me very difficult because of my poor C skills.
I *guess* it starts with WinMain() that calls Host_Init(),but then Host_Init call R_SetRenderer with argument to NULL and then I lost the way home! :biggrin:
I really really would like to contribute and to make a super light build of FTE with just client( and no net protocols at all),opengl, iqm, tga and an already bsp hull created by code at startup (I did it in quakec but not in the engine) but for now it's too difficult for me

Spike wrote:side note: building a server using only a client is a little folly.
That's what Max_Salivan said. I never said I compile the server. That would be absurd, I agree.
Infact, I use make gl-rel FTE_TARGET=win32 -j 8. That's it.

PS:Since you're here, I sent you a pm some day ago to say that latest modification you made (v5221) to add dynamiclight_spawnstatic ruined dynamiclight_add func. Now dynamic lights flicker every frame.
Sorry to bother you
toneddu2000
 
Posts: 1318
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: [SOLVED][FTE]Is #CLIENTONLY define really works?

Postby Spike » Mon Mar 12, 2018 10:11 am

in terms of rendering, the basic idea is that FTE is 'just' trisoup.
the client generates batches of trisoup meshes. each batch has a single shader and a few other common properties. the backend logic of each renderer then takes those batches, walks through the shader passes, and draws the meshes accordingly.
the backends configure the shader logic via the sh_config struct, which controls the accepted aspects of the shaders (like whether glsl can be used or not, or the max number of textures per pass). the usable texture formats are configured the same way too.
so the model code is responsible for loading models, the image.c code is responsible for loading texture files and converting into formats supported by the gpu. the gl_shader.c code is responsible for parsing shaders and generating the internal representation of those. the client code handles bsp culling+pvs to add the various meshes into batches.
each renderer has a rendererinfo_t struct that tells the rest of the engine what to call in order to get any gpu work done - its pretty much all trisoup, textures, and buffers.
the renderer then has a fairly generic interface which allows FTE to support many renderers without too much extra effort, in theory.

rendering wise, GLSCR_UpdateScreen is the function that's meant to be responsible for throwing everything at the screen. So if you're trying to walk through FTE's rendering stages, start there. There shouldn't be any drawing elsewhere. Note that the other renderers have their own alternatives to this function, which sucks.
pr_csqc.c contains most of the csqc-only builtins (any externally-visible gunctions are meant to have a CSQC_ prefix, while builtins follow the PF_ prefix), with pr_cmds.c giving the ssqc-only ones, with pr_menu.qc giving the menu-only ones, supposedly. pr_bgcmd.c contains the generic builtins that might be used by any vm, while pr_clcmd.c gives builtins shared between csqc+menuqc, and pr_skelobj.c giving the skeletal object, ragdoll, and a number of model-related builtins shared between csqc+ssqc.
gl_shadow.c's rtlights are sandwiched between two shader sort values called from somewhere inside gl_backend.c or so.

but yeah, its a large project, with lots of legacy, the more you play with it, the more you'll understand it - practise makes perfect.... or something.
Spike
 
Posts: 2883
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: [SOLVED][FTE]Is #CLIENTONLY define really works?

Postby toneddu2000 » Sun Mar 18, 2018 9:45 am

Spike wrote:rendering wise, GLSCR_UpdateScreen is the function that's meant to be responsible for throwing everything at the screen. So if you're trying to walk through FTE's rendering stages, start there. There shouldn't be any drawing elsewhere.
Thanks a lot Spike, that's what I was trying to do

Spike wrote:pr_csqc.c contains most of the csqc-only builtins (any externally-visible gunctions are meant to have a CSQC_ prefix, while builtins follow the PF_ prefix), with pr_cmds.c giving the ssqc-only ones, with pr_menu.qc giving the menu-only ones, supposedly. pr_bgcmd.c contains the generic builtins that might be used by any vm, while pr_clcmd.c gives builtins shared between csqc+menuqc, and pr_skelobj.c giving the skeletal object, ragdoll, and a number of model-related builtins shared between csqc+ssqc.
That's important too. Are there parts of skeletal code that are shared with ssqc? Or, if I build an only client release, do I have all the skeletal stuff up and ready?

Spike wrote:gl_shadow.c's rtlights are sandwiched between two shader sort values called from somewhere inside gl_backend.c or so.
well, I'll try to look at that too

Spike wrote:but yeah, its a large project, with lots of legacy, the more you play with it, the more you'll understand it - practise makes perfect.... or something.
LOL
toneddu2000
 
Posts: 1318
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy


Return to Engine Programming

Who is online

Users browsing this forum: No registered users and 1 guest