Xycaleth

From looking at the SP code, it doesn't look like it needs any new trap calls.

What computer are you running this on? What kind of specs does it have?

I'll just leave this here... http://xkcd.com/386/

Oh right. I must have still been doing that back then I wouldn't do it now though lol I imagine the Newton API between version 2 and 3 changed quite a lot so it probably wouldn't work, but you could give it a try. Anyhow, I stopped working on it partly because like I said, at the time I couldn't get the level of integration that I wanted. You can't just add a model and rotate it arbitrarily and have a correct bounding box because of limitations in the engine. It's doable now, but the networking issue is still there. The only objects that could be affected by physics were map objects. The cubes in all of my demo videos are part of the map itself, but turned into physics entities.

We don't have a PayPal account. You can thank us in advertising if you want

I never comment my code like that I'm not sure exactly how much of it is working, but the main files to look at are trunk/code/game/bg_physics.cpp and trunk/code/game/g_physics.cpp. The handling of the physics itself is done by the Newton Game Dynamics physics engine which can be found in trunk/code/newton. I haven't changed any code in that directory, it's just the (probably now, very out of date) Newton physics engine out of the box.

I never intended to port my code if you're interested in trying or just to have a look at the code, search for "japhys source code" on google and you should find it pretty easily. It's hosted on google code.

We had a monitor at university which had a vertical green line from top to bottom. You could make it disappear by tapping on the top of the monitor just above where the line was, but it would always reappear eventually

As far as I know, none of the Q3 engine derivatives have made any extensive changes that would support massive number (e.g. 50+) objects all moving at the same time in one area. And I personally don't know what would need doing to allow this either. I'm sure there are games that have done it, but I've not really looked into it.

Easier, yes. Easy, no there's a whole load of issues with overloading the net code when too many things are moving about which I came across, and it's a lot of work to get a really good level of integration between the physics engine and the game itself :/

Huh?

No. Or at least, in a very limited fashion I think. Server can tell players to go into ragdoll, but that's it?

Trigger textures don't work on patches as far as I know. They need to be solid volumes (i.e. A brush).

I'd say the screen. Graphics card artifacts don't tend to be so regular in my experience. Regular as in, following some strict rule, or opposite of irregular looking. Not regular as in common

To quote myself from earlier: There's pretty much no reason to use any other anti-aliasing technique except for MSAA unless you can't use MSAA (if you have a deferred renderer instead of a forward renderer). MSAA is Multisampling Anti Aliasing. Reading the SMAA page, it says: So why clone the results, when you can simply produce the correct results in the first place?

I'm pretty sure it was just a one or two line change when I added it for my jk2 mod o.O.

You make it sound as if Valve haven't been working on improving the Source engine since 2007

Sounds like overheating to me, like @@CaptainCrazy said.

Epic puts massive amounts of research into graphics technology and are one of the games companies driving real time graphics today. A smart phone is still a phone, even though it's basically a mini personal computer and does more than just phoning people.

For falling items, look in g_exphysics.c. For ragdoll, you want to look in the cgame folder - I think it was in cg_players.c.

Keep in mind that just because you can have 5 meshes each with 800 verts, doesn't mean you should! A hilt model is tiny and will hardly take up any space on the screen so you won't even see all the additional detail if you add it.

They would override the base files, which not everyone would want. It'll also prevent you from connecting to base servers which have the pure setting enabled. Graphics drivers are tricky things. It can work in some cases, but if you use it in ways which wasn't tested very well then you can get bizarre looking problems like in your screenshot. It's very rarely a problem with the chip/card itself. You would get even worse artifacts than what you see if it was the chip (something like this http://forums.techguy.org/attachments/153841d1248621800/corrupt-display.jpg)

The OpenJK folder contains the 'mod' part of OpenJK, rather than the engine (which is a replacement for jamp.exe and jasp.exe). It's mainly a fixed up version of base and very little else. That looks pretty bad lol. I'd still lean towards it being a driver issue. Like I said, the Windows and Linux Intel drivers aren't comparable in being up to date, or quality.

1) It depends what you mean by widescreen support. You can force OpenJK to use a widescreen resolution by setting r_mode to -1, and then setting your screen resolution using r_customwidth and r_customheight. If you mean native widescreen support, where the UI elements are not stretched, then that's not supported. 2) Nobody's reported a bug like this before, so no, no known fix Does it happen when you run OpenJK in Windows? (I assume you had this problem in Fedora) 3) There are known problems with using retail Jedi Academy save files with OpenJK. It's on the todo list, but nobody at the moment is interested enough in tackling it. 4) Can you post a screenshot? This is likely to be an Intel graphics driver bug. Their Windows drivers are miles ahead of their Linux drivers so you should never expect something in Linux to work as well as it does in Windows. Hopefully we can get a better idea if it is a driver bug by the kinds of graphical glitches that can be seen in a screenshot. You might also want to try turning off texture compression as @@Raz0r had a problem with this when running OpenJK under Linux - set r_ext_compressed_textures to 0. EDIT: One point I've just noticed about @@Apprentice's post: there is no such cvar called r_customaspect. I'm not sure where you got that from.

Great success: I've finished writing the code for the performance improvements! The bad side of it is that I now get 5 frames per second on FFA3 So I got to find where the bottleneck is now.