Xycaleth

Down the road, I plan to greatly simplify the .mtr shader syntax anyway So you'll need to write two separate shaders.

If you have a .mtr file present, it will ignore the .shader file. Or do you mean, it doesn't work at all without a .mtr file?

But that would require knowing when the collision was going to happen. And then you'd have to predict and... yeah, back to square one.

Sorry for the lack of updates everyone. I'm finding it hard to motivate myself at the moment but I'll get back to it soon hopefully - don't worry!

Actually, through experimentation I found that my rend2 wanted a .shader equivalent of the name of the .mtr that kept my rend2 shaders. But what I put in the .shader didn't matter, it seemed, it just needed to exist. So all that exists in my bootland_nmaps.shader is "//placeholder file for rend2". The same file with .mtr contains all my normal maps, and they work in game, but without the placeholder file all my textures lack normal/-parallax maps and load up like a regular texture.

Huh, didn't know that! The code confirms what you've found as well. I think the .shader should be optional to be honest, so I might look at changing that.

rend2 treats .mtr and .shader files in the same way - you can use all the new keywords in either. The only difference is, like DT said, that priority is given to the .mtr files. The benefit of using the .mtr file is so you can use the .shader file for the vanilla renderer and not have any errors.

While the talk does present some interesting ways of hiding latency, the previously mentioned problems still stand. All the examples shown in the talk all have a fully predictable component to them. The grenade has a fixed animation length before the grenade is thrown. The armour lock is the same. The synchronized animation for assassinations works more by coincidence than by design as you can adjust the player's perception of what's happening. Compare that to two sabers colliding. What part of the collision, or the few milliseconds leading up to the collision, are predictable? There are none. If the client predicts it wrong, because the other player has suddenly turned violently or a weapon projectile caused you to deflect it, then you get horrible visual feedback.

ZeroPing for guns works because their projectiles have a very predictable path through the world. They travel in a straight line or arc and cannot deviate from that path. With sabers, the player can change the path of the saber at any time and in any direction during the swing which isn't something that can be predicted. The only way this would work is if you were playing single player or in a LAN game where your ping is zero anyway

Did you tell it to use the rend2 renderer? Enter /cl_renderer rd-rend2 into the console and then /vid_restart.

There isn't an SP version of rend2 for now. It's multiplayer only until I get everything working and fixed.

To the modelers out there, this news maybe of interest to you. Autodesk are discontinuing its Softimage modeling software after its next release in the month to come:

http://area.autodesk.com/softimagetransition

The force sun stuff is mainly for debugging purposes. There's a way to do the same thing using sky lights but I can't remember how.

Try turning off texture compression? Should be an option in the regular video menu.

I think DT mentioned it was broken a few pages back. Unfortunately I'm still not feeling great and so no more changes to report this week

That does look odd. What does your shader look like, and what does the normal map look like?

Which shadows are you referring to? Can you post a screenshot please?

This will happen if you are not forwarding the ports on your router. Take a look at this:

http://portforward.com/english/routers/port_forwarding/

You want to forward internal port 29070 to external port 29070 using UDP.

For Visual Studio 2010, you need to install the VS2010 service pack 1.

Dat parallax mapping

When the Jedi Academy source code was released April last year, a few people (including me) got together to clean it up and improve it. This project is known as OpenJK. We've taken some hints from ioquake3 (a similar project to OpenJK but for Quake 3) and in the process added a feature to swap out graphics engines while playing. The original graphics engine which comes with JKA is still there, but we're also working on rend2 (also from ioquake3), which is an alternative graphics engine that provides more modern-day rendering techniques but requires higher computer specs.

So in short, rend2 is another graphics engine for JKA which will make it look better.

Strange, rend2 shouldn't be using OpenGL features that the card doesn't support. The minimum version required is OpenGL 2.0 (the GLSL version is added at runtime depending on the GL version available). Might have been a driver bug

Yeah you want to make a separate thread the normal maps you're having problems with are used only by q3map2 and the shading is baked into the lightmap.

Okay, back from weekend away, got ill in the process, but I'm ready to continue work on this again Stay tuned over the next few days.

Won't be able to work on this for the rest of the week unfortunately as I'm busy with sorting out a weekend trip.

In the end I'll incorporate the parts of the screen which have picked by the artist to use dynamic glow with the parts picked by the renderer to have bloom applied and it'll look are shiny etc etc.