[DustFalcon85]

StrikerMan780, on 25 August 2015 - 01:39 PM, said:

I PM'ed Frederik about the possibility of working together, but I never got a response.

Try getting a hold of him on twitter: https://twitter.com/Freschism

[Striker]

My Twitter is a private account, I can't reach him there unless he follows me.

[MusicallyInspired]

You can't even private tweet him?

[Striker]

MusicallyInspired, on 25 August 2015 - 03:31 PM, said:

You can't even private tweet him?

Nope. Twitter doesn't allow you to direct message people that don't follow you.

[Lunick]

StrikerMan780, on 25 August 2015 - 04:15 PM, said:

Nope. Twitter doesn't allow you to direct message people that don't follow you.

Nope.

[Striker]

Lunick, on 25 August 2015 - 04:54 PM, said:

Nope.

That only applies if the other person has that setting enabled. Note: Receive, not send.

[Smoke Fumus]

Striker, striker, my man. You're dropping the ball again. I already dropped you a gl matrix example, but just for the sake of convinience - here's a basic gl matrix construction (assuming you're using rows)

export function makePerspective(fieldOfViewInRadians:number, aspect:number, near:number, far:number): number[]
    {
        var f = Math.tan(Math.PI * 0.5 - 0.5 * fieldOfViewInRadians);
        var rangeInv = 1.0 / (near - far);

        return [
            f / aspect, 0, 0, 0,
            0, f, 0, 0,
            0, 0, (near + far) * rangeInv, -1,
            0, 0, near * far * rangeInv * 2, 0
        ];
    };

This is in javascript but i am sure it can be converted into C with ease

[Striker]

I'm not dropping shit. Just because I'm learning and working at my own pace, and not the pace you want me to doesn't mean I'm dropping the ball. You can kindly go fuck yourself with the unhelpful, condescending crap you've been slinging at me over the entirety of this project. I'm bloody well losing my patience with it. I don't speak to you on Skype anymore because it always ends up in some irritating and convoluted roundabout that gets us nowhere and helps nobody. Sometimes I think you enjoy aggravating me, especially when I don't do things your way. I'm stressed out enough as it is, and I don't need that. I need to be given room to breathe.

I tried code almost identical to that before, and it doesn't work well for how TV's engine handles things. Besides, I don't need to construct a matrix. The perspective matrix is *already made*, custom-made by Mark Randel himself. I thought I was clear about this a LONG time ago.

What I need, is the math to make sure that a polygon is within the frustum, and takes the correct shape and size of the frustum area / planes into account, all utilizing information from the matrix. This isn't easy, and the tutorials don't take into account having a custom projection matrix. It also doesn't help that I'm completely unfamiliar with the concept. I have no reference to go by. The only reason I've gotten so far is that I've always had some sort of direct, applied reference or concept to extrapolate from. I was able to get into C for example so quickly because I've already had a basic concept of it formed by over 10 years modding experience. I don't have that this time. This is completely alien/foreign territory.

Be that as it may, I'm already working on alternatives, have been for the last few weeks. Also, Mark has still been helping me out. It's nice having someone who helps you without having everything laced with an insulting/belittling undertone. It's also nice not being misunderstood all the time.

[Striker]

I want the new renderer to support all of the effects the software renderer did, such as shadows, but with how things work, I'm going to need to use FBOs to handle shadow rendering. However, that means anything that uses less than OpenGL 3.0 is out of the question, leaving half of the Intel GMA chips out of the question.

Is everyone ok with this?

[Striker]

Shadows are now working. Using FBOs:

[Striker]

They are. I went over this already, they're linear filtered in the distance, nearest filtered up close. Why? To prevent texture seaming artifacts.

Anyhow, here's another shot:

[Hendricks266]

Juris3D, on 04 September 2015 - 04:03 AM, said:

Well, I guess my question should have been "why blocky textures". It was historically first thing that 3D acceleration did (3dfx, even Virge) - smoothed textures. It was kinda first and main "wow! thing" (besides rendering speed, framerates). So it is strange to see blocky textures now.

Not directed at you, but I don't understand the "kill the pixels!" mindset. I'd rather see some squares than a smear on lowres textures.

[Smoke Fumus]

Ok here's the deal. You cannot just throw a bilinear or trilinear filtering onto low res textures. It worked back in the day because monitor resolutions were way smaller so at 640x480 blurry textures still looked like sharp edged ones but better.

But with passage of time it becomes apparent that low res textures better left with nearest neighbor filtering to preserve visual crisp and let the mind fill the gaps, rather than blur it out and get a blurry mess out of everything.

That or replace them with near-solid color analogues which can be resized and filtered freely (Planetary annihilation did that)

That or use advanced filtering, which half of the time looks like garbage on nearly colored textures (hq2x/4x, super eagle, etc)

[Striker]

I don't mind the filtering itself, mind you... in a game like Hellbender, which is entirely 3D, with only minor usage of sprites, the filtering isn't that bad. Linear filtering technically doesn't make textures lose detail, because no information is actually being lost. It just causes the pixels to gradient in between one another.

However, when you use linear filtering in a tile-based engine like this, the textures will create these really nasty seams, since the filtering is blending pixels on both edges of a texture (since that's just how it works, and looks great if you have the same texture repeating), and there's often times where you get textures that are used to transition between different terrain types. (Causing a very, very nasty seam of pixels bleeding from the texture's opposite edge. Imagine seeing an extremely ugly line of white pixels between the snow and grass in TV's Ymir, for example.)

I will give the option to use Linear Filtering of course, if you don't mind the seaming, that is. I'm already using clamping to get rid of pixel bleeding, however, when linear filtered, you'll see a minor seam where the polygons join together. I may be able to reduce that with shaders at some point, using it to blend adjacent polygon pixels together, or by using N64-style 3-point filtering.

[Striker]

Finally got lightning and weather effects working again in OpenGL:

[Striker]

Yeah, still a lot of complicated things to figure out. Such as optimization. Right now, it's capable of taking a 3.7ghz CPU and a GTX 560 to it's knees at times.

Anyhow, I got particle effects rendering now, using the same technique as Quake 2:

[Striker]

Now snow.



Also, Starfields and certain HUD lines.

[Striker]

I don't have anything to show for it yet, but I have fragment shaders loading into memory, so I'll be able to replicate the software renderer's bright pixel effects later down the road.

[Striker]

The software renderer had the ability to make certain pixels of textures fully bright regardless of the brightness of the surrounding pixels. For example, a texture that's a metal plate with a LED light on it, that's lit up and fully visible in a dark room, where the surrounding metal is dark.

Here's a picture of the effect in action in the original game:

[MrFlibble]

Is that the original HUD or is it scaled up?

[Striker]

MrFlibble, on 09 September 2015 - 04:39 AM, said:

Is that the original HUD or is it scaled up?

That's the original game, not my port.

[MrFlibble]

Uhh, I'm sorry, I was kinda distracted

Do you use/plan to use any filter to scale up the HUD for higher resolution modes? I remember some HUD variants for TV/Fury3 in earlier shots which were scaled up, but not sure if pre-made or procedurally generated.

[Striker]

For TV/F3 they'll be pre-made high res versions. For Hellbender they'll be linear upscaled, since the base HUD graphics for that are already higher resolution than TV/Fury3's.

[icecoldduke]

StrikerMan780, on 08 September 2015 - 03:33 AM, said:

Yeah, still a lot of complicated things to figure out. Such as optimization. Right now, it's capable of taking a 3.7ghz CPU and a GTX 560 to it's knees at times.

What are you doing wrong that your bringing that hardware to it's knees? Is this still in Java? If so why....more importantly if this game doesn't perform well why are you adding in effects?

First things first do you know if you are CPU bound or GPU bound?

[Striker]

icecoldduke, on 11 September 2015 - 09:47 AM, said:

What are you doing wrong that your bringing that hardware to it's knees? Is this still in Java? If so why....more importantly if this game doesn't perform well why are you adding in effects?

First things first do you know if you are CPU bound or GPU bound?

You're clearly confused or don't really know what it is you're talking about. Sorry to say.

1. This isn't Java, this is the actual source code to the original games. This isn't Terminal Recall, and I have nothing to do with the Terminal Recall project. Terminal Recall is thataway -> https://github.com/j...terminal-recall
2. I'm not adding in effects, only reproducing software mode effects that were left out of the original's Direct3D renderer. I'm not even close to thinking about adding new effects yet until things are sorted out.
3. Performance is mostly CPU bound, some not my fault, but the fault of old code that really fucks with new systems. Second reason that there's heavy CPU usage at the moment, is because the software renderer is still active alongside the hardware renderer, this is necessary at the moment for development and making sure the hardware renderer does things properly. The GPU-related performance issues are mainly due to the GPU getting stalled when swapping between the main framebuffer and FBOs.

I feel like you're trying to criticize me or insinuate that I'm clueless as to what I'm doing. I'd suggest being patient, stuff like this is normal during early development.

[icecoldduke]

StrikerMan780, on 11 September 2015 - 10:19 AM, said:

You're clearly confused or don't really know what it is you're talking about. Sorry to say.

1. This isn't Java, this is the actual source code to the original games. This isn't Terminal Recall, and I have nothing to do with the Terminal Recall project. Terminal Recall is thataway -> https://github.com/j...terminal-recall
2. I'm not adding in effects, only reproducing software mode effects that were left out of the original's Direct3D renderer. I'm not even close to thinking about adding new effects yet until things are sorted out.
3. Performance is mostly CPU bound, some not my fault, but the fault of old code that really fucks with new systems. Second reason that there's heavy CPU usage at the moment, is because the software renderer is still active alongside the hardware renderer, this is necessary at the moment for development and making sure the hardware renderer does things properly. The GPU-related performance issues are mainly due to the GPU getting stalled when swapping between the main framebuffer and FBOs.

I feel like you're trying to criticize me or insinuate that I'm clueless as to what I'm doing. I'd suggest being patient, stuff like this is normal during early development.

1) I skimmed through the thread and at least the original topic was about something made in Java, would have been nice to start a new thread about this .
2) You shouldn't even be doing that, the first thing is getting the game up and running and it hitting 60 fps(or even faster...its Terminal Velocity). EVERYTHING else comes second to that. You have added unnecessary complexity to a system that's already broken.
3) Then you should be able to turn off the software renderer at will, not have it always run along side the 3d renderer. GPU performance is never related to swapping between render targets(unless your swapping a shit ton of render targets), its whats going into the buffers thats stalling you out and there are many ways to fix that. You need to open up a GPU profiler and see what all the wavefronts are doing, and see where your bound on each of your passes.

