Jump to content
  • Advertisement

skow

Member
  • Content Count

    1040
  • Joined

  • Last visited

Community Reputation

248 Neutral

About skow

  • Rank
    Contributor
  1. Quote:Original post by hplus0603 The devil is in the details, though :-) Ohhh, i know, but you gotta start somewhere ;). Quote:Original post by hplus0603 That's not true. A fixed frame rate is one of the most important considerations for a stable physical simulation Good to know I'm not alone. The last project i worked on (where i was not doing any of the network coding) had a surprising amount of inconsistencies build up over time with our simulation running at variable frame rates. I guess what I'm doing is interpolating based on a future frame that is calculated, but not necessary extrapolated, so i shouldn't have the visual glitches nor display delay that the article mentions. The only real cost is that commands are registered after the next forecasted frame leading to a slight "delay" in command recognition. Thanks for the feedback!
  2. This is my first shot of doing the networking side of a game and would love some feedback of my plan for a rts/rpg style game. 1) Both the server and all clients will run the game simulation in their own thread locked at 20 FPS. 2) Parts of the simulation such as attacks, damage, will only be triggered by the host simulation and sent to the client. 3) The simulation will forecast several frames, and re-forecast as needed when commands are issued. The graphics loop will then interpolate unit positions based on its start time between 2 simulation frames. 4) The execution of commands on the host are delayed the ping time of the client, this delay will be included for other clients with faster pings. (But reduced by that clients ping). A few things still up in the air before I start. I'm deciding on if I want all simulations to calculate pathing, or when a command is issued have the host issue the "path" for a unit to take. If i were to do that i could time dependent movement to synchronized positions and have less concerns about the simulations getting out of sync. Any major flaws, something I'm missing?
  3. Quote:Original post by hplus0603 1000 TCP sockets is not a problem on modern hardware. Ohh, well I must be reading outdated information. That solves all my problems then, thanks!
  4. Quote:Original post by Antheus Then use UDP - the connection-less protocol. Thousands of connections are not necessarily the problem, if there's not much traffic going over them. Idle connections will just need a keep-alive signal once in a while. Thousands of users in same chat room isn't practical anyway. On IRC, having 100 in same room leads to disasters if unmoderated. But lobby server isn't necessarily same as chat server. Most such servers are partitioned to limit number of users, since thousands simply cannot talk at the same time in the same channel. Yeah, I was hoping to stick with purely TCP/IP. It wont be 1000's in a channel, but a a collection of channels with 1000's across the board. Thanks for the feedback.
  5. Hmm, Well for the game I'm maintaining the connections, but for the lobby client to create/join games ill have far too many connections. Is there really an alternative to breaking connections if ill have potentially 1000's of connections to the lobby?
  6. I see, I was hoping to keep the server listening for connections, and having the client purely connecting to send and receive (and closing connection after). Thanks for the feedback.
  7. Sorry if this is a trivial networking question; I am making the jump from pure graphics programmer to starting on networking. I'm looking to create a main server that handles messages such as basic chat. While its is quite obvious how to send/acknowledge chat sent to the server, I'm not sure how to update clients with chat sent by other clients. The only thing that comes to mind is to pull the sever every given interval with new chat that has occurred since the last poll. Is there a better way to do this using TCPIP? Thanks!
  8. I’m sorry, but this subject matter doesn’t even make sense. Starcraft 2 has been announced for how many days? How can we even pretend to comment on game play, strategy, and innovation? Why don’t we wait for a game to be released before destructing it down to its flaws? As others have said, graphics have ever been blizzards bag, so you really don’t know what to expect based on a few screenshots.
  9. skow

    Multi Thread and OpenGL

    Quote:Original post by Farfadet I'm reading that an openGL app can be CPU or GPU limited ; would multi-threaded rendering not be faster in the first case ? Yann is referring to just the rendering portion of your code. Your rendering portion of code should never be CPU limited; this means putting it across more threads/processors will not yield any benefit. Things like file texture loading and physics will put CPU and hard drive bottlenecks on your program, thus it may be a good idea to put those in separate threads. All additional rendering threads will result in is large headaches trying to sync your drawing while getting no performance gain.
  10. skow

    PhysX programmers?

    I too will give physX a good review. I have been very pleased; I also like their "free use for non commercial" license.
  11. skow

    transparency and textures

    Well, you have a few options: You can add logic on your texture load that will set the alpha channel to be low for blues. Photoshop your image, delete out the blue, and save it as 32bit image (with alpha channel). Once you have a image with an alpha channel you can use the following blendFunc: glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA) You will find it’s best to be good with a decent image editing software to change textures before the load to fit your needs rather than finding workarounds in your code.
  12. Yeah, im sure it's the same with or without the smoothing. Here is how bad it looks:
  13. skow

    Refraction shader for dummies

    Well I have no links but I can give you a brief explanation of planar Refraction. If you are looking for information using cube map refraction, disregard this. First you will want to render what is being refracted to a texture. In the case of water refraction, this would be everything below the water. Or if this is a window, draw everything behind the window. You will want to make sure not to draw anything in front of the refracting plane. To render to the texture you can use a FBO or simply glCopyTexSubImage. Now that you have your texture, you will be using projective texturing and distort the 3d texture coordinates to create the refraction. These 3d texture coordinates should be the same as the vertex coordinates. So now do your standard scene draw, and note that now you don’t need to draw anything behind this refraction plane as it will be projectively drawn. Normal maps are a great way to distort the cords for nice refractions. For water you can scroll multiple normal maps for a really simple but good looking flowing water look. I’ll include some shaders I use, just with the disclaimer that they use just one of many ways this can be done. Here is a sample vertex shader outdata main(appdata IN, uniform float4x4 ModelViewProj, uniform float4x4 TextureMatrix, uniform float4 shift) { outdata OUT; OUT.color = IN.color; OUT.textCordRefract = mul(TextureMatrix, IN.position + shift); OUT.position = mul(ModelViewProj, IN.position + shift); OUT.textCorNormal = IN.textCoords; return OUT; } Note the above shift above is how I translate my plane. Here is a sample fragment shader outdata main(appdata IN, uniform sampler2D refractTex, uniform sampler2D normalTex, float amplitude) { outdata OUT; float4 normals = (tex2D(normalTex, IN.texNorm.xy)*2.0-1.0 )* amplitude; OUT.color0 = IN.color0 * (tex2Dproj(refractTex, IN.texRelect +(normals))); return OUT; } Hopefully this is enough to get you started.
  14. I could be wrong, but I am fairly sure alpha testing is not needed. Just to be safe I tried adding it, no luck :(
  15. I must admit that I haven’t used GL_LINES in years, but now that I need to use them, I cannot manage to get the lines to anti-alias. I’ve google’d around to make sure I’m not forgetting anything. I do recall reading some glHints aren’t even used any more. Is there a chance that my 6800GT with updated drivers is not allowing lines to blend? I’m testing with the following: glHint(GL_LINE_SMOOTH_HINT,GL_NICEST); glEnable(GL_LINE_SMOOTH); glLineWidth(2.0f); glEnable(GL_BLEND); glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA); glBegin(GL_LINES); … glEnd();
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!