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

kb1

Members
  • Content count

    2670
  • Joined

  • Last visited

Everything posted by kb1

  1. I haven't played with this yet, but I have to say that this is a brilliant, impressive, ambitious idea! One question about your implementation: Do you handle multiple simultaneous requests serially, or are you multithreading (running multiple copies of your port simultaneously?!!) Very, very cool idea!
  2. kb1

    So, John Romero is teasing a thing

    Just pre-ordered the Megabox!
  3. kb1

    SIGIL - New Romero megawad for Feb 2019

    Port devs can always add some legitimacy with a new episode menu choice, support for E5Mx, if needed, built-in automap level names and the like. Or, it'll be fine as simply a PWAD. A MAPINFO lump, or DeHacked lump/file would suffice as well... perhaps this would be a slightly less "clean" approach, but it'd be better than nothing. I'd love to see a new intermission pic, maybe with a set of progression pics, like the Tower. The community maybe should contact John and ask about these subjects, to preempt a "sanctioned" setup. Maybe an artist could assist with some graphics, and a port dev, for the map name stuff. I rest my case.
  4. kb1

    SIGIL - New Romero megawad for Feb 2019

    Thank God my life doesn't suck this bad.That's some sad shit, right there. And, if you don't totally agree, you prove my point.
  5. kb1

    How should I contribute to the Doom community?

    In the grand scheme of things, the truth is that no one *really* cares if your map is not the best map ever, or even close. Being embarrassed is largely in your own head. Actually, there are so many Doom fans that, if you gave it half an effort, someone will most likely appreciate your style. I understand the desire to contribute. There are tons of things you can do. Make maps, review maps, draw and build resources like textures/flats/monsters. You could make songs. Even helping newcomers with installing and running Doom, or providing info on mapping techniques is contributing. Leaving constructive criticism on others' maps is contributing.
  6. kb1

    So, John Romero is teasing a thing

    No, no. Romero is who made the game fun. 3D engine - big woop, without the awesome game being hosted behind it. You can't pick it apart and judge each component, because it's nothing without the engine, the sound effects, the music, the art, and the gameplay. The whole thing crumbles without every piece of it. Romero earned his stripes, as did all of the key members of id. How quickly we forget. What I want to know is: Will the universe let Romero do what he does best?
  7. kb1

    Chocolate Doom

    Ok, well this sounds like it might be possible to, at least, make the behavior predictable, and done in a clean, consistent, sensible manner. As is often the case, identifying *what* the desired behavior is is at least half the battle :)
  8. kb1

    Level Progress Diagrams – PDF POSTER READY

    This is really something special! I have difficulties with spatial navigation, in general, so, for me, this is a very cool way to understand map flow in a Doom goal-related sense, without needing the actual map itself. Essentially, that's what this is, for me: A way to visualize level progression, highly distilled. I wish there was some way to import one of these diagrams into Doom's automap, and show a pointer where DoomGuy currently is in the diagram, and maybe even grey-out areas that have already been visited. Do you think it's possible? (Just an idea) I'm going to have to play through the IWADs again, while checking out the diagrams. I *do* think seeing the diagram on the automap, or via a different keystroke would be awesome. Great job - this was a lot of work, I can tell. Thanks for this.
  9. kb1

    EXE hacking

    @xttl: Thanks! For some reason, your last post really explains it in a way I can more easily understand. I know writing that post (and the posts before it) was a lot of work, and I appreciate it. This is a really neat system. I really want to write a program that breaks down the structure of these types of EXEs, in a way that easily explains all of the runtime relocations, and maybe provides a way to streamline hacks like the work that you're doing. Your process provides a method to bypass the need for most of that, but, as you said, the EXE format is over-complicated, and I'd really want a better understanding of it. Speaking of which, I am going to need to study what you've written and done a lot more, before I can claim to really understand it on a deep level, but, from what I've read so far, this is very slick, man. Who says you aren't a Hacking Wizard? :) @xttl and @Quasar : Your posts are always interesting, and you're doing very cool stuff! Quasar deserves some credit here too. The beta is a really neat piece of history, and the work you guys have done are really turning it into a new, fully playable game, which is fascinating! Thank you both.
  10. kb1

    EXE hacking

    @xttl Let me see if I can understand your difficulties and your system: Pre-patching the exe if difficult, except for tiny patches: Since you don't know where the OS will relocate the code, you cannot use long jumps - all jumps must be relative, and therefore, nearby, making it impossible to add large functions, or subroutines called absolutely. Patching at runtime via Stage2.bin give you absolute addresses, but you still must figure out where the loader put the Doom code. If you can get the Doom code to call your patch, you can pop the return address off the stack, and determine where the caller is, but, to get the caller to call your patch, you need to know where the caller is. Catch-22! You said that when stage2.bin starts, it has the location of the Doom code - how do you accomplish this? You also said that upon stage2.bin running, EDX contains the relocation offset for game code EBX contains it for game data Can all game code be directly referenced as an offset of EDX? I thought there were lots of relocation entries, perhaps one for every Doom module. Can EDX be used to find all game code? If so, that's beautiful, and it makes much more sense to patch post-relocation. So, basically, you patched the exe to get it to load stage2.bin, then you pop (and then re-push) the return address off the stack and place the address in EDX, and, finally you call stage2.bin which returns to the Doom code you patched. Is this what you're doing? If so, sounds like a nice system, indeed!
  11. kb1

    Chocolate Doom

    If DOSBox + Vanilla behavior is different than pure vanilla behavior, that almost has to be due to a timing difference, and it means that there is no reliable way to get the two to match. I would bet that you'd get different results with vanilla on a 486 vs. vanilla on a much faster CPU as well. There's a tiny chance that the difference is due to a difference in a native mouse driver, vs. the speed at which DOSBox polls Window's mouse and forwards the info into a pseudo DOS interrupt. What I mean is, the whole purpose of DOSBox is to emulate DOS as best as possible. If you can't even get Doom in DOSBox to match Doom in DOS, what chance is there for a source port? You might get the source port to match vanilla running on a certain CPU, but not in every case. So if you cannot get a source port to match vanilla, you'd probably be better off getting the source port to, at least, work the most favorable way. So, what do the speed runners want, exactly?
  12. kb1

    EXE hacking

    Ok, this has got to be the coolest, most bad-ass post I've seen in a long time! I'm dying to check out what your patcher is doing, and how you're getting everything to work, despite the awful run-time relocation stuff to deal with. Great stuff - I'm massively impressed! Cacoaward!!
  13. kb1

    Chocolate Doom

    You know, DOS (and Windows) would queue up and repeat keypresses that were held down for a small length of time. Maybe it's that simple: Maybe in the DOs days, with slower computers, DOS could queue up more keypresses before the game gets to the screen wipe, but on faster computers, there's just not enough keypresses in the buffer for the game to fetch, before the screen wipe. If that's true, maybe Chocolate could detect a key being held down, and fill the 8 tics with it, as if the buffer was full of that keypress. Man, I really need to research this - what an interesting issue! What do you all think? Could it be that simple?
  14. kb1

    Best Dummy texture wad?

    How many different dummy textures do you use? Should be easy enough to build something like that, if there's not too many.
  15. kb1

    k8VaVoom: no good thing ever dies!

    Ah, ok. Interesting. 90 fps is a curious choice, for me. It's not easily divisible by 35, and it doesn't match most monitors I've seen. But, of course, since it's over 35, it's ok. I suppose making it a number not easily divisible by 35 forces the "free stepping" stuff to do its thing on every frame, huh? You're right, I probably got a lot of things wrong about k8VaVoom: it's obviously a very advanced engine that I'd really like to study!
  16. kb1

    TeamTNT

    Wow, thanks! Unfortunately, no source, but the executable's there! By the way, I haven't forgotten about you. I'm just too damn busy right now. Soon, I hope.
  17. You're most welcome, Doomkid - glad to help! I was really hoping that it didn't read like chicken scratch :) It's really a bizarre concept: tools that are routinely used to hack a spread of similar game executables... it's almost doing the unthinkable, and getting away with it. I've been toying around with building a more powerful, updated version for a long time, but I'm nowhere near completion. And, with the availability of ports, and the lack of availability of DOS environments, demand is pretty low, you know? Still, it's fun checking out the old executables, so the next logical step is to hack on them.
  18. kb1

    [WIP] Eviternity - A Boom Format Megawad

    Bunches of 1px. sectors are a bit expensive, performance-wise, but they look great! Because it's a lot of sectors and lines in a small space, it becomes more expensive than a single sector of that general size. But, used sparingly, it shouldn't be that bad. It seems to be worth it, to me, looking at that beautiful screenshot!
  19. kb1

    [v 0 .95] Doom Neural Upscale 2X

    What is amazing is that fact that the data needed to upscale "accurately" simply is not there. The upscale process is a guess at best, because the data describing what's inbetween the pixels is simply non-existent. So, yes, the results are amazing!
  20. kb1

    PBR for Original Doom Textures

    Oh, wow! unbelievable, and gorgeous!
  21. kb1

    Chocolate Doom

    The theory is that if an engine can queue up inputs, and apply them in tics, surely it can store them in the demo. Reading demo bytes is roughly equivalent to reading inputs - these actions should occur at roughly the same point in time, during execution. Stated differently, there are X chances for input, before the 3D screen is visible. Let's call this InputCmdCount. So, if a given engine can queue up InputCmdCount number of cmds before showing the 3D view, a demo recording should also be able to store X cmds, before the 3D screen is visible. Let's call that SaveDemoCmdCount. Likewise, in demo playback, X number of cmds should be able to be applied, before the 3D screen is visible. Let's call that LoadDemoCmdCount. My theory is that, if working properly, InputCmdCount = SaveDemoCmdCount = LoadDemoCmdCount. So, I think the first step is to be able to determine if this statement is true: InputCmdCount = SaveDemoCmdCount = LoadDemoCmdCount. Next, we should determine if Vanilla.InputCmdCount = Chocolate.InputCmdCount, Vanilla.SaveDemoCmdCount = Chocolate.SaveDemoCmdCount, and Vanilla.LoadDemoCmdCount = Chocolate.LoadDemoCmdCount. Finally, all 6 should match. At this stage, from the reported bug above, I cannot claim to know which of the statements I list are not true. Isn't this what we're talking about? And, because it's difficult to debug vanilla, it seems to me that using and verifying demos is a decent way to get tic-level, input command debug information out of the vanilla engine, in a format that can be directly compared to Chocolate. Have I missed something? Yes, the -1 trick might be a way to go. But I'm left with wondering: How does vanilla get away with not needing it, as it's calling the same high-level functions to poll for input, write tic cmds, etc. Sure, the low-level mechanisms for actually gathering the input are different, but the rest of the engine is not supposed to care about that. After studying the initial release, and then all the various ports, the D_DoomLoop function is slightly different in all of them. A lot of silly little bugs get squashed by rewriting some of the goofy global state management flags in and around this function (dont_fuck_with_me, not_to_be_fucked_with, etc.). For example, in my port, I run an extra render loop at the *end* of a level, so you can see the exit switch change state before the level completed screen appears. I also added the second counter that allows the use of the Pause button during demos, without desync. In other words, it seems that there are good reasons to monkey around with the order of steps in that function, and the state management features within and around that function. This seems to be a necessary thing to do in most source ports, so it follows that this function could be a likely culprit for what looks like an "off-by-one" situation, which seems to be what we are dealing with here. (Whew! I hope that made sense.) My only point is that we want Chocolate to do exactly what vanilla does, for normal play, for demos, and for net games. To do that, we need to know: How many tics does vanilla apply, before showing the 3D view? How many tics does Chocolate apply, before showing the 3D view? Why doesn't this issue appear when playing a demo recorded in one engine, and played back in another? or, more simply: How, exactly, do we know that Chocolate's current behavior is wrong? (I need to re-read those posts, to understand exactly how this evidence was derived. I cannot claim to yet have much experience disassembling demo files). If someone has some luck creating a fix, please post your results here. I'm very interested to know more. Thanks.
  22. kb1

    Things about Doom you just found out

    Thanks for the concrete explanation. I think this is another engine bug, for which it would be nice to provide an optional fix for, but the fix would alter gameplay. I'd like to see the vertical component have a random component applied, so the monsters would have a chance vs. having perfect aim. I sure did!
  23. kb1

    Things about Doom you just found out

    There is a bug in Doom with targeting that occurs when a monster and its target are a different heights. I've been on a ledge watching imps below on a platform try to shoot me, and the missiles end up always hitting the wall below me, over and over again. I haven't researched the cause. Might be the inaccurate sine/cosine/tan tables, the fixed-point math, or an honest-to-goodness bug. It's probably a consequence of adding a small offset to the missile's Z-coordinate each tic, causing a compound round-off error. That's my guess. But I don't think that solves your issue. From what you describe, my money is on the spider targeting the baron out of retaliation. @KVELLER I know you say you checked, and I believe you: But, how did you check, exactly? You'd have to debug the game, and check the Spider's .target field at the proper game tic, to know for sure. If this isn't the opening room of the level, can you say for sure that the baron (or something behind him) didn't hit the spider? Why else would the spider fire up there, if you were down below? It doesn't make sense - that just doesn't happen in Doom, as far as I've seen.
  24. kb1

    Who is better?

    I like the idea of the clean ones becoming bloody after taking damage. If that were possible, you'd need a clean version, then a bunch of bloody versions for each monster, for variety.
  25. The beauty of .deh files is that DeHacked provides a layer of compatibility, so, to the .deh author, the executables appear to be the same! In other words, no matter what executable you have, DeHacked will try to apply the effects in the .deh file. The idea is that you distribute your .deh file, and DeHacked applies the .deh changes to whatever executable your mod players are using. This works really well, just as long as DeHacked can identify which .exe is being used.But if it identifies the Doom exe incorrectly, DeHacked's changes will not be applied to actor tables, or frames. Instead, there's a good chance that it will alter executable code itself, resulting in crashes.
×