Gez

Steam, like other online shops, now comes with the so-called Unity port as the default option. You can still play with the original in DOSBox if so you choose, though. While "Doomnity" has a few changes, like this dynamic crosshair you've noticed, those are mostly cosmetic and QoL things; the port is generally considered quite faithful besides those, as it can record and play back demo files correctly; something that is only possible if the pure gameplay is not changed. (Pure gameplay is things like physics, monster behavior, etc. It does not include visuals and soundscape. That doesn't mean the player experience cannot be changed; a wallhack would not break demo compatibility, for example.) IWADs are the game data that came with the games themselves ("Internal WAD"); PWADs are game data created by modders that modify the game ("Patch WAD"). In Doom jargon, IWAD is basically synonymous with game; for example when GZDoom asks you to choose an IWAD, it asks you to choose a game.

Usually these are projectile graphics, and they are therefore rendered with an additive renderstyle. Additive means that instead of just drawing the pixel as it is in the image, the color of the pixel is added to the pixel behind it. Black, being the absence of color, is worth 0, so adding black means adding zero, meaning it does not change the underlying color and is therefore about equivalent to being transparent. However, this gives the ability to have a smooth gradient, whereas classic Doom transparency is just an on-off issue where pixels are either fully opaque or fully transparent. A dark but not fully black color will still get to add a little bit. Additive rendering allows to make things look bright and illuminating, so it's often used for fire and anything else that glows.

Those two steps are the wrong way around; textures are created from patches, so the graphics need to be added to the patch table first. In fact, when doing "add to texturex", slade will automatically add to the patch table first if needed; so adding to the patch table separately (either before or after) is supperfluous. Adding to patch table is when you don't want to make the images automatically into textures. I don't know if this explains your problem, though.

Have you looked at @dpJudas's SurrealEngine?

You can use the term "partial conversion" instead of "semi total conversion". ;)

Normally, all of the standard actors are inheritable, be it in ZScript or in DECORATE, regardless of what game they're for. My first explanation would be that you've made a mistake in the inherited actor's name. Double-check that.

It's not the developers' decision to shut down the game; Microsoft just decided to close down Alpha Dog Studios who were making it. Also closing are Arkane Austin (Prey, Redfall) and Tango Gameworks (The Evil Within, Hi-Fi Rush). And Roundhouse is getting folded into Zenimax Online Studios and disappearing as well.

