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

[Striker]

Unfortunately, it's not like I can just post the source code of the relevant pieces, because I'm under an NDA. The only code I can post is the new stuff I've made, and a majority of the issues aren't there, but in the game's normal code.

Also, please wait a few moments before replying. I tend to edit my posts a few times after making one, instead of double-posting if I need to add something else.

I really don't wish to be so hostile right now, but really... I don't like it when someone acts like a know-it-all, saying something's wrong or that I'm incompetent when they haven't a clue about the situation, the context, or what actually is wrong without first seeing the source to begin with and familiarizing themselves with it. This is still early in development, I'm in no way spinning my wheels. Shit's getting done, it just isn't finished yet.

About the software mode thing, I don't need to re-clarify, my old post says this:

Quote

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.

As for the shadows and lighting, well... first thing, GL_LIGHTING isn't even on. In fact, none of the lighting is done in OpenGL, there's no need currently. Hellbender has it's own lighting system, and it's extremely fast, and has no impact on performance (it ran on a Pentium after all). The intensity value that Hellbender assigns to a vertex, which is in the range of 0-255, is applied directly as the vertex color. So, a vertex that has the intensity of say... 128, has the vertex color of (0.5f, 0.5f, 0.5f) in OpenGL.

Shadows are rendered like any other model in the game, however, unlike software where it would render shadows to a 64x64 framebuffer (a simple char array), it now sends the polygons to OpenGL with the POLY_SHADOW flag. When that flag is passed with a GLdrawPolygon call, it switches from the main framebuffer to the FBO, draws the shadow polygons to the FBO, then switches back to the main framebuffer. This happens not randomly, but it happens very often.

First, the model of the object is drawn, then the objectDraw function (part of TV, not my code) calls AddShadowToDisplayList, which then has a callback that'll draw the same model blackened, to the shadow buffer. So for each model, it draws to the main framebuffer first, then switches to the shadow buffer, draws there, and then repeat the process for all models in the scene. Keep in mind, I already have an idea of how I can make this process faster. Also, it isn't the biggest framerate killer, and if I can solve the biggest culprit, this part may not push the framerate below 60 anyway.

[icecoldduke]

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

Unfortunately, it's not like I can just post the source code of the relevant pieces, because I'm under an NDA. The only code I can post is the new stuff I've made, and a majority of the issues aren't there, but in the game's normal code.

Also, please wait a few moments before replying. I tend to edit my posts a few times after making one, instead of double-posting if I need to add something else.

You stated before that can people NDA'ed on to your project, while I can't devote a whole bunch of time to this(it would be weekends, if that's an issue then this won't work). But everything I've stated before I can say is accurate without having to look at exactly what's going on in there, and I hope you take it seriously.

[Striker]

Look at my previous post, it's been updated.

[icecoldduke]

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

As for the shadows and lighting, well... first thing, GL_LIGHTING isn't even on. In fact, none of the lighting is done in OpenGL, there's no need currently. Hellbender has it's own lighting system, and it's extremely fast, and has no impact on performance (it ran on a Pentium after all). The intensity value that Hellbender assigns to a vertex, which is in the range of 0-255, is applied directly as the vertex color. So, a vertex that has the intensity of say... 128, has the vertex color of (0.5f, 0.5f, 0.5f) in OpenGL.

Shadows are rendered like any other model in the game, however, unlike software where it would render shadows to a 64x64 framebuffer (a simple char array), it now sends the polygons to OpenGL with the POLY_SHADOW flag. When that flag is passed with a GLdrawPolygon call, it switches from the main framebuffer to the FBO, draws the shadow polygons to the FBO, then switches back to the main framebuffer.

Yes it did run a pentium which is why I pointed out that your stuff bringing down a new nvidia card and a high end intel chip isn't acceptable in terms of performance. .

So in normal shadow buffer rendering, the shadows are rendered from the view of a light source, this is NOT the case right? It sounds like your doing a render to texture and doing some weird projection to get the shadow on the ground, that should get removed as whatever it's doing is a fixed function implementation, is that more or less right?

