[nm]

Correct. If the Depth Buffer Limit is set to 800 JKU, I'd like to see it pushed back to at least 3000 JKU. This should clear me for a 2400 jku ^3 single sector. If it can be pushed back to say 5000 JKU, hey, that's even better, just as long as it doesn't occur within my sector.

(Actually, after doing a quick calculation, it would need to be at least 3395....er rounded up to a nice 3500 JKU for a 2400^2 JKU sector to work without having to worry about this event occuring.)

Edit:

Setting the limit to 5000 JKU would allow a sector limit of 3535^3 JKU without this event occuring.

He was talking about the Depth Buffer problem. I've given the solution to your problem many times on the Main Editing Forum and even in the Showcase Forum.

And I've said many times it doesn't work on my pc. Which means it's not a consistent technique.

It looks like the far draw distance is actually more like 1024 jkus (for a point directly in front of you).
It's not a problem with jk, it seems to be a problem with directdraw and the depth buffering that jk uses in hardware mode. I tried it with software rendering, and there is no problem, and also I tried it with my opengl wrapper, and again, no problem. The opengl wrapper uses z-buffering probably just like the d3d that jk uses should...I tried logging the vertices that jk is passing through direct3d, and they all seem to have reasonable z values. It's just that the last little bit of the z-buffer is being cut off too early for some reason. Oh, and for some reason it seems to be storing the values into the z-buffer backwards, maybe this is just a directx thing, because normally 0 is the near clip plane and 1 is the far clip distance, but actually increasing the z-values jk passes to d3d by a small amount removes the problem with things being clipped too close (but messes up the up close precision).


And about removing the limits on sectors/things...jk didn't have a limit for things to being with, it just crashed if you had more than a certain amount. Now you can have more, and there's still no actual 'limit' in the code for it. The sector count did have a limit, and it still does, it's just much higher. Jk might crash from something *else* if you have too many sectors though.

You could fix this problem with the clipping by having something that scales the z-values before they are passed to d3d, apparently scaling them up is what is needed (for some reason...), but then you'd either need a wrapper around directdraw or another patch on the exe. The patch on the exe might be difficult, depending on how hard it is to find where jk does it's transforms at and whether the scaling can be fit in or not.

Perchance time to send this bad boy to the editing forum? just a thought...

Sige, how does your OpenGL wrapper perform? An OpenGL wrapper is something we wanted anyway, so if that fixes the problem...

Oh, by the way Sige, where did you come from? I mean, I haven't been paying much attention to the JK community in years, and recently it's like BAM, we have this great new talent. Programmers that not only have talent but aren't lazy!

My opengl wrapper is a little bit faster than rendering with d3d. That is with d3d and opengl running simultaneously though, because I only disabled the actual 3d drawing part of directx, it still does all the texture and surface stuff...So with some more work on making jk happy with not having the real directx stuff going on, it could be a little bit faster probably. We're talking 10% maybe, and right now it is something like less than 5% faster.
It looks exactly like you are playing jk normally, with the exception of a couple problems, the HUD and 3rd person. The HUD would be the hardest thing to fix, because jk expects to be able to just write directly to the screen in order to draw your ammo/health/crosshairs, which just isn't something you do under opengl. I think that if I were to come up with a good solution for this, then in the end the performance of the opengl vs the directx renderer would be about equal...The penalty that would come from rendering the HUD under opengl is something that is constant though, so in more complex scenes it would be less noticable than in some simple test case. The 3rd person problem probably is just a weird thing that has to do with how jk renders stuff, and can probably be worked around (but I'm not sure).

I used to do some jk editing a long time ago, and recently Hell Raiser contacted me to get ahold of some mouse wheel thing for jk that I made for him back then, and I got interested in doing some stuff related to the problems I saw HR talking about in the forums (the thing limit).

edit--
The problem with the hud is specifically related to 2D huds. Using a 3do hud should work fine. Also, it might be possible to fix the problem with the hud in such a way that is actually pretty fast, but it would require pulling information out of jk's memory, and of course you have to know whether you even need to draw the hud and which hud to draw.

Is there no way to wrap the Direct3D draw (or DirectDraw) functions to say, an OpenGL shader that can do something similar on the screen (or on some polygons)?

