kb1

Members
  • Content count

    1244
  • Joined

  • Last visited

Community Reputation

5 Neutral

2 Followers

About kb1

  • Rank
    Ask me about my source port
  1. Ok, no big deal, you said it. But, do yourself a favor, and check him out - do some research. Start with perfectpitchrob's post above. Chuck Berry rocked...when there was no such thing :)
  2. Some ports have a special case for shooting Romero's head when infinite height checks have been turned off, cause height checks with explosions can make it more difficult to inflict damage as well. This is the one case where infinite height is undeniably a good thing :)
  3. Yeah, that's nice, clean, fast code there. If there's a bottleneck, that ain't it :)
  4. Oh, you replaced PrBoom's process, not ZDoom's. Got ya. Also, now I understand what you meant about the visual glitches: They occur when using the software filters. Thanks for clearing that up (figuratively and literally :)
  5. Not sure about the HOM, but the rest of it sounds like a reasonable result. It can be thought of as a convenient way to handle mistakes without simply failing to render, so any approach lets the game continue is better than nothing. Oh, you replaced PrBoom's process, not ZDoom's. Got ya. Also, now I understand what you meant about the visual glitches: They occur when using the software filters. Thanks for clearing that up (figuratively and literally :) I must say: The forum software is pretty darn powerful. The Multi-Quote function is awesome! It surprises me how easy it is to do. This could have been a very tricky thing to try to get a web page to do, but the forum software handles the tagging of multiple posts very gracefully.
  6. Yep, works like a champ! I went back and edited my post. No debate. A few posts back, sirjuddington said that his test of the CRC32 hash read was slow. If you're calling a library function to do the hashing, maybe try my included CRC32 code vs. a library call - it should blow away MD5, in theory, anyway. As far as hashing the whole WAD, it really shouldn't be very slow on a semi-modern box, unless the I/O is being done one byte at a time. If each lump is read in whole, or even in chunks of, say, 64K or so, a whole WAD should take about as much time as it takes to copy the WAD to another folder. The bonus here is that, afterwards, the entire WAD should be in disk cache memory, so manipulating it in the editor should be fast. I'm not sure about Slade, but some editors read the lump contents, in an attempt to auto-categorize the lump, so the hashing could be done during that phase. Alternately, you could do the lump read/hash in the background, after displaying the contents, under the assumption that it will take the user a couple of seconds to begin editing anyway. This could be done to hide the delay caused by the lump read, though it must be done carefully. Unread lumps must be locked until they've been read. And, if any hashes are inconsistent, you'll probably want to tell the user and/or correct the lumps before allowing the lumps to be edited. And, finally, you may want to paint the lump list in two passes: Pass 1 shows the standard info, and pass 2 shows long names, pseudo folders (if you're supporting those features), and the other new fields (create date, modify date, author, etc).
  7. The YT video sounds nice! I wish it had a "side-by-side" (one after the other) comparison to really hear the difference. Is this something for Vanilla/DOS, or can it apply to modern ports? I guess what I'm asking is if modern ports can take advantage of your files.
  8. (Woah, big bump). CRC32 is blindingly fast when optimized: First, add the table (which can be generated vs. this list), and initialize the CRC stream. Then, add bytes, ints, or strings to the stream. (Could probably be optimized a bit more...) And, finally, get the final CRC32 value: Using this last function to get the value is required, because the standard required bit flip is postponed until you're ready for the final value. This allows the streaming to be a bit faster. So, for each byte, we've got a right shift, a bitwise AND, 2 XORs, and a table lookup, which, hopefully ends up in a few cache lines. This is so fast that the bottleneck is, most probably in the disk I/O involved in reading the lumps, not the hash function. You could get "slick" and do the hashing in the background, in a thread, or in a pseudo-thread (in a timer, read a few entries between mouse/keyboard clicks), but that gets tricky. MD5 is a bit more complex, and a bit slower, but still very fast, as it only does primitive logic transformations too (and, or, xor, bit-shift, add, etc.) The performance difference is probably not even noticeable, compared to the lump-read time. @DaniJ: I know it's been a long time, but I was re-reading the last few pages of this thread, and I feel that I had a less-than-desirable attitude towards your concerns. In fact, I don't think I ever really understood what your concerns were. If you want to explain, I'd be interested to try to understand, but I don't want to fill up this thread. Maybe, if you wish, send me a PM - I'd be interested to understand better. I am curious if any more progress has been made? Just looking for a status report, please :) EDIT: Oops, I thought the code windows would be collapsible. What tag should I use? (You know, a plus sign that you click which expands everything within tags to toggle visibility? RE-EDIT: Woah, it works, even through an edit. And, it's nice: Being able to choose "C-style" formatting is awesome!
  9. Thanks for noticing Wiggle Fix! Sorry it detracted from your texture compositor fixes! Honestly, I got lost on your description of the algorithm, at the "weird 'copy patch pixels down and right'" part. I assume that this is ZDoom's Medusa Effect fix for using transparently patched textures on 2S walls, right? If I try to understand, ZDoom takes the patches, renders all of them into a texture buffer, and then it has either a solid texture, or a texture with some holes in it. If the texture has holes, ZDoom goes to the first hole, and copies the solid pixel from either above or to the left, filling in the hole. It then repeats this process until the texture is solid? Is that what's happening? But you're claiming that this process could miss some holes, so you added the ability to scavenge pixels from below and to the right, as well as above and to the left, thereby ensuring that all holes are filled? Is this what you are describing? Yes, I think GL textures need to be solid, even if one of the colors is designated as transparent. More accurately, I think the fourth byte - the alpha byte is used as an alpha channel. I need to check out the source, I guess, cause, from this description, it seems like it's doing more work than necessary. It seems like it could simply start with a cleared buffer (0x00), render all the patches, then generate an in-memory patch representing a solid texture with the holes filled in with black. Maybe it is doing exactly that, and I just can't tell. But the down/right stuff feels like an "over-engineered" solution, with all due respect. But, that's hard to believe. I think it's more likely that I'm simply missing part of the picture. And, if it works, it works, right? :) So, one question: When will you get a black texture, and when will you get a checkerboard pattern in ZDoom?
  10. It's kinda a difficult question to answer. To me, the movement, the weapons, and the monsters make it Doom as much as the architecture does. Nice screenshots (all of them), by the way!
  11. Kreimeier made a big mess out of the source. You can guess how Doom code originally was organized by looking at the Heretic and Hexen source. The filenames and their contents make more sense in those releases, and the code is arguably more organized. I would love to see Doom in its original state before Kreimeier "cleaned it up". It would be a neat project to try to restore the source to its original state using the Heretic/Hexen releases as models, and including the DMX release.
  12. Could the black output be an artifact of the texture compositor? Like it zeros out its buffer before loading patches, PNGs, turning flats into walls, etc? (I really need to brush up on the various port's progress).
  13. Printz, This is massively impressive! Your bots have very intellegent, human-like movements and abilities - great job! You'd almost have to dumb them down to use them as coop helpers! The only indication I saw that they were bots was when the bot would ride up a lift and aim at a not-yet-visible monster. But that could be equated to a player that has played the level before. When I get some time, I'd love to check out your decision tree and how it resolves conflicts. Keep up the good work!
  14. By also adding the functionality to Eternity, you are effectively condoning the behavior (not a criticism - I understand and sympathize with your reasoning). You could go other ways with it: Menu/command-line/console option, defaulted to checkerboard pattern, put back the error code, or maybe soften it (display a bug in the console). Arguably, the black texture is more presentable than the checkerboard pattern, for people that just want to play the damn wad. Question: Does this also affect missing patches? Do they also get painted black, or checkerboard, or just HOM? I would think those should show checkerboard, as it can only occur as a mistake, whereby a map author could conceivably purposefully make a 0-patch texture.
  15. Holy crap, auto refresh?!! That I like.