Dark Pulse

Yes. Yes they do. Film at eleven.

It's called "being fair and paying for something." It's five bucks, for God's sake. Your cup of coffee at Starbucks probably costs more. Unless you are absolutely flat-out dead-broke, or are under the age of sixteen, or for some reason spend every single dollar you earn on bills, you've got five bucks.

If you'd like to thank us, picking up the game legally at some point is a nice way to do so.

Well that definitely rules out a corrupted WAD or some sort of hacked IWAD. At this point I'd say either something is corrupted with the Chocolate Doom install, or your RAM is going bad, but if it were the latter all sorts of other things would glitch up. So yes, at this point, install the latest Chocolate Doom, in a clean folder, and see if the problem goes away. And as others have said in here, NEVER modify the IWAD. If you want to add or alter things, always always always do it in a PWAD. (Though admittedly there are some oldschool mods that DO modify the IWAD - to replace sprites in the original game, you used to have to modify the IWAD with DeuSF for example - but Chocolate Doom should be able to handle these cases without merging the alterations into the IWAD.)

To which version? If it's not 1.9, that could be why. Source ports, including Chocolate Doom, pretty much expect the latest version of the IWADs.

Quite willing to bet that the IWAD is modified or corrupted somehow, potentially due to the means with which the OP obtained it. The quick-and-dirty way to test it: Download HashCalc (assuming you're on Windows, of course). Tick the boxes for CRC32, MD5, and SHA1. Drag your IWAD onto the program. It will calculate the hashes. Compare those hashes to the list of hashes on the Doom Wiki. If none of them match, your IWAD is corrupted or modified. If it matches one of the older ones, you probably need to get it upgraded to 1.9.

It's designed to be a drop-in replacement for ZenNode, so if you wanted to, you could literally set up UDB for ZenNode and just rename the executable zennode.exe and it'd work right out of the box. Alternatively, just add a configuration block for it. Here's the one I got: compilers { // This defines what files a compiler uses // The setting named "program" defines what .exe to run zokumbsp { interface = "NodesCompiler"; program = "ZokumBSP.exe"; } } // Below are configurations for this nodebuilder. If you want to make your own configurations, // it is recommended to do so in your own file as this file will be updated each release. // NOTE: Nodebuilder configuration key names defined here must be unique for all nodebuilders! // Recommend to start the key name with the name of the compiler, followed by underscore and a specific name. // The "compiler" setting must refer to an existing compiler (such as defined above), but it // does not have to be a compiler defined in the same configuration file. nodebuilders { zokumbsp_normal { title = "ZokumBSP - Normal"; compiler = "zokumbsp"; parameters = "%FI -o %FI"; } zokumbsp_fast { title = "ZokumBSP - Fast (no reject)"; compiler = "zokumbsp"; parameters = "-n3 -nq -rz %FI -o %FI"; } } Save that as ZokumBSP.cfg, save it (along with ZokumBSP.exe) in <UDB folder>\Compilers\Nodebuilders, then in Tools > Game Configurations, simply select it as your nodebuilder in the Nodebuilder tab for whatever games you are using to build levels with it (presumably Doom, Doom II, and Final Doom). It should also work for Heretic, Hexen, Strife, HacX, Chex Quest, etc. as well. Note that it will NOT work for ZDoom-based features or UDMF - you will want to use ZDBSP for that.

Admittedly, I'm not sure. I do know that it's really meant for ZDoom-based ports. If you're looking for something compatible with Chocolate Doom, you'd probably want to try ZokumBSP. That will definitely work, as its whole point is to be vanilla-compatible. If you're not comfortable compiling it on your own, here's a binary of Version 1.1: https://web.archive.org/web/20220909041501/http://www.doom2.net/zokum/zokumbsp/releases/zokumbsp-1.1-win64-mingw.zip (Also, @zokum, you may want to update your releases on Github, since your website seems to no longer be operational.)

I mean, the source code is out there. https://github.com/obsidian-level-maker/Obsidian Nothing stopping anyone from porting it to Android. License is GNU2. So the only reason it hasn't been done is lack of interest/demand.

@Maximum Matt certainly does. :)