Well, specifically jk expects to be able to take the already rendered contents of the screen, get a pointer to them, and then actually change each pixel that corresponds to the HUD. I don't know why they do it that way, because other stuff, like the console text, are done differently.
The problem is that opengl is designed to not allow you to physically touch the buffer that you are drawing to (it really doesn't make sense to be able to anyway).
Shaders might be a solution to the console text (right now transparent parts of it are pink, and just need to be replaced), and possibly for a part of the HUD problem. The real problem is trying to get JK an actual copy of the buffer being rendered to though. It is possible under opengl, it just takes a very long time to read back all of the pixels, and then more time to draw them back onto the screen.

Some solutions to this:

I can use a system that tries to detect where jk draws to in a blank buffer (jk doesn't read back any part of the buffer, it just changes pixel values), and only update those portions in opengl.

I could read from memory the health and ammo values, and draw them myself. But then, I need to know which hud to draw too, in case a mod has changed it from jk's default. A way around this might be something similar to the method above, where the first time around I let jk draw the hud normally, but then I store it and just used the stored one + read from memory what text to draw.

Both of those methods can be sped up by actually putting the pixel data into a texture and then drawing...
But, then again, does it really matter that much if the HUD doesn't work? I am not sure if just replacing it with some text would be good enough. Some people might want the hud, and some others might have a mod that does it with 3dos, and I wouldn't want to draw over that.

any chance we can finally replace the crosshair? finially make it smaller?

Great work by the way

Well, that's what I'm talking about. The crosshairs and hud could just be replaced instead of trying to make it create an exact duplicate of jk's rendering.

You could support custom HUDs by reading HUD data from GOBs. JK loads resources like this I believe:

Resource directory
>GOBs
>Unarchived files

Mod directory
>GOBs
>Unarchived files

Episode directory
>GOB needed for the current level
>Unarchived files? All of them or whatever is needed?

I'm not sure the order of GOB loading, probably alphabetical or just whatever some dir function returns. The tricky part is with episodes, since you have to figure out which GOB is currently loaded. You can just detect the current level in memory and search the GOBs, but that doesn't help if there is more than one level with the same name throughout the GOBs. However that's very unlikely, and in such a case you can just draw a default.

would jk even use the hud from an episode? I guess so, but there are some things it won't override with from a level.

Also, does jk always output it's ammo/health to the same spot? or do you specify it somehow?
If it always outputs it to the same spot, in the same size, and there's no way to change that, then that makes it easier. I don't remember how jk does that.

Yes, some of the BoaM and ToaM levels have custom HUDs from episode. What won't JK override from episode? I thought it was everything, or almost.

No, it's not fixed in position. I never messed with HUDs, but I do know that some HUDs had graphical meters instead of or in addition to a numerical display.

Sige; screw the HUD. Throw some text in the corner and forget about it.

I think gbk has been reading my mind or something

Heh yep.

What about texture size limit? With acceleration we're limited to 256x256, software can go higher I hear. This sounds like another issue with the rendering engine and not a predefined limit. I suspect the OpenGL wrapper could fix this if it hasn't already? You should try throwing in some 512 or 1024 textures and see how it works.

Well, if the software engine can handle bigger then it will probably work. Back then 3d accelerators couldn't go above 256x256 textures. I'll try it in a bit.
I actually did get the hud working without doing it myself, just letting jk draw it. It runs at a playable framerate but otherwise kills performance.

On what level does your OGL wrapper work? Did you actually write a basic renderer that renders all the geometry and lights and textures? If so, couldn't you change how lights are rendered? Replace them with nice Z-buffered shadows say? Cause that would be...hot.

actually, I have an idea for getting the hud to work the way it normally should.
I can keep the current hud between frames in textures and update when something changes...

It works on any level. It basically just does for jk what d3d would normally do. The result looks the same, except for a couple things that need fixing.

You know, emon, you just gave me a very good idea. Can't do shadows for a few reasons...jk doesn't give me light positions, it does all of the transforms itself actually, and so what I draw is already flattened out to fit into the screen.

But...what if instead of writing a d3d/ddraw to opengl wrapper, I made something that reads jk's memory and does the rendering that way. That could open a lot of possibilities
I won't ramble too much about what this means until I know I can do it.

Wait, what? I'm a little confused, never worked with wrappers before or read much about them. Does your OGL wrapper actually have vertex/texture rendering code in it or are you just rendering pixel data or something coming from D3D?

it does have vertex/texturing stuff to do, but what I get to draw has already been run through some transformations, so I'm not getting 3d stuff from jk, I'm getting 2d stuff, but it is still in the form of vertices/triangles. This is how older games do it because they were designed for software renderers, which would require them to have already transformed the coordinates anyway, so it is easier for them to just submit to the 3d api pre-transformed coordinates.

Anyway, if my other idea works out I will just be able to forget about making the wrapper and make something much better.

Ah right. I forgot about older renderers that did all that trig stuff to turn 3D into 2D.

I'm no longer a proxy, yay! :p

Yea, Sige is the man.

Wow. If you could just read the raw data wherever necessary and do all the rendering yourself, we could have a practically new engine. You could use a modern open-source engine like Ogre3D and just feed it the data extracted from JK.

WOW.

My old level before adjoin-patch:


After:

Uhg I know the environment looks so much better but the .mats are just terrible in that thing.

Maybe I don't know as much as I thought I did about JK... but nothing changed as far as I can tell...

JediKirby

It's the spiral staircase in the moutainside or whatever, there's a lot of HOM in the first picture. The black stairs are HOMing as well as the fact that you can't see the gray pillar.

JK loads resources by a priority system.

Ah I had it backwards a bit. It won't continue loading once it finds the resource. I was thinking it would load over the top, which is, I think, how Quake works.

Oh! I see now!

Wow, it basically eliminates detail HOM.... wow.

JediKirby

Qu4ck sux0rz :p

Take. That. Back.

So I'm the only person for whom this patch has completely borked JK.. as in it won't run after the patch. WTF!

I put a spell on it, wooooououououooooo :p

You're SURE you're not using JK 1.01 or whatever? Maybe LEC started distributing fresh copies of JK with it already updated?

Dang Hell Raiser, you might be right. I bought my current copy of JK very recently. But why would a simple joystick fix conflict so badly with the patch? Am I just out of luck?