Xycaleth

The rim lighting, i.e. it gets lighter around the edges of the player model

I just noticed this happening in rend2. I don't know how it happened, but I think it's intentional 8D

Do you really mean spell checking? Visual studio doesn't do spell checking...

So here's something that needed doing a long time ago. Without the fix, you get some interesting results:

But now it looks normal again

It might not look like much, but this took a fair amount of thinking/work to produce the right results So now I can tick that off the list of things to do! Next stop, fixing normal maps

Unless your computer is too old

ctags don't apply to Visual Studio. They're the Linux equivalent of the symbols database file.

Thanks for the answers and responses so far everyone!

It would break compatibility for players not using OpenJK.

I can make an OSX build but I don't think it will support 10.6.

There's not really much maintenance required for the OSX build as it shares a lot of code with Linux.

Out of curiosity, I want to see how many people here are using OpenJK If you're feeling generous, please answer the following questions as well!

Questions for those who answered No:

1. If you don't use OpenJK, why not?
   I'm looking for something along the lines of, "couldn't find the download" or "couldn't get it to run", or "don't see any reason to use it". Obviously you can come up with your own answer though

Questions for those who answered Yes:

1. How did you find out about OpenJK?
2. How difficult was it to get OpenJK working?
3. Do you know anybody who isn't on JKHub and uses OpenJK?
4. What would you change (if anything)?

We say many light sources won't affect FPS.

I've always been able to get intellisense working at some point on Windows XP. You could try deleting the symbols database (while VS is closed) and get Visual Studio to regenerate it by reopening the solution file. In VS2010, it's the .sdf file (I believe). I can't remember what extension the database file had under VS2008.

The only impact more lights can possibly make is an increased lighting compile time

Just out of interest, and I'm sure other people are interested as well, what was the reasoning behind relaxing the rules?

It shouldn't even need a cvar. You can detect if jamp or OpenJK is running at run time.

You will need the MB2 team to make an rpi port as well though. Raz0r can only do the server program porting.

How can you tell it ignores smoothing groups? If it did, then you wouldn't get any hard edges on your GLM models.

It doesn't need to support normal mapping. The information needed for normal mapping can be calculated using the per-vertex normals and UV coordinates.

Carcass doesn't handle any of the tangent space calculations.

These are all done in the renderer, but are calculated using the normal and UV information, which obviously come from your exporter of choice. So to me, the best solution would be to 'fix' this in the exporter if possible. If it was done in the renderer, then loading times would increase (if only by a little).

I can't really help with the flags you should use, but you have a mistake. It's -lomem without a w, not -lowmem.

Try this: http://176.227.202.109/openjk-2014-05-06-15939504-linux-64.tar.gz

You'll need to install the 64-bit version of SDL2 as well.

Yeah that would cause problems.

You have a pretty old version of OpenJK. You should try a newer (read: the newest) version. I'm not at my pc atm but I can upload the latest 64-bit version for you when I get home from work.

What do you get if you do, ls -l /usr/lib/i386-linux-gnu/libSDL* ?

If you're running the 32bit version of OpenJK, you'll also need SDL2 installed. Try something like, sudo apt-get install libsdl2:i386 in the terminal.