Official Post Your Enging Coding Tips Thread

[Team Xlink]

Hello, I thought this would be a helpful thread.

You just post all of your little Engine Coding Tips and common problems and what solves them.

I will start.


Unused Variable

Code: Select all

gldraw.c:1010: warning: unused variable 'verts'

Solution

Go to line 1010 of "gldraw.c" and remove the variable "verts"

[revelator]

hmm ok

warnings about mismatching formats (int to float etc)

say you have a variable that needs a float value like ent->fog[0] = 0.0;

this will give a warning about doubles so change 0.0 to 0.0f.
int needs long type as far as i know so if 0.0 is int change it to 0.0L.

the example ent->fog[number] above is btw an array "very usefull"
instead of having 3 or more float variable's you can get away with a single definition.

float x=1
float y=2
float z=3

can instead be float xyz[3] = {1,2,3};

[Spike]

warnings about mismatching formats (int to float etc)

#pragma warning( 4 : 4244) //conversion from const double to float
#pragma warning( 4 : 4305) //truncation from const double to float
#pragma warning( 4 : 4018) //truncation from const double to float
#pragma warning( 4 : 4267) //truncation from const double to float

much easier.

But really:
#pragma warning(1:4013)

I highly recommend that one. Highly highly recommend it.
It makes functions without prototypes generate decent warnings (hint: change the 1 to 'error').
Note that functions without prototypes are assumed to take only int parameters. Everything breaks when the function really takes a float - floating point arguments are actually passed as doubles, and take twice as much memory as ints. Meaning that if you call a function without prototypes, your arguments all get shifted and mixed up and converted when they shouldn't be, etc. Its not pretty. Failing to warn about this kind of bad practise is not nice. Note that this is even more important when you're mixing int and pointers and floats and stuff on a 64bit build.

[Team Xlink]

If you have this in your code:

Code: Select all

	}
	else
	{

Then you can change it to this to make it shorter:

Code: Select all

	}else{

Also speaking of floats:

Is it good to fix this error:

Code: Select all

GlBlend undeclared first use in this function

by adding

Code: Select all

	float		GlBlend;

to the top of that function?

[Downsider]

If you have this in your code:

Code: Select all

	}
	else
	{

Then you can change it to this to make it shorter:

Code: Select all

	}else{

:roll:

[Creebo]

Oh and before you compile make sure you put everything on one line. I would make a backup, but one line will make the entire engine 200% faster.

[frag.machine]

Oh and before you compile make sure you put everything on one line. I would make a backup, but one line will make the entire engine 200% faster.

Huh ? :?

[Downsider]

He's just screwing with you.

[Team Xlink]

So I shouldn't use that?

the:

Code: Select all

}else{

I have seen it used in the code tho.

[Downsider]

Feel free to use it, it's just that it's basic knowledge regarding the syntax of many, many languages out there.

[Spike]

Use whatever makes your code more readable for you/your team.
Consistancy is often better than reducing line counts.
If you have a widescreen monitor, consider twisting it by 90 degrees for coding, then you don't have to try and keep line counts low.

Quake has a consistant style already, that is, braces are on their own lines. Zoid messed up parts of the quakeworld code by breaking that style - you can clearly distinguish the bits that were written by him.

I'm not going to argue about which style is best (gah gnu style!), but I will argue that a consistant code style is more important than mere line counts. Readability is king.

Creebo: My own engine has too many #defines for it to all fit on a single line, sadly enough.
Interestingly enough, if you find compiling C++ code slow, you can concatinate all your source files together into one blob (basically just #include "*.cpp"). This can increase compilation speed fairly significantly if you use a few different classes and inheritance and other stuff from a monolithic header file such as the one quake uses. Sure, okay, its not a single line, but mneh. That really would be a pain to fix any compile errors. 'Error on line 1 compiling everything.c'. Nooo!

[revelator]

hehe

ok heres one that might be usefull if someone decides to go compile the original quake source on newer msvc.

the assembler in NET. msvc has changed quite a bit over the years
for one inline assembly was removed .

also the syntax for the gas2masm conversion in old msvc used "command","variables" in NET it just uses command,variables

so remove all the "" and it works


if you get sick of msvc NET's warnings add _CRT_SECURE_NO_WARNINGS or
_CRT_SECURE_NO_DEPRECATE to the preprocessor variables.

some might argue that it's not intended to turn of compiler warnings but unless you want to port everything in the source to microsofts secure library format "which will also break compatibility with free compilers like mingw etc" this will have to do.

and yes floats are evil use byte or int instead if possible.

[Downsider]

Haha it takes more effort and time to reduce everything to one line anyway, and it certainly won't help the game itself run faster, only the compile time if anything.

[mh]

Code: Select all

}else{

Some people prefer it, some people don't. For me, code readability is far more important than vertical real estate, and I just find that style of coding to be completely unreadable. It's all about visually matching opening and closing braces in the same column. But everyone's different, and no one style is intrinsically superior to any other. Plus if someone's already made their mind up about their own preference, no amount of hot air and wasted energy is gonna convince them otherwise, so let's just leave it, eh?

Q1 specific: instead of doing positional and orientation interpolation in R_RotateForEntity, do it in CL_RelinkEntities.

[Team Xlink]

Use whatever makes your code more readable for you/your team.
Consistancy is often better than reducing line counts.
If you have a widescreen monitor, consider twisting it by 90 degrees for coding, then you don't have to try and keep line counts low.

Quake has a consistant style already, that is, braces are on their own lines. Zoid messed up parts of the quakeworld code by breaking that style - you can clearly distinguish the bits that were written by him.

I'm not going to argue about which style is best (gah gnu style!), but I will argue that a consistant code style is more important than mere line counts. Readability is king.

Creebo: My own engine has too many #defines for it to all fit on a single line, sadly enough.
Interestingly enough, if you find compiling C++ code slow, you can concatinate all your source files together into one blob (basically just #include "*.cpp"). This can increase compilation speed fairly significantly if you use a few different classes and inheritance and other stuff from a monolithic header file such as the one quake uses. Sure, okay, its not a single line, but mneh. That really would be a pain to fix any compile errors. 'Error on line 1 compiling everything.c'. Nooo!

So adding everything into one file will make it run faster?

This will be excellent, there will be a lot of messed up defines and includes tho.