Swaggy Lee, the OG.

Well, after June 22nd I'm home until September, so I'd be able to pick up stuff like this a lot quicker. Basically, if you don't mind waiting a hair longer after the 22nd, I'd probably have something worthwhile. I need to get some mapping chops in anyway; need to work on that map for Pandora 64 as well as work on my last GEC Master Edition conversion for PS1, so a DM map is a nice little warmup. :)

Oof. If that June 24th deal were a bit later, I'd consider taking a spot, but work is going to keep me super busy until the 22nd, and I'm not all that sure if I'd have more than an extremely barebones skeleton by June 24th - if I'd even have one at all. :(

Well aware of that, but we're not talking about "what was supposed to happen." The end result was not that, and that's all that matters.

Yeah. I know they're reduced-rez. They basically chopped up the wall into eight 128x128 segments; you can see this easily via PsyDoom when you load up Icon of Sin and then use the VRAM viewer cheat (idram, or F7 if you've enabled the developer cheat shortcuts). The wall, for the record, takes up 2/3rds of the entire space set aside for textures as a result - it can generally hold up to 12 128x128 textures. GEC used a trick as of Beta 4 that let it be up to 13, though. This is the reason why a LOT of PSX Doom textures are 64, 32, or even 16 wide. As far as sprites are concerned, it only matters if it's loaded into the level or not. Tracking each individual monster does require a miniscule amount of RAM to account for its position, HP, etc. but otherwise, there's no difference between loading one Mastermind or a hundred, because they all use the same sprites. The TYPES of monsters matter, but the AMOUNTS, not really. (To a point, of course - there is still a hard limit on how many Things can be inside of a map.) But the JagDoom codebase is what was shopped around, and that version had cut-down maps. In fact, the only contemporary port that did NOT have the cut-down maps was, ironically, the SNES port, because its developer reverse-engineered the game from the PC version, as opposed to starting with a codebase designed for weaker systems in mind. Also, keep in mind that even if the geometry can be more faithful, texturing almost certainly wouldn't have been. Even if you included every single texture the PC versions had, there's simply not enough VRAM to include every map in perfect fidelity. If the PS1 had 4 MB of RAM or so, it might be a different story. Note that this isn't a problem unique to Doom - a lot of games suffered. Street Fighter Alpha 3, for example, had tons of its animation frames cut from all sorts of character animations. The Sega Saturn version, on the other hand, had near-perfect Arcade animations with only very minor cuts - but the difference there is that the game required an add-on cartridge to be plugged into the Saturn's rarely-used cartridge slot, and that cartridge added 4 MB of RAM to the system. The game would refuse to run without the extra RAM. Basically the only maps where you can get away with near-perfect texturing is maps where a lot of variety wasn't used in the first place. My conversion of Dis is a pretty solid example; I actually had leftover texture room and so was able to make use of some extra textures (most of which was in the new central "pedastal" and the exit room). Other conversions of mine, like Bloodsea Keep, weren't so fortunate. :) I mean, theoretically they could have. But the thing with commercial game dev is that getting the game out on time is the #1 priority - and this would be especially true for Doom, since by the time that came out on PS1, Quake was already making the news and would be hitting PC very shortly (June 1996), and everyone knew the PS1 was capable of pushing 3D so basically, a delay on Doom could have been catastrophic. With infinite time and resources, you can iron out all sorts of stuff, like the texture stretch issue GEC fixed and so on. But of course, you don't have that luxury as a commercial game dev - you've got a budget, you've got a deadline, and they'd damn well better be met - even if that means cutting features, accuracy, or functionality.

