Advertisement

Trouble trying to set up Enet

Started by November 29, 2005 04:29 PM
7 comments, last by misterPhyrePhox 19 years, 2 months ago
I've been trying to compile Enet and, although it compiles fine, it doesn't link very well. I get a bunch of link errors relating to list.cpp, saying that the list functions (enet_list_clear, etc) are unresolved external symbols. I am on windows. Has anyone experienced this problem before? Does anyone know what could be wrong? Here is the full build log:

------ Build started: Project: Server, Configuration: Debug Win32 ------
Compiling...
Server.cpp
win32.cpp
c:\base\code\enet\win32.cpp(82) : warning C4996: 'strncpy' was declared deprecated
        c:\program files\microsoft visual studio 8\vc\include\string.h(123) : see declaration of 'strncpy'
c:\base\code\enet\win32.cpp(160) : warning C4244: '=' : conversion from 'SOCKET' to 'int', possible loss of data
c:\base\code\enet\win32.cpp(277) : warning C4244: 'argument' : conversion from 'ENetSocket' to 'int', possible loss of data
host.cpp
c:\base\code\enet\host.cpp(66) : warning C4244: '=' : conversion from '__w64 int' to 'enet_uint16', possible loss of data
c:\base\code\enet\host.cpp(173) : warning C4267: 'argument' : conversion from 'size_t' to 'u_long', possible loss of data
packet.cpp
peer.cpp
c:\base\code\enet\peer.cpp(115) : warning C4267: 'argument' : conversion from 'size_t' to 'u_long', possible loss of data
c:\base\code\enet\peer.cpp(126) : warning C4267: '+=' : conversion from 'size_t' to 'enet_uint32', possible loss of data
c:\base\code\enet\peer.cpp(135) : warning C4267: 'argument' : conversion from 'size_t' to 'u_long', possible loss of data
c:\base\code\enet\peer.cpp(141) : warning C4267: 'argument' : conversion from 'size_t' to 'enet_uint16', possible loss of data
c:\base\code\enet\peer.cpp(171) : warning C4267: 'argument' : conversion from 'size_t' to 'enet_uint16', possible loss of data
protocol.cpp
c:\base\code\enet\protocol.cpp(52) : warning C4244: 'argument' : conversion from '__w64 int' to 'enet_uint8', possible loss of data
c:\base\code\enet\protocol.cpp(251) : warning C4267: 'argument' : conversion from 'size_t' to 'u_long', possible loss of data
c:\base\code\enet\protocol.cpp(406) : warning C4267: '=' : conversion from 'size_t' to 'enet_uint32', possible loss of data
c:\base\code\enet\protocol.cpp(658) : warning C4267: '+=' : conversion from 'size_t' to 'enet_uint32', possible loss of data
c:\base\code\enet\protocol.cpp(920) : warning C4267: '+=' : conversion from 'size_t' to 'enet_uint32', possible loss of data
c:\base\code\enet\protocol.cpp(1160) : warning C4267: '=' : conversion from 'size_t' to 'enet_uint8', possible loss of data
callbacks.cpp
list.cpp
Generating Code...
Linking...
host.obj : error LNK2019: unresolved external symbol _enet_list_clear referenced in function _enet_host_create
protocol.obj : error LNK2001: unresolved external symbol _enet_list_clear
peer.obj : error LNK2019: unresolved external symbol _enet_list_remove referenced in function _enet_peer_receive
protocol.obj : error LNK2001: unresolved external symbol _enet_list_remove
peer.obj : error LNK2019: unresolved external symbol _enet_list_insert referenced in function _enet_peer_queue_acknowledgement
protocol.obj : error LNK2001: unresolved external symbol _enet_list_insert
Debug\Server.exe : fatal error LNK1120: 3 unresolved externals
Build log was saved at "file://c:\Base\Code\NetworkTest\Server\Debug\BuildLog.htm"
Server - 7 error(s), 16 warning(s)

have you included the list.c file into the project?

on microsoft c++ compiler, did you built the library with the same code generation settings as your application?

are you also linking against ws2_32? and in case of microsoft c++, winmm?

are you using the latest CVS version from enet.bespin.org? (enet.cubik.org is an older site. also, connect to the CVS repository, the downloadable archive is older).
Advertisement
Quote:
have you included the list.c file into the project?

Yes.
Quote:
on microsoft c++ compiler, did you built the library with the same code generation settings as your application?

Yeah.
Quote:
are you also linking against ws2_32? and in case of microsoft c++, winmm?

I'm "linking" ws2_32 and winmm, yes, but I don't know what "linking against" means -- is it the same thing?

Quote:
are you using the latest CVS version from enet.bespin.org? (enet.cubik.org is an older site. also, connect to the CVS repository, the downloadable archive is older).

I downloaded the archive from enet.bespin.org. I don't know that much about using CVS... I'll try downloading the client and getting the latest version there.

But anyway, I think I may have solved it. If I just copy the contents of list.cpp into the beginning of host.cpp (or, if I #include "list.cpp"), then it seems to work fine. Is this OK? I'll try playing around, and see if I encounter any problems using this method.

Thanks, though! I'll definitely try getting the latest version from the CVS, and see if that works... if I can figure out how to use CVS :D.

(I also have another question, about networking in games in general. What is an acceptable/average size of a packet? Like, should I maybe transmit the server-side position of an entity to a client in one packet, and then send 20 packets for each ent, or should I have one packet per 20 entities, or what?)
You certainly dont want to have a packet for each entity, but how many you send really depends on how big they are and how often you send them. Pack all relevant information into one packet, although most MTU settings allow a maximum UDP packet size of about 1400 bytes for a single packet.

In client server architectures, there is generally a 'net tick rate' which is the frequency at which the server sends out a state update packet to each client. Each of those packets would describe the state of all relevant entities (or maybe only changes among them; delta compression). Most quake 3 servers run at 30 fps with a net update each tick. However based on your game, you may need more or less. Think about your target bandwidth, and work it out yourself. If your packets are about 100bytes usually, then at 30fps, 100*30 = about 3kbps.
Oops, that was me :D. Forgot to sign in.
Err... actually, I have another question. Sorry about the triple post :D. Anyway, I was wondering -- does ENet have any functions to convert from host-byte ordering to network-byte ordering? Or do you have to do that using the winsock functions (I forget what they are, something like ntohl, etc)? And when you're transmitting a string, you have to convert every char to network-byte ordering, right?
Edit: And one more, final, question :D. What is the significance of UDP channels? Thanks alot in advance, sorry I'm asking so many questions!
Edit2: I found ENET_HOST_TO_NET_16 in the source file, so never mind about my first question. I also am pretty sure you would have to convert every char to network byte-ordering -- that seems like it would make sense.

[Edited by - misterPhyrePhox on November 30, 2005 4:43:01 PM]
Advertisement
Hi,

Byte ordering (endianness) is really about "byte" ordering, so you don't need to change anything in your chars. The only data that has to go through your ENET_HOST_TO_NET_16 (or ENET_HOST_TO_NET_32) are shorts, ints, and other integers that take more than 1 byte of space.

That's why it is so easy to send text through networks :)
Quote:
Original post by small_duck
Hi,

Byte ordering (endianness) is really about "byte" ordering, so you don't need to change anything in your chars. The only data that has to go through your ENET_HOST_TO_NET_16 (or ENET_HOST_TO_NET_32) are shorts, ints, and other integers that take more than 1 byte of space.

That's why it is so easy to send text through networks :)


Ahh! Thank you! I was under the mistaken impression that byte-ordering was bit-ordering. Which, looking back now, is incredibly stupid :D.

This topic is closed to new replies.

Advertisement