Get rid of the patch table. Just have the patch names in full in the texture definition lumps. Also add some of the stuff Hexen added, like special parameters (but don't restrict them to a single byte), things ID, etc. and MAPINFO. Do like Boom did and export the anims and switch tables to the wad, but go further and also export the actor state table and actor def table.

The revenant looks weird because it lost its armor. These models are not very robust. The mancubus' skin had to be changed at least once. There is one, actually; though specifically for editing. Tricky, as the game doesn't have a function to render a straight line. Okay, that sounds odd when said like this. But yeah, the renderer only knows about sprites, walls, and flats; it has no way to render some arbitrary straight line. That means that a tracer visualizer would represent entirely new code. Even the Unmaker from Doom 64 doesn't really fit the bill, as its shots are rendered through a weird hacky way -- it might be noticed the lines drawn are not always perfectly straight...

MAP32: Self-Destruct (Hell To Pay) is another, with a reskin of the Keens to look like glass fuse thingies, and the added complication that you have a limited time to blow them all up to escape before the place self-destructs (hence the level name) and your voodoo doll gets crushed. ... and I just see now that it's been mentioned already.

Even worse, some games already had an existing independent wiki but Wikia had to go and make their own copy anyway. For example the UESP has existed as a wiki since March 2005 (and had a long history as a static site before that), Wikia created their copycat Elder Scrolls wiki in June 2006.

Gerald Bald Mald

When you talk about global scripts, do you mean ACS? I will assume so. My advice would be to use a library and properly scoped world or global variables.

In fact it's actually one of the central part of DECORATE's design to let you use an actor to define another. Actor SmallVersion 31337 { <include all actual code here> } Actor BigVersion : SmallVersion 31338 { Scale 2.5 } Here we describe fully the small version (actual code not included), and then define the big version by simply making it inherit from the small version and only specifying a large scale.

Really the order in which you do those things does not matter, the only thing that matters is that every lump is in its proper namespace. Music lumps should not be put inside map lumps; maps can completely fail to load properly if the map lump order is not scrupulously respected. Those wiki articles may be useful: https://doomwiki.org/wiki/WAD#Lump_order https://zdoom.org/wiki/Namespace Specifically for music, this page can be useful as well: https://doomwiki.org/wiki/Doom_II_music SLADE should be able to sort lumps correctly, so as long as maps are cleanly inserted without getting inside of each other like Seth Brundle (or André Delambre, if you're truly oldschool) and a random fly, you should be able to use its sort lumps function to get everything clean and nicely ordered.

Thing is that video game graphics in the 1990s were so unspectacular at the time that advertising seldom used it at all. Instead they tried to convey (usually in a very dishonest and exaggerated manner because it's still advertising and therefore lies) what playing the game felt like. Actually showing what playing the game looks like would have been terrible marketing. If you look up 90s video game ads on youtube you'll find a lot more of this bullshit. In fact it's remarkable that there was that much gameplay footage in the ad, thanks to Doom's graphics being, at the time, actually quite spectacular.

Good explanation, but wrong order, the frame character goes before the rotation angle, not after, so it'd be NOTEA0. https://zdoom.org/wiki/Sprite https://doomwiki.org/wiki/Sprite

Something you can do is make yourself a sort of "sampler sheet" of various sprites and textures that you find representative (you can use SLADE's TEXTURES editing ability to do that). Then you can add all the palettes you want to the SLADE palette drop-down with "test palette" and you can look at your sampler sheet with all the various palettes you're testing.

Map format is irrelevant, as long as the port supports DECORATE then the actors can be used in any map format. In fact, in ZDoom, all standard actors are internally in DECORATE format, and the vanilla maps can still be played! And in GZDoom they're all in ZScript, and same comment. Actor format and map format are fully orthogonal issues. The most likely case for a sprite not being visible despite the sprite being present and no error being reported is an offset issue. Let me explain. A Doom actor is, in-game, a column with X, Y, and Z coordinates. The Z coordinate is specifically for the bottom of the actor's column. This way it can do things like check if actor.z == floor.z to see if the actor is on the floor. The renderer draws the actor's sprite at the actor's X, Y, Z coordinates. Like most computer graphics, sprites have their origin point (the pixel at 0, 0) at the top left corner. So this means that by default, the actor's sprite is drawn to the right and, crucially, below the actor's physical position, which means it disappears under the ground. To avoid this problem, the sprite's offsets should generally be set so that the X offset is half the width of the sprite image, and the Y offset is its full height.

What is this from? For those who want to compare the claims made here with the reality, GZDoom's survey code is contained there.

https://zdoom.org/wiki/A_quick_beginner's_guide_to_ACS

If you want the music to start playing once a specific monster is attacked, that's still possible but a bit more involved; you'll just have to implement a way to detect when the monster is attacked is all. For example, you could have something like this: while (GetActorProperty(MonsterTID, APROP_Health) == GetActorProperty(MonsterTID, APROP_SpawnHealth)) delay(5); SetMusic("BATTLE"); The while loop is there to check that the monster still has all its health, the delay is there to avoid runaway execution (infinitely looping during the same tic), and once the monster stops having exactly as much health as it started with, meaning once it has received some damage, then the while loop is exited and the music is changed. There's a lot of things you can do with ACS if you dig a little bit.

This depends on target port. At the lowest levels (i.e. vanilla, Boom, original MBF), there's no real way to do that. Going up the ladder, about every MBF21-compatible port also handles MUSINFO, so you can use that to have the music change when the player goes through certain sectors. Going further up the ladder, if using ACS, you can use LocalSetMusic which will allow you much greater control over when the music change as you don't have to rely on the player entering a sector, it can be triggered by killing a monster or any other sort of event.

This is rather funny, given all the audiovisual and gameplay differences between all the various official Doom versions, including some that weren't even using the Doom engine at all. The only thing id Software really intended was that you'd want to play the game so you'd buy it, again and again and again and again.

Explicitly non-commercial, making it incompatible with all the GPL-licensed source ports as well as things like ZMusic. Too bad. Still a very interesting project, but it can't be integrated directly into a port, so you need a port that can send MIDI to an external device (external to the port, I mean).