What you are doing is basically networking a real time strategy architecture with a fps style game. If there are only so many players and you control one of them, you can get away with just sending updates of the players position as what is suggested.
So you can either validate, and then continue sending movement updates every 15ms. Or you can validate movement while you receive them instead of up front. If you get a movement command, check the current tile the player is now on, if it is invalid then send a stop command and move them back or something.
What are you making? Why does the server need to do anything related to paths?
Uh well the server needs to tell the other people where this player wants to walk. Send the start and end points to all the players. You could still have some lag though that someone doesnt get the walk command right away and then you will still have some lag issues.
Working on creating tutorials strictly focused on making games and not any specific topic. It is from scratch to end making games using C++/openGL/Visual Studio/Blender as a DVD. Covering all bases here. Why? Not enough information in one spot. I hated trying to find the answers and I'm trying to bring them to one spot. Also, how many game books say "game development" that really just focus on opengl or windows programming?www.ultimategamedevelopment.com
Also working on an online FPS, doing everything from scratch:
Posted by dpadam450
on 23 September 2011 - 01:06 AM
What you're describing is using stencil testing, right?
No. I think deferred is a bit over your head. In no offense, the reason your not getting a lot of stuff is that your skipping from beginner to advanced with no intermediate.
As I said and the whole optimization of what everyone here including you are talking about is: For each light, I dont want to run a pixel shader on pixels that are not affected by the light. How do you do that? Simplest way, know how big of a 3d area in the world your light effects. So draw a sphere in your world, any surfaces that collide with that sphere (use GL_DEPTH_TEST as GL_GREATER), the sphere ("light") will actually be hitting a surface. Since the sphere is drawn right over the screen those are the exact pixels you need to light. So while you draw your sphere, you arent drawing the sphere, you still run your pixel shader and pass the light position etc, but the pixel shader only draws the triangles being sent (The ones from the lights sphere that collide and hit surfaces).
look up some more tutorials, i swear every one i read talked about that. Your scissor test is going to do NOTHING faster than the first method I posted UNLESS you actually figure out and do method 2 and compute lighting in grid regions for each light in 1 pass for multiple lights. Just do the method we told you and ur fine. All you have to do is draw a 3d sphere at the lights position and scale it big enough. If its a small desk lamp draw the sphere like 3 units, a streetlight 50 units etc.
Posted by dpadam450
on 22 September 2011 - 03:58 PM
Drawing spheres as we suggested IS scissor testing. Just draw a sphere, where your light is, and the only pixels that will be be lit are the ones that the sphere projects to on screen.
However, as expected, performance is terrible when the number of lights increases, as every light is currently being rendered as a full-screen quad.
I think you missed the deferred rendering memo. You draw a sphere for each light. When you really need to optimize, you draw portions of your screen with multiple lights at once using scissor tests:
Assuming 8 lights in your scene:
1.Draw sphere, sphere projected on screen will basically give you the "scissor pixels" the only ones the light will effect. 2. Light those pixels and ADD blend them to the scene. 3. Step 1 for next light.
8 Blend operations.
Optimized 1. Figure out (like that mechanics article, or basic ray tracing) what lights are in what part of your screen image. 2. Assuming your screen is cut in 4, say 2 lights are in each quadrant. You draw 4 quads, upperleft, upperight, etc. And send to your pixel shader 2 light locations for each quad you draw (the lights that actually are projected on screen and only light/influence those pixels in 1 specific quadrant). 3. Light those pixels and ADD blend them to scene. 4. Step 1 for next quadrant.
4 Blend operations. Because you calculated lighting for 2 lights at once.
For now just settle with the first version 8 blends.
Posted by dpadam450
on 19 September 2011 - 10:23 AM
Nobody ever used ray picking and nobody knows anything about it.
Nobody here gets paid to help you. Considering this is doing per triangle collision with objects in the world, its pretty obvious it you call glTranslatef() the graphics card draws it to translated, but you still just have the original data.
There are other ways to do raycast collision as well.
Posted by dpadam450
on 11 September 2011 - 09:19 PM
Look up occlusion query. You can query back how many pixels have been drawn from start() to stop(). You would draw your big occluders like buildings all normal shaded and such, then you would draw your basic bounding volumes for your small objects like cars etc (without allowing writing to the screen glColorMask). For each object you make an occlusion query start, and after you are done drawing them all, you request the queries back all at once.
I don't see much use for occlusion queries other than cities, so you could optimize it by spatially dividing your city blocks and having all cars etc being inside those city blocks. This way you would only have a few queries to actually check and then you mark everything inside the block as visible or not.
Posted by dpadam450
on 08 September 2011 - 09:39 AM
Well if you view most of the people in that forum, it is usually their first post after being on the site. So yea its basically 13 year olds who say "I'm going to be the President and CEO of [insert stupid game team name], but I dont know how to do anything, I will just oversee the project."
Really the best thing you can do anyway is just go solo. Online teams are the absolute worst idea ever and never accomplish anything.
The only real thing you need, to get started are what you already have: position, normal, diffuse (texture) color.
1st, your diffuse has all perfectly lit green grass. So if you have a sunlight, you should calculate that first and put that in your diffuse buffer as well. For all other lights (lamposts, vehicles etc): they are contributing (addding) EXTRA light to the scene. So first again, you put your original diffuse on the screen (with or without sunlight), then you use addative blending of each extra light. Again keyword add/extra (addative). For each light you draw a physical model of the actual lights area. For a lampost it might be a 3d cone, a lightbulb would be a sphere. Hopefully you already knew that cuz if not, then your stepping too far.
After that you should have basic lighting. Again with materials like metal you have a certain specular power, as well as certain spots of metal that have different amounts of specular. Imagine a piece of metal with rust, the rust portions have no specular, and the clear ones do because they reflect light back. But even more when the light hits that surface, it has a specular power, either it is really focused and hard metal, or not as focused and soft. So you could (and eventually will), want to have those properties stored either in the color,normal,position, anywhere.
Any property/material that effects light from an object standpoint, is saved. The light properties are just used when you draw those 3d models.
The first thing you have to do right before you draw lights, is put the full screen diffuse to the screen. Then for each light such as a point light, you will have to draw a physical sphere , but your shader isnt drawing the sphere, its just using it to do lighting on the diffuse you already drew to the screen. It just continually blend with what is on screen and your screen will fill up as more objects are drawn.
AHAHA someone at work figured this out, no idea how. Again waiting to ship a title so we don't have anything to do but fix bugs when found. Well there you go everybody start applying to Sanzaru games so we can make well artist salary + .25*artist salary = programmer salary. So I guess 80/hr sounds about right.