MaceMadunusus

There should be somewhere yes. The only part of MB2 we've had to remove from revision history is the physical SVN for all the assets (Code is separate) due to running out of disk space. So it should all be there. But there isn't much point in digging it up, doing that work, then testing to be sure its all proper when we want to hopefully release a new build this summer anyway. Easier to just do it on the current build to not take up limited time the beta testers have.

This is something that happens when people come on and off a project thats been going on so long. A lot of things are a mess in MB2's code related things. Even if something is simple for an outside project, it isn't quite the same for MB2 because of how much coding hands were traded off. I know you're just talking about some of the more basic things, but that still kinda applies. We start updating things to say a new version of VS, forget filters or whatever. Happens. MB2 isn't something any of us praise for having the most user friendly code base in the world. This stuff is something I'll be changing for the MB3 version. Rules and such so the code base will never get to a hard to manage state like MB2 is.

I'm not updating all of MB2s maps. That is just not gonna happen.

Most of us want to finish our launcher that we can pack a OpenJK build with, so that we know random pubs don't have some weird dev or beta build that could fuck with things by accident. It also will give MB2 people easier access to OpenJK. Plus the things Sxx mentioned. Trying to get things ready for release first, then we can do little tasks like this when doing the final testing. You guys do know how long it has been since an update to MB2 was released right? Well I'll remind you: December 2012. It isn't like we released a build without OpenJK compatibility since OpenJK started. Don't worry, its coming. Also remember, a lot of us are short on time (I went awol for almost two years till recently as an example).

Hopefully you can optimize the usage of the renderer within that one core. At the very least, when you get to that point, it might be fine just separating the renderer from everything else so that all the game code, physics, network, etc can all sit on one core while the renderer can sit on another. That might be enough for JKA. I don't think you are going to get to UDK's quality level without a ton of work. UDK is much more optimized than most engines out there. However, using meshes that draw in one go is certainly possible with the OpenGL version you are using which makes me happy . Cascaded shadow maps themselves are hugely inefficient in general. A few games do use RTW, not many at the moment because its still pretty new in the DX11 feature set and consoles didnt support them till the new ones came out. A lot of games still do texture aliases. It is a pretty decent way to optimize texture rendering if you aren't using OpenGL 4+ (3.3 is likely what you are using) or DX11. An example of which was already mentioned, UDK Should have likely said GLSL version there, but yeah you answered it. Thanks @@Xycaleth!

Glad to see you guys are still working pretty hard on this. And glad to see you now have proper Specular, Gloss, and Environment Cubes as well. I have known that you have had normals for a while, but seeing those editions are much more exciting to me. I haven't been paying too much attention and mostly skimmed over things so I ask: How much have you upgraded JKAs ability to use the power of newer computers? For example, baseJKA uses only roughly 15% of a GTX 660 FTW edition at maximum settings and as you know one CPU core. If yes to the previous, how much more room would we have for detail in meshes, brushes, and textures? What version of Gloss/Roughness do you guys use? For example, UDK uses black for fully reflective, while Marmoset uses white. I am assuming you are using the White for fully reflective based off of the shader values posted. What dynamic shadow model are you using? For example, I believe the most efficient, most recent, and highest quality variant for games is RTW (Rectilinear Texture Warping) Have you guys increased JKAs ability to properly load textures & lightmaps (Higher resolutions, better efficiency like using texture aliases)? What shader version/model have you guys been utilizing? So far, you guys have been doing a good job from a visual standpoint. Maybe there is hope for me getting some of my newer stuff into JKA at some point. Like these: also incase this helps: http://blog.selfshadow.com/publications/s2013-shading-course/karis/s2013_pbs_epic_slides.pdf

Thank you MoonDog for being awesome. Just saw this thread so I would have suggested the same thing earlier, but looks like I don't have to. This looks pretty good so far, especially for using the byss texture pack. A lot of people use them in wrong ways. Everyones got my minor critiques so far, I have a few more but I'm not gonna pick till I see some more

Using existing Q3 upgrades, they fix a lot of the vulnerabilities of the engine itself. Not to mention all of the upgrades the community has already made to the original SDK to stop those exploits. With the source, we can also patch new ones a lot quicker without fucking around trying to find out if we can fix it or not, or if we have to hook the engine to do it. Plus, the Q3 engines source has been released for a long time, and JKA's isnt that different from it as well so if they really wanted to take some time they could have made those exploits much sooner than now. Eh, its 4am and I feel like I am having a terrible time wording this, I hope you can see what I mean.

I love you, you just made me laugh my ass off.

Holy shit, I seriously didn't expect this to come out of the closing of lucasarts. This is fucking awesome.