Development did begin in late 1994, but for PS1 Doom, I'm sure development began even earlier - the PS1 released in Japan in December of 1994, so it was fully possible to get PS1 devkits around the time, or even before then. We'd probably have to ask one of the devs to be sure (sadly, none of them are floating around here anymore), but I know for a fact PS1 Doom was based on the JagDoom codebase. That and it's very silly to develop two totally different branches of the game side-by-side - code is going to be put into one and used in the other, if it's sensible to do so. PS1 Doom came out first (by over a year - November 1995 for PS1 Doom, March 1997 for Doom 64), so there's really no way the game would be done almost a year and a half later if PS1 Doom were based on the Doom 64 codebase. It just doesn't make logical sense. I'd really recommend not using that terminology, as it is extremely confusing. In a technical sense, hardware rendering is when some sort of specialized graphics chip accelerates the rendering, and software rendering is when the CPU itself is doing all of the graphical processing work. "Partial hardware" conversely implies some of it is hardware, and some of it is software, and that is definitely not the case for PSX Doom. (It is the case in a few other ports, though - IIRC the 3DO version does have acceleration for walls, but the flats still had to be done in software, and that's one of the reasons the 3DO version is so terrible performance-wise.) It is rendering things like how the PC renderer did it, but that is done fully in hardware. The MIPS CPU of the PS1 has nothing to do with drawing the scene, so calling it "partial hardware" is not only erroneous, it's flat-out wrong. Doom II and Final Doom were the more relevant games by the time PSX Doom came out; doing a port of just the original game would have seemed silly and old. I mean, the original (Non-Ultimate) version was released on 32X, SNES, Jaguar... a port to the PS1 of just those levels, especially when how much stuff CD-ROMs could hold was frequently a highlight point at the time, would've just seemed backwards. Also, the reason they couldn't easily implement the Arch-Vile and IoS was simple: Lack of RAM. The PS1 has 2 MB of RAM; after you reserve the chunk necessary to run the game engine, you're left with about 1.6 MB. Your entire level, textures, and so on, must all fit within that space. Sprites have a hardcoded amount of VRAM dedicated to them (about 384 KB, if memory serves), but the problem is the Arch-Vile also has like twice the frames of animation of any other monster, and reducing it would look quite choppy. GEC achieved it, IIRC, by judicious frame cutting as well as reducing the resolution of the sprite (but don't quote me on that). Icon of Sin is a problem for a similar reason: If you try to load all monster types, or even most of them, in a map, the game will quickly run out of VRAM for sprites and bomb. The solution GEC came up with is that the mapper defines what monsters can spawn, and that's what the IoS spawns on a map that it's on - and only those (though IIRC it can nightmare flag them as well for variety; those take no extra sprites as it's really just a different blending mode). Dis was indeed not in PSX Doom. And you're forgetting it was more than that - there were also Barons of Hell and Cacos in there. Which is also doable - but it runs into a problem when you're doing a gimmick of "Doom II monsters in Doom I maps." I did the conversion for Master Edition (please die a lot, it will make me happy), so I can speak in detail about my version of the map, but simply put, I tried to add Pain Elementals to that list and the map ran out of RAM. I had to chop the Cacos to make it work. The Spider Mastermind takes up an INSANE amount of the sprite VRAM space - so dropping one in limits you to one or two other types of monsters, and that's about it. There's a reason it's used very sparingly - and in official maps where it is used (Redemption Denied comes to mind), that's the reason there is very little monster variety besides the Mastermind.

Neither of these are correct. First, Doom 64 was directly built off of the PSX Doom codebase. It's fairly obvious when you look at the reversed code for both games. Second: There is no "partial hardware" stuff on PSX Doom. It's all done in full hardware, just in a weird way. Rendering pixel-wide polygonal strips is what allows the game to avoid the affine texture swim that Carmack hated, but it also means that a hell of a lot of polys are being pushed and rendered to do it, and this is what is tanking the performance of the engine. Devs hadn't thought things like increasing poly LOD as you got closer to a surface yet (again, this game came out two months after launch), so a lot of the trickery that was done in a late-era PS1 game like Quake II simply hadn't been discovered yet. Also, while there was some limits that would have complicated things due to how they wrote the renderer, I'm pretty sure that if that were rewritten and improved, there wouldn't be any technical reason that the original map geometry couldn't be restored. The main issues are that textures don't tile on the vertical axis more than once (which GEC has fixed) and that large or tall rooms kill performance hard (which is due to how the renderer renders in strips of polys, overdraw, etc.). If that could be fixed, missing textures got restored, and the map limits pushed to Final Doom spec, I'm pretty sure at least the OG maps could be made to run just fine. Textures might have to differ due to limited VRAM space, however, and custom maps would probably still have a problem, of course - IIRC the first map limit that would usually get hit would be Sidedefs.

