Free Borland Compiler problems (exe has been made)

[BinarySpike]

Ok me and my friend (crewmanjenkis? I think he posted about modding)  have been setting up dp on various compilers.  On windows VC was fine, but Borland had a problem.

Whenever we tried to join the normal b18 (that we updated from b16) it would just say "ub_cliff by unibonger" over and over and over.

We tried the Borland compiled server as well, same problem.  When using a normal client on our compiled server, the problem was not there.  Obviously it is client error, anybody have any clues?

Also, multithreading messes up debugging, so I can't debug.  if someone could tell me the location of where it prints the worldspawn "message" that would be helpful.  Cause it just keeps printing that over and over and over.

Thanks

*edit*
I tried going to the list server and it crashed, multithreading won't show me where though :-/

*edit2*
Ah, on "join game" I get a dialog.
Net_SendPacket: bad address type

[BinarySpike]

Oh yes, Just remembed.

I changed a ton of variable mismatch (several int variables were declared earlier as qboolean, etc. etc.)

As for several if statements that used floats
if (dedicated && dedicated->value)

to
if (dedicated)
  if (dedicated->value)

And there were a crapload of warnings mostly unsinged and signed comparison and "suspicious variable assignment"

(not to mention I had to make borland versions of pthreadvc.lib, winmm.dll and wsock32.lib)

[jitspoe]

Do a search for COLOR_MAPNAME.  That will point you to where the map name is printed out.

As for several if statements that used floats
if (dedicated && dedicated->value)

to
if (dedicated)
  if (dedicated->value)

These both do the same thing -- why the change?

[lekky]

if (dedicated && dedicated->value) is better coding style

[Cobo]

if (dedicated && dedicated->value) is better coding style

According to who?
It may be a better coding style for some people but im sure the other way is prefered by others.

[lekky]

#1
if (dedicated && dedicated->value) {
// do some action
}

#2
if (dedicated) {
  if (dedicated->value) {
// do some action
}
}

# 1 is better because the action depends upon that clause being met. #2 would be better if:

if (dedicated) {
if (dedicated->value) {
// do something
}
else {
// do something else
}
}

[S8NSSON]

Maybe you should look at some simple assembler equivalents of both of those lines and then decide which is better?

if(dedicated && compare){} version:

Code: [Select]

MOV  R0,R4
OR   R0,R5
BREQ _0x5
MOV  R0,R6
OR   R0,R7
BRNE _0x6
_0x5:
_0x6:
if(dedicated){if(compare){}} version

Code: [Select]

MOV  R0,R4
OR   R0,R5
BREQ _0x7
MOV  R0,R6
OR   R0,R7
BREQ _0x8
_0x8:
_0x7:
It may just come down to coder preference, ya think?
I prefer the all-in-one-line compare methods myself whenever possible.

[Eiii]

It depends, what are the timings of BREQ and BRNE?

[jitspoe]

Why are you using the Borland compiler anyway?

[S8NSSON]

eiiio:
I looked into the timings a bit and couldn't find anything directly related, but logically I would imagine both commands operate identically.
I say this because it's a simple matter of setting setting a flag, or not setting a flag (possible the zero flag of the CPU). It should really take no more CPU cycles to do one versus the other.
EDIT: Both commands work on the same timings according to the documentation.
It's retarded. I hate assembler.

Jitspoe:
It's AVRAssembler (avrasm32).
It's what I use (as little as possible) for programming these ATmega128 micro controllers.

The assmbler I posted is a direct AVR interpretation of the stated c code above each example.
I mostly code in c using AVR's GUI. The c code is then converted to assembler and then into the hex file I upload and run on the micro.
That's why the assembler contains oddities like "_0x8:" instead of a more sensible labeling.
I only resort to writing out straight assembler when I really need to control registers and memory space, which is rare, and mostly in-line with c code.

Did I say I hate assembler?
But understanding it helps, especially with these micros.