First what I would do is get everything into IBO/VBO's so your not submitting the verts every frame, let that stuff reside on the GPU you have the memory for it especially on the PC. Then I would completely remove that crappy out door lighting implementation and switch it over to cascaded shadow maps(http://developer.dow...shadow_maps.pdf).

[Striker]

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

Yes it did run a pentium which is why I pointed out that your stuff bringing down a new nvidia card and a high end intel chip isn't acceptable in terms of performance. .

Ugh, you just don't get it. That's the lighting code. The lighting code has nothing to do with the shadows. I was basically proving that the crap you spewed earlier was BULLSHIT.

Something tells me you're someone who can talk the talk, but not actually walk it.

One, I'm already using IBOs/VBOs for rendering. That's stuff is fine and is fast.

Two, shadows aren't done through the lighting system and have nothing to do with it. We're talking about an old game here, that doesn't have realtime lighting beyond basic Goraud shading. See: Duke3D sprite shadows, but on a quad aligned with the ground.

Three, shadows do indeed render to texture, and that part isn't slow. It runs fine.

Four. The performance issue is because the driver locks the thread while it reloads the state of the buffer from slow RAM when switching to and from it, this isn't intended behavior, it is a bug on the part of the driver. The most I can do, is try to reduce the number of calls to glBindFramebuffer. Even then, this isn't the biggest culprit for poor performance.

Five. The biggest culprit, which, when fixed, will likely give everything else breathing room, is the old texturing system from software, which does thousands of strcmp calls every frame when trying to find what texture to assign to a polygon. This wasn't so bad in 1996 when the draw distance was tiny and only a few polyogns were drawn at a time, and no more than 100 textures.

[icecoldduke]

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

Ugh, you just don't get it. That's the lighting code. The lighting code has nothing to do with the shadows. I was basically proving that the crap you spewed earlier was BULLSHIT.

Something tells me you're someone who can talk the talk, but not actually walk it.

1) Good
2) How much speed do you get back by taking out the shadow code? How many milliseconds?
3) That wasn't what I asked, and I said you could get better shadows by doing sun/moon shadows via cascaded shadow mapping.
4) Then switch all of your rendering code over to another thread but your explanation of whats going on doesn't sound right, what evidence do you have this is whats going on? If this isn't a perf issue then do you even know what is your biggest GPU performance issue? Have you opened up Nsight or anyother GPU debugger? Have you inserted GPU perf markers?
5) I hate when people use string compares all over the place, and it would have been a big problem back then too but this can fixed easily.

[Striker]

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

1) Good
2) Shadows should have there own pass, if that's what your doing great.
3) That wasn't what I asked, and I said you could get better shadows by doing sun/moon shadows via cascaded shadow mapping.
4) Then switch all of your rendering code over to another thread, if you know your renderer is CPU bound; but your explanation of whats going on doesn't sound right, what evidence do you have this is whats going on? If this isn't a perf issue then do you even know what is your biggest performance issue? Have you opened up Nsight or anyother GPU debugger?
5) I hate when people use string compares all over the place, and it would have been a big problem back then too but this can fixed easily.

2) Shadows do have their own pass, they did even in software.
3) While projection and clipping is done in OpenGL, rotation is not, it's handled by the game engine itself, so something like that would be quite difficult to do properly. There is a sun vector for the terrain Goraud shading, but that's all done before rotation, and before OpenGL even touches things. Also, rendering of the scene isn't done in one glDrawArrays call, but multiple times, once for each object in the scene. It's fast, but wouldn't shadow mapping require the entire scene to be rendered together?
4) This is written in C, multi-threading isn't possible. Also, the code in general isn't multi-threading friendly, it's a lot like Doom in that way. Take ZDoom for example, it hasn't become multithreaded after all these years, because doing so would essentially need a rewrite of everything from scratch.
5) Yeah, it's pretty bad. However, I can't fix it yet, it's tied into some other important bits of code that depend on it at the moment, but I'm slowly clearing it away.

