Josh

I posted one version in the BlitzMax code archive.

The only way to get smooth video is to save the buffer each frame to an image file, and use a fixed time step.

The log file will have information on what happened. Probably a shader failed to compile. The Radeon 1600 does not even comply with the shader model 3 specification, and will crash if you try rendering terrain or animated characters. It may work aside from those features if you update your drivers, but it's not officially supported hardware. We may in the future add another renderer for low-spec cards. Leadwerks is getting a lot of good game-making features, so the strength of the engine is no longer just graphics. It might make sense in the future to have a low-spec fallback.

buffer=nil

That problem is pretty much identical to regular old bumpmapping. You will need the binormal/tangent, somehow.

You can make an ambient occlusion map and use it with dynamic lighting. Several people have used this technique.

I am not sure exactly what you are doing, but let's say you have a heightmap. It's easy to make a normal map out of that, and read that texture for the normal, instead of calculating it in the shader from the height. Now you have a normal, let's say it is 0,0,1. Okay, let's just swap the y and z axes, and now you have your world normal, 0,1,0. You can add in another high-frequency normal map lookup to get some more detail if you want. Then take your directional light direction in world space. You can calculate this and upload the vec3 to the shader each frame. The world space vector of the light direction would equal TFormVector(Vec3(0,0,1),light,Null). Now take the dot product of the light direction in world space and the water surface normal in world space, and that tells you how "lit" the pixel is. This can be used with a specular equation to calculate specular reflection.

The edges look like Crysis water. I don't know why, but I could just never get ocean water quite right. If you can find a good-looking surface pattern to add all over the surface, it will make the deep-water areas look a lot better. Are you trying to write the normals out to the screen? Why not just use the normal map and calculate the dot product of the normal and the directional light vector, and write out the brightness? I assume you are rendering this after the main lighting pass.

I am cleaning the code up now. I haven't posted a client-controlled version yet.

I'd be very interested to see a compiled example.

Interesting...and you can even use C++ with this, since Lua can call DLLs.

Yeah, of course that will be instant. I am pretty well satisfied with the design now. Either the client or the server can create an entity and upload it to the network. If you have a fast-paced FPS or racing game, just let each client control their own player entity. If you have a physics-intensive game and are comfortable playing only on low-ping servers, let the server control everything. You might be able to create a controller on both the server and client ends, and do your own comparison, but I am not too worried about it. The point is that once you sync an entity, you can move it around, let physics move it, free it, and it will automatically be updated on all the clients, which is fantastic.

They're really different products. Leadwerks runs great on the laptop 9800M cards, but it won't ever run on your integrated chip. On the other hand, the graphics of Unity free are very limited, and performance is slower on good GPUs. So it's a question of what you value most and who you are making a game for.

What is your ping with the server you are on?

Can someone please create a server for testing?

Sure, but that's not even really a physics problem. The held object doesn't even have to be physically interactive. A much hard problem is if two players push a box in opposite directions. Fortunately, the way I am setting this up allows you to make everything from pure server physics to client-controlled players. What I am aiming for is a means to have both with some glitchy interaction between players and physical objects.

That is exactly how I am handling it right now. The problem is that the interaction between the client-owned controllers and the server-owned drums is not as simple as it might seem. Still, if I can solve that, even with some problems remaining, it will be the best of what we want within the confines of the hardware.

The problem is this leads to instant corrections when the client and server results diverge, which is very often if you have an interesting physics simulation running. This is why multiplayer games rarely have very advanced physics interactions. You can create the player controllers on the client machines and let the clients dictate their orientations. This result would be the same as what you described above. Alternatively, you can let the server control everything, if you are willing to accept lag on servers with bad latency.

My advice is to make the routines based on their hierarchy. If there are ten windows onscreen, each with one button, you should only have to evaluate one button when the mouse is clicked. For both drawing and mouse input commands, the routines should be designed like this: Method Update(x,y) if not self.hidden() if x>self.x and x<self.x+self.width and t>self.t and t<self.t+self.height for child=eachin self.kids... child.update(x,y) next endif endif endmethod

I tried updating the controllers on the client side. The major problem with that is the controllers no longer influence any physics objects. Client-side prediction did not have a good outcome. It resulted in "teleporting", which is something that really bugs me about networked games.

I need someone to create a server with the latest version. I am testing client-side prediction, and can only do it if I have a remote server with some latency.

Reliance on CSG used to be a huge complaint from artists. They wanted to model a building in their own 3D modeling program of choice.

When did you install the SDK? I think there was a problem like this earlier, but it was fixed last month. What program are you trying to run?

To make a game for the consoles, you need to be approved by MS or Sony. To get this, you must already be an established game house with one successful title under your belt. It's much easier to get a game approved for sale on Steam. As I have pointed out before, Penumbra is the best example to model your plan after. So even if our engine was offered on the consoles at this time, it is unlikely anyone here would be able to use it.

This is how I would do it. I will keep an eye on this.