Official Post Your Enging Coding Tips Thread
Moderator: InsideQC Admins
51 posts
• Page 1 of 4 • 1, 2, 3, 4
Official Post Your Enging Coding Tips Thread
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
Solution
Go to line 1010 of "gldraw.c" and remove the variable "verts"
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"
- Team Xlink
- Posts: 368
- Joined: Thu Jun 25, 2009 4:45 am
- Location: Michigan
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};
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};
-

revelator - Posts: 2567
- Joined: Thu Jan 24, 2008 12:04 pm
- Location: inside tha debugger
reckless wrote: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.
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
If you have this in your code:
Then you can change it to this to make it shorter:
Also speaking of floats:
Is it good to fix this error:
by adding
to the top of that function?
- 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?
- Team Xlink
- Posts: 368
- Joined: Thu Jun 25, 2009 4:45 am
- Location: Michigan
Team Xlink wrote: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{
-

Downsider - Posts: 621
- Joined: Tue Sep 16, 2008 1:35 am
Creebo wrote: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 ?
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC
(LordHavoc)
-

frag.machine - Posts: 2090
- Joined: Sat Nov 25, 2006 1:49 pm
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!
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!
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
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 :S.
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.
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 :S.
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
-

revelator - Posts: 2567
- Joined: Thu Jan 24, 2008 12:04 pm
- Location: inside tha debugger
- 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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
-

mh - Posts: 2292
- Joined: Sat Jan 12, 2008 1:38 am
Spike wrote: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.
- Team Xlink
- Posts: 368
- Joined: Thu Jun 25, 2009 4:45 am
- Location: Michigan
51 posts
• Page 1 of 4 • 1, 2, 3, 4
Who is online
Users browsing this forum: No registered users and 1 guest