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

2187 profile views
  1. kb1

    The Definitive Guide to Visplanes

    @Anarkavre Nice, straight-forward description, and interesting post! Thanks for taking the time to write this.
  2. 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.
  3. 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.)
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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?
  12. 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.
  13. That smiley face means "I'd be glad to", right?
  14. 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.-
  15. riched20.dll - Isn't that a DLL that supports the creation of Windows Rich Textboxes? RichText boxes allow the display/editing of multi-color, multi-font text in a single textbox, with lots of the standard editing features, like alignment, tabstops, numbered and bulleted lines, etc. Could GZDoom's "crash window" be using a RichText box while showing the crash report? I wouldn't think that would be Linux/Mac-friendly, though... Now, it doesn't necessarily mean much that that .DLL is being reported. *Any* callback to/from that module, or another module that calls it could cause a crash to occur in that DLL, through no fault of its own. You should try to obtain and post the entire call stack - there's more happening than that DLL. And, yes, being on an old version is problematic. At the very least, you should determine which versions exhibit the bug, to at least provide some clue where to begin looking.