Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content count

  • Joined

  • Last visited

About kb1

  • Rank
    Ask me about my source port

Recent Profile Visitors

2203 profile views
  1. kb1

    Vanilla Doom smooth weapons

    So..., your edit is on the right side?
  2. @zokumThere might be some merit in assuming that sprite sorting may remain somewhat accurate across frames, especially when far away. The beauty of radix sort is that it automatically creates something like your "Close, distant, really distant" categories, by virtue of what it does. And, it's run time remains pretty constant, regardless of pre-sort order. But, yes, radix sort could be altered to treat far away sprites specially, in a way that's kinda clever. It could sweep from the most-significant to least-significant bits of the sort key, across multiple frames. Effectively, it could take, say 8 frames to put the distant sprites in exact sort order (if they don't move). This basically follows radix sort's algorithm, split into multiple frames. Personally, I'd be worried about the flickers, and about trying to maintain state between frames, with sprites changing from visible to not-visible, and moving through different distance categories. If not implemented exactly right, there could be lots of subtle bugs occurring in ways difficult to track down. If you could make it work, it might provide a nice boost. I think I'd prefer a straight-forward simpler approach that performs well in all conditions. Radix sort is a solid performer, and a good choice here.
  3. I re-read your description, and I think I understand better. It'd be really cool if you could toggle between the original and new methods runtime, and measure the difference, but that'd probably be a nightmare. Very interesting. I'd love to know what performance gains you get, and how difficult it was to implement. When I first read your description, I immediately thought of overdraw, due to the fact that I was getting major, unexpected performance losses when the player would approach a mass grave. In some cases, the frame rate would drop to single digits, with only a relatively small number of corpses. We've basically solved the hi-res Doom rendering performance issue in the general cases. It's these diabolic edge cases that require new clever techniques to keep the frame rate going. It seems like Doom still has a lot of room for improvement after all :) That doesn't really seem like enough memory usage to really worry about, especially if it profiles well. I'm a fan of big memory usage to gain performance. If you have the memory, why not use it? Nowadays, you have to worry about read/write patterns to keep the cache happy, but in this case, it's one big usage per frame, which seems quite acceptable. I'm glad you brought this up - I've long been worried about the quicksort worst case possibilities. It's right in the name "quick", but it ain't always so :) It's nice to see a robust solution that works in all cases.
  4. kb1

    Things about Doom you just found out

    There's a consequence to being able to read the source code - you learn all the game's secrets. Before, it just seemed like Archviles were extra bad-ass, but now we know what's going on. It takes away some of the mystique.
  5. kb1

    Vanilla Doom smooth weapons

    Oops. Well, there you go - I can't tell the difference. It seems like the left one has more frames in the gun-lifting sequence. But, maybe the frames are faster on the right?? So, they are both enhanced over vanilla? I should be able to tell that... I guess I could say that: Left: Looks more fluid, which is a good thing Right: Looks more realistic, which is a good thing. Again, after looking at them for a few seconds, I can't tell which one looks better. So, @Linguica, 3 questions: How did you make the GIF (edit the frames, or just video manipulation)? What do you think would improve the weapon patch as-is? Is one of the above images your idea of best improvement, and, if so, which one? (Sorry, I really can't tell...)
  6. kb1

    Has PBR for Doom been a disappointment so far?

    Hi-res definitely has its place. But, the beauty of working on low-res PBR stuff is: It's approachable. Does not require quite as much artistic ability - you don't have to draw the textures, just the pixel properties of the pre-existing textures. Still a ton of work - I just mean that you don't have to also design the texture from scratch. The best benefit: PBR will make the original textures look hi-res, to some degree. And, depending on how the renderer works, they may actually become hi-res, as the PBR processing affects each destination pixel vs. source pixel.
  7. kb1

    Vanilla Doom smooth weapons

    Great job on the patch, and wow, I love the DEH9000 capabilities. I've had a project idea on the back burner for years - a Dehacked GUI that hides the frame number layer of complexity from the user. Without your approach, it's just not practical. But with the idea of choosing the least-invasive frames first, it becomes feasible. Furthermore, the functions you've built are just very cool. Nice job! This is quite clever! I have a hard time seeing the difference already being done with this patch. The one on the left is the enhanced version, right? Also, I have difficulty visualizing what you suggest. Do you mean adding images inbetween, when the gun raises up diagonally toward the player?
  8. @jvalThanks for posting these interesting results! It always amazes me how one small aspect of the Doom engine can bring rendering speed to its knees! Nuts.wad *is* a good test scenario, simply because it demonstrates the case where you need quick sorting. In "normal" scenes, there's no enough sprites to need a fast sorting algorithm Sure, nuts.wad is not typical, but typical scenes sort fast anyway. In other words, if you can make nuts.wad sort (and render) quickly, every Doom scene involving lots of sprites has a good chance of performing well. I don't think there's any way to reliably depend on the order of the vissprites, because this order regularly changes. But, of course, if there's a way to reduce the number of items to sort, you'll improve sorting performance. So, how much memory are we talking about, for radix sort? Does the key consist of some upper bits of the distance (inverse scale)? You could always do a rough pre-sort with, say, radixsort, with possibly a smaller memory footprint, that separates items into groups. Then, you could sort each group with a simple, non-memory intensive sort that performs ok with reduced item counts. This could afford you the best of both worlds: Lesser memory usage and faster speed, at the cost of complexity (requiring a multi-step, multiple sort algorithm approach). Something to think about with the multiple sort algorithm approach: For close-up sprites, sorting by scale makes sense, but for further-away sprites, it may make sense to use distance instead. The correlation between the two is non-linear. As distance increases, scale decreases very little, which has a negative effect on the grouping aspect of radixsort. Profiling some specific Doom scenarios will shed some light on this phenomenon: Scenario 1: Lots of nearby monsters Scenario 2: Lots of far-away monsters Scenario 3: A combination of both Scenario 4: Lots of monsters spread out evenly along the line-of-sight Ideally, for Scenario 4, you want the first sort, the radix sort, to "fill each bucket" with the same number of monsters, to be able to exert some control on the number of elements the second sort has to deal with. Using scale might be appropriate here. Perhaps the second sort is also a radix sort, but uses distance vs. scale, to provide sufficient precision and "dynamic range", allowing it to also evenly fill each division. It may require a lot of trial and error, and a lot of profiling to produce best results, but it's worth it to keep those frames coming :) @anotak: When you feel better, can you elaborate a little bit on your idea? I don't know if I understand what you're describing, but I think I had a similar idea. Are you describing clipping overlapping sprite spans to avoid sprite overdraw? If so, this has some real potential. In some experiments I did a while back, I found that sprite overdraw is a *big* performance killer...way bigger than I expected. I think it's a cache invalidation issue. One of the worst culprits is when you're standing at some threshold, picking off monsters, causing their corpses to fall at the same place. Some map layouts promote this. Once you get a couple dozen bodies piled up on top of each other, you can watch the frame rate plummet as you approach the pile. Because of the holes in sprite spans, it's not so easy to build clipping spans, as it is with textures, but if you could, it could improve a majority of Doom scenes, including that Nuts screenshot.
  9. kb1

    Has PBR for Doom been a disappointment so far?

    Taking the original images and adding PBR layers is a great idea. The same could be done for sprites - this would simulate models as good as PBR textures simulate depth in walls/flats. In all honesty, this is much more approachable than trying to create hi-res replacements and adding PBR layers.
  10. kb1

    PC Doom sound effects VS PSX Doom sound effects

    To me, there's no "PSX" or "PC" sound effects...it's just what sound an imp makes, or a baron, a shotgun, or a door. I've played for so long, that these items make specific sounds, just like an electric can opener makes a specific sound. I play Doom on the PC. In other words, for me, no matter how cool the PSX sounds might be, they are not the correct sounds, for me. For me, there's no "A. vs. B.". There's no "better or worse." Only "right", and "wrong". It might be fun to compare each game's sounds, one-by-one, and compile a WAD with the best choice of each. That would be especially nice for people that haven't been playing Doom for 20 years.
  11. kb1

    New PC build vs Doom

    On which CPUs? What resolutions? Software or hardware rendering? Which video cards/sound cards? What settings? What maps? Singleplayer, multiplayer? Under what memory conditions? With how many free threads? I'm not trying to be harsh, or picky here. Each port does literally thousands of different things, and the speed at which it can accomplish those tasks depends on all the above factors, and many more. Maybe you could accurately say that, on average, on your computer(s), with the setup(s) you use, and the maps you play, one port appears to perform better. But, generally, every developer tries to make his/her port as fast as possible, for each of those tasks, with varying levels of success. Isn't Zandronum a modification of GZDoom anyway? Doesn't it frequently synchronize with the GZDoom codebase? If that's true, they should both be similar in performance, right? Regarding OP question: You should be able to do some profiling to determine where your bottlenecks occur. In Windows, a crude Task Manager check should reveal the state of your CPU, and let you determine if you're currently bound by CPU. Load up a map that "stutters slightly", and see if the CPU is pegged. And, there should be some profiling tools available for your graphics card. If you do hardware rendering, you can load up that same map, and reduce some graphics options to determine if the GPU is the bottleneck. Becoming intimately familiar with these two values, during setting and map changes should, over time, paint a picture for you about the state of these two most important factors. If you notice that frame rate goes way up when, say, anti-aliasing is turned off might suggest that your video card is struggling. However, if this and other similar graphics features don't drop the frame rate below your acceptable level, but a more populated map does, your CPU might be struggling. The devil is in the details. The true knowledge only comes after spending time studying these factors, during the changing of various adjustable settings. Notice which settings have drastic immediate effects, and this will help pinpoint what hardware limitations are in effect.
  12. kb1

    Has PBR for Doom been a disappointment so far?

    Every change is inconsistent at first. I totally agree that consistency is very important. But it tends to go against the Doom community's resource improvement model. Doom improvements have always been slow and incremental. Now, unless you're a total Doom purist, it's hard to deny that Doom looks and plays better than ever. Take the original sprites, for example. Here's some incremental sprite improvements that have been done over time: Smooth weapons (new frames added, as well as "remastered" sounds) Sprite offset alignment fixes Sprite pixel fixes (fixing stray pixels, etc.) Smoothed monster movements Animated/extra animation frames (torches/candles) Destroyable objects Romero's release of the missing monster animations Extra gore, extra death animations These are just some of the improvements that stay true to the original look and feel of Doom. Some like them, some do not. The point is that these improvements were done by many people, over many years. For one person to have made all of the changes in a single release is an impractical idea. Going from vanilla Doom, to a full conversion to PBR, the same process applies (many changes by many people over many years): Creation of GL-rendering ports Full 3D rendering port support New shading/lighting support Dynamic lighting Shader-based rendering PBR rendering support 3D actor model support Creation of 3D models Creation of PBR floor/ceiling, and wall texture content Creation of PBR texturing for 3d models Each of these areas are quite complex, and they require the same incremental approach, done by many people. During this time, it's not unreasonable to expect some inconsistency. Bottom Line If you are of the opinion that the stock resources will always be the best for you, I cannot argue with your personal tastes - good for you (seriously). But for everyone else, I have to assume that you'd welcome a Doom with modern rendering and totally new, hi-res assets, as long as they look good, and are consistent. If this assumption is wrong, please forgive me. But if I'm right, I argue that inconsistency is a temporary condition that gets hindered by negative reception of partially improved resources. Stated differently: "We'll never get to see a nice PBR model of, for example, the Archvile, if everyone complains about how awful stock sprites look against nice PBR walls. No one will want to approach the task, because of the discouragement. I'm not saying to hold back your views about the inconsistency. But to say that it's not worth it? That it will never work? That's just not a fair assessment. As far as I can tell, here's what's missing: improvements to Doom's lighting model dedicated modellers dedicated artists The first obstacle requires some planning and some programming. The other two could be accomplished with enthusiasm and hard work. Or crowdfunding...and hard work. If I were to hit the lottery, I'd pay for it myself. If I had artistic ability, I'd make and paint the models myself. These recent PBR demonstrations are stunningly beautiful. I'll be the last person to rush to the forums, complaining about how, mysteriously, those sprites that I know and love have instantly become shitty. Or even worse: "Those new textures look *too good*" Huh? Does anyone ever stop and think about how amazing these effects are? These are completely flat, solid walls, yet shadows hug the edges of bricks, following the contours as the light source is moved. Each pixel of the wall can reflect incoming light with its own intensity. To do this with geometry would require many millions of polygons. It's a miraculous thing that was only a dream not too long ago. This feature is brand-new to Doom, and it's already shit? I'm embarrassed to read this - what a shame. For what it's worth, (I know that many others and) I truly appreciate the efforts of everyone involved in PBR, and the other improvements being done for Doom, for that matter. Bravo! Please carry on - I can't wait to see where it goes! Can we please follow the example made by id Software and thousands of subsequent modders, and have a little bit of encouragement and enthusiasm for those responsible for these great developments? They deserve it. Long ago, the list of improvements necessary for realistic rendering was huge. But with the work that you and others have brought to Doom, that list of remaining to-dos is getting smaller and smaller. I'm sure, with time and effort, the remaining issues are not insurmountable. It's getting closer and closer! Thank you! Subtlety is the key to all such effects. Ideally, all effects should quietly contribute to the whole, not hog the whole scene. When you watch a movie, you don't want to realize that you're looking at special effects...instead you want to believe that what you're seeing is true. Much improved!
  13. kb1

    How does one make high quality sprites

    I re-read this, and then realized what you must have done. More on that later. As I mentioned before, this method has the following advantages: You get proper sizing/aspect ratio of all portions of the model (head, arms, legs, torso) all sized with proper perspective. Proper hidden surface removal and proportions for 8, 16, or whatever angles of rotation. Proper lighting and shading, regardless of source color. If source is colored properly, then you get proper colors with shading too. The only issues with this method are: You need to be able to sculpt. Your model must remain pliable enough to be able to adjust it for walk, attack, pain, and death frames. You will need to touch up the pixels just a bit. You said your attempt turned into a massive mess. You didn't read my post, and you didn't set up a model on a rotatable platform, right? My guess is that you just broke out your phone, aimed it at your GI-Joe doll, and winged it :( Do you realize that the method I described is how id made the Baron (and others)? Yeah, I guess I should have mentioned that the camera position needs to be securely fastened at the proper angle and height, the model needs to be centered on the platform, and the platform needs to be set to precise angles. Furthermore, you need fixed, adequate light of proper color to illuminate the model, and you also need a solidly-colored background, preferably of a primary color, or white or black, with no shadows. This color must be different than any colors on the model, so it can be cropped out. These are things that just seem obvious to me, to have a chance of producing high-quality master images. The fact that you screwed it up doesn't make the method "stupid". You replied with a completely asshole-ish response to me answering your question, providing you a detailed, honest approach that is one of the fastest, easiest ways to produce great results. WTF, home? You throw around the word "stupid", yet it was you that made 4+ separate threads asking how to make a sprite appear in Doom, regardless of dozens of available tutorials, and literally thousands of example WADs to examine. "der" indeed.
  14. kb1

    Things about Doom you just found out

    Clever? Devious, maybe. You can crash most programs with bad data. For Doom: WADs with bad pointers, recursive node data, negative-sized/huge textures, sounds with bad headers, etc., etc. It's much more difficult, and more clever (and more enjoyable) to make something that does not crash... Regarding your example: Does the repeated autosave fill up the hard drive, or overwrite all previous autosaves? To me, it looks like a lock-up vs. a crash, unless each save is being queued, filling up a stack. Theoretically (ideally) ZDoom should catch something like this. But, you can't really provide power, and simultaneously catch every possible stupid script construct. Arguably, if ZDoom does crash, then it is catching and stopping the bug. A script like this can be considered to be on the level of malware, and rightly so. Yeah, all-ghosts bug. Cool, I didn't realize the player could clip as well. You know, the all-ghosts bug is almost a really cool, fun effect. It would be neat if, say, a wizard could cast a spell that turned nearby monsters into ghosts. (Hmmm, a neat WAD idea :)
  15. kb1

    Site and/or forum bugs or things not working

    I think it's an ID number mix up: 19204 vs. 19205, for example. This might require the creation of a custom process that walks across each record - a tool that's complicated to build, and will only be run once. (only a guess). Those 3 links above contain both an ID number, and a map name. If links like this need to be preserved (I imagine that's true), doing fixups could require some messy work. Anything I can do to assist?