QuotePilgrim

First off, apologies for responding to a dormant thread, but considering that it's stickied thread I think this is fine. Also, this is a resource that really belongs here and more people should be aware of. BCS What Is It? BCS is an extension of ACS. BCS is mostly compatible with ACS and provides many interesting and useful features, including the following: Structures Enumerations Namespaces Preprocessor Strong types Block scoping Optional function parameters Object and function references && and || operators are short-circuited foreach loop ?: operator Knowledgebase ZT-BCC Wiki Tools ZT-BCC - The BCS compiler. It compiles BCS scripts to the same bytecode as the ACS compiler and should work fine with the vast majority of existing ACS scripts, so chances are you can use it as a drop-in replacement and start using it for your new scripts without worrying about updating the old ones. On a side note, since this isn't mentioned anywhere: if you use SLADE you can modify the contents of "slade.pk3" so it'll recognize files with the "bcs" extension as ACS scripts and automatically enable syntax highlighting for those files. The relevant file is config/entry_types/text.cfg; just look for the line that says «match_ext = "acs";» and change it to «match_ext = "acs", "bcs";».

You can probably tell from the fact that I'm a junior member despite being around for more than three years that I'm not a very active member. As a result whenever I come back and see a notification it comes as a big surprise. And of course in this instance it had to be someone quoting a post where I made a pretty egregious typing error I only notice upon rereading it LOL Anyway, always glad to hear someone other than myself likes one of my dumb ideas.

DavidXNewton. He does more than just DOOM and I actually found him through one of his Prince of Persia videos back when I was replaying the game for the billionth time; I didn't even know he made DOOM videos for quite a while after finding his channel. Which is to say, while I really enjoy his DOOM content, that is not necessarily what I care about the most. I just wanted to mention someone that wasn't already mentioned by everyone else. My favorite DOOM-specific content in all of YouTube is decino's analysis videos.

Tell them to go have intercourse with themself, problem solved.

UV, usually with a lot of quick-saving because I want to finish levels within a reasonable amount of time and I'm average player at best. I don't think I actually finished either DOOM or DOOM II in UV though; back when I played them through I would only play HMP because it's what is selected by default.

That is absolutely a valid way of thinking about it. It is also valid to think that the map is moving differently for each player. That is the thing about movement, it only exists relative to some frame of reference. The XKCD comic someone posted is a silly joke, but it is also true. In physics, from the frame of reference of a person standing inside the train, the train is stationary and Earth is moving, and from the frame of reference of someone standing somewhere else outside of the train, the train is moving. Both things are simultaneously true. As for what happens in the game, each player's computer is rendering a separate copy of the world, so there is no issue. Let's pretend the level doesn't exist for a second, and imagine there are two players standing in front of and looking at each other. If player A strafes left, what will both players see? Player B will obviously see the player A sprite moves towards the right side of their screen, but it is also true the Player A see's player B's sprite move towards the right of their own screen. Player A is moving from player B's point of view, and vice versa, in the very real sense that both computers are moving the other player's sprite across the screen. If you only looked at either screen, without knowing who is actually strafing, you would come to the same conclusion that the person see on the screen is the one moving. (Also, in case someone is about to bring up the fact that the strafing player's player would show a walking animation, I'll just point out that a walking animation doesn't have to be tied to movement. You could have neither sprite animate at all, or both animate constantly regardless of whether the player is doing anything, for instance.) It's more a matter of how to think about what is happening than what is being done in code. But one way in which the game actually move everything around is what I just described above, which you can see happening right in front your eyes. Just look at any object in the game and rotate your character a little bit with your mouse, and you see the object move on your screen. I think seeing this as moving the object relative to the player is a reasonable way of looking at it; if you don't, there's not much else I can say. Just think about this: the game has to calculate the position of everything relative to the position of the player in order to draw it on screen. It would be impossible to place anything on the screen without doing that. -- I hope this all makes any semblance of sense, it is very clear in my head but I often have trouble getting what is in my head out in a coherent way. Also, I think I have repeated myself enough, so I'll refrain from posting any further in this thread.

The point I'm making isn't that the map moves and the player doesn't. The point that I'm making is that both interpretations are valid. Thank for proving my point. So, let me state this a little more clearly. It is true that the player has a set of coordinates relative to the world origin, which change according to some user inputs and other things that happen in the game. You can think of those numbers changing as the player moving relative to the level. As a player it makes more sense to think of the player character moving, because that what's happening conceptually. It is also true that the way the level is rendered consists of calculating what parts of the level to draw on the screen relative to what the player coordinates are. You can think of this as the level moving relative to the screen/player. As a programmer it makes more sense to think of the level as moving, because it's the thing that you actually see move on the screen as the player coordinates change. The player moves relative to the level, the level moves relative to the player. Both statements are equally true. This exactly what I said from my very first comment.

Even in real life, if you move from your living room to the bathroom, it is perfectly valid to think of it as you being stationary as your house moves around you. That's what a frame of reference is. That is why I said both ways of looking at it are valid, and both are technically not the truth. There is no true interpretation, movement is relative. If you're just playing the game, it makes sense to think of it as the player is moving and the environment is not, but when you are programming movement in a game, what you are doing, usually, is making the environment move according to what the player's coordinates are. Look at the automap in DOOM, the little arrow that represents the player is always at the same spot on the screen as the map rotates and moves around. Or just look at gameplay in general, what is the thing that you actually see change position in the screen? Is it the player or the environment around the player?

That doesn't actually mean the player is moving though. I have next to no familiarity with DOOM's source code itself, but I have coded enough little game prototypes to know that what usually happens is the player coordinates are just some numbers that change with certain user inputs, and those numbers are used to calculate where to render the level relative to the player (and the player relative to the screen). You can interpret this to mean either the player or the level is moving, both are valid interpretations, neither is tecnhically true.

