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


  • Content count

  • Joined

  • Last visited

Posts posted by SaladBadger

  1. interestingly enough cp_cloak was included with the Source Filmmaker a year or two before the steampipe update added it to TF2 proper. In the SFM side of things its joined by another map named just "Cloak" that's a simple 1 flag CTF map. There's also a dev-textured version of 2fort with the same layout as the TFC version of 2fort strangely.

  2. re: room over room: I really need to stop being lazy with my map convertor (or just try to fiddle with some ancient version of yadex...) but I get the impression that some of the older portal based Doom alphas (someone get me off this doom alpha wild ride, please) can do room-over-room. They're "portal" based renderers, which consider which sectors to draw by a recursive algorithm looking into two-sided lines, and regions drawn are clipped to the bounds of the specific line you're looking into. If you have a sector over another sector, since the portals looking into both sectors cannot exist in the same region of the screen, there should be no interference from the overlapping sectors. There's still problems with no z-clipping on things, and it'll be like the limitations you get in the earlier build games like Duke3D where you can't see both the upper and lower part of the stacked sectors at the same time, but the renderer should support it.

  3. some of the games I've played the most this year were published this year (though one is a port of a game originally published a few years ago), so I can't say I agree. Yes, AAA is pretty fucked, when games get this big and involved they become huge financial risks, and CP2077 can show how that investment can backfire... But there's still plenty of good shit, even some from big development studios.

  4. I really have no idea what you're trying to prove anymore, all these connections are waaaaaaaay too vague to be interesting. Shiny metal isn't exactly a rare thing in a sci-fi setting, and the gradients on all the metal textures are uniform enough to strongly suggest they've been drawn. There's very little reason to photosource it, and if it was photosourced, they would have photosourced it from an actual metal source rather than a toy painted a shiny silver paint

  5. I still love Descent's cloaking device, and it's probably my invisibility powerup, and alongside Blood's is one of the few times in a game where I'm actually happy if I see an invisibility powerup.


    There's smoke and mirrors to it, it is really hard to make AI respond to invisibility entirely convincingly, so there's oddities like the AI knowing exactly when you uncloaked even if they can't see it, but while the cloaking device is running, enemies will only respond to sound and will try to fire at the point where you last made a sound. It also cancels out the effects of homing missiles, which alone would be worth the price of admission, but being able to carefully herd monsters accelerates it to my favorite invisibility powerup

  6. only thing i really want to do is actually finish Evil Unleashed in 2021. The work rate for finishing up the demo was promising, but my interests shift between subjects pretty rapidly, so I guess we'll see.


    I suppose my other main goal is to work on better time scheduling to avoid these issues.

  7. Oh yeah, I was going through this thread again and I found a post talking about the source code and how the z-axis was a convenience notation added later down the line:

    in some source code yes, in others no. It all depends on what source code you are referencing in relation to games lifespan. The very early releases of the game never had the source code publicly released as by the time it was released they had already given the game engine an internal overhaul. In the very early versions of source code there was no z axis referenced anywhere. In the later ones closer to when it was publicly released, yes there are z axis referenced, but the z axis referenced isn't even an actual game engine axis. It is a custom variable tied to an advanced algorithm put in for the sake of making referencing easier as well as identifying it's purpose easier. It is easier to look at a variable labeled z axis and understand what is purpose is than an entire algorithm. Also trims the code up so it performs a little better. However despite having this intricate rendering algorithm, none of the games logic runs based on an actual z axis, just a complex algorithm that's main goal is to create an optical illusion


    This has been thoroughly debunked for every release version of Doom, but after spending a couple of weeks of my life working on reverse engineering and then reimplementing the 0.5 alpha, I can confirm that this wasn't true even as far back as the alphas, and I have the symbol tables to back me up. All things have a z coordinate, this Z coordinate is absolute instead of relative to a sector's floor or something like that, players have Z momentum, and so on. The Z coordinate for things is meaningful and is used to control where they render. The one downside is that since it's alpha unfinished code, there is no Z movement at all, the movement code just glues your thing to the floor of a particular sector (though platforms in 0.5 do have to explicitly move things). But Z positioning and movement was a consideration as early as 0.3.

  8. Okay, sure, at a conceptual level, we can argue that the projectile has no Z velocity. it's not relevant for gameplay purposes how it's implemented, but that it exists somehow. (even then, though, an implementation not considering Z velocity would require a lot more work to simulate) But at an implementation level, this simply isn't true. The same code that makes an imp fireball soar through the air is the same code that makes the player (or dead monster) fall off a cliff, or a player or monster blasted by an archvile soar into the air. All of these interactions involve proper Z velocity, and the projectile indeed has Z velocity, just calculated differently than how, say, Quake would calculate it.

  9. I think it's entirely too early to tell (and you're not going to get company secrets by pinging a id software staffer, btw). Doom is currently their priority, and they've been on it for about a decade in terms of development time, but id was making games called "Quake" at one point for a long period too. It's also been mentioned the Ancient Gods duology is going to be "the end of the Doom Slayer's arc", but anything on that is currently baseless speculation.


    It's worth noting that making the same game over and over is part of what resulted in the corporate infighting and eventual departure of many old id employees.

  10. my way of looking at it is, any game is going to have approximations. In a game where motion is typically constrained to the XY plane, with much less control over the Z axis, approximations favoring the XY plane are going to be more common. We have things like Quake's reality bending steps, in a game with otherwise very rigorous 3D physics. I am fully aware you mentioned that this doesn't make the game not a 3D engine, but I also don't really understand the intention here, at least why it's important enough to bump a 2 year old thread over it I mean it's important to understand from a gameplay perspective at least

  11. the imp projectile calculates a speed in the x/y plane and then adds enough z velocity to make it reach the correct Z height once it reaches the correct XY position. It has a full 3D position and velocity vector. You can literally do this in any 3D game engine. I could go do it in UE4 right now, and no one questions that UE4 is a 3D engine?


    Likewise, steps are also a bit of a bad example. In games like Quake, where we're not questioning their 3D engine status, stairs also instantly change your Z height. Ramps don't, since the physics are more involved, but stairs have absolutely no effect on your XY plane velocity and you traverse them instantly. I'm less familiar with what more modern game engines tend to do here.

  12. I think I've played Descent long enough that I'm completely used to it's bullshit. Even the sluggish turning isn't too bad for me (though maybe I should finally get a good flight stick for constant turning...) A zero life loss run on even Hotshot is out of my grasp, but I can beat the game pretty effectively on Ace at this point. The later skills are odd because while you're much more likely to die, you're almost always getting at least one extra life every level simply due to the skill level based modifier applied at the end of each level.


    It kinda reminds me of an early arcade game, though much more generous with the 1-ups.

  13. Licensees of the engine have full reign over the engine and can transform it how they want. All id ever did with the console officially was create the simple one. I wouldn't be surprised if the developers of MOH:AA spent time creating a new UI library and they decided to make the console use it for convenience. It was in style, Unreal Tournament did it, the steam versions of HL did it.

  14. I made a replica of romero's map a while back, so I could probably convert it to alpha format and look at it. Sadly a lot of the maps shown in screenshots are somewhere in between the various alpha releases we have (which is annoying, since the screenshot set that shows one of the first ever maps made with the sector iteration algorithm has a lot of flats that are not present anywhere in any released data set)


    From looking at the images though, it's possible to see where the problems lie. The ring structure would be stepped into by either 2 or 3 portals based on how you're looking at it. Based on your view angle, the portals within the rings would be stepped into multiple times (IE, if you were staring into the ring dead on from a cardinal direction, I could see there being five iterations into the second step depending on perspective). Stepping into a sector multiple times isn't always too bad, since lines that weren't clipped by the left/right bounds should be cached, but any that were rejected in a previous step will have to be reprojected again.


    EDIT: Just looking at E1M8 in the Alpha confirms some of the things I was thinking. Indeed, the innermost steps are entered 5 times each.


  15. doom_05_renderer_demo.gif.3e5b3d1e3642c9fa8dd980d44b1efdbc.gif

    Trying some ways to visualize the recursive rendering for the Article I Want to Write On The Alpha Doom Renderer. I think this works out quite nicely, and indicates some of the fun aspects of the recursive stepping problems John Romero brought up, like how sector 10 is stepped into twice and sector 1 is stepped into 4 times in this view.


    The lines that appear before each iteration are the clipping bounds for that pass.

  16. it was mentioned the last time this came up, but giving the projectile enough health to survive a hit doesn't work because whatever shoots the projectile first will claim ownership of the projectile because of the reused target field. Maybe you can implement maes idea of capturing revenant projectiles as "shields", but that's probably not the intended idea here. It's generally safest to just give them 1 HP so they die instantly.

  17. web browsers aren't the only things capable of downloading from a FTP server. Specialized FTP clients like Filezilla are still a thing if you need to download from a FTP server. Browsers are just canning it because it's not a common use for them anymore.


    FTP itself is a bit of a dinosaur protocol, with the web increasingly pushing for "secure by default" and FTP offering no security features whatsoever. It's not really a huge deal for a little Doom archive, but with the overall support for it plummeting, that bridge will have to be crossed at some point.