[icecoldduke]

Also you mentioned it's using vertex color to do lighting, is this ever edited on the fly by the game? Or is it set once when the VBO is created? Also just clarify are the VBO/IBO's used for the world and game entities? When the game loads in the world it populates the VBO right? Or does it do that on the fly each frame?

Basically is there is anything in the game that edits the VBO dynamically? If so you would get a big stall there. If there is are they editing the same buffer multiple times a frame?

2) Good
3) Yes it would so that's why I just asked about how the world is currently being handled.
4) I still would really argue the renderer should be re-written from scratch anyway, but if that isn't an option then you need to have evidence of driver stalling, do you have any of that right now?
5) I would argue this is something you should tackle now, even if you just hash the string names, that wouldn't take long to do at all.

[Striker]

icecoldduke, on 12 September 2015 - 09:30 AM, said:

Also you mentioned it's using vertex color to do lighting, is this ever edited on the fly by the game? Or is it set once when the VBO is created? Also just clarify are the VBO/IBO's used for the world and game entities? When the game loads in the world it populates the VBO right? Or does it do that on the fly each frame?

The lighting is done on the fly, the VBO is also populated on the fly. The performance is fine however. With everything shut off except for polygon drawing, the framerate is in the thousands. The framerate goes to shit with other things unrelated (which I've already mentioned). I cannot do it when the level loads, because the game is extremely dependent on the order of when things are drawn, such as when drawing picture-in-picture/windowing effects like the compass and minimap. Keep in mind, the game wasn't developed with modern rendering techniques in mind.

Quote

5) I would argue this is something you should tackle now, even if you just hash the string names, that wouldn't take long to do at all.

Can't yet. I'd sooner just get everything that depended on it working with the new texture system, and delete the old one entirely. If I make any alterations right now, the game crashes outright.

[icecoldduke]

StrikerMan780, on 12 September 2015 - 09:37 AM, said:

The lighting is done on the fly, the VBO is also populated on the fly. The performance is fine however. With everything shut off except for polygon drawing, the framerate is in the thousands. The framerate goes to shit with other things unrelated (which I've already mentioned).

Have you opened NSight and figured for certain where your perf hits are coming from? NSight might have problems with your fixed function stuff, so you should add NVIDIA PerfKit to the game https://developer.nv.../nvidia-perfkit it gives you hardware perf counters so you can figure out exactly were the game is locking up and why.

Quote

I cannot do it when the level loads, because the game is extremely dependent on the order of when things are drawn, such as when drawing picture-in-picture/windowing effects like the compass and minimap.

At the very least you should be double buffering VBO's that are being changed on the fly to prevent stalling. Do the ships have any animation what so ever? If not you can get away with getting them into there own VBO's, and never update them on the fly. But for all of this you should be double buffering your dynamic VBO's.

Quote

Can't yet. I'd sooner just get everything that depended on it working with the new texture system, and delete the old one entirely. If I make any alterations right now, the game crashes outright.

As I said I can help you out if you want that is, and if your able to get me NDA'ed, but the correct course of action is to re-due the renderer and if you can redue that part by itself that would be a great solution, but I still think in the short term you can get those string compares moved over to string hashes without a problem.

[Striker]

VBOs are already double-buffered. Stalling isn't related to VBOs, I already said it was FBOs and specifically glBindFramebuffer. I've already done my research, and I've done profiling. BTW, Vertex buffers and Frame Buffer Objects are two totally different things.

Most ships do have animations, so that isn't much of an option.

Lastly, no need. I should already have everything moved over to the new texturing system by the end of the week. I'm very busy, I have college to attend.

[icecoldduke]

StrikerMan780, on 12 September 2015 - 09:55 AM, said:

VBOs are already double-buffered. Stalling isn't related to VBOs, I already said it was FBOs and specifically glBindFramebuffer. I've already done my research, and I've done profiling. BTW, Vertex buffers and Frame Buffer Objects are two totally different things.

Most ships do have animations, so that isn't much of an option.

Lastly, no need. I should already have everything moved over to the new texturing system by the end of the week. I'm very busy, I have college to attend.

Are you planning on joining the game industry? If so as a junior engineer people won't listen to you often times and you have to stop being sensitive. You can do all the research you want but you haven't shipped a game, it would be wise to accept someone who has on your team who has even if it isn't me.

Are your render targets double buffered? Also glBindFramebuffer doesn't cause much of a performance hit, in practice I have never had it be a huge bottleneck. What evidence do you have this is whats happening? Can you post your timings for your different hardware counters?

[Striker]

I'm going dark with this project until further notice. That is all.

[icecoldduke]

Juris3D, on 15 September 2015 - 08:14 AM, said:

I hope that means you are going forward without discussions here, so nobody interferes you in a bad way. I wish you all the best. I personally will be impatiently waiting for news from you. Take care!
P.S.: this thread and all coding progress posted is making my days lately. I hope it will stay that way.

I too wish him the best, and I understand were his mind is because once upon a time I was a junior engineer trying to prove myself too. Maybe this is a good project for him to gain some experience on, rather then him making these mistakes in the industry. I just don't have high hopes for the quality level of the port if he isn't accepting help from people more senior then himself(there are a lot of people on here that could help him out, not just taking about myself).

My last tidbit of advice, you won't make in the industry if you can't accept criticism about your work .

[Striker]

That is exactly why. I don't need the attitude, premature judgement and douchebaggery from people. It's just making working on this project hell, and makes me want to just stop altogether. So, I'm going away to work on it in silence, so I don't have the deal with the bullshit. People were lucky that I was open as I was about the project as I was, but like anything, people tend to abuse that and sling shit with the emptiest of excuses.

IcecoldDuke: I can take criticism fine, I just can't take bullshit. And what you've been giving isn't criticism, it's spewing empty assumptions and trying to be a dictator over something that you have no bloody clue about. I'm the ONLY person in the world, aside from the original Developers, who has ever seen or worked on this code. And here you are, trying to judge me about the quality of a port (in extremely early development at that) that you've never seen, when your own port of Duke3d(a game that is open source and well-documented), EDuke Iced, was a piece of rancid, steaming shit? (Even the AAA titles you have claimed to work on aren't exactly shining examples of quality.)

This is why we can't have nice things. I'm stressed enough in life right now, I don't need more stress and pressure from outside sources. It's snowballing out of control.

Requesting a thread lock. I'll open a new thread when a release is ready. It may take several months before everything is ready, due to college, but I don't want BS to distract me in the meantime.

[icecoldduke]

StrikerMan780, on 15 September 2015 - 09:13 AM, said:

IcecoldDuke: I can take criticism fine, I just can't take bullshit. And what you've been giving isn't criticism, it's spewing empty assumptions and trying to be a dictator over something that you have no bloody clue about. I'm the ONLY person in the world, aside from the original Developers, who has ever seen or worked on this code. And here you are, trying to judge me about the quality of a port you've never seen, when your own port of Duke3d... a game that has open, public source, EDuke Iced, was a piece of rancid, steaming shit? (Even the AAA titles you have claimed to work on aren't exactly shining examples of quality.)

I wish you the best . Damn I forgot about EDuke Iced, but the AAA games I've worked have sold 5 million or more units, couldn't have been too bad .

Edit:
Obviously you don't like me that's fine, but there are other senior engineers on this forum that can help you out. You and the port would benefit a lot from having a least one senior engineer on the team.

Edit2:
Damn I'm feeling old EDuke Iced I did that in 2003(at least thats when the files were dated), that would have made me 15 at the time.

[Striker]

It's nothing directly personal, I just don't like how you've been addressing me. I feel like you've been belittling and trying discredit what I've doing. I don't care if you're a senior engineer or not, treat me as an equal, not an underling. I'm very unpredictable, I learn best by direct applied example, not by being told what to do, and I know I can excel against people's expectations, but these things take time, and I don't like being condemned before I get there.

About two months ago, I never had C, or OpenGL experience. However, my problem solving skills, my deductive/application-based learning process, the experience I've had in other fields, my existing knowledge of the workings of older titles, and the experience I had reverse-engineering this game (I learned a fair amount of Assembly before I got into C) before I even had the source, all helped me get where I am today. Normally people learn by starting off with the easy shit, not me. I don't learn that way. I may have had issues with Frustum culling, but by that point I already had many, and much more complicated things down perfectly fine.

Sometimes the small things evade me where the big things just click, but simply saying "you gotta do X" never helps me. If someone wants to help me or teach me something, they're better off actually doing something with the exact context in question in front of me where I can watch every stage of the process, and memorize it so that I can do the exact same process in the future. (Ie. Giving someone the source, having them implement whatever it is I'm trying to learn, so I can look it over, tear it apart, look at it's guts, then finally learn how it all went together. At that point, I have the concept, so then I can go forward and do the same thing unattended.)

[icecoldduke]

StrikerMan780, on 15 September 2015 - 09:33 AM, said:

It's nothing directly personal, I just don't like how you've been addressing me. I feel like you've been belittling and trying discredit what I've doing. I don't care if you're a senior engineer or not, treat me as an equal, not an underling. I'm very unpredictable, and I know I can excel against people's expectations, but these things take time, and I don't like being condemned before I get there.

I've never been attacking your intelligence, you probably have the ability to be a great engineer...but

StrikerMan780 said:

About two months ago, I never had C, or OpenGL experience.

The problem is your lack of experience is working against you. When I asked you for evidence backing up your claim that render target switching was causing your performance issues, it wasn't that I was belittling you, it was I wanted to see what evidence you got to back up your claim. Maybe your drawing the wrong conclusions (this is very probable as render target switching wouldn't cause the slow downs you have been describing). If you want this project to do well, and actually look good on your resume you would benefit from someone who is smarter and has more experience then yourself(not saying that your not intelligent). This project has to do well for anyone to care about it, no one will care that you did all the work by yourself.

I treat everyone like an equal, I would ask any Junior, Mid Level or Senior level engineer for evidence to back up there claim .

By the way if you wanted to judge my open source work, you can look at the source code for this here https://github.com/j...23/UnrealEngine (dynamic god rays(VLS) in UE4 ).

Initial Check In https://github.com/j...024191027645c64
Should have updated the readme, the code in there can hold 60 fps, fixed that with CL(rendered the VLS buffer at quater resolution and upscaled it) https://github.com/j...e792b19b5e7f120
Fixed a bug with the previous checkin, so people can sync it https://github.com/j...8de07080001cd72

Also you should have some form of source control up if you don't already.

[Striker]

I'm just going to stop talking, since everything I say will be used against me.

[Smoke Fumus]

Something did came up recently.

[Striker]

TerminalFury (the TV/Fury3/Hellbender port) is still on hiatus, but I did commit the current progress into a working branch in the repository, so should something happen to me, or should my PC fall victim to a hard disk failure, the code won't disappear.

[DustFalcon85]

I noticed StrikerMan780 changed his name to "I want to die". I hope that he's not suicidal. I'm afraid that we'll never see a source port and a source code release to Terminal Velocity.

[Smoke Fumus]

DustFalcon85, on 10 July 2016 - 08:17 PM, said:

I noticed StrikerMan780 changed his name to "I want to die". I hope that he's not suicidal. I'm afraid that we'll never see a source port and a source code release to Terminal Velocity.

Nevermind that, striker sometimes is a huge attention #####. Besides, i have sources with me. If process grinds to a halt - i might be able to convince Mark Randel to give community GPL-licensed source access.

Meanwhile - here's 4th iteration of tv-202.

I decided to drop the old details completely, but keep resemblance of shape.
This definitely come a long way since quiet garbage original model

Here's the iterative progress so far

Spoiler

[Smoke Fumus]

And here it is finalized with PBR

https://sketchfab.co...a9c9fde46cb05bd