You don't seem like you know what your doing, especially based on this comment

Quote

Does anyone here have experience with OpenGL Frustum Culling? If so, speak up, and I'll post a small snippet containing my OpenGL projection matrix.

Frustum culling is as basic as you can get as a rendering engineer.

If you need help, I can help point you in the right direction.

[Striker]

icecoldduke, on 11 September 2015 - 10:42 AM, said:

1) I skimmed through the thread and at least the original topic was about something made in Java, would have been nice to start a new thread about this .
2) You shouldn't even be doing that, the first thing is getting the game up and running and it hitting 60 fps(or even faster...its Terminal Velocity). EVERYTHING else comes second to that. You have added unnecessary complexity to a system that's already broken.
3) Then you should be able to turn off the software renderer at will, not have it always run along side the 3d renderer. GPU performance is never related to swapping between render targets(unless your swapping a shit ton of render targets), its whats going into the buffers thats stalling you out and there are many ways to fix that. You need to open up a GPU profiler and see what all the wavefronts are doing, and see where your bound on each of your passes.

You don't seem like you know what your doing, especially based on this comment


Frustum culling is as basic as you can get as a rendering engineer.

If you need help, I can help point you in the right direction.

1. I'm tempted to make a new thread. I decided to post here since it was the most relevant at the time.

