Forum

InsideQC Forums

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

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

Posted: Sat Mar 10, 2018 9:48 am

by toneddu2000

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!!

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

Posted: Sat Mar 10, 2018 10:50 am

by toneddu2000

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

yay! Next step will be to remove sv_phys and engine menu and re-do all this stuff in craFTEr!

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

Posted: Sat Mar 10, 2018 9:08 pm

by Max_Salivan

compile engine with make sv-rel CFLAGS=-DCLIENTONLY ???

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

Posted: Sat Mar 10, 2018 10:31 pm

by toneddu2000

I don't understand ,was it a question or an answer?

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

Posted: Mon Mar 12, 2018 1:32 am

by Spike

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=myconfigcauses 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.

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

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! 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

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

Posted: Mon Mar 12, 2018 10:11 am

by Spike

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.

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

Posted: Sun Mar 18, 2018 9:45 am

by toneddu2000

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

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

Posted: Fri Sep 13, 2019 9:16 am

by toneddu2000

After 1 year (!) I followed your suggestion to use the wastes config and it worked, thanks Spike! The exe size ranged from 7MB to 3.5MB!This is my copied config from the wastes (I left Vera Visions copyright to avoid irritating anyone)

Detected attempt to draw framebuffer where framebuffer is not validR2D_Flush was set outside of SCR_UpdateScreen

In my commenting rampage I definately commented something that must be not commented, but what?

##EDIT##I noticed that also the wastes config gives same error, so probably must be in the fact that is client only##EDIT2##if I add a variable that is triggered by input and according to that variable I print drawstring,drawfill,etc, it works. Apparently it shutdown when level is not completely loaded and a draw call is called. There's a way to detect is level is full loaded?

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

Posted: Fri Sep 13, 2019 4:17 pm

by Spike

You're only allowed to throw stuff at the screen during CSQC_UpdateView or CSQC_UpdateViewLoading calls. If you're trying to draw within the callstack of any other entry point then you'll get those sorts of errors.As a special exception, drawing to render targets is permitted elsewhere (as the results may still be useful).

Violating this rule is pointless as the next call to CSQC_UpdateView will scribble over everything anyway.And these are warnings, not errors, if its shutting down then that's being caused by something else.

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

Posted: Fri Sep 13, 2019 6:14 pm

by toneddu2000

You're only allowed to throw stuff at the screen during CSQC_UpdateView or CSQC_UpdateViewLoading calls. If you're trying to draw within the callstack of any other entry point then you'll get those sorts of errors.

I jush test it with my latest release of Meadow Fun!!, which it's now online since January (so I guess it's pretty stable). With normal FTE build no errors(even v5540), no warnings and of course no CSQC shutdown at all. The problem is when I use the stripped build from the wastes or the one derived from it (same shutdown).

All the draw* calls are inside CSQC_UpdateView, as always. It's just that the stripped build cannot handle it properly. No idea how, my VERY humble opinion is that, during map reload (is in that moment that CSQC shuts, between game map exit and map menu) client calls server and since there's no server in that build, it failed the R2D_Flush calls. You say, how can I be so sure about it?Because, if I set