Jump to content


  • Content count

  • Joined

  • Last visited


About kb1

  • Rank
    Ask me about my source port

Recent Profile Visitors

1392 profile views
  1. @PinkLionI filled out the optional questionnaire. I don't know what you think about the spreadsheet, but it would be nice to see (I assume you are going to compile one anyway).
  2. Interesting. That makes me want to investigate them further right now (but I can't :) I am. I was comparing bleeding midtextures to slime trails...What's an exposed hidden pit? It's a good workaround. Unless it causes another slime trail! Or, unless you're running up too close to a map limit. I wasn't dogging your method, nor am I unhappy - again, nothing wrong with it. I was just providing clarification, in case you or someone else cared to know.
  3. Edit: You ask for sources of research, but you don't describe the goals of your project, except that you're a game designer. What kind of research do you need? There's a Doom Wiki (link at top of page). Edit 3: The optional questionaire looks basically identical to your posted questions...what's up with that? Edit 4: What do you mean about an Ethics Protocol? Who is asking for that? Before I provide answers, I have a question for you: Will you provide us a compilation of the answers (without names, of course)? I mean, if we are providing you data, for free, it seems like a small favor for you to eventually provide us with a spreadsheet of totals and averages of the question results, please. Right?
  4. There are efforts underway to create a generic, universal MAPINFO for interested ports, but, currently, MAPINFO is *very* port specific, as is the ClipMidTextures property. However, the "change the light by 1" method does, in fact, work in all ports, including vanilla. I suggested it, because you indicated your desire to create amps that work everywhere. Office? You lost me there. The phrase "the fix" is exactly what I meant. A "fix" would eliminate slime trails in all maps. What you describe is a "workaround" (nothing wrong with that, just saying.) I think you are confusing 2 issues and 2 solutions. The "change light by 1" method is to fix bleeding midtextures (where it looks like a midtexture dips into and below the floor). This has nothing to do with slime trails, which cause the ends of lines to bleed. The "change light by 1" method will do nothing to correct slime trails.
  5. Ultimate Doom tree driven into ground

    From a player's viewpoint, I think the multiple configs and enables would be a bit confusing, and I haven't seen other ports need that level of separation. I am hoping that the SyncDebug stuff will help get you towards a known-good state. From that point on, the re-introduction of things like the MF_ONGROUND flag and others will feel like a more controlled process, and will promote your ability to isolate specific new features, and see their individual effect more easily. Please keep me informed when you can.
  6. Why do people care about FPS past 120?

    There are many factors to consider here, some factors are scientific, some are related to human physiology, some psychological, and some are pure b.s. Here are a few of those factors, in no particular order: Movies, especially older movies are traditionally shown at a very low frame rate (24 fps to 30 fps). But they typically look rather fluid in high-action scenes, regardless. If you slow down a movie, and look at each frame, you'll notice the 'motion-blur' effect. Cameras create this effect due to exposure time (shutter speed), and due to certain properties of the film. In essence, this effect works hand-in-hand with how the eye works, allowing the viewer to perceive fluid motion. CRT screens have a retention period, where the phosphor of each pixel continues to glow after being charged. This assists the motion-blur effect. LCD/LED screens lack this ability, though many of the high frame rate monitors have special circuitry that blends frames to fake a higher frame rate. Human eyesight is not as precise as one might think. The eyes also have a retention effect. More accurately, sight works largely by differential. If you stare at a bright light, then look away, you see an inverse color effect. The eyes are also more sensitive to some colors, and less sensitive to others. This effect also depends on position in the field of vision. Near the edges, the eyes are more sensitive to brightness than color. And each primary color is retained for different periods of time. Some scene changes (like a flickering light) can be detected by your eyes up to 1/500th of a second. Most others require more time to detect. When you pan a real-life scene, your eyes don't stay fixed: They make micro-movements as they try to focus on interesting areas. The equilibrium mechanism in your ears aids this effect. But, in video games, the mouse does the panning, not your head. This effects the micro-movements of the eye, as they are no longer guided by actual movement. So, the motion-blur effect is very complex, and it depends on a lot of different factors. In movies, the camera creates a motion-blur effect very similar to what happens in the eye. In real-life interaction, the eye's retention, combined with micro-movements has a similar effect, which the brain interprets as fluid motion. In video games with low frame rates, lack of a motion-blur effect can make turning look very jarring. The more an object moves per frame, the worse it looks. However: Because of the nyquist theorem, producing more than double the number of frames than your hardware can render provides no visual benefit whatsoever. Now some people claim that, with faster frame rates, the time between the mouse being read, and the next frame is reduced, allowing better control. I counter with this: In the music for Doom E1M1, with that crazy guitar solo, those note are being played slower than 12 notes per second. Imagine the picking hand, while playing that solo, alternating 12 times per second. Some guitarists can do it, but if you can, you're fricking wailing! Now, imagine alternating the mouse, instead of the pick, 12 times per second. Now imagine doing it 60 times per second. See what I mean? I suggest that a nice motion-blur effect would work as good, if not better than a massive frame rate, and it would be easier on the electricity bill. This is not an easy effect to build right, but it's worth looking into.
  7. Lee recently rejoined the community, to inform everyone about Jim Flynn's passing. I was never able to thank him and the rest of the team for the profound impact of their contributions to the community. Before the release of the Doom source, Lee was investigating the many quirks of the Doom engine, with a special interest in visplane overflows. Through tireless experimentation, Lee developed heuristics that he incorporated into BSP, that would reduce the possibility of encountering visplane overflows. When the Doom source was released, Lee and the rest of TeamTNT set out to build one of the most stable, efficient, clean source ports out there, Boom. The improvements brought by Boom are too numerous to list here. The programmer in me causes me to take a particular interest in Lee's contributions. Lee's code serves to stabilize various Doom functions, remove static limits, improve performance, and fix many bugs. Boom also achieves the impossible: Using new source code to play old vanilla demos in sync. Lee was instrumental in making that a success. After Boom, Lee went on to produce MBF, which brings even more stability, and new features. It is important to note that nearly every modern source port designed for modding incorporates Boom and MBF code, as the definitive standard first step - it's practically a requirement. Personally, I appreciate everyone that has contributed to Doom. But I cannot think of a programmer, outside of John Carmack, that has done more for Doom than Lee Killough, and though I am sorry for the reason he decided to log on, I am very glad to have the opportunity to highlight his still-relevant achievements. So, I would like to say "Thank you, Lee! You are appreciated."
  8. Jim Flynn

    Oh, what a shame. Strokes are bad news. Thanks, Lee, for letting everyone know. You and Jim, and the rest of the team brought such innovation and joy to so many. It's yet another reminder to celebrate each other with the time we're given.
  9. PrBoom-Plus, ver.

    Look for a missing semicolon above the errors, or possibly in an include file.
  10. MAPINFO, and its setting, "ClipMidTextures" is ZDoom-specific. Because you want multiple-port compatibility, you'll need to use a compatible method to get proper clipping. If I'm not mistaken, the fix is to find the sector where the bleeding occurs, and change its properties slightly, do it differs from nearby sectors. For example, you can change that sector's brightness by 1 unit, and that is enough. Technical reason (as much as I understand it): The problem occurs during visplane merging. When Doom prepares to draw flats, it examines all the sectors in the scene. If it finds multiple sectors with the same brightness, height, flats, etc., it merges the separate rendering steps into a single step, which usually helps renderer performance. But, the id guys never bothered to differentiate between different mid-textures. So, sometimes, the scene is rendered properly clipped, and sometimes not, depending on which sector, in a given view, happens to become the model for the merge process. Changing a property that the merge function will be actually checking on, is enough to ensure that it draws that sector by itself, with its own properties.
  11. Please search the Doom Wiki for "slime trails". It's a renderer math calculation problem that occurs occasionally with diagonal lines. There's nothing wrong with your map, so there's no way to fix it. There's some hacky things you could do to the most offending lines, but not really worth it. Any true fix must happen engine-side. It changes each time you edit and compile the map, because the nodebuilder makes different choices as the map is changed. You cannot really control those choices deliberately. The most effective "fix" is to slightly move the vertices where the effect is noticed most. EDIT: Beaten to it :)
  12. Things about Doom you just found out

    Don't sweat it: Doom tricks get rediscovered and re-invented all the time. Make a cool mod with some tricks you've discovered, and I'm sure you'll blow away at least some people with your mod. It's *how* you assemble the tricks that makes them fun and interesting.
  13. @Revenant100 I agree with your assessment, and I appreciate the project's goals and philosophy, and that you follow them. At the same time, I'm slightly conflicted - there are just a few small instances where I'd like to see things like this slip into the mix. That original wiggly megasphere has always caught my eye, but I guess it's supposed to, right? Again, I don't envy your job here :) I feel you do it pretty darn good, including the mega. "As intended, to the best of our abilities" is the definitive way to go! Good call!
  14. Things about Doom you just found out

    What about a rocket that explodes, but also spawns rockets right before it explodes. A never-ending bomb? Or smoke and extra flames. Change the sprites and call it a poison cloud? Man, I need to get back into Doom hacking! I imagine a very complex combination of spawns of special objects with special properties could create all manners of interesting things. But, beware pure vanilla, that doesn't appreciate targeted objects that disappear too quickly.
  15. Raymoohawk's sprite edits

    @raymoohawk Your sprites are just astonishing and amazing! You employ that *very rare* quality of being able to match sprite size with proper 3d perspective, and perfect shadowing! It's a skill that Adrian and Kevin possess. It's hard to describe, but Doom's lower-res sprites uniquely require special shading on curves, and shading of a proper size and position. I can't quite describe it, but I know it when I see it! Can anyone else help elaborate? Anyway, unbelievable. Great job!