Depends on use-case. Obviously something not written to very often is going to last longer.

Assuming your PSP is jailbroken (no reason not to at this point - it's trivial to do so), there are plenty of screenshot plugins that you could use to solve that problem. Also, yeah, you do (unless you have a PSP Go, which comes with 16 GB of onboard storage), but in reality, that's really just buying a cheap-ass Memory Stick, or an even cheaper Memory Stick adapter and some sort of SD/MicroSD storage. Granted, that's just how modern tech is nowadays. And the upshot of that that you seem to be forgetting is that those batteries inside the cartridges can, and eventually do, die - replacing them generally requires disassembling the cartridge casing, desoldering the old battery, and soldering in a new one, either directly or (if there's room) via soldering in a holder. A modern memory device, on the other hand, is solid state storage, so in theory it should stay good for quite awhile. Also, you can easily transfer that save to another device and continue the game there, whereas good luck getting your save data off of a cartridge (generally you would need to purchase a cartridge dumper to do it, and writing it back to the cartridge would be even harder). Lastly, I remember more than a few Game Boy games that used passwords to save progress. Remember: Battery-backed SRAM added costs to the cartridge, so not every game used it.

I do not know, though I do know some fixes and improvements were made. (For example, walls can now be above 256 units vertically without the texture stretching.) The challenge there is that before such a fix could be applied, it must be tested for regression - in other words, "If we fix this thing, does it break something else that explicitly breaks this other thing that depended on it being broken?" If it's just an obviously wrong linedef or something, that's one thing. That said, GEC has stated repeatedly that a "combined" release will be its own separate thing from Master Edition (which will just cover cut content or content that came out since by notable people involved in the original games), so that's not really something that applies here either way. Believe it or not, not everyone had a memory card back in the day. The PlayStation did not come with one; they were only sold seperately for like $25-30 each if memory serves, and again, this was a near-launch title (The PS1 released in North America on September 9, 1995 - Doom was released barely two months later on November 16), so basically they assumed that many people might not have memory cards, plus it was a transition phase from 16-bit (where passwords were very common since most cartridges didn't have battery-backed SRAM to save progress) to 32-bit (where by the end of it games more or less assumed you had a memory card). That said, do note that PSX Doom doesn't store your status exactly as it was. Health and Armor amounts, in particular tend to be rounded up to the next highest 25%, and ammo can be rounded up in the same way as well (based on how much of it you have in terms of eighths of maximum capacity). But it will keep track of your difficulty, armor type (if any), weapons possessed, and if you have a backpack or not perfectly. If you'd like the dirty details, this spills all the beans: https://classicdoom.com/hosted/lpalin/ps1pwfaq.htm Also: Note you can get your current password at any time by pausing the game, pressing Select (i.e; the automap key), and choosing "Password." You do not need to wait for the intermission screen to obtain one.

If you didn't play shooters in the era, it can take some getting used to, and since this was an early title, analog controls didn't exist yet (though the GEC Master Edition does add those - and PlayStation Mouse support, I believe). That said, that's also how I assign my controls. But as I grew up playing PS1 Doom (and my first port was an even clunkier one, SNES Doom), I'm pretty used to playing it with a controller. I made sure my conversions for the project were beatable by me on Ultra-Violence before I submitted them, after all. :P Other way around - Williams was bought out by Midway.

Not normally, no. PS1 Doom didn't have any sort of memory card capability, just passwords (and even those round values). Normally I'd say "use a savestate" but POPS doesn't have that capability, so you kind of just have to deal with it. Unless there's a PS1 emulator for PSP that isn't POPS - if there is, you can look into that.

That's a separate thing you would define in MAPINFO.

Last modified, 2016. One version released (0.1) in 2012. It's fairly safe to say the project has been abandoned.

Pretty sure GEC's stance on this stuff is that they'd like to stick to stuff id either did, directly approved of (i.e; Final Doom), or ex-id members did (i.e; Romero's extra maps). Obviously other people can do whatever they please for whatever other mapsets they'd like to try to torture themselves into converting. :P