2. Yes, I should be. The old Direct3D renderer refused to draw some extremely important things, it was a half-implemented mess, that is something I want to avoid. This renderer isn't that complex to the point where I can't do optimizations after the fact. I have been doing optimizations along the way the whole time as it is. Throughout development, it's been at 60fps nearly at all times, with exception for certain situations, which is when performance takes a nose-dive... and that's being fixed as I go. Working on this stuff not only helps make sure stuff is drawing correctly, it lets me see progress and prevents me from burning out by spending ages just trying to optimize one thing before moving to the next. It also helps me make better decisions when it comes to optimization once I have the bigger picture in consideration.

A lot of the issues right now are going away now that I'm moving over to GLSL instead of Fixed Function anyway. Just because it's Terminal Velocity, doesn't make it immune to performance issues, nor does it mean it will just magically run super-duper fast. Many things that were done in software just can't be reproduced on Modern GPUs without a lot of work, and use of things such as shaders and FBOs, not to mention the architectural differences... what may perform great on CPUs and old GPUs doesn't translate well into how modern GPUs work.

3. The software renderer will be completely and utterly removed when I reach release. It's old, broken, and a complete mess. This isn't something you should be worrying yourself about. Also, the issue with swapping between the FBOs is related to shadow rendering, since TV is very dependent on the order of drawing, I need to switch in and out of it very often. I've already managed to speed things up a bit today by having it bind to the FBO at a different stage in drawing, so the binding isn't changing so rapidly.