Thank you. It's nice to find another Yume Nikki fan. 99% of the time, when I mention that game, no one has a clue what the heck I'm talking about, haha.

The starting area of my current project has a swinging door in it, and I wanted to replicate the effect of the light tag present in regular doors. I have half working solution that is very janky. Essentially, I'm using PolyObj_RotateRight(/Left) in conjunction with Light_Fade, and making the door non-solid as it moves so the player can't interfere with its movement, otherwise the light level of the affected sector and the angle of the door would get out of sync. So, my question is, is there a simple way to tie the light level of the affected sector to the current angle of the door? That is, if for example the player stands in the way of the door as it opens, impeding its movement, I want the light level to stay constant until the player gets of the way and the door can continue to move, and the light level increase with it. Same for the door closing, of course. For the curious, my current script looks like this: script 3 { int speed = 24; int tics = 24; Line_SetBlocking (1, 0, BLOCKF_PLAYERS); PolyObj_RotateLeft(2,speed,64); Light_Fade(30,160,tics); delay(tics); Line_SetBlocking (1, BLOCKF_PLAYERS, 0); delay(40); Line_SetBlocking (1, 0, BLOCKF_PLAYERS); PolyObj_RotateRight(2,speed,64); Light_Fade(30,80,tics); delay(tics); Line_SetBlocking (1, BLOCKF_PLAYERS, 0); if (dest) { Teleport_NoFog(dest,0,0,0); } } (It's a BCS script, hence the lack of "(void)"). The teleport line is more jank, to prevent the player from getting stuck in the door. I have another script activated by a few "Actor Enters Sector" things that sets "dest" to the id of one out of two teleport destinations, so the player is teleported out if they're inside the door when it stops moving.

Today is my birthday, and this is my little gift to the DOOM community. (I'm treating this as a hobbit birthday.) It's a preview of the project I started 2 years ago, and have talked about here and there. Maddy Dreamscapes is a Yume Nikki inspired game where you play as Madison, a girl who refuses to leave her bedroom and instead chooses to go exploring the worlds of her dreams. As the title indicates, this is pretty much just a prototype, so there's not a lot in it yet, and most of it will be completely different in the final release. What is there, though, I believe is interesting enough to take a look at. This project is standalone GZDoom game, so it doesn't require and IWAD as it is its own "IWAD" (or ipk3, rather). It comes bundled with GZDoom, but you can also download only the ipk3 file if you want. All assets in the game were created by myself, and are licensed under the Creative Commons zero (CC0) license, which releases them to the public domain. So, feel free to use any of it in your own projects if you want. Although, there probably isn't much use for most of it outside of this project, I just chose that license on account of my personal beliefs. While I intend for it to tell a coherent story without trying to be mysterious about any aspect of it, the final game will have a lot of hidden secrets that will require some cryptography and steganography knowledge to uncover. I may or may not have hidden a very hard to find secret message in this alpha ;) Download: https://quotepilgrim.itch.io/maddy-dreamscapes Screenshots:

Because, as I said, for the sake of sharing the game with the DOOM community, it's simpler to just give people the pk3 and let them use their own installation of GZDoom if they wish to. So far, I believe I can make everything I have in mind work with unmodified GZDoom -- even if requires atrocious workarounds --, but if there is some game mechanic I deem absolutely required which would need me to modify the engine, I might do that. Or I would at least try to, as I am not super familiar with C++ (I wrote a couple simple command line tools back in high school, learned Python, then never looked back), meaning I would have to essentially learn the language as I make the changes I want.

What's to stop any game other than Doom from doing the same thing? If one game did that to you would you also stop trusting all games ever? Every PC game engine out there allows game developers to read and write files with arbitrary data in the users machine. GZDoom is the only exception to this I can possibly think of. Why is it a bad idea for GZDoom to have that feature, and not a bad idea for every other game engine in existence? Any game you have ever played could have filled your PC with millions of files, but they didn't, and I bet you never worried that they might do that. Besides, if that's what you wanna do, you don't even have to make a game at all, just distribute a zip bomb under the pretense that it is a game, it's a lot less work than making a game (or a mod/level for a game, as would usually be the case with DOOM), and just as effective. I've been working on an off on a standalone game made in GZDoom for a couple years now. The ability to create files in the user's home directory (which, again, is a normal thing almost every game does) in order to save persistent data would be a very useful feature that would save me a lot of headache. The game has very little content in it at this point, and I'm already having to come up with ugly workarounds to implement some of the features I want. I have honestly considered forking GZDoom, making changes to the source code, and ensuring my game would only be playable with my modified version of GZDoom. I have ultimately decided against it, as it would be simpler to just distribute the pk3 for members of the DOOM community, even if I still have to bundle my game with GZDoom for everyone else. I may, however, revisit this idea at some point.

I've been trying to get back into developing my GZDoom standalone game, and I wrote a line that looked something like the following in one of its scripts: int flags = CheckInventory("EventFlags"); ...only to find out it doesn't compile. This is a pretty common thing to do in every programming language I have ever used, so I was a bit surprised to find out it didn't work. I looked everywhere in the ZDoom wiki and couldn't find a solution. Is there some way to get the return value of a function and store it in a variable, or am I out of luck? (EventFlags is a custom inventory item I have defined in ZScript. I'm essentially using the amount of that item that the player has in their inventory as a set of bitwise flags, so I only need one item to remember multiple things at once. I want to store that number in a variable so I only have to call CheckInventory once in any given script that checks for multiple flags, which makes the code easier to write, plus it should run faster.) EDIT: I'm an idiot. It does work, I have no clue what the heck I was doing wrong. Disregard my stupidity.