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

Blzut3

Members
  • Content count

    705
  • Joined

  • Last visited

4 Followers

About Blzut3

  • Rank
    Forum Regular

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Emphasis mine. Careful with your terminology here. Mathematically speaking, there is technically 3D rendering going on, it's just that the projection used has the convenient property of not requiring texture scaling. An axonometric projection does however map 3D space onto a 2D plane just like perspective projection does. The fact that this optimizes down to just layering sprites is irrelevant to if it's 3D or not. So the correct thing to say is "there's no perspective 3D rendering." Which I think most people would agree is "more 3D" than axonometric since it has less visual ambiguity and matches how the real world looks.
  2. It's been awhile since I've played through the game, but I do believe there are a few instances in this game where there is indeed a Z axis (for example I believe there are a few instances of platforms you can be over and under). Axonometric projection is a form of 3D projection, so yes even though it's very cheap to render using 2D hardware it does mean that axonometric games do technically have 3D renderers. So you have a game which has a 3D playsim and 3D renderering, but is obviously not full 3D as we understand it today. How does 2.5D not work to describe this? If being an axonometric game by itself is enough definitely has room for debate just like Wolf3D could be debated to not fall under 2.5D despite being perspective correct. Honestly though unless I'm just too selective on what groups I'm in, I honestly don't see too many people using 2.5D outside of first person shooters. I know some people do, but for the most part there are more specific and equally concise descriptors for these types of games. If we look at player movements only, wouldn't you be proposing that a game like Space Invaders is a 1D game? You also say to look at "enemy movements" and there's places in Zaxxon where they clearly move in along all three axes (36:30 in the video you link to name one place) even if the player is limited to only directly controlling two axes. I really don't think you're going to get consistently satisfactory results by just looking at one aspect of a game be it play sim or rendering.
  3. Mostly because I felt like writing this. I understand that you probably agree with at least some of the following since you say "when in fact the mechanics of the projection are the source for the limitation." Personally I find the term "2.5D" to be just fine if you're not trying to force the literal string "2.5D First Person Shooter" to be a mathematical concept just because it happens to look like "3D" and instead just interpret it as a descriptor for a certain type of game. I do think the term have proliferated a bit further than it probably should have since it was effectively invented to describe the renderer that many games had which optimized out pitch and roll from their projection. With pitch and roll being a constant as a fundamental design of these renderers it's becomes clear that there's a distinction to be made between something that has a full 3D transformation matrix and the games that do not. (Although roll can be emulated with screen space effects, pitch is definitely limited.) I think where the term falls apart is that people then try to use it to describe game play, but then we find that the games don't necessarily fit into any well defined pattern. Given that for the most part even "full 3D" games have limited yaw, pitch, and roll (i.e. hitboxes always being aligned), and how even within the same engine one game can be limited (i.e. Doom) and another could basically be full 3D (i.e. Hexen) the term really is useless there. It would honestly be fine if the line was just vague since often times the labels we assign to games are (for example why is Hexen II fairly obviously just a first person shooter and not a first person role playing game), but in this case I feel like the line is so vague that it really doesn't describe anything of use. Outside of first person shooters, games such as the axonometric projection games many of which do have a functional Z axis in their playsim but still have a strictly 2D renderer. I think these are also perfectly fair uses for the term "2.5D" since it follows with the limited projection even if differently limited. Not too much of a fan of using the term for when 3D objects are rendered to a 2D plane (i.e. New Super Mario Bros), but in the absence of any conflicting usage of the term for this genre of game I can't really object to it either. Maybe there is a better term than "2.5D" that doesn't hijack a mathematical concept, but ultimately language is about conveying ideas. We often use things in ways that are technically incorrect, but everyone understands the usage. The most relevant example I can think of is how widespread the term "source port" is despite the fact that it originated from the fact that Doom had to be ported back from Linux to DOS. If a change in platform didn't happen then it's not technically a "port." Yet everyone knows that the term now effectively means "fan modification of the source code" or perhaps even more egregiously "reverse engineered recreation of a game." (Which would involve neither source code nor porting in some cases.) Despite how incorrect this term usually is people are pretty much comfortable with using it, although I'm sure there are a few exceptions. It is unfortunate that the terms mathematical implications does result in some people drawing false conclusions. I don't really think "Pseudo 3D" would make any difference in this regard. It still mentions dimensions so there's going to be someone explaining the pseudo means it's actually 2D. Even if a better term exists, I'll probably sooner convince everyone that Wolfenstein 3D doesn't have fixed size 64x64 sprites than for the term "2.5D" to go away. If games like Wolf3D can actually fall under the "2.5D" label would honestly be a much more interesting debate to me. I'm actually not sure where I stand on that.
  4. Heretic, Hexen, and Strife all implement solid actor passing. To be honest, I have no idea why id didn't implement it in Doom. Not having solid actors cross makes things a little simpler, but not by a particularly significant amount. Off hand I think pretty much the only thing you have to do is make sure that upward movement can't happen if there's an actor in the way. Maybe fix some potential division by zero.
  5. The way I'd put it: Doom is a full 3D game upon which certain key invariants were established in order to remove many expensive calculations. This is why it's hard to point to any particular things and say "this is 2D and not 3D" since Doom is a 3D game that simply doesn't let you do certain things in order to break those invariants. The reason you can't put rooms over other rooms is because one of the assumptions made is that this construct can't exist. This doesn't mean that the Z axis is removed at all, it just means that certain checks don't need to be done because you know a fact ahead of time. In this case the player is always bounded by the one floor and one ceiling. Compared to say Duke 3D which allows some degree of room over room the difference is this assumption is carried out to the precalculated physics and renderer data. The way gravity works, or why certain things are allowed to pass over/under other things is because it's still a 3D game with a complete Z axis. Within the bounds of the game everything carries out like it was full 3D. Thus it's actually better to look at it the other way around, that is the fact that rooms can't be over other rooms is a hardcoded "feature" of the engine for speed.
  6. Blzut3

    Finding Outpost Omega in Doom 64

    Agreed there. Doom 64 using the secret levels to give a tangible benefit (after solving another puzzle) makes finding them far more rewarding. Just a shame how they implemented getting to the first one since not a huge fan of permanent lock out if it's not a gimmick level. Good point, although the teleporter by itself isn't the hint. The fact that there's a secret up there with a berserk pack is technically something missable that you might want to go back for. However there is a pool of blood right in front of where the exit will appear. Logically since wall humping the area yields nothing you do need to do something in the rest of the level and come back up.
  7. I feel surprised that I haven't been able to find discussion on this topic. Is the path to Outpost Omega entirely trial and error in Doom 64? Every guide I've seen simply gives the correct sequence of switch presses to reach the level, but if you're playing without a guide is the only way to get there really just guessing and restarting the map if it was wrong? (No mid level saves in the Nintendo 64 version.) Or is there some subtle hint that I'm just not observant enough to see? I know it would only take 9 runs to brute force worst case (3 with a realistic left to right strategy), but it just seems odd to me since I believe this is the only time the game does something like this. Especially since it's not a gimmick level like Hectic. Although I'm not sure since I'm hearing impaired, but I think Hectic has an aural cue if you happened to destroy all the barrels the first time around?
  8. For what it's worth, the maps already exist in the "butchered" form officially for the Saturn release (well a couple effects made it over I guess, but most of them are gone). That said the maps probably could use a little adjustment to the lighting to make it more Jaguar like. Personally I've always found the colored lighting in the Playstation version to be super gimmicky, so bad frame rate aside I prefer the way the Saturn version looks. (Although I find the colors in Doom 64 a little gimmicky as well, Playstation Doom's lighting more often than not looks to me like they just added color for the sake of adding color.) I think it would be kind of cool to have the Saturn campaign ported over officially similar to how Mac Wolfenstein contains both the SNES and PC campaigns. But having the Playstation campaign on the proper engine would admittedly feel more complete even if I'm not that much of a fan. As for the Sewers and Betray debate, I'm definitely in the camp that considers them official. Definitely understand why they would remove them/not try to re-release them since they're objectively very low quality. But I have them in my personal mod that injects all the console doom maps into game.
  9. VGA

    Dude, I found some Wolf3D game files in my old PSP. Your patch_util.exe doesn't recognise them, is that weird? Do you want me to send you the files? Most of them don't match the hashes in your ECWolf page.

     

    vswap.wl6 has an md5 of 82c20804eea23067e83bef88605cf982

    1. Blzut3

      Blzut3

      Given how Wolf3D modding works, it's very common to end up with accidentally modified files.  Given that you're pulling off your PSP I'm just going to guess that you don't have the original media the files came from?

    2. VGA

      VGA

      It's been years and I don't know where I got those from.

  10. Blzut3

    DOS Doom Code Execution

    The answer to this is probably going to vary a bit person to person, but from what I can tell there's basically only two truly practical uses for this: 1) It allows distribution of modified vanilla code using DMX in a way that's more legal than redistributing the complete binary. I'm sure it's possible to armchair lawyer for days on if code injection actually is a loophole, but we can definitely agree that redistributing DMX without a license would be illegal. By live patching you avoid this redistribution. 2) It allows embedding some of the same conveniences that ports like Chocolate Doom provide potentially allowing running vanilla mods that would traditionally need deusf and dehacked simpler. I really can't think of anything else that couldn't more easily be solved with "just compile the released source code." From my point of view ACE Engine is just another source port on the block, it just requires doom2.exe to launch it. The technical difference between traditional source ports and this are academic. Which of course doesn't mean this isn't cool to mess with.
  11. Blzut3

    DOS Doom Code Execution

    In short: no. Long answer: ACE exploits are considered security flaws so if one was found the source port developer would basically be obligated to fix it. Especially in the multiplayer space where the odds of someone trying to be malicious is higher. Additionally you'd have to defeat security in modern operating systems such as address space layout randomization. And this doesn't even get into the issues with there being multiple operating systems you'd have to support (finding unique security holes), across multiple architectures, and potentially across multiple compilers. All of this requires a much higher skill set than just downloading the Zandronum source code and getting on the development team. Also keep in mind that doing ACE wouldn't mean you get multiplayer sync for free.
  12. Blzut3

    Multiple GZDoom Installations?

    Yes, you can copy the old GZDoom files where ever you please. Since on Linux it by default uses a config file in your home directory you'll probably want to setup a bash script which launches the old version with -config to point to an alternate file of your choosing.
  13. Blzut3

    DOS Doom Code Execution

    There's also a vulnerability in the stack which was demonstrated with ZDoom's VM by jakob Dec 26th, 2017 and patched in GZDoom 3.2.5. As you noted Chocolate Hexen also patched the issue. After I speculated it might also apply to vanilla, Jakob confirmed that it should be possible. I think it's fair at this point to go ahead and disclose what Jakob said in his private disclosure on Dec 27th, 2017: So yeah, the ACS VM being vulnerable to arbitrary code execution has been known for few years. Just never got around to demonstrating it.
  14. I mean there have been threads pointing out the issues that appear when you increase the resolution in Chocolate Doom. Maybe not this issue in particular, but I've seen enough to come to the conclusion that one doesn't just simply increase the resolution and expect a ZDoom quality render. While I may have exaggerated, what I was getting at is that there are many ports with high resolution renders that don't exhibit these issues. It's cool that you want to document the issues, but I just found your comment that your new sampler is "just plain necessary" odd when clearly ports have been using a variant of the original code without issue. (At least not at the resolutions you're using, there's going to eventually be a limit even with adjustment math.) My suggestion to check existing ports was more of a "check that you're not making misinformation" rather than a "see if you can apply the fix." I do realize that I may have misunderstood the exact context of your "just plain necessary" quote, in which case carry on. GZDoom does have a second software renderer called softpoly, which is a full 3D renderer and not Quake's. Still probably won't get much in the way of revelations from it, but just wanted to point out that technicality. ;) In any case, still looking forward to reading your write ups of course. As I said before, you're going down some paths I've wondered about in my head (and well beyond) so it's cool to see what the results turn out to be.
  15. Have you compared the original function with what existing ports have done to make it work? Off hand I don't think ZDoom made any major changes to how span rendering worked, but I've only compared the high level. Can't say I've seen any obvious precision distortions even at 5k. Not that it's the point of your project, but I do find such comparisons a little weird since the community at large has known about the precision issues and fixed them a long time ago.
×