Xycaleth

I would like to remind people again - I am a retired MB2 dev, not a programmer, and that you'd likely have more help with this kinda deal on the MBII forums if this turns out to be a MBII specific issue.

Just to add to this further, I don't believe any of the active MB2 devs regularly visit these forums. So anyone here (I guess with the exception of Tx606) is basically waving our arms grasping for anything that might be wrong.

2. When jampgame.x86.dll (and/or cgame.x86.dll) are not present in the GameData folder, the installer will ignore the missing DLLs and still try to launch the game, resulting in crashes. Instead the installer/launcher should check if these files are available if needed and notify the user of their absence before launching the game.

Neither of those DLLs should be in the GameData folder, unless you're referring to GameData/MBII.

 

I have no MBII folder in "Documents/My Games/openjk/". I've been using the MBII client (OpenJK) from the start. If what you're saying is true, then MBII is not compatible with other versions/releases of regular OpenJK.

What folders do you see in the My Games/OpenJK/ folder? If you're running MBII then I would expect to see an MBII folder in there. This has nothing to do with the mod, this folder is created by OpenJK and the mod has no control over whether or not it gets created.

 

On the flip side, what folders do you see in your GameData/ folder? I'd also expect to see an MBII folder in here, containing all of the mod files.

Figured it out. A misplaced DLL was responsible for the crash.

Which DLL?

Yep, should be available from next build (Monday evening). Your save games should work too

I've not actually managed to test what happens if rend2 doesn't load properly so this might be it. What graphics card do you have and are the drivers for it up to date? Rend2 requires a minimum of opengl 3.2 support

This should be fixed now

That's a pretty trivial change to make if I ever get around to adding MD3 support But thanks for pointing that out!

Could you post a screenshot of the problem?

I'm pretty sure the OpenJK packaged with MB2 is just the same as regular OpenJK, with a few changes for their master server.

The big killer in the lighting stage is -bounce. This attempts to simulate how lights reflects off of surfaces and illuminates nearby objects and I think will take the majority of the compile time.

Did you paste the right files? They're both the same!

HI Pierry. Sorry to hear you're having problems with OpenJK. Just to be clear, you're getting poor performance when using an AMD graphics chip and Intel runs okay but dynamic glow is wrong. Does that sound right? We can try a few things.

 

When you've loaded up OpenJK with your AMD chip, can you run "/condump logfile.txt" in the console? It will write a file called logfile.txt in My Games/OpenJK/MBII/. Do the same when loading using your Intel chip (change logfile.txt to logfile2.txt) and then paste both files here That should give me a bit more information about what could be causing your problems.

Aw, I forgot about this again Too many projects going on!

 

But I'm glad you could make good use of it, @@Cerez

I think I can have a look at some point this week Can you upload a save file starting at a point before the crash would happen? It just saves me having to play through everything and means I can be sure I'm setup the same way as you to make a crash happen!

So this really highlights the importance of using texture compression. In the screenshot in my previous post, texture compression wasn't enabled. Here's a new screenshot with texture compression enabled.

 

 

You can see that we get roughly 70% savings in texture memory usage And don't forget that all the models have to be stored as well and they use quite a bit of memory too!

So this was slightly unexpected:

 

But how would Cgame get this information from a water Shader to properly define the parameter hcolor?

cgame doesn't have access to this information. As soon as you bring cgame into the mix then rend2 has to start relying on a specific behaviour set by cgame and it's not going to be something I'm going to consider at all.

Rend2 doesn't know which square is for water, or if there even is a square for the water (like I mentioned in a previous post, a mod's cgame might do something different). You can guess which blue square it might be, but you might get it wrong, and end up ruining some mod's effect, and won't even work if cgame isn't rendering a blue square but a blue watery texture instead.

 

Modifying cgame itself doesn't break compatibility. Compatibility is broken with existing mods because rend2 now relies on that cgame change. If you load up JA+ in rend2, you will get the blue square (which you can't get rid of) as well as rend2's water effects.

 

EDIT: I think the best we could do is to add the fog effect in rend2 (without any colour), and let cgame tint everything blue. Still won't be great, but it would be better.

Right. From what I can tell, there's no way of doing it reliably. OpenJK mods still need to maintain backwards compatibility with jamp.exe, and existing mods needs to be compatible with the OpenJK engine, so changing cgame is a no go.

Not quite. The renderer has no context as to what the blue square is for. It could be for something other than water. Other mods may even try to draw something else instead of the blue square to make the water look better.

Ignoring cgame's rectangle, yes, rend2 would have to handle this if it were to be done correctly.

 

EDIT: But this won't work with existing mods that have their own cgame. That's who we are catering for here. Existing mods.

The cgame tells the renderer "draw this blue square on top of the screen". That's it. No water information, no brush information. Just a square.

 

https://github.com/JACoders/OpenJK/blob/master/codemp/cgame/cg_draw.c#L7776-L7805

 

This is the specific code. You can see that cgame is able to determine what kind of brush the camera is sitting in, and from that it tells the renderer to draw a square. cgame doesn't have access to any brush information, or shader information, or texture information.

Taking out the tint from cgame will mean any mods run with the vanilla renderer don't see any blue tint :/ And the vast majority of mods don't use OpenJK as a base, and are no longer being maintained/updated.

But cgame is specific to each mod. If you play on a server with basejka, you're using a different cgame from the one that's used with JA++, that's different from the one that's used in MB2, etc.

Hi Veosar! As you might know rend2 is still heavily work in progress so there's going to be a lot of issues with it still and it really helps me when people do report the issues they find, so thank you for doing that

 

Luckily, the first two problems are related and I have already fixed these issues. I just need to get around to uploading a newer DLL. Watch the rend2 topic in this forum for my sporadic new releases

 

I still need to work on a full set of commands specifically for OpenJK's version of rend2, but you can find a list of commands from the original ioQuake3 rend2 here: https://github.com/ioquake/ioq3/blob/master/opengl2-readme.md Most of the commands should be the same.