Jump to content


  • Content count

  • Joined

  • Last visited

Everything posted by kb1

  1. 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 :)
  2. 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.
  3. @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!
  4. 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.
  5. 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!
  6. Complete /idgames Archive Downloads

    Very generous! I might be able to cough up some support. If you get to that stage, send me a PM, if you would.
  7. Nice find, and nice fix Evolution! Your fix looks right, and the original looks so much like a sprite offset problem (even though it's not), that I think everyone who likes the "Minor Sprite Fixing Project" will approve this.
  8. This crash...

    The EIP register holds the current address where the code was when it crashed. If you look at the listed modules, it's a safe bet that the crash occurred in zandronum.exe, not the OS, and not a driver. Unless the OP is running the CPU too far overclocked, or the CPU or memory is damaged, the real most likely cause is that zandronum.exe used an uninitialized pointer, and tried to write to the pointed-to address, which is why the first line of the dump reads: "Code: C0000005 (Access Violation - tried to write address 00000044)" Pass that crash dump to the port devs, an make sure to include a list of the files you were using when it crashed, and the exact way you started the port (launcher, shortcut, command-line, etc). They should be able to help.
  9. This crash...

    It looks like the crash occurred in Zandronium itself, vs. the OS, or a driver. The crash occurs at 0x0035b18e. Depending on how Zandronium waas compiled, you might be able to start Zandronium in a debugger, set EIP to 0x0035b18e, and see which function caused the crash. But the source port authors definitely can do this.
  10. spectral pain elementals

    Exactly! As an alternative, you could instead replace the Wolfenstein guys, as they're not used much. Then you could still have cacos.
  11. Complete /idgames Archive Downloads

    Ah, I didn't think of that. To the naysayers: When a file is transmitted via FTP (or any other single file move/copy), your OS has to, at a minimum, write a directory entry to the drive, write the file contents to a different part of the drive, then update the directory entry with file info. Point is, single file moves can be slow, especially with tons of teeny files (like most zipped wads, text files, etc.). Downloading a single large zipped file is *a lot* faster. So, if you've never downloaded the archive, the fastest method is to download savagegrant's zips, and *then* update it via FTP. However, if you already have most of the archive, just use FTP to keep it current. Easy Peasy. That's why these zips are a good thing, on top of the fact that there's safety in having more than one copy around. Thanks, savagegrant!
  12. Something you can do about overrunning the blockmap limit: Imagine drawing a box around your map that just barely doesn't touch any lines on your map. Calling it a bounding box, cause it shows the horizontal and vertical bounds of your map. Making the entire width and height of your map smaller (so this imaginary bounding box can be smaller) will reduce the blockmap requirements. ZokumBSP is an awesome tool that works hard to reduce these requirements too. But it can only do so much. Good luck!
  13. Post Your Doom Picture (Part 2)

    I'm not the best player by far, but I'd love to help test! I'm sure levels like that take a long time to build. x32: an ambitious project! The best of luck to you! That's what I thought. But they look really good, so I was wondering if they were going to become actual releases, instead of private WADs. There's a great many nice WADs in this thread, but those caught my eye.
  14. Flaws in Doom 16'

    Here's a take from a guy who's never played the game (but I've seen and read a lot, in this thread and others). From everything I've heard so far, there's 2 themes that continue to appear throughout all the discussions: Performance Management - Preventing you from backtracking, and linear design go hand in hand to limit memory and performance problems. Once you're locked out from going backwards, the game can toss all that map data from the locked out area. Linear design ensures that you will only encounter monsters in a spoon-fed fashion. Disappearing corpses also helps with memory and performance. The game engine is probably jumping through hoops behind the scenes, swapping old data out of cache, and pulling new data in for the area you're about to cover. It's micro-managed and controlled to allow the frame rate to stay up. This will continue to be true for games, until computers and graphics cards become more powerful. Appeasement vs. Focused Design - From what I've heard and seen, it sounds like the developers tried to appease a lot of people, vs. concentrating on a specific theme and goal. Obviously they wanted to appease the Doom fans somewhat, so they threw a lot of superficial energy to that effect. Instead of making a game that *feels* Doomy, they made the monsters similar looking; they added old Doom levels; they made DoomGuy a badass. It's hard to explain. To me, it feels like they scoured the Doom wiki and Doomworld, looking for ideas. They seemed to take a lot of inspiration from Brutal Doom, because it occurs in a lot of forum searches. It seems like they did this, without actually *being* Doom fans themselves. Instead of actually having their own vision, it seems like they just sprinkled in some of this, and some of that, until they had enough *stuff* to plop into an otherwise generic experience. It's kinda like taking a everything-but-anchovies pizza, adding peanut butter and jelly, hamburger lettuce tomato ketchup, crablegs shrimp mussels, and chocolate and ice cream, and mixing it all up and calling it dinner. (maybe that's a bit too harsh, but I hope I made my point). Note: These opinions come from what I've read here and in other forums, and from what I've seen from Youtube videos of Doom'16 gameplay. All in all, it's massively impressive. And, it may seem to try to appease a lot of people, but they obviously put a ton of effort into it. It's a masterpiece, despite some flaws here and there.
  15. Complete /idgames Archive Downloads

    @savagegrant Well, I happen to appreciate it. Nothing wrong with an easy-to-grab snapshot. I've got to ask for something though - 2 things, actually: Any chance you can zip up all the files for one complete massive download? Honestly that would be the easiest, most convenient method. Mediafire likes to be slightly difficult and rude, and I'd like the whole archive, even if you just zip the (23?) files you linked into one massive zip. Please? Suggestion: I'd suggest always naming such files by including the date you extracted them, like 2018-03-13_idStuff1.zip. It's best to use yyyy-mm-dd date format, and placing that at the beginning of the name. That forces proper sort order by date, then by type. And, it's good because the archive changes each day: Using the date in the name suggests "This is the idStuff1 archive as of 2018-03-13". It also avoids reliance on the file's date/time stamp, which can get changed at times you might not expect. Anyway, there's nothing wrong with having another backup, and some people will find this method to be easier. Re-zipping zip files with a better compressor like 7-zip *may* make the archive a little bit smaller. Usually it makes it a little bit bigger :) Glaice's idea would do a lot better - the archive contains a lot of uncompressed content, like text files, which compress really well. But it still ain't gonna be much better - maybe 10% or so. The *real* benefit of compressing everything is that you end up with a single file, which speed up lots of stuff. FTP is great, but downloading a single compressed file and locally decompressing it is *way* faster, almost always. The exception, of course is if you already have most of the archive, and, as Grazza suggests, your FTP program can do differentials and download and update changes. Even just pulling new files based on date is better than nothing, and it would get all new stuff, but miss deleted archive entries. So, maybe for people without any files, the plan is to use the zips to populate local storage, and then set up an FTP client to run every week or so for updates. This is probably the fastest way to start from scratch, making the zip files a very useful resource! Thanks, savagegrant!
  16. Ultimate Doom tree driven into ground

    @wesleyjohnson Did you read your PMs? Have you given this any more thought? EDIT: We have since discussed this in detail. I'll be releasing the SyncDebug system soon, for anyone that's interested.
  17. Post Your Doom Picture (Part 2)

    Oh, my! These are all unbelievable and beautiful. I am jealous that I cannot play them now! Each of you, please tell me that these will be released, and, if so, what are the names (so I can store them in my "WADs to play" list, and so I can search for and follow a not-yet-written release thread). Amazing. I'd like to see the 3d skulls rise up from the ground when you enter the room, maybe. Conveyors in the eyes could carry and spit out stuff, like health, or imps, or even some gibs! The first screens look like a seriously evil temple. Gorgeous! In the next screenshot, I love the trees and the mushrooms. And that tiny golden elephant - what's that about? Good stuff! And the E4-like map: It's got that Classic Doom look and feel! Beautiful!
  18. Things about Doom you just found out

    Nice find on the title screen background! I actually enjoyed Doom 3, but I think that's because I was too busy checking out the graphics. I had a friend over, and we would switch playing SP, and he was getting annoyed because I was spending too much time looking at the floor, checking out the shadows, etc. It started out great, but, yes, the rooms did start to look very same-y, and dark. The hell levels were a much needed surprise, and they were gorgeous. I think they should have added more resources (walls, floors, etc.) and made some marble rooms like Doom and Doom II, some more outside stuff (with a proper suit), caves, water blood and slime, and some more abstract stuff. But I suppose Doom 3 levels are very difficult to make, and they were probably pressured to finish. It's a shame - there was so much potential.
  19. The downward sprial (WAD)

    @Nine Inch Heels Yep, I agree - that's exactly what it looks like. I don't know why it has to be that way. Maybe I said too much. I got angry, because the subject matter is serious, and it sounded like a cry for help, yet when help was offered, it was not received congruently - things didn't seem to add up, maybe due to my failure to understand - I'll accept that. I've asked for, and would welcome a PM. And, I've done what I can do. I made an assessment of the situation, and voiced it. I also admitted that I could be wrong (and I hope I was). Finally, I've offered to listen to any honest attempt to communicate, PM or whatever. I feel that I've made my intentions clear, and that I'm willing to try to understand, and provide any insight I may have. This is as much as I can do now, and the ball is now in your court, SayWhatOneMoreTime. I will respect your privacy, if you choose to PM me.
  20. Aarrrg! That's right. Does anyone remember the TRS-80 Model 1? It stored programs on cassette at 500 baud (bits/second). That's about 64 bytes/second. You preyed that there wasn't a bad spot on the tape. It took over 10 minutes to load a 16K program. We're spoiled nowadays. At least it wasn't punch cards...
  21. It amazes me just how much sprite reuse was done. I must also admit that it worked on me - I never noticed any of it. Adrian and Kevin are master pixel pushers! I think, in general, making any sprite work look good when resized in a game like Doom takes a specialized skill above just being able to draw. There's moire patterns and aliasing that must be avoided, all the while trying to provide a feel for depth and light shadowing. And, especially in low-res Doom, there's not a lot of pixels to work with. Impressive, indeed.
  22. Site and/or forum bugs or things not working

    Someone fixed the colors in C-formatted code tags that had become hard to read - thank you!
  23. NASTY: Not A Sourceport, Thank You (Alpha 2)

    Holy Moly - very nice! Suggestion: Randomly rotate the view upon player death along the depth axis to simulate falling on your ass when dying. Or turn the view downward when falling off a tall ledge. There's lots of possibilities. Very cool.
  24. @Jon Absolutely I will be asking for your help - I'm going to need it. And we can include your patches! I made a huge, ugly list of every suggestion in this thread, the other thread, and from various other sources. We will need to decide on many things in the draft, including new actions such as those you built. I am going to need help organizing those decisions, and organizing spreadsheets of various new stuff. I am still bogged down with work. I'm going to release this draft, and then switch over to other priorities in my life (I am juggling time and projects). So, yes, if you are willing...be careful what you ask for...you just might get it :) By the way, I did make some progress this weekend, so I'm moving forward. More on my progress later.
  25. Recent threads have revived discussion on the current state of compatibility between source ports that strive for limit removal and mod capability enhancement. Currently, the best a map author can hope for, in terms of modding capability, that can be expected to run in most all source ports, is the vanilla format, plus the additions afforded by Boom and MBF. After the release of Boom and MBF, port authors began adding features that, for whatever reasons, were not accepted and adopted by all source devs. Of course, this forces map authors to choose a port to mod for, if they want those extra capabilities, and it forces players to use that port to play these maps. There will always be advanced, port-specific features, and that's a good thing. It promotes continuous advancement. But, it would be nice if port devs could add some of those features in a standard way that all ports could take advantage of. This thread is to serve as a place where we can discuss a possible update to this standard, beginning with a narrow focus on which features can be readily added, without conflicting with each port's philosophy and direction. This idea has been attempted before, and failed, I think because the proposals did not encompass all possibilities, or did not take into account some capabilities of this port or that. Because of this, I suggest some ground rules: Start small - For this first phase, we should only include things that all ports can use. For example, 3D floors is out, as it requires drastic changes to the renderer, and game logic. But a replacement for, say 242: Boom water/prop transfer is a good place to start Future Extensibility - There should be no updates that prevent the ability to expand capabilities in the future. Use existing port-specific capabilities wherever possible - The new standard should leverage on the existing capabilities afforded by advanced ports such as ZDoom, Eternity, Legacy, Edge, Vavoom, etc. No need to re-invent the wheel. But we may have to modify how they are accessed, to fit into a global standard. Research each addition - We don't want to, for example, use a linedef number that a source port is already using. Boom took the bulk of linedef numbers, leaving a small subset. We should compile lists of unique scarce resources per port, to see what's available Dev Review - For this to succeed, the devs need to be involved. The port devs intimately know how their port works, and they have plenty of good ideas to contribute. We must collaborate like never before, if this thing is to get off the ground. Eventually, after converging on what this update should entail, these ideas can be compiled into a specification, which will be submitted for modification/approval. That can, in turn, be turned into a source code module, which, not unlike Boom, can be dropped into a project with minimal changes, improving the chances of wide adoption. But, we're nowhere near there yet. This thread can be a place for new ideas to be included in that standard. Please restrict replies to discussing ideas for an upgrade to our current standard, if possible.