[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.

[Juris3D]

StrikerMan, thanks a lot for this lesson about problems with texture filtering. And, it is all good news that there probably will be an option to that. Options are almost always good for playing around. Except when there are too many

Edit: well, if there are many many options, it is maybe okay, just need then one more: "Panic" button , initial settings.

[Striker]

Finally got lightning and weather effects working again in OpenGL:

[Juris3D]

StrikerMan780, on 08 September 2015 - 01:22 AM, said:

Finally got lightning and weather effects working again in OpenGL:

It comes without saying, but still - I am glad for your progress. Is there still big obstacles, challenges to solve?

[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.

[Juris3D]

StrikerMan, you are on a good creative wave now, great!

[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.

[Juris3D]

StrikerMan780, on 09 September 2015 - 02:38 AM, said:

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.

Well I am not sure what exactly you just said (semi-joking), but nice to hear another step in progress (seriously).

[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.

[Juris3D]

Off topic: resurrection of not-aerial-but-underwater action Archimedean Dynasty / Aquanox got funded on Kickstarter. I am a backer too.
https://www.kickstar...x-deep-descent/

[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?

[Juris3D]

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

Is this still in Java?

"Terminal Velocity" ported to Java - that is completely different another project. "Terminal Recall", here:
https://github.com/j...terminal-recall

[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.

[Juris3D]

Thanks for this update, StrikerMan. It is nice to see and hear you are progressing forward nicely.

[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.

[Striker]

icecoldduke, on 12 September 2015 - 07:38 AM, said:

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.



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 a previous pass to complete.

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

The lighting and shadows work nothing like that. Not even close. You're making assumptions about a codebase you have never seen, and questioning my ability based on those assumptions.

Also Console Development is a hell of a lot different than PC development in a lot of respects. You're developing on one piece of hardware in that case so you know exactly what to expect. When developing for PC, you have to consider many different video card and CPU manufacturers. I've already run into this situation, where a particular vendor and their drivers don't act how they should. The stalling? Not my fault, I need to find a workaround.

Quote

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

Ok, I'm losing my patience now. You have no fucking idea what you're going on about in this case. I'm not "Salvaging" shit. How in the mother FUCK do you expect me to be able to see half of the shit in-game and other information until I you know.... actually implement it in OpenGL? The whole purpose for having the software renderer still there is so I can compare between OpenGL and Software side-by-side, and also to see information that hasn't been migrated over to OpenGL! Without that, there'd be no point of reference... nothing to tell if something has been done right or not. This isn't like building a game from the ground up, there's a lot to code needing to be re-written/re-implemented.

[icecoldduke]

StrikerMan780, on 12 September 2015 - 08:04 AM, said:

The shadows work nothing like that. You're making assumptions about a codebase you have never seen.

Those are the only two ways they should work if there doing something else it needs to get removed and redone. Check your PM.

Quote

The stalling? Not my fault, I need to find a workaround.

Yes it is, stalling is your fault and you need to prevent that from happening by understanding how the hardware works. You don't need to hack in a solution, you just need to code your rendering pass the right way .

Quote

Shut it. You have no fucking idea what you're going on about in this case.

Then enlighten me on how I'm wrong .

[Striker]

Just piss off. I don't want your "Help", and I don't need it. I'll get help from someone who will actually listen to me, and not just spit everything back in my face like I'm some kind of idiot. I have no patience when people pull this shit when they've never actually have seen the code.

icecoldduke, on 12 September 2015 - 08:08 AM, said:

Yes it is, stalling is your fault and you need to prevent that from happening by understanding how the hardware works. You don't need to hack in a solution, you just need to code your rendering pass the right way .

A hardware manufacturer's driver blunder isn't my doing.

Quote

Then enlighten me on how I'm wrong .

I already did for christ sake.

[icecoldduke]

StrikerMan780, on 12 September 2015 - 08:16 AM, said:

Just piss off. I don't want your "Help", and I don't need it. I'll get help from someone who will actually listen to me, and not just spit everything back in my face like I'm some kind of idiot. I have no patience when people pull this shit when they've never actually have seen the code.

You need to do whats best for the project, your letting your ego get in the way. I hope you will realize soon that your wrong, otherwise this port isn't going to go anywhere .

Quote

I already did for christ sake.

Then re-enlighten me if you want that is.

[Striker]

icecoldduke, on 12 September 2015 - 08:19 AM, said:

You need to do whats best for the project, not best for your ego . I hope you will realize soon that your wrong, otherwise this port isn't going to go anywhere .

This isn't about ego, this is is about not having some asshat jumping on my dick and harassing me about something that they're not even remotely familiar with. You didn't even wait to see the code, how it's structured, how it works, how Terminal Velocity works, before slinging shit and trying to tell me that I'm doing X wrong, when you have no idea what X is, and trying to get me to do things that make absolutely zero sense in the context of the code.

[icecoldduke]

StrikerMan780, on 12 September 2015 - 08:26 AM, said:

This isn't about ego, this is is about not having some asshat jumping on my dick and harassing me about something that they're not even remotely familiar with.

Well I've looked over what you have done and I have my concerns as I've stated above, enlighten me on how I'm wrong if you want that is.