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

zokum

Members
  • Content count

    481
  • Joined

  • Last visited

About zokum

  • Rank
    Member

Recent Profile Visitors

2033 profile views
  1. Id are the ones to blame for FD, not Team TNT. I do think Team TNT delivered a sub par product, but id accepted it. I would probably have done the same as Team TNT if I were in that position. Like I said earlier I would have patched FD to be a better product. Replaced maps and put them into a lost levels bonus episode. Fixed bugs, added more textures etc. It would have been neat if Final Doom had received the occasional update, much like the current Unity Doom does. The world might not have been ready for that kind of game experience back in the mid 90s. Not everyone had internet access. It would have been a neat product though.
  2. It should be noted that Final Doom was released July 1996. The public beta of Quake, QTest was released February 1996. The first shareware version of Quake was released June 1996. The full game in August 1996.When it comes to gameplay and engine, Final Doom came out AFTER Quake. And it looked incredibly dated since everyone knew id had a more advanced engine fully working and playable. People were playing Quake over the internet and 16 player LAN games. Compared to that, Final Doom was technically a very poor multiplayer game. It was obvious to everyone that id spent their time on Quake. Final Doom was a cash grab-in and for those who couldn't run Quake, or it ran horribly slow. Quake required 8 megs of ram and an fpu. In practice it was more or less unplayable on anything below a Pentium 75 as the code was tuned for the pentium line of CPUs. Doom in 1993 was a technical marvel. Quake in 1996 was another major milestone in technology. Final Doom is a mediocre mission pack when compared to those.
  3. zokum

    Why wasn't the 4th episode based on DOOM II?

    #ifdefs are checked compile time. That would make for different executables. The code simply checks things like what is the wad we're loading called etc to determine the behviour. A lot of the stuff like titlepic, demo playback etc are the same, so there aren't that many changes. Since doom doesn't contain any doom 2 monsters, the code for loading the graphics for them is never run etc. Doom 2 is also a bit simpler when it comes to things like the intermission screen so all in all, it is probably a simpler code path. You could take a look at the released source code to determine the specifics of how it is handled.
  4. zokum

    Why wasn't the 4th episode based on DOOM II?

    No. The excecutable for Doom 2 is perfectly capable of running Doom 1. The Doom 2 1.9 executable is the same as the 1.9 Doom executable. Let me quote the Doom wiki: Latest version of Registered DOOM The executable distributed with the DOS version of Registered Doom 1.9 is identical to the one distributed with Doom II 1.9 & Shareware Doom 1.9. Version 1.9 is 709,905 bytes in size, is dated 1995-02-01, and has the following hashes: The changes for Final Doom and the Ultimate Doom are very minor, it would not have been hard to keep it in a unified executable. Having just one executable makes it much easier to implement bug fixes and improvements to the engine. Doom basically has a sub set of Doom 2's features.
  5. As I remember it. Considered a cheap cash grab in. A decent quality fan community project packaged as a new game. Doom 2 received some criticism for containing a lot of stuff from Doom reused. It felt more like a mission pack /expansion than a new game. Final Doom though took that to a new level. Very little new content. No new monsters, bosses or special effects. At least Doom 2 added new linedefs and monsters. It isn't quite as bad as "The Master Levels" but as an overall standalone game it is one of the worst products id has ever released. The best element in it is by far Plutonia. The rest is on par with randomly downloaded 1996 pwads from ftp.cdrom.com. If I were in charge of Team TNT and that product, I honestly would have provided a free "patch" for the game replacing the worst maps, bad design choices, etc after the release. In its current form, it's really bad. Sorry to say it.
  6. zokum

    Ultimate Doom Builder is not user-friendly.

    You do not understand what use friendly means. It is NOT the same as newbie friendly. A user friendly interface lets the user do what they need done in an efficient manner without hiding useful stuff. It doesn't hurt to be more newbie friendly, but a proper user friendly application will NOT favor new users over existing users. User friendly interfaces will group things logically, have hotkeys, be predictable, customizable and enable the user to do the job. A more newbie friendly thing with a wizard and some questions and a click here to make exit button might be more newbie friendly, but it would quickly get in the way of anyone above the novice level. The Doombuilder family of editors is very friendly to anyone who have some basic doom internals experience. It's loads easier to use than dck, edmap, deth, deu, ade2 etc were back in the mid 90s. If an editor caters mostly to users with 0 experience and knowledge, it will most likely be limiting and annoying to more experienced users. A good example of user friendliness is to have everything available with both mouse menus and hotkeys. To automate common tasks, to perform decent consistency checks, provide good search functionality etc. There are some things that DETH did that I miss in DBX. You could use , and . to rotate things. That was handy for selecting a group of monsters and making the face the right way without having to edit any properties.
  7. Many of the 256 color lucasarts games used a special palette technique. The UI and main characters were in a certain set of fixed colors that were available in every area/room/scene. The remaining colors were custom per image. This allowed for eerie greenish stones, lush jungles, fantastic lava, just not all at the same time. The same approach could be used in Doom. Use a few fixed colors (grey/black) for ui and have the others as dynamic colors from frame to frame. Implementing red tint when hit, green tint for rad suit etc should be easy peasy with custom colors and a nice touch in text mode port.
  8. I made a quick mockup and experimented with the color intensities a bit. Doom doesn't have so many dark reds, so we should adjust all those upwards. We could also do with just one yellow and two browns instead. Orange didn't look particularly good with dithering. Maybe squeeze in one orange and drop a green? Or perhaps we could do with just two reds due to the lack of dark red in the game palette. The point is that this kind of approach does have some potential. The important thing to remember is that some colors are used much more in Doom than others, making them more important. Bright blue isn't seen a lot in the game, while brown is. One should adjust to favor color choices in representing the more commonly used colors and not the full palette. I dropped the pink and purple hues. Mixing red and grey might work for the brighter pink colors and the darker just map to red. If we wanted to go completely bonkers, we'd render 320x200 VGA to a buffer and compute the 16 optimal colors for that frame and use those colors. Constantly updating the palette to render the game as close to vga as we can. In a dark room with brown walls, we'd have many browns and some grey and others for hud/weapon and no greens etc. Doom in grey scale with this approach should look very good. You'd easily get 64 shades of grey, enough to render everything fairly close to the original brightness.
  9. I was thinking of EGA+ stuff yes, not MDA specifically. Redefinig the glyphs is standard practice in DOS when changing code pages. I'm norwegian so we have a few changes in DOS like æøå ÆØÅ and ¤. The ¤ is the generic symbol for currency, I think it's called scarab. Way more characters than 80x25 is probably also an ega/vga thing. Some of the modes are probably vga only. With 256 glyphs, you could create pseudo pixels out of the characters or lower resolution, but dithered pixels to improve the color space. Add the custom color trick used in earlier doom setup versions and you could probably find a set of color values to create a really nice doom experience in text mode. With 16 custom colors, I'd probably go with something like: 1 white 1 black 3 shades of grey 64,64,64 160,160,160 and 192,192,192 3 shades of red 3 shades of green 2 shades of blue 2 shades of yellow 1 shade of brown. The trick would be to make the brightness of the colors in a way so that you could use dithering of black and red to make a darker red, or with white for a brighter red. Orange in the game would be replaced with yellow/red dither. The less vibrant green colors with a dither of green and grey etc. The 64,64,64 dithered with black would look like a 32,32,32 pixel. The 3x160 a 3x80. Dither of 64 and 160 would look like 3x112. Ideally you would need some sort of spacing that would give you many perceived brightnesses of each color. Having a 3x64 and 3x128 isn't as useful as dithering the 3x128 with black would look similar to the solid 3x64. The brightnesses I chose here were taken out of thin air, more optimal schemes for getting more dithered hues probably exist. You could also make every 3/4 pixels on dither patterns as seen in ansi art. Then you could use black and 64 together to make a pseudo 48,48,48 and 16,16,16. The math for all of this wouldn't be too hard and could be pre-computed into a lookup table for each color in the doom palette. Dithering black and white to make a 128,128,128 color pixel doesn't look good. You'd probably get a better result from a 3/4 dither of 160 and 64. Dithering works best if the colors are close in brightness. The 132*50 svga mode is fairly standard and could allow for some really nice "text mode" doom. The 80x60 or 80x50 is probably a safer bet on older machines and monitors. Windows NT loves to use higher res text modes, so support should be decent. NT 4.0 used 80x50 during boot.
  10. zokum

    How can I start making classic doom 1 mods

    This depends on what you mean by classic Doom mods. Do you mean mods that run with the original 93-94 executables? Do you mean mods that use source ports? Use something like Doombuilder 2 to make the maps, if you want maps in the mod. Slade works well for assembling all of the various maps, textures, graphics into a single wad or pk3 file for play and distribution. I'd advice you to find some mods you like and open them in these tools and poke around and see how they are made. Start with something that isn't too complex.
  11. Plutonia might be using some special effect stuff that the port does not handle. Sigil isn't vanilla compatible, there might be several things breaking it, did you use the e3 replacement version? The port might not handle the episode 5 stuff well.
  12. zokum

    Completely closed self-referencing sector?

    That's nice. These kinds of effects were more obvious back then when things were more manual. Older editors let you place vertices all over the place and then add linedefs between them as a common way to make things. Things took a lot longer back then, some people have no idea how much more work it was to make maps in the 90s. The editor aligning automatically for you was a god-send! In id's editor you had to do everything manually as well. I think the game would have looked better if they had some sort of auto align code.
  13. zokum

    Completely closed self-referencing sector?

    More recent versions of Zokumbsp have code that can move vertices around after they have been placed in the editor in order to achieve such effects. Manually editing vertices in slade will also achieve the same effect. I can't remember the details, but it's certainly doable even if the editor is a bit shit. Older editors like DETH allowed you to set vertice coordinates directly and didn't auto merge in the same way DBX does. They might have used that. I haven't looked into the TNT map. In Zokumbsp I added code to move walk over linedefs to the same location, allowing for traps where you trigger all the linedefs at the exact same time. This is important if a trap or door or something is timing sensitive in order to look good. I made a small demo maps showing this off with a few triggers like that and a door+lift door opening like 'teeth' going separare directions. I used the bigdoor texture with support3 on it and separated it into 5 parts. 3 went down and 2 up. Custom textures designed for this use could probably make a much better version.
  14. CRT filters are generally shit. They tend to recreate the effect of a crappy NTSC tv. We never had that bad pc monitors back in the 90s. The original pc with a cga card and using the composite output is the closest one gets to crt filters. That however was a 4 color graphics mode, (more can be faked on ntsc). A lot of pixel graphics for PC did look pixelated, just that the edges were slightly fuzzier than they are today. The pixles weren't exact squares like today, they consisted of a ton of colored sub pixels, the phosphor dots.
×