FlipCode网络编程库源码

  • L4_178990
    了解作者
  • 159.9KB
    文件大小
  • zip
    文件格式
  • 0
    收藏次数
  • VIP专享
    资源类型
  • 0
    下载次数
  • 2022-05-06 12:40
    上传日期
The code includes the cComm, cClient, cPlayer, cNetworkClient, cNetworkServer classes as mentioned in the articles on www.flipcode.com. It also includes working scalable bezier patch code. For those of you not in the know, bezier patches are what's used to create curved surfaces in Quake III, LithTech 2.0 and all the other big engines today. I'm currently using them to draw the background grid but I have plans to make some cool surface deformity animations when a missile explodes.
FlipCode-network.zip
  • Debug
  • NetworkServer
  • Debug
  • NetworkServer.rc
    6.5KB
  • resource.h
    1.5KB
  • cCommServerThread.h
    3.4KB
  • NetworkServer.dsp
    6.3KB
  • cAboutDlg.h
    1.5KB
  • cStatsDlg.h
    2.1KB
  • cClientsDlg.h
    2.1KB
  • cNetworkServer.cpp
    5.1KB
  • cCommServerThread.cpp
    28.8KB
  • cNetworkServer.h
    1.8KB
  • cConnectDlg.h
    5.1KB
  • networkServer.cpp
    478B
  • Common
  • Debug
  • cVehicle.cpp
    3.4KB
  • cMatrix4.h
    6.4KB
  • cMissile.cpp
    3KB
  • cMissile.h
    1.6KB
  • cDialogBox.h
    2.8KB
  • cDInput.h
    4.7KB
  • cClient.h
    2.6KB
  • cWindow.h
    2.5KB
  • cDirectX.h
    316B
  • cMsg.h
    3.4KB
  • State.h
    422B
  • tcLinkedList.h
    2.1KB
  • cPoly.h
    1KB
  • cConsole.h
    954B
  • cVector3.cpp
    447B
  • cPlayer.cpp
    3.3KB
  • cVector3.h
    6.4KB
  • NetworkPrivate.lib
    205.8KB
  • cLog.h
    928B
  • cPoly.cpp
    1.8KB
  • cVehicle.h
    1.4KB
  • cVector4.h
    3.2KB
  • cComm.h
    4.2KB
  • cPlayer.h
    3.4KB
  • cD2D.h
    2.7KB
  • cPatch.h
    960B
  • cDDraw.h
    2.8KB
  • cComm.cpp
    9.2KB
  • cVector4.cpp
    487B
  • cMsgQueue.h
    1KB
  • NetworkPrivate
  • Debug
  • cMatrix4.h
    6.4KB
  • cDialogBox.h
    2.8KB
  • cDInput.h
    4.7KB
  • cWindow.h
    2.5KB
  • cDialogBox.cpp
    4.9KB
  • cDirectX.h
    316B
  • cMatrix4.cpp
    1.3KB
  • cWindow.cpp
    6.4KB
  • tcLinkedList.h
    2.1KB
  • NetworkPrivate.dsp
    3.8KB
  • cConsole.h
    954B
  • cConsole.cpp
    2.9KB
  • cLog.cpp
    3.2KB
  • cVector3.h
    6.4KB
  • cLog.h
    928B
  • cVector4.h
    3.2KB
  • cD2D.cpp
    10.7KB
  • cDInput.cpp
    22.4KB
  • cD2D.h
    2.7KB
  • cDDraw.cpp
    15.3KB
  • cDDraw.h
    2.8KB
  • NetworkClient
  • Debug
  • cCommClientThread.cpp
    19.9KB
  • cNetworkClient.cpp
    18.6KB
  • resource.h
    692B
  • cWindow.h
    2.5KB
  • networkClient.cpp
    478B
  • cOptionsDialog.cpp
    2.8KB
  • cPatch.cpp
    6.2KB
  • NetworkClient.dsp
    7KB
  • cOptionsDialog.h
    1.3KB
  • cNetworkClient.h
    2KB
  • NetworkClient.rc
    2.9KB
  • cCommClientThread.h
    3.1KB
  • ReadMe.txt
    6.5KB
  • Network.dsw
    778B
