OpenJK General Topic

[eezstreet]

https://github.com/eezstreet/OpenJK/tree/CPlusPlus

 

It's slightly outdated. I believe the reason they didn't want to do it was because they didn't want to make mods a pain or something. Something about merging, anyway.

[tinny]

So i spoke to Raz0r and Ensiform  yesterday.  I came from the angle of being able to port sp code more easily and they convinced me c++ is not a good idea because of template programming which is really the main feature of cpp being used in the sp code causing slow downs in build speed which hurts dev/modding time.

[mrwonko]

I talked with some of you guys about this before.. but did you guys want to vote on converting JA MP code to C++?

The amount of C++-ification that is possible is limited by having to keep the interface to mods the same. I'm not sure if it's something that should be done in OpenJK. Personally, I plan to start my own fork at some point, which will be mostly C++ and Lua and abandon mod compatibility in favor of modernization.

[eezstreet]

I'd like to break the gentity_t structure into a class with unions for client/server, and then have a few derived types ie Missile, LogicalEnt, et al. But yeah I can see why that might be seen as slow.

[afi]

Can you maybe add support for a new video-codec? Coz everyone knows that RoQ and QVM sucks. That would be awesomesauce..

I think Razor(?) already did that in the past not sure

[Raz0r]

theora + vorbis will be an option in the future, we've also improved the RoQ code to allow higher resolutions and fix some bugs.

[Kaiser]

Is it possible to lift up the limits of jk2 up to the ones from JKA? Mainly the issue "ERROR: MAX_SUBMODELS exceeded" causes JK2 to not properly run JKA maps  I think. Any fix in that direction would be awesome!

[Szico VII]

There'd be a load of limits that'd be good to raise; MAX_MAP_VERTS,  MAX_MAP_BRUSHES, MAX_EDGE_LINES.

 

Also, implementing  proper external lightmaps (instead of those baked into the BSP would be epic.. @@eezstreet is this a possibility?

[Raz0r]

You already can use external lightmaps?

[minilogoguy18]

Is it possible to lift up the limits of jk2 up to the ones from JKA? Mainly the issue "ERROR: MAX_SUBMODELS exceeded" causes JK2 to not properly run JKA maps  I think. Any fix in that direction would be awesome!

 

Read through some of the thread, a future goal is to make JK2 and JA run on 1 engine so they'll be equal in functionality.

[Szico VII]

You already can use external lightmaps?

 @@Raz0r - Not really. The only way I've gotten external lightmaps to work is with faking it via shaders, and even then it only works on patches and you have to use nodlight (so no saber glows, weapon bullet glows) - its very hacky.

[eezstreet]

http://www.ioquake.org/forums/viewtopic.php?f=2&t=100

 

Applies to JKA as well. Note that JKA's lightmap size (max) cannot exceed 128x128.

[DT.]

Totally need to increase that limit imo....

[Szico VII]

a) I dont understand that link. The -export function will output external lightmaps but JKA doesn't use them.

B) Why use external lightmaps if they remain the same size as JKA? I thought it was obvious that the use of external lightmaps was precisely so you could have higher resolutions.

c) I have used these methods to produce external 1024x1024 lightmaps but as mentioned before, there are serious limitations!

 

Also, none of the links on that page work!

 

http://sgq3-mapping.blogspot.co.uk/2009/01/using-hi-resolution-external-lightmap.html

[mrwonko]

a) I dont understand that link. The -export function will output external lightmaps but JKA doesn't use them.

It's a Q3Map2 feature, not a JKA one. It's for manually editing lightmaps and then using -import to put them back in, as far as I know.

B) Why use external lightmaps if they remain the same size as JKA? I thought it was obvious that the use of external lightmaps was precisely so you could have higher resolutions.

No, it's just for manual editing besides scaling, as far as I can tell. Although I agree that an arbitrary lightmap size limit is no good. On the other hand, lightmaps already make up a major part of the level size, I'm not sure they need to be increased any further - realtime lighting would be better suited for the cases where you want crisp shadows.

[Szico VII]

I've never managed to get import to work, alas.

[Raz0r]

Applies to JKA as well. Note that JKA's lightmap size (max) cannot exceed 128x128.

I forget how MaceMadunusus does it, but..

low resolution (256x256)

 

 

 

high resolution (1024x1024)

 

 

[eezstreet]

Yea, the limit might actually be 1024x1024.

What Raz0r posted doesn't appear to be external lightmaps though. I believe that's something else.

[Szico VII]

I already posted the link to how that is achieved - Ill post i again: http://sgq3-mapping....l-lightmap.html

 

I'll also say again that that method has severe drawbacks,in JKA at least. 1) Has to be used on a patch, doesn't work on brushes. 2) Needs to have surfaceparm nodlight, which makes it look odd. Why? no idea.

[eezstreet]

@@Szico VII: I'm talking about using -export/-import to embed lightmaps into the actual BSP itself, not overriding it with some silly texture method.

[Szico VII]

I think that shot is actually showcasing the 1024 texture workaround as I remember him making that map.

 

And I know eez, but import has never worked for me with high res exports.

[eezstreet]

Because the game is limited to 128x128 lightmaps.

[Szico VII]

How is it limited to 128x128 when the source is now open and moddable? I thought anything was possible ;D That was the request. Can high-res external lightmaps be implemented? Hell, even internal ones if that's easier.

 

Of course if there's a plan for a dynamic lighting system I guess its irrelevant...

[eezstreet]

The lightmaps lump (afaik) limits it to 128x128. If you're talking about external lightmap via shader (which I hate the idea of using anyway), I don't know if there actually IS a limit (but if there was, it'd likely be either 1024x1024 or 8192x8192). Increasing internal lightmap dimensions could potentially break base map support but I haven't looked into it enough to know for sure. It'll definitely disallow any sort of usage for that map on base though.

Also you need to use a special version of q3map2 to take advantage of said feature.

[Szico VII]

Well the external method works on patches (when using nodlight ) but not brushes - if that could be fixed its be a solution that allows high-res maps whilst retaining compatibility.