Rakscha,
both of your examples are considered to be one Logical Source Lines of Code (LSLOC), which was the measure back then in the previous lines of code contest in 2007.
This is from Wikipedia:
"Logical SLOC attempts to measure the number of executable 'statements', but their specific definitions are tied to specific computer languages (one simple logical SLOC measure for C-like programming languages is the number of statement-terminating ***semicolons***).", see
here.
So, if you have 200 or less semicolons, it is OK. That is why there is KB-limitation as well.
I had very much fun back then, I made
a7titude; but it seems to me that most people, who liked it, had problems with the sourcecode (
click here) for one particular reason:
1) function nesting - instead of writing several lines of functions you can pack them together to "abuse" their return values as argument in the next, enclosing function.
For example, the following code makes the my entity look to the you entity, while turning around the z-axis; this is pretty easy:
VECTOR v;
vec_diff(&v, you->x, my->x);
vec_to_angle(my->pan, &v);
my->roll = 0;
This can be reduced in 3 steps into one logical line of code, with the very exact same functionality:
A) Instead of using the static vector in vec_diff, you could replace it with a temporary one:
VECTOR* v = vec_diff(vector(0,0,0), you->x, my->x);
vec_to_angle(my->pan, v);
my->roll = 0;
B) vec_diff returns the modified vector, which is the VECTOR* pointer as was inserted as first argument (the vector(0,0,0) statement); so we could just insert the whole vec_diff statement into vec_to_angle:
vec_to_angle(my->pan, vec_diff(vector(0,0,0), you->x, my->x));
my->roll = 0;
C) vec_to_angle doesn't either return a VECTOR* or an ANGLE* pointer, but a var, which contains the length of the vector. Since we are assigning a value to my->roll, we can abuse this value and multiply it with 0, to make sure that the roll of the my entity becomes zero:
my->roll = vec_to_angle(my->pan, vec_diff(vector(0,0,0), you->x, my->x)) * 0;
2) After I made sure that I fulfil the lines of code restriction, I had trouble with the filesize. So, the other trick I used was using macro replacements: often used instructions were replaced through short macros.
Imagine your code has lots of wait(1); statements, lets say 50. The string "wait(1)" (without the semicolon) has 7 characters (=7 Bytes), x 50 occurences you have 350 characters -- this makes 350 Bytes for the "wait(1)" strings in your textfile (not including the semicolons!). Now, if you use the following macro at the beginning of your code:
and replace all strings "wait(1)" with "XX", you now have 2 Bytes x 50 occurences = 100 Bytes, plus 18 Bytes from the macro definition, a total of 118 Bytes, which is ~34% of the code you used before; you saved a total of 232 Bytes.
You may think "why should I do this?" - well, first of all, this is fun
second, if you left the filesize limit, it helps you especially when you are using one or two functions regularily (other candidates are the vec_ functions, c_move and the like. In some cases certain pattern became visible to me and I even made macros to merge two other macros. The full macro list I used in a7titude is this one:
#define MENU "mainmenu.wmb"
#define A7 while
#define WT wait
#define VS vec_set
#define VG vector
#define K skill
#define J my
#define VI VISIBLE
#define CM camera
#define Z if
#define ID skill1
#define VV VECTOR
#define RE return
#define SP snd_play
#define MM mouse_map
#define NL NULL
#define VD void
#define X )))
#define Q {}
#define SW s(WT(1))
#define JK J.K
#define JI J.ID
#define JV JK[99]/100
#define K1 JK[1]
#define SS screen_size
#define VL vec_length
#define EA ent_animate
#define CL clamp
#define LA eLd.alpha
#define BC bmap_create
My favorite one is of course "A7"
I also had in earlier source versions
but this was too long ^^ As you can see I also noticed that I have sometimes lots of closing brackets, so I did things like
to save code again. All together it resulted in the following: this is the code for the player entity, that little round thing that you move around on the plates:
VD actPlayer(){
A7((pzNr!=JI)&&(s(WT(s(set(J,256*sv(VS(J.x,vs(-10000)X)))))Q
A7((s(WT(s(pl=J)X&&((pzNr==JI)&&(s(reset(J,256)X)Q
Z(!(s(pl=NL*s(ent_remove(J)X)Q}
Creepy, isn't it? And the interesting thing is, that my player function doesn't even have semicolons ^^
But in the end I fulfilled both requirements and made a complete game; it was so much fun
I am considering to take a shot on this contest again, maybe I will do a small component-type thing, which doesn't need this, or I am making a game again, which will need these tricks again ^^ so, lets see if I find the time; other than that I am curious what you will guys make in the end!
I'm already working on something nice. Thanks for the tips, hints and guiderules HeelX!
