opentnl-general Mailing List for Torque Network Library (Page 10)
Brought to you by:
mark_frohnmayer,
s_alanet
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
(39) |
May
(34) |
Jun
(5) |
Jul
(5) |
Aug
(3) |
Sep
|
Oct
(8) |
Nov
|
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(2) |
Feb
(8) |
Mar
(18) |
Apr
(6) |
May
(12) |
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
(8) |
Nov
(1) |
Dec
|
2006 |
Jan
(5) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2007 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
(1) |
Feb
|
Mar
(10) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(3) |
2009 |
Jan
(24) |
Feb
(2) |
Mar
(2) |
Apr
(26) |
May
(75) |
Jun
(85) |
Jul
(46) |
Aug
(18) |
Sep
(14) |
Oct
(24) |
Nov
(8) |
Dec
(3) |
2010 |
Jan
(1) |
Feb
(1) |
Mar
(40) |
Apr
(57) |
May
(80) |
Jun
(58) |
Jul
(45) |
Aug
(49) |
Sep
(28) |
Oct
(6) |
Nov
(1) |
Dec
(3) |
2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(3) |
Jun
(10) |
Jul
(7) |
Aug
(7) |
Sep
(2) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
2012 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
(1) |
Jul
(11) |
Aug
(13) |
Sep
(8) |
Oct
(4) |
Nov
|
Dec
(1) |
2013 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
(2) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(14) |
Sep
(44) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
2014 |
Jan
(4) |
Feb
(42) |
Mar
(3) |
Apr
(1) |
May
(7) |
Jun
(5) |
Jul
(14) |
Aug
(2) |
Sep
(2) |
Oct
(54) |
Nov
(43) |
Dec
(36) |
2015 |
Jan
(48) |
Feb
(64) |
Mar
(52) |
Apr
(24) |
May
(52) |
Jun
(60) |
Jul
(6) |
Aug
(15) |
Sep
(1) |
Oct
|
Nov
(7) |
Dec
(12) |
2016 |
Jan
(17) |
Feb
(2) |
Mar
(6) |
Apr
|
May
(66) |
Jun
(40) |
Jul
(51) |
Aug
(42) |
Sep
(24) |
Oct
(10) |
Nov
(46) |
Dec
(7) |
2017 |
Jan
(14) |
Feb
(11) |
Mar
(2) |
Apr
(1) |
May
(31) |
Jun
(8) |
Jul
(10) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Mark F. <ma...@ga...> - 2004-08-19 20:27:00
|
Hey Matt, I just checked in fixes to all three problems. I'll be doing another release either today or tomorrow that will fix all of the current known issues with TNL. For reference, the fixes were: 1. Changed the scoping function to always scope the buildings 2. Fixed the NetConnection::writeRawPacket function to encrypt and hash ping and ack packets 3. TestConnection::isDataToTransmit always returns true now - Mark matt wrote: >Hi, > >There are a couple issues with the 1.4.0RC4 build for windows. I'm >running XP and using the .NET compiler (2002, version 7.0.9466). > >The problems I'm seeing are from comparing the current version of >TNLtest to the version in release 1.1.2. > >1) The buildings are not sent to the client machines. When the >buildings are generated there is no way to mark them as always in local >scope, like in version 1.1.2; and they never get ghosted on the clients. >The clients are always running around without knowledge of the building >existing. >2) The client times out after 50 seconds of inactivity. Both the host >and client are sending activity pings to each other, but the ping >packets are getting thrown out in the "NetConnection::readPacketHeader" >function. It happens at "pstream->decryptAndCheckHash", the packet is >too short and gets rejected by this function. Later in the >'readPacketHeader' function though, there is a check if the packet type >is a ping packet (line 464) and it calls sendAckPacket in response. >This will never get called for a ping packet. >3) The client only receives updates of the AI positions when the client >player is moving. As soon as the player stops, the AI updates stop as >well. And the client's AI players remain wherever their last moved >stopped them. It seemed that the server's client ghost was detecting >the AI players in its scope, but not sending those AI movements to the >client. > >And lastly, there is a bug in the VC compiler that prevents Zap from >building. The 'ProjectileInfo' structure contains the 'Color' struct >witch is non-aggregate, and the compiler freaks out. The projectile >structure is aggregate, so there should really be no issues (MS bug), >but it still doesn't compile. > >Are these bugs currently known or fixed? If so can you tell me how to >get these items resolved? I'm working on a project with similar >functionality to TNLtest and would appreciate it. > >Regards, >Matt > > >------------------------------------------------------- >This SF.Net email is sponsored by OSTG. Have you noticed the changes on >Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, >one more big change to announce. We are now OSTG- Open Source Technology >Group. Come see the changes on the new OSTG site. www.ostg.com >_______________________________________________ >Opentnl-general mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opentnl-general > > |
From: matt <ope...@ho...> - 2004-08-09 07:11:54
|
Hi, There are a couple issues with the 1.4.0RC4 build for windows. I'm running XP and using the .NET compiler (2002, version 7.0.9466). The problems I'm seeing are from comparing the current version of TNLtest to the version in release 1.1.2. 1) The buildings are not sent to the client machines. When the buildings are generated there is no way to mark them as always in local scope, like in version 1.1.2; and they never get ghosted on the clients. The clients are always running around without knowledge of the building existing. 2) The client times out after 50 seconds of inactivity. Both the host and client are sending activity pings to each other, but the ping packets are getting thrown out in the "NetConnection::readPacketHeader" function. It happens at "pstream->decryptAndCheckHash", the packet is too short and gets rejected by this function. Later in the 'readPacketHeader' function though, there is a check if the packet type is a ping packet (line 464) and it calls sendAckPacket in response. This will never get called for a ping packet. 3) The client only receives updates of the AI positions when the client player is moving. As soon as the player stops, the AI updates stop as well. And the client's AI players remain wherever their last moved stopped them. It seemed that the server's client ghost was detecting the AI players in its scope, but not sending those AI movements to the client. And lastly, there is a bug in the VC compiler that prevents Zap from building. The 'ProjectileInfo' structure contains the 'Color' struct witch is non-aggregate, and the compiler freaks out. The projectile structure is aggregate, so there should really be no issues (MS bug), but it still doesn't compile. Are these bugs currently known or fixed? If so can you tell me how to get these items resolved? I'm working on a project with similar functionality to TNLtest and would appreciate it. Regards, Matt |
From: Mark F. <ma...@ga...> - 2004-07-26 21:07:23
|
Hey Norbert, Great fixes! We would love to integrate them and have you on board as a contributor for TNL. The only thing we need you to do is to fill out the joint copyright assignment form at http://www.opentnl.org/contribute.php and fax or mail it back to GarageGames. Thanks for the fix on the Zap struct initializers too -- that one was giving me a headache. - Mark Norbert Harrer wrote: >First of all, thanks to Mark Frohnmayer for fixing the >"isDataToTransmit() bug" about two month or so ago. I never got around >to thank you for the quick response. Sorry. > >Since I am using CodeWarrior 8.3 for Windows, I have ported the tnl >and Zap source to it. Is there a chance that I could contribute my >modifications to the official source on SourceForge? > >The biggest addition has been made to tnl/tnlMethodDispatch.cpp. >CodeWarrior is using a 3*DWORD class method pointer, which needed >another special assembler code in MarshalledCall::dispatch() for >de-referencing the pointer. The other changes are mostly two-liners to >solve some compiler depending issues. > >To give you an overview, here is the list of changes that I had to >make in order to get CW to compile tnl, Zap and the other little >sub-projects: > > >1. Introduced the macros TNL_COMPILER_STRING and > TNL_SUPPORTS_MWERKS_INLINE_X86_ASM in: > > tnl/tnlTypes.h > >2. CodwWarrior's class method pointer is 3 DWORDs long (no kidding) > and the dereferencing is done completely different then in MSVC and > GCC/x86. > > MethodPointer has been extended to 3*U32. Also wrote a separate > dereferencing assembler code for CodeWarrior in > tnl/tnlMethodDispatch.cpp. Altogether, changes have been made in: > > tnl/tnlJournal.h > tnl/tnlMethodDispatch.cpp > tnl/tnlMethodDispatch.h > tnl/tnlNetObject.h > tnl/tnlRPC.h > >3. CodeWarrior doesn't allow the initialization of an array with a > class like it is done with gWeapons[] in zap/gameWeapons.cpp. Same > issue with gProjInfo[] in zap/projectile.cpp. I added a constructor to > the structs ProjectileInfo and ShipWeaponInfo and did the initialization > through those constructors. Changes made to: > > zap/gameWeapons.cpp > zap/gameWeapons.h > zap/projectile.cpp > zap/projectile.h > >4. Typedef'ed the types U64 and S64 for CodeWarrior builds in: > > tnl/tnlTypes.h > >5. _HEAPOK is not supported in CodeWarrior. So I had to disable the > macro TNL_CHECK_HEAP for CW builds. Changes made in: > > tnl/tnlPlatform.h > tnl/platform.h > >6. CW does not know <memory.h>. <string.h> needs to be included > instead. Modifications made to: > > zap/lpc10dec.c > zap/lpc10enc.c > zap/private.h > >7. The function lrintf is already definition in one of CW's include > files. The duplicate definition needed to be #undef'ed in: > > zap/ftol.h > >8. CodeWarrior for win32 does a "using std::exit;" in stdlib.h. So > declaration of ::exit(int) in glut.h causes an ambiguity error if > someone include stdlib.h before glut.h. Modified glut.h to use > std::exit() instead of ::exit() for CW builds: > > glut/glut.h > >9. A similar issue exists with std::malloc, std::realloc and so forth > in: > > libtomcrypt/mycrypt_custom.h > > >Regards, >Norbert. > > > > > > > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >_______________________________________________ >Opentnl-general mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opentnl-general > > |
From: Norbert H. <nh...@gm...> - 2004-07-25 17:39:43
|
First of all, thanks to Mark Frohnmayer for fixing the "isDataToTransmit() bug" about two month or so ago. I never got around to thank you for the quick response. Sorry. Since I am using CodeWarrior 8.3 for Windows, I have ported the tnl and Zap source to it. Is there a chance that I could contribute my modifications to the official source on SourceForge? The biggest addition has been made to tnl/tnlMethodDispatch.cpp. CodeWarrior is using a 3*DWORD class method pointer, which needed another special assembler code in MarshalledCall::dispatch() for de-referencing the pointer. The other changes are mostly two-liners to solve some compiler depending issues. To give you an overview, here is the list of changes that I had to make in order to get CW to compile tnl, Zap and the other little sub-projects: 1. Introduced the macros TNL_COMPILER_STRING and TNL_SUPPORTS_MWERKS_INLINE_X86_ASM in: tnl/tnlTypes.h 2. CodwWarrior's class method pointer is 3 DWORDs long (no kidding) and the dereferencing is done completely different then in MSVC and GCC/x86. MethodPointer has been extended to 3*U32. Also wrote a separate dereferencing assembler code for CodeWarrior in tnl/tnlMethodDispatch.cpp. Altogether, changes have been made in: tnl/tnlJournal.h tnl/tnlMethodDispatch.cpp tnl/tnlMethodDispatch.h tnl/tnlNetObject.h tnl/tnlRPC.h 3. CodeWarrior doesn't allow the initialization of an array with a class like it is done with gWeapons[] in zap/gameWeapons.cpp. Same issue with gProjInfo[] in zap/projectile.cpp. I added a constructor to the structs ProjectileInfo and ShipWeaponInfo and did the initialization through those constructors. Changes made to: zap/gameWeapons.cpp zap/gameWeapons.h zap/projectile.cpp zap/projectile.h 4. Typedef'ed the types U64 and S64 for CodeWarrior builds in: tnl/tnlTypes.h 5. _HEAPOK is not supported in CodeWarrior. So I had to disable the macro TNL_CHECK_HEAP for CW builds. Changes made in: tnl/tnlPlatform.h tnl/platform.h 6. CW does not know <memory.h>. <string.h> needs to be included instead. Modifications made to: zap/lpc10dec.c zap/lpc10enc.c zap/private.h 7. The function lrintf is already definition in one of CW's include files. The duplicate definition needed to be #undef'ed in: zap/ftol.h 8. CodeWarrior for win32 does a "using std::exit;" in stdlib.h. So declaration of ::exit(int) in glut.h causes an ambiguity error if someone include stdlib.h before glut.h. Modified glut.h to use std::exit() instead of ::exit() for CW builds: glut/glut.h 9. A similar issue exists with std::malloc, std::realloc and so forth in: libtomcrypt/mycrypt_custom.h Regards, Norbert. |
From: Ala566 A. <al...@ho...> - 2004-07-13 08:52:04
|
Hello everyone. I'm a newbie of network programming. I chose TNL as a platform to develop network-based application. But I encountered a problem while trying the "Hello World" sample: the server responses to the client, while client doesn't response to the server. The situation is the same as Devrim Erdem described: http://sourceforge.net/mailarchive/forum.php?thread_id=4846104&forum_id=40302 My working environment is: Windows XP, Visual C++ 6.0 sp5. Please any guru give me some advise. Thanks a lot in advance. Best regards, ala566 _________________________________________________________________ 享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com |
From: Ville A. B. <vbe...@cc...> - 2004-07-11 13:02:05
|
Greetings, While trying to compile tnl with MinGW, I got the following: platform.cpp: In function `bool TNL::Platform::checkHeap()': platform.cpp:123: `_HEAPOK' undeclared (first use this function) This may be a MinGW bug, perhaps _HEAPOK should be defined in malloc.h. Anyway, my solution was to comment out the checkHeap function entirely, since it is apparently never used (and not even defined on platforms other than WIN32). Another question: In class NetConnection, is there a good reason for enum TerminationReason to be protected? I'd like to use it roughly in the following way: void LNetInterface::CL_Reset() { if (server_con) disconnect(server_con, NetConnection::ReasonSelfDisconnect, "Client quits.\n"); netstate = NS_Unconnected; } Is there a better way to do this? Thanks, Ville |
From: <de...@mo...> - 2004-07-07 15:17:15
|
Hello, I have a client which is disconnected after 50 seconds without = networking activity (PingRetryCount * PingTimeout). Is this normal? If I look at the checkTimeout() method the server try to send a ping = packet to check if the connection is still alive. Should the server reveive an ack packet in return? I'm wondering if I must send packets every n seconds to avoid = deconnection or TNL handles this automatically (and so there is a problem in my code because it doesn't work and the = client is disconnected). Thanks in advance, Herve |
From: Ben G. <be...@ga...> - 2004-06-19 22:27:45
|
Todd, That's very mysterious. I'll alert Mark to the situation when he gets back from his trip; I'm not enough of an OSX guru to address the problem. Regards, Ben Todd Brannam wrote: > Yes, I originally started with the head of the CVS archive - and > assumed that perhaps there was a recently introduced problem since I > did see that the precompiled ZAP sample worked fine on the Mac -> > Windows connections. The TNLTest exhibits a similar problem - It > apparently connects ( puzzle is solved, but subsequently the Players & > Building are never rendered on the client). Oddly enough I can't get > the ZAP project to run on OSX either --- I'm getting a mysteriout > ZeroLink runtime warning. I'm new to the XCode environment (and I'm > fairly green on OSX in general) so I haven't figure out that that's > all about. > > Other ideas or follow ups are welcome > > Todd |
From: Todd B. <tbr...@ca...> - 2004-06-19 21:05:27
|
Yes, I originally started with the head of the CVS archive - and assumed that perhaps there was a recently introduced problem since I did see that the precompiled ZAP sample worked fine on the Mac -> Windows connections. The TNLTest exhibits a similar problem - It apparently connects ( puzzle is solved, but subsequently the Players & Building are never rendered on the client). Oddly enough I can't get the ZAP project to run on OSX either --- I'm getting a mysteriout ZeroLink runtime warning. I'm new to the XCode environment (and I'm fairly green on OSX in general) so I haven't figure out that that's all about. Other ideas or follow ups are welcome Todd |
From: Ben G. <be...@ga...> - 2004-06-19 03:48:49
|
Todd, Unfortunately, Mark is out of town until the 22nd, so he can't give you an authoritative answer right now. :) Have you tried the latest version in anonymous CVS? We are using Zap as our test case for TNL development, and it has reliably worked in networked games across mac, linux, and windows systems. Does the TNLTest application work? Regards, Ben Todd Brannam wrote: > I've tried several tagged builds of the TNL library - and I have not > been able to build a the library such that I can connect between an > OSX client and a Windows client. It appears that an onConnection > occurs on both, but further calls never seem to arrive on either > side. The same build works fine on Windows to Windows - and localhost > connection on Mac. > > Are there endian issues or OSX issues that are outstanding that may help? > > Todd |
From: Todd B. <tbr...@ca...> - 2004-06-19 02:53:24
|
I've tried several tagged builds of the TNL library - and I have not been able to build a the library such that I can connect between an OSX client and a Windows client. It appears that an onConnection occurs on both, but further calls never seem to arrive on either side. The same build works fine on Windows to Windows - and localhost connection on Mac. Are there endian issues or OSX issues that are outstanding that may help? Todd |
From: Ben G. <be...@ga...> - 2004-06-08 18:34:38
|
Hi, We're occasionally asked by the press for projects using TNL (right now we're talking to NewsForge), and we'd like to include anyone who has a project that they'd be interested in having mentioned. Of course, that means we have to know about your project. :) If you're interested in having your project mentioned, we'll need a brief project overview and contact person for following up. You can contact me off-list with information. Thanks, Ben Garney |
From: Devrim E. <os...@ma...> - 2004-05-29 20:58:46
|
Hello, Warning : network newbie ! I have got the simple example ( http://opentnl.sourceforge.net/doxytree/simpletutorial.html#simpletutorial ) working on linux. When the example is started, as expected, servers prints the message ( from ::rpcMessageClientToServer() method ). However the ::rpcMessageClientToServer() never gets called. What is wrong ? Is the simple example too simple ? I would appreciate if any OpenTNL expert could give some hint. [lastest stable OpenTNL on Linux] Thanks in advance, Dev |
From: Mark F. <ma...@ga...> - 2004-05-27 17:24:35
|
> GhostConnection::setGhostFrom initializes mGhostZeroUpdateIndex, but > this only happens if that side of the connection is sending ghost > updates. So your analysis was correct - the client is never sending > packets back to the server since has an empty event queue and the > ghostZeroUpdateIndex is 0. The solution that I will implement is to > have the NetConnection also send packets - Ack packets, if it has > received packets that it has not sent acknowledgements for. This will > not advance the window on the clients, since Ack packets don't use a > new sequence number, but it will allow the server to send new > packets. This should not be a part of isDataToTransmit, however, > since that would create a new data packet - which would need to be > ack'd by the server. > > - Mark > Ok, I checked in the fix for this. There were actually two bugs - one was the window filling bug, and one was an unsigned integer underflow comparison issue. Both have been fixed. - Mark |
From: <ben...@id...> - 2004-05-25 08:40:10
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: Mark F. <ma...@ga...> - 2004-05-24 19:09:13
|
Norbert Harrer wrote: >This was not a problem up to now, because the empty packages carried >the ACKs in their header. The behaviour can also be observed when >making a release build of TNLTest with VC++ (where >mGhostZeroUpdateIndex = 0). > >I guess the solution would be to also check on pending Notfies in >isDataToTransmit(). I am not sure though. I have barely understood the >underlaying network mechanisms. > > >Thanks, >Norbert. > > Hey Norbert - good find! I actually have this on my short list as "figure out isDataToTransmit() bug" - I ran into the same thing on a release build of Zap, but fixed it by putting an override function in GameConnection. I'll take a look at the code. * Later * GhostConnection::setGhostFrom initializes mGhostZeroUpdateIndex, but this only happens if that side of the connection is sending ghost updates. So your analysis was correct - the client is never sending packets back to the server since has an empty event queue and the ghostZeroUpdateIndex is 0. The solution that I will implement is to have the NetConnection also send packets - Ack packets, if it has received packets that it has not sent acknowledgements for. This will not advance the window on the clients, since Ack packets don't use a new sequence number, but it will allow the server to send new packets. This should not be a part of isDataToTransmit, however, since that would create a new data packet - which would need to be ack'd by the server. - Mark |
From: Norbert H. <nh...@gm...> - 2004-05-23 18:53:44
|
Hi. First of all, thank you GarageGames, for putting TNL under GPL. I have spent the last two days working around with it. This is really a fine piece of code. I tried to compile TNL & Zap with Metrowerks CodeWarrior 8. I had to make a couple adjustments (maybe more to that in another e-mail), but in the end, Zap seemed to run fine. However the TNLTest didn't work. I tracked down two issues. I am not completely sure if the description below is 100% correct, so it would be great if somebody could look into to verify it: Bug #1: When TNLTest is started as a client, GhostConnection::mGhostZeroUpdateIndex is never properly initialised. The VC++ DEBUG build initialises it to a non-zero default value of 0xcdcdcdcd for example. Now, somewhere down the road, the method NetConnection::checkPacketSend() uses the isDataToTransmit() to check if a package should be sent. This is however always the case, since GhostConnection::isDataToTransmit() checks if mGhostZeroUpdateIndex != 0. This leads to empty packages (besides header) being sent all the time. The weird thing is, that this covers a second bug, which makes the app just run fine when built with VC++. I noticed this, because CodeWarrior initialises mGhostZeroUpdateIndex to 0 instead of 0xcdcdcdcd. So it 'unfortunately' (read below, why) behaved correctly. Bug #2: Now, let's say mGhostZeroUpdateIndex is correctly initialised to 0 and no further empty packages are being sent. However, the only time the TNLTest client sends a package to the server is when the user sets a new position of his player, (rpcSetPlayerPos() and rpcPlayerWillMove() is called). So if the user doesn't do anything, there are no packages sent at all, and no ACK's are ever sent back to the server. When I turn on the LogConnectionProtocol logging, I see that no Notifies are received by the server. I think this causes the server to stop sending packages after a short time. This was not a problem up to now, because the empty packages carried the ACKs in their header. The behaviour can also be observed when making a release build of TNLTest with VC++ (where mGhostZeroUpdateIndex = 0). I guess the solution would be to also check on pending Notfies in isDataToTransmit(). I am not sure though. I have barely understood the underlaying network mechanisms. Thanks, Norbert. |
From: Ben G. <be...@ga...> - 2004-05-13 04:47:16
|
Mark, Seems like you're mixing the multithreaded and singlethreaded C runtime libraries. It can give you all sorts of interesting errors. In general, I've seen the MT recommended, but obviously whatever works is best. :) Regards, Ben Mark P Neyer wrote: > I'm not sure what caused this conflict, but after adding an address > object to my game, I got a linking error - multiply defined symbols. > It said there was a conflict between LIBCMTD.lib and libcd.lib. I > told it not to use libcd.lib and then everything worked fine. Is this > a problem that anyone's aware of? > > > ------------------------------------------------------- > This SF.Net email is sponsored by: SourceForge.net Broadband > Sign-up now for SourceForge Broadband and get the fastest > 6.0/768 connection for only $19.95/mo for the first 3 months! > http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click > _______________________________________________ > Opentnl-general mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentnl-general > > |
From: Mark P N. <Mark@Neyersoftware.com> - 2004-05-13 03:49:41
|
I'm not sure what caused this conflict, but after adding an address object to my game, I got a linking error - multiply defined symbols. It said there was a conflict between LIBCMTD.lib and libcd.lib. I told it not to use libcd.lib and then everything worked fine. Is this a problem that anyone's aware of? |
From: Mark F. <ma...@ga...> - 2004-05-12 21:14:31
|
You're in the right place. This has been fixed in CVS and we're going to do another souce tarball release today. you can replace that line that defines the new operator with: #include <new> should fix your problem. - Mark Mark P Neyer wrote: > Hi, it's me again with another question. I'm working on adding TNL to > the game engine that I'm making, and when I go to complile after > adding the line '#include <tnl.h>, it tells me that the function 'void > *operator new(size_t,void*) already has a body, which has been > definted in (MSFT Visual Studio.NET)\Vc7\include\new. I looked at this > definition, as well as the definition of new in 'tnlTypes.h', and > they appeared to be the exact same thing. I commented out the > function definition in tnlTypes.h and then told it to #include<new> > right there instead, and everything compiled fine. I haven't actually > made the TNL code /do /anything yet, so I can't be sure if this ruins > functionality. Is there any reason why 'new' was defined outside of > the TNL namespace? > > As an aside question, this is my first time joining any sort of open > source development mailing list. Am I asking the 'right kind' of > questions and is this the right place to ask them ? I'd hate to be > annoying everyone on the list ... > > Mark P Neyer |
From: Mark P N. <Mark@Neyersoftware.com> - 2004-05-12 21:00:50
|
Hi, it's me again with another question. I'm working on adding TNL to the game engine that I'm making, and when I go to complile after adding the line '#include <tnl.h>, it tells me that the function 'void *operator new(size_t,void*) already has a body, which has been definted in (MSFT Visual Studio.NET)\Vc7\include\new. I looked at this definition, as well as the definition of new in 'tnlTypes.h', and they appeared to be the exact same thing. I commented out the function definition in tnlTypes.h and then told it to #include<new> right there instead, and everything compiled fine. I haven't actually made the TNL code /do /anything yet, so I can't be sure if this ruins functionality. Is there any reason why 'new' was defined outside of the TNL namespace? As an aside question, this is my first time joining any sort of open source development mailing list. Am I asking the 'right kind' of questions and is this the right place to ask them ? I'd hate to be annoying everyone on the list ... Mark P Neyer |
From: Mark F. <ma...@ga...> - 2004-05-12 18:45:52
|
I wouldn't say it's critical - the base TNL uses dynamic_cast in 3 places and it would be possible to work around these. Stuart Bingë wrote: >On Tuesday, 11 May 2004 22:57, Mark Frohnmayer wrote: > > >>Make sure that in your C++ compiler options you enable RTTI - this may >>be causing the crash. >> >> > >Unrelated to this thread, but is RTTI a critical part of OpenTNL? Basically, >is there no way to build OpenTNL without RTTI? > >This is not a major issue for me, I'm just curious about it :-) > >Cheers, >- Stuart > > >------------------------------------------------------- >This SF.Net email is sponsored by Sleepycat Software >Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver >higher performing products faster, at low TCO. >http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 >_______________________________________________ >Opentnl-general mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opentnl-general > > |
From: Ben G. <be...@ga...> - 2004-05-12 18:43:45
|
Stuart, Isn't so much RTTI as the ability to dynamic_cast, but yes, you're=20 correct. :) Ben Stuart Bing=EB wrote: >On Tuesday, 11 May 2004 22:57, Mark Frohnmayer wrote: > =20 > >>Make sure that in your C++ compiler options you enable RTTI - this may >>be causing the crash. >> =20 >> > >Unrelated to this thread, but is RTTI a critical part of OpenTNL? Basica= lly,=20 >is there no way to build OpenTNL without RTTI? > >This is not a major issue for me, I'm just curious about it :-) > >Cheers, >- Stuart > > >------------------------------------------------------- >This SF.Net email is sponsored by Sleepycat Software >Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to del= iver >higher performing products faster, at low TCO. >http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3 >_______________________________________________ >Opentnl-general mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opentnl-general > > > =20 > |
From: Stuart <omi...@mi...> - 2004-05-12 18:34:08
|
On Tuesday, 11 May 2004 22:57, Mark Frohnmayer wrote: > Make sure that in your C++ compiler options you enable RTTI - this may > be causing the crash. Unrelated to this thread, but is RTTI a critical part of OpenTNL? Basically, is there no way to build OpenTNL without RTTI? This is not a major issue for me, I'm just curious about it :-) Cheers, - Stuart |
From: Lucas M. <lu...@ma...> - 2004-05-12 08:38:24
|
Funny, I didn't turn on RTTI on my first try either, but got a compile error using the same compiler. strange, Lucas > That did it! Thanks for your help. > > Mark Frohnmayer wrote: > >> Have you tried running in the debugger? >> >> Make sure that in your C++ compiler options you enable RTTI - this may >> be causing the crash. |