And yes, I do know what I'm doing, there's just some things are just confusing as fuck to me, such as frustum culling, even if it is basic. But, that's irrelevant to what I'm currently doing. Right now, I'm doing things FAR more complex than Frustum culling, but they just make sense to me. This is likely because I already have a concept of how those things work from previous experience in other situations.

Just let me do my thing, I'll get everything figured out, don't chastise me in the meantime.

Anyhow, I have GLSL shaders working now, and I got a really nice, unintended side-effect without any performance loss:

As you can see, overbrights are now possible, just like in Quake.

[Striker]

No problem.

[Striker]

I ended up finding a few memory leaks and plugged them. Performance is a bit better as a result.

[icecoldduke]

StrikerMan780, on 12 September 2015 - 03:30 AM, said:

And yes, I do know what I'm doing

It's ok to not know what your doing, but you need to understand that you really don't . Here is my advice for what its worth as someone who has shipped console games in the past.

StrikerMan780, on 12 September 2015 - 03:30 AM, said:

Also, the issue with swapping between the FBOs is related to shadow rendering, I've already managed to speed things up a bit today by having it bind to the FBO at a different stage in drawing, so the binding isn't changing so rapidly.

I don't know what the last part means but I'm assuming your renderer is something like this(I hope your not rendering lights at random stages during the frame :/):

For Each Light
       Render Shadow Pass
       Render Light Pass

This is wrong because in order for the light pass to start doing work the shadow pass has to get done first and you would be waiting for those draw calls to get submitted to the card, and then you have to wait for it complete.

You should do something like this.

For Each Light in view
        Render Shadow Pass into LOD'd Render Targets

For Each Light in view
        Render the Light

This allows the graphics card to render all of the shadows at once, then render all the lights. All the draw calls will get submitted to the card and probably even completed by the time you render all your lights. The shadow draw calls will get submitted and then the next light will do the same, without having to wait for the previous shadow pass to complete. You need to ensure your renderer isn't stalling waiting for previous shit to complete.

For your sky light(sun or moon) you should be using cascaded shadow mapping it will give you the quality you need.

Really the only you should be using out of the old renderer is whatever code its using to turn there world data into verts thats it, you should have gutted and removed the old renderer, so that way you could avoid any legacy stuff such as there fixed function code. I rarely say that is a good idea, but there literally nothing in there renderer worth salvaging and your just spinning your wheels by using it .

Take my experience or don't either is fine but I couldn't watch this go on without trying to help you out.