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

SaladBadger

Members
  • Content count

    1424
  • Joined

  • Last visited

Posts posted by SaladBadger


  1. much of it is sourced from Sound Ideas and then cobbled together and edited in various ways. Perkristan gives a look at what kinda things were done here. The rest is recorded from various sources. What are these sources? you'll have to ask bobby prince I guess. He's mentioned some of the things he's done, such as editing a recording of a girl saying "why" for the archvile death sound, and of course there's the famous Icon of Sin sound. I can't find the post anymore, but Bobby once remarked when he needed a mechanical sound for a Duke Nukem game, he recorded a bit of the sound of a vending machine dispensing a drink at the office.


  2. I wonder how much interest mod support will churn up. The presumed difficulty of it is a factor, but at the same time small teams of developers make pretty good things in other modern game engines, so maybe we can set that aside. The big worrying factor for me is that Doom 3 doesn't have a huge amount of mods, and RAGE has very few at all, but at the same time both of those were less popular games. Doom 4 has had a small but dedicated modding community, suggesting that there are people who are more than willing to cut their teeth into Eternal modding, which I can assume is because it is a more popular game that people would want to work on and extend.


  3. The original version came in a simple box with a printed manual and the game on 4 floppies. This wasn't sold retail in the states, it was only available via mail order. I don't know offhand if it was shrink wrapped or not. In contrast, The Ultimate Doom was made specifically to give Doom 1 a retail presence in the states. (For its entire lifetime, Doom 2 was made specifically to be retail too)


  4. I'm going to go out on a limb and say that "there was no mouselook in doom" is more because of technical limitations (y-shearing is not elegant (carmack might have rejected it on those grounds), and the renderer would have to be much slower in order to support it properly) rather than people not considering the idea of looking up and down with the mouse. Surely there were flight sims and the like that would allow for you to look around like that. Just the fact that id was already even using the mouse to turn as early as Wolf3d suggests they're perfectly fine to experiment.


  5. This is honestly likely a false memory, as there's no special code to do this in the original Doom source. Maybe you're remembering the slime floor? If you were playing on ITYTD and had the megasphere from the entry room, the slime would passively do 1 damage every damage tick. I can't really scrape up any explanation here. I suppose a really bizarre memory corruption bug could have given every sector a slime special, but this seems exceedingly unlikely.


  6. I think if I have a problem with the first person "cutscenes" in the Half Life series, its that since you have full control, you're free to basically just go around, crowbar everyone, crowbar everything in the scene, play basketball with props, and so on, all while everything is proceeding normally.

     

    ... Has anyone made a SFM vid where they run through a HL2 scene perfectly normally but add a Gordon in the background who's doing all these things?


  7. can you use the console command "changemus" to change the song to D_OPENIN? if you can't, that suggests something is wrong with the song file itself.

     

    It's unlikely to be memory, 120 KB is fucking peas on any remotely modern system (for reference, Dave D. Taylor blues is 63KB, right at the limit of the MUS file format).


  8. I like lifts when you approach them from above. I tend to make the player drop into dangerous situations a lot in some of my maps, and lifts make it harder to just back out after you dropped, while still providing the option.

     

    in any case, this is the first I'm ever hearing of this supposed hatred of DR doors, but I get rdwpa's point. But is this really a good reason to just say "using line special 1 is the devil?" I like using a few doors on my maps, not one for each room, just to add some separation to my maps. if I'm trying to segment off a big battle or something, I'll frequently use a drop or something instead.


  9. What version of GZDoom are you trying to load the satyr wad into? The current iteration works fine in the latest version, with no error messages. Did you edit the satyr wad in any way?

     

    And yeah, if you want these newfangled monsters to show up in Doom Builder 2 at all, you'll need to get GZDB-Bugfix instead, which is maintained and has facilities for loading zscript enemies. Also keep in mind that the ZScripted Realm 667 monsters DO NOT have editor numbers by default, and since they're zscript, you'll have to use MAPINFO to give them numbers


  10. it'd require more than that, I feel. From the "8mu = 1 foot" scale id's thrown around a few times, you learn that Doom levels are fucking gigantic. Scaling them down to a size where someone would be willing to walk through them to work would require pretty extensive changes, and it doesn't work so well when your player is car speed rather than human speed.

     

    It's all possible, of course, but the resultant WAD would not be Doom at all anymore.


  11. To add a minor thing to #1, since you bring up the alphas in the first place, this line is present in the Doom 0.4 ALPHREAD.ME file:

    8       Good level for network death matches, awaiting gettable objects.

    I have to assume that given this following line in the document, whoever was writing up the readme was speculating more than anything.

    o  N-E-T-W-O-R-K-I-N-G (actually, it's sort of in there now, but you can't move anywhere, so...)

    If this is true, apparently there was already some net work done at the time? (there's stuff in the executable's symbol tables about ACKs, comm ports, sending frames, etc which may confirm this?). But in any case, it confirms that networking was considered for a long time and that "deathmatch" as a term existed as early as April of 1993.

     

    ed: a look at the strings I've found related to networking and multiplayer in doom 0.4:

    Syncronizing
    Communication syncronization aborted

    Network sync? The comm stuff could be referring to any sort of comm device, but this seems to more strongly suggest networking

    G_InitPlayer: bad player number
    G_RunMap: player %i not spawned on map %s
    G_WarpToMap: player %i not spawned on map %s

    Referencing multiple player numbers

    P_ProcessFrames: Lost input from player %i

    well i dunno when this would occur. on a disconnect? I dunno

     

    I poked at Doom 0.3 also, but Doom 0.3 appears to have been made with a different compiler, and looks like it was symbol stripped, so no peeks at the function names. In addition, error messages related to communication sync don't exist, but there are the lines referring to player numbers, suggesting MP was thought about when architecting things.


  12. I very much recommend the black book. It's got some mistakes here and there, but there's nothing that will trip you up too severely (thankfully there's an errata sheet and fabien's updated it at least once so far (btw, to anyone who owns it on Google Books, it is updated there, surprisingly!))

     

    If you are interested in "unrolling" the whole game, d_main.c is where you will start, it's where D_DoomMain lives. g_game.c is where tics are actually run. the i_ files are interesting, as they're (supposed to, at least, the linux doom "sound server" was implemented in a somewhat intrusive manner) where all the system specific code is placed. The included i_ files are for Linux, but you can get a feel for what the dos ones are like from the heretic and hexen code.

     

    In case it's even remotely helpful (after writing all of this I started to question it...), here's a quick look at the namespaces, as I understand them:

    • d_: overall things related to all parts of the game. Where D_DoomMain lives.
    • f_: finale, related to showing the text screens, the doom 2 cast call, and the screen wipe effect.
    • g_: game, handles running the game logic. Handles starting, progressing through, running, and the like with the game.
    • hu_: hud, handles the text line at the top of the screen and a few other things.
    • i_: things that are platform dependent.
    • m_: the source calls this the "main menu loop", but it also contains other misc functions.
    • p_: the playsim. Where all the logic making the maps do their things, all map objects do their things, player specific code, and so on.
    • r_: renderer. Elegant but it'll take a bit to understand. This is the one place where I feel the Game Engine Black Book can fall a little short in a few places, it gives a good feel for the overall picture but I think there's some really neat things that are lost in Fab's work. It explains perspective correct texture mapping in overall terms, but doesn't explain how Doom does it (which I believe doesn't require divides?). Do give it a good read though, it gives the overall picture of how the BSP tree is created and iterated, how lines are projected, how visplanes are created and merged, how lines are clipped, how sprites and lines with see-through bits are rendered, and many other things.
    • s_: sound. How sounds and music are emitted. the released Linux Doom source did a lot of changes to this...
    • st_: status bar.
    • v_: video. Handles the creation of the game's multiple framebuffers, handling the "dirty box" (region of screen to update), and basic drawing tasks. GEBB will give a good feel for why there are multiple framebuffers. Is this referring to the shotgun wrap bug in Final Doom?
    • w_: wadfiles. dunno what to say about this...
    • wi_: world maps and intermission. It's the intermission code.
    • z_: zone memory allocator. Why a custom memory allocator? Some of it is a legacy of id's 16 bit games, but it carries some useful functions and can help reduce memory fragmentation. Also allows for caching WAD assets.

  13. all i can say looking at this picture is

     

    "hey look it's a bony revenant"

     

    Have there been any clear pics of the Doom Eternal revenant? I liked the 2016 one but at the same time I really did kinda miss the bony guys we came to know and love from Doom 2 and 3.


  14. here's mine: i think descent's automap is mostly usable (bank controls in it can get fucked though) if you orient yourself with the mine and use multiple reference points

     

    i fully feel they could have added something that works similarly in quake and it would have helped a lot, probably even better than descent itself since you can't bank and the levels aren't near as twisty


  15. in theory, though, a thinner walls gives more opportunities for the projectile to hit something. An imp's fireball has a diameter of 12, but only moves at 10 units per tick, so unless I'm missing something obvious, an imp fireball will never go through a wall outside of nightmare. A baron's fireball could, as it moves at 15 units/tick, but a wall thicker than 3 units would be sufficient to stop it. Mancubus fireballs (and for that matter, imp, baron, and caco fireballs on nightmare) still have a diameter of 12, but a speed of 20. In this case, they should be sure to hit a wall that's more than 8 units thick but less than 32 units thick. So there's no strict technical reason they need to be 16 units thick, but it does fall in that range of greater than 8 but less than 32. In some cases, projectile clipping is just sort of unavoidable. They go through walls on Dead Simple that are way thicker than 16 units.

     

    ed: i say unavoidable, but you could keep your walls always thicker than 8 units and pad any one that's thicker than 32 units with extra sectors between them in the void to try to stop the projectile. If you have a big detailed map though, is it worth soaking segs on that though?

×