内容介绍
Name : Network Client v1.00 Network Server v1.00 Created by: Dan Royer circa 07/1999-08/1999 Contact : Email : aggravated@bigfoot.com ICQ : 4491034 Web : http://members.home.com/droyer http://www.flipcode.com -------------------------------------------------------------------------------- Notes -------------------------------------------------------------------------------- 0. What's in this ZIP (or rather, what's not.) The code includes the cComm, cClient, cPlayer, cNetworkClient, cNetworkServer classes as mentioned in the articles on www.flipcode.com. It also includes working scalable bezier patch code. For those of you not in the know, bezier patches are what's used to create curved surfaces in Quake III, LithTech 2.0 and all the other big engines today. I'm currently using them to draw the background grid but I have plans to make some cool surface deformity animations when a missile explodes. A few classes are only accessible via the lib files. This is because the source is not related to network programming and is part of my 3D engine which I have no intention of releasing at this time. 1. Why this code ain't so hot I originally intended to have the apps multithreaded for reasons that quickly proved to be bad. Thus the odd names, the strange layout and the occaisional seemingly pointless and disassociated comment. Nothing out of the ordinary for a big project, quite out of place for something this small. Another good case is cVehicle. I intended to have different vehicle types and a powerup that let you switch between them bu it hasn't happened yet. I have unconfirmed reports that if you are not running at least DirectX 6 then the program will crash. I'm not too sure why, I have checks for invalid versions, etc... My goal was to clean all this up before release, if I didn't then I apologize. 2. Where there's room for improvement Every refrence of "Bad C++" May or may not be Bad C++, it's just a phrase I can search for when I'm looking to kill bugs and improve things. So if you see it, don't panic, just know that what follows is something that could definitely be improved upon. I only have one computer so checking to see if this thing runs well on a large scale was not possible. I can say right now that I don't think it will, mainly because it's TCP/IP and would require an EXCELLENT lag-free connection. I'm sure it wouldn't take much work to make an in-game server (instead of a dedicated server). It would require a bit of rewriting to get UDP working, I plan to have that working in the next version. You'll notice as the game runs that the "snap" messages come further and further apart. This is apparently a problem with Winsock TCP/IP and not much can be done about it. I hear that if you wait long enough all TCP/IP communication will simply lock up and you'll have to reboot. Speaking of TCP/IP, the reason everything is "jumpy" is because of the lag involved. Switching to UDP will cure that right up. The server tells EVERY client about EVERY OTHER CLIENT MOVE. It should only tell the client about ships that are within a certain distance of the screen borders (unless you add a radar, then you'll have to tell the clients about everyone up to the radar range). The clients are told about every missile because it only has to happen once, at spawn time. The snapshot should be a single block of data that contains everything. Spawns, deaths, who's moving or shooting, who logged in or out, etc... The fewer the message blocks, the less worry of lag between blocks and the less problems you'll have in UDP mode. Remember, UDP does NOT guarantee that data will arrive in the same order it was sent. Theoretically you should be able to reduce the blocks to: server: 1 block for login approval & game world state (since all update just modify the current state) 1 block per game tick (state update) client: 1 block for login request 1 block for movement update/keep alive The more I think about it the more I realize it would have been much smarter to set the first int of every message equal to the total size of the message. That way several messages could be sent with a single queue and it would save everyone a lot of trouble. The rest of the server dialog box could be implemented. All you need is to set up a clock tick that would update the current page based on whatever the server data access methods return. A new system for logging server messages is desperately needed. MessageBoxes are BAD for the server. 3. What I'm gonna do about it I fully intend to keep working on this little space shooter thing, though I don't know how long I'll keep new versions as open source. 4. I really enjoyed this project (or) "Ha ha h-that's not funny." As with all programs there's that one little bug that stumps you for a couple of days and absolutely drives you up the wall. In my case it was a transformation error that screwed up visual effects and took nine days to track down because it was one of the least likely possibilities. There was even a time when I became convinced it was a rendering problem, then proved the matrixes were right so I was sure it was a networking error. Grrr. Other than that, this project was slick & easy going the whole way. I got a little lazy when I started putting method bodies in header files, I'll be sure to clean that up later. 5. Find a bug? Got a question? Wanna chew me out an' diss my homeys? Write me! Please put FLIPCODE NETWORK GAME in the title. -------------------------------------------------------------------------------- Legal -------------------------------------------------------------------------------- Rights: Dan Royer wrote all the material contained in this ZIP and reserves all rights, titles, etc. associated with said ZIP. Liability : Dan Royer is not liable for any damage resulting from use of Network Client or Network Server. Dan Royer might be liable for permanant brain damage resulting from trying to understand some of the nonsense he's written but any court in the land would accept the argument that you were probably insane to begin with. Distribution: All files in this ZIP may be redistributed in any media provided it is done free of charge and without alterating the ZIP. Yeah right, like anybody would pay for this.
评论
    相关推荐
    • Scala02
      Scala02
    • Scala Cookbook
      Scala Cookbook 英文版 带书签
    • Scala 框架
      Scala框架,光宇play的框架,这个只是一个模板,需要的自己下载
    • Scala
      Scala
    • scala 源码
      scala 基础源码大全
    • scala安装包
      scala安装包,直接下载安装,用于scala学习
    • Scala Cookbook
      Scala Cookbook Scala Cookbook Scala Cookbook Scala Cookbook
    • Scala
      Scala
    • scala2.10.6
      scala2.10.6,官网下载贼慢 scala2.10.6,官网下载贼慢 scala2.10.6,官网下载贼慢 scala2.10.6,官网下载贼慢 scala2.10.6,官网下载贼慢
    • scala安装包
      从官网下载的完整版scala安装包,双击直接安装scala,用于scala的开发