Re: The amazing triangle drawer!
Posted: Sun Nov 13, 2016 19:03
If it's nicely commented I'll be able to pick it up a lot more quickly.
Also - what do you need help with right now?
Also - what do you need help with right now?
It is mostly a question of fixing the logic picking the vertical coordinate (i.e. checking the unpegged flags correctly and such). You're right that it might help looking at the same function in the GL part and see how it calculates it. The way it draws the wall itself is fine.Eruanna wrote:Texture coordinate stuff
Hmm, it does follow the rule as you describe it. Maybe the problem is instead with the way it "floodfills" the ceiling at those locations. Either way, there's sky some few select places that shouldn't be having it.Eruanna wrote:There is only one surface that gets culled when two nearby sectors have a sky: that's the upper texture.
The old software renderer divided light on a surface into three categories: attenuation by distance to camera (diminishing light), fixed light that is always the same no matter the distance (i.e. imp fireballs, some sectors), and globally fixed light (night vision, invulnerability). Right now it renders everything as the first one.Eruanna wrote:4) "Fixed" light?
The poly renderer only uses the r_poly* files. The drawers are completely new. I found nothing worth keeping in the old renderer.Eruanna wrote:Other than that, how are your drawers working for the triangle renderer? Are you using the r_draw_rgba stuff or did you write new ones?
All the std::vector variables are reused between frames and only allocates new memory if the lists grow larger than they've ever been before. Thus, after a frame or two, they reach a situation where they don't need allocate any more memory.Eruanna wrote:7) Yes, I have seen the sprites having this behavior you are describing. For this I would make a simple linked binary tree that simply adds and sorts each sprite that is to be rendered by its distance from the camera. How much does it hurt performance to dynamically allocate and destroy said trees every frame? If it's bad you could probably just create a static array (I doubt there will ever be more than 512 per subsector, for example) and have it index-linked and sorted, instead.
Sorry about that. Still - it is for my own benefit, also. At least then I have some idea of what to do, here.dpJudas wrote:Sorry, I probably should been more clear that I wasn't so much seeking advice on how I could do it myself, but more what things could use work. I do appreciate the input, of course. A few comments on what you wrote:
One thing to keep in mind - GZDoom determines texture coordinates by 0.0 to 1.0 where 1.0 is the right-most (or bottom-most) part of the texture.dpJudas wrote:It is mostly a question of fixing the logic picking the vertical coordinate (i.e. checking the unpegged flags correctly and such). You're right that it might help looking at the same function in the GL part and see how it calculates it. The way it draws the wall itself is fine.Eruanna wrote:Texture coordinate stuff
Ah. Well I did notice that - I thought that it was being overzealous on how to choose the areas for the sky.dpJudas wrote:Hmm, it does follow the rule as you describe it. Maybe the problem is instead with the way it "floodfills" the ceiling at those locations. Either way, there's sky some few select places that shouldn't be having it.Eruanna wrote:There is only one surface that gets culled when two nearby sectors have a sky: that's the upper texture.
I can work on this, after I do some things in Paranoic. This one isn't too hard for me.dpJudas wrote:The old software renderer divided light on a surface into three categories: attenuation by distance to camera (diminishing light), fixed light that is always the same no matter the distance (i.e. imp fireballs, some sectors), and globally fixed light (night vision, invulnerability). Right now it renders everything as the first one.Eruanna wrote:4) "Fixed" light?
Cool. I hope your code is easier to understand than Carmack's.dpJudas wrote:The poly renderer only uses the r_poly* files. The drawers are completely new. I found nothing worth keeping in the old renderer.Eruanna wrote:Other than that, how are your drawers working for the triangle renderer? Are you using the r_draw_rgba stuff or did you write new ones?
Fair enough.dpJudas wrote:About sorting by distance, the GL BSP tree already guarantees that they are sorted. Only within the subsector is there any need for further sorting (which it is already doing). I will probably have to create some pictures of how the subsector gbuffer looks like to really explain properly how I ensure the correct depth clipping. Otherwise it gets too abstract.
The poly renderer does the same thing. No midtextures or other weirdness.Eruanna wrote:One thing to keep in mind - GZDoom determines texture coordinates by 0.0 to 1.0 where 1.0 is the right-most (or bottom-most) part of the texture.
Excellent! It is probably a good starting task to get acquainted with the code.Eruanna wrote:I can work on this, after I do some things in Paranoic. This one isn't too hard for me.
The original Doom codebase is pretty typical for that age. Massive use of static variables because the computers had very little memory and their compilers were of low quality. Add to that C is a very simple language where your options are limited. Those things considered, the original code isn't that bad. But ZDoom should have refactored it, and in its current stage there's very little left worth reusing.Eruanna wrote:I will not put down Carmack. He's a genius. I think he just made this code without ever considering he'd be releasing it in the future for others. If he knew he'd be releasing the source I think he'd have made it very much differently.
Adding the missing modes is probably easiest for me to do, because I should be able to grab the stuff we need there out of the old drawers. Of course, you're welcome to ask as many questions as you'd like and welcome to give it a try adding a missing mode too.Eruanna wrote:Nevertheless if I can understand the new poly drawers it might make it easier for me to make new ones to help out with this problem - or even better, add parameters to the existing ones to have different drawing "modes".
I was going to make them from scratch and create a special mod to compare them.dpJudas wrote:Adding the missing modes is probably easiest for me to do, because I should be able to grab the stuff we need there out of the old drawers. Of course, you're welcome to ask as many questions as you'd like and welcome to give it a try adding a missing mode too.
Code: Select all
bind kp/ "toggle r_newrenderer"
All of them have their flaws and have missed the mark more often than not after the glory days of Wolf 3D, Doom and Quake. Those three games were a perfect storm, everything coming up together in an addictive whole despite being made by people who had no idea what they were doing.dpJudas wrote: As for Carmack, I think he's a little bit overrated tbh. He became famous because he's the incarnation of every teenage developer's dream: coding the coolest game engine in town. But if you look at his career, he has consistently missed the mark ever since the release of Doom and Quake. He was wrong about going polygon exclusive in Quake (ugliest shotgun ever!), wrong about how to sell game engines, wrong about shadow casting in Doom 3, wrong about mega textures in rage. When Romero and Hall left id software they lost the part that knew how to make a fun game. Not that Carmack isn't an excellent developer, but I like the personality and style of Romero much more.