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

kb1

Members
  • Content count

    2421
  • Joined

  • Last visited

Everything posted by kb1

  1. 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?
  2. @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.
  3. 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.
  4. 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.
  5. 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.
  6. 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!
  7. 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.
  8. 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 :)
  9. 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?
  10. kb1

    Has PBR for Doom been a disappointment so far?

    PBR has been available in Doom for...how many weeks? And each texture requires...how many layers? Is this seriously a thread complaining about how good PBR textures look?? Each and every time someone attempts to improve Doom's imagery, it is followed by a few unsatisfied voices: "Translucent fireballs suck" - too dark, too bright, too ugly with 8-bit color, too slow... "High res output sucks" - too sharp, not like the original, the textures are too low-res... "Low res sucks" - too blurry... "High res textures suck" - not exactly like originals, makes things look out of place... "Thing models" - look cartoony, not enough polys, move awkwardly... And now, PBR Has anyone noticed the lack of 3D models for the Doom monsters? Yes, it's difficult, and it requires master artists and modellers. But I wonder about the effects of the constant lack of encouragement. It's almost as if someone must release new enhanced textures, floors/ceilings, beautiful 3D models, new high-fidelity sounds, and a set of awesome maps, all at once, to avoid this inevitable "X looks out of place with Y" rant. And, that's probably not enough. Summary: Can we at least play a few PBR maps, and enjoy the new possibilities a bit, before having to read a bunch of obvious conclusions that one set of resources is more advanced than the other? Guess what? Building 3D models (PBR or not) requires totally different skill sets than making textures. What if someone makes an awesome new PBR pinky? Will everyone have to suffer hearing that "The pinky is totally out of place against the original textures - what a disappointment"? By the way, I am astonished and completely impressed with the new textures, and with the engine responsible for displaying them. And, I guess I can cope with playing a map or two with beautiful textures, and those awful original monsters, for a week or two...
  11. kb1

    How does one make high quality sprites

    Do I need to say it?
  12. kb1

    The Definitive Guide to Visplanes

    @Anarkavre Nice, straight-forward description, and interesting post! Thanks for taking the time to write this.
  13. kb1

    How does one make high quality sprites

    If you can sculpt in clay or play-doh, you could set up a fixed camera, and put your model on a lazy susan, and take pictures of it at 45 degree rotations. Then you have to color each picture, and add some artistic detail. That's for one animation frame. Then, alter the model for each new standing, walking, attacking, pain, and death frame. Of course, it's a ton of work, but it's much better than trying to draw each frame by hand. You get proper sizing/aspect ratio, hidden surface removal, and all eight rotations "for free", so to speak.
  14. kb1

    Does anyone have this?

    Point the camera downward towards the floor, and force strafing on? Hack up the automap? I don't know if Doom is the most appropriate engine (but it may be do-able.)
  15. Another aspect I didn't think of before: Gaming was very different in '93 than it is now. Not long before that, video games were in the mall, and at convenience stores, and they cost you a quarter to play for only a few minutes. Or, if you were lucky enough, you had a crappy game console like the Atari 2600 plugged into a TV, and you could play simplistic, very ugly games on it (Atari 2600 was awesome, actually). Or, third option: You had an 8-bit home computer with simple games and simple graphics. Doom arrived a bit later, in the BBS and shareware era. Again, very different from the modern scene. You have to take all of this into account when thinking about popularity and the effects thereof. Doom really couldn't have been more popular, in '93, like a game can be nowadays, with the ability to instantly download it and play it against anyone in the world. Totally different scene back then.
  16. Self-promotion *is* important, but self-appreciation is what keeps me going. Relying on others to notice leaves a lot to be desired. Very true, even if the progress bar doubles the runtime. Amazing how that works. Oh, that is awesome - I've never seen traffic lights like that. I really despise the city when they paint the ring around the light black, so you can't tell when the opposing light is changing from green to yellow. This promotes road rage, as far as I'm concerned. *This* Often, I see the 'decision makers' not wanting to spend the money. Usually it takes a catastrophe to open their eyes. Meanwhile, it's the guy in the trenches that suffers, and has to save the day.
  17. kb1

    Things about Doom you just found out

    Damn shame - the keyboard has its own processor, but they couldn't be bothered to include a lookup ROM to convert scancodes. Because of this, the OS (or even worse, the program) has to know about every keyboard layout out there. Too late now, though.
  18. Totally opposed to changing these, or any other such terms. When a baby cries out of discomfort, the appropriate response is to cater to them. When a baby cries as a means to an end, the appropriate response is tough love. It not about what people say, it's about what they think. And, you're not going to change the way people think, by changing their language.
  19. I don't know if it's just me, but everytime I look at Quake 1, I think "Man, that is one ugly color scheme." *Any* color scheme would be better than brown, and green with yellow highlights.
  20. Oh, it's way impractical! Then again, you've already gone to great lengths to improve ZokumBSP output (which is pretty damn cool). And, yeah, it'd be slow, but not horribly slow. The idea of using a source port was that you could get some demonstrable results without a lot of coding. It would be much better to emulate visplane creation within the node builder directly, allowing it to be lean and highly optimized. The thing about genetic algorithms is that they bear fruit pretty quickly, if they have a reliable scoring mechanism. That's where the visplane counter comes into play. That has to be highly accurate, otherwise the genetic algorithm oscillates between slight differences, and never gets a foothold. At any rate, it would be fun to build. Please keep us informed on the results of your future tests.
  21. kb1

    Things about Doom you just found out

    Yeah, every time I watch that video, I do a double-take, cause my eyes are so accustomed to seeing doors go up and down. It's a cool effect, even if its implementation is non-existent.
  22. As if that's a positive trait... There was a time when people had to pray in secret, for fear of persecution. Now, people are embarrassed by religion? What if God was more popular? Anyway, there were supposedly more installations of Doom than Windows at that time. How much more popular could it have been?
  23. kb1

    Things about Doom you just found out

    More ugly hacking could seriously improve this effect: Instead of storing the same texture inthe WAD 4 times with slightly different offsets, the offset of an in-memory texture could be adjusted runtime, making the door action smooth. The bullet and object clipping could add a lot of complexity. For a fairly easy to build, but truly hideous hack, invisible things could be attached to the door opening, effectively blocking bullets and passing objects alike. If it were not for the modern polyobjects in ports like Eternity, adding such nasty hackiness might almost be justified. I would almost always say 'No' to an idea like this, but even with just the 4 frames of that video, I can appreciate the visual animation - it has some potential.
  24. That smiley face means "I'd be glad to", right?
  25. I was going to ask for your 'Ling's Reverse' code, and attempt the hex edit, but I can't get my other Doom projects released :( Anyway, am I reading your terminology backwards? As far as I can tell, less visplanes = more merges = better performance, right? Chart #2 looks like chart #1 with the green turned into blue, so, does the green represent extra merging that happens when merging in reverse? Aw, hell, what is the reverse algo? @zokum Nice colored console output! I find your algorithm to try tons of variants fascinating. But the idea of using a general algorithm to estimate visplanes worries me...or, let's say that it seems like a shot in the dark, precisely because of the 360-degree nature of visplane creation. For better results, a primitive line-intersection 90-degree "eye" could walk the level, by scanning a grid of blockmap-sized steps, left to right, top-to-bottom, in, say 8 or 16 rotations, with each "gaze" performing a mock visplane merge. Finally, add up the total number of merged visplanes for the level. Use this final sum to judge the quality of your current variant. Do this after each variant, and retain the variant with the lowest count. This could be the basis for a genetic algorithm that finds the best configuration. But, it's a whole lot of work! A demo could be made easier with the help of a source port. The port could load the map using the "-wart" hack, calculate the visplane sum, and write it to file. But, again, yikes :) An efficient runtime "perfect merge" algorithm would be the most ideal solution, I would think. Hex-editing that into Doom.exe would be the most "fun". Damn it, you guys are having all the fun, and I'm stuck writing order entry programs - grrrr.-
×