Super Moderators
  • Content count

  • Joined

  • Last visited

About fraggle

  • Rank
    Registered just to make two posts
  1. These seem like bizarre reasons to be choosing a language though. It sounds a bit like you're saying "this can't work well with the nuts.wad use case where you have a million monsters, so we won't even consider it". Why focus on that as the most important thing? I want something that beginners can pick up easily. Something that people can have fun with and that will work well enough on most maps. Can't we focus on the users and make something that's fun to play around with? Performance is important at all but sometimes it's nice to let your hair down and do something more experimental, interesting and imperfect.
  2. Written from scratch when I was 17 and didn't know anything about writing compilers. I guess that's something of an achievement in itself, but it's a horrible codebase in retrospect (I had no idea what I was doing and now know a lot better) and the language itself is a mess and is missing many basic features, like functions for example. Bits of the syntax are braindamaged because I was too lazy to do them properly - for example the for loop syntax uses commas instead of semicolons because it was easier for me to code. It's rather disappointing to me that there doesn't seem to have been any serious attempt to add scripting to Doom with a dynamically-typed language. FraggleScript is the closest thing that exists. I really want to see a Doom source port where I can just bring up something like a Python console and just reprogram the whole thing from inside itself in real time, but nobody else seems to share that vision. My main idea when designing FraggleScript was that it ought to be as simple as possible because most of the people using it were probably going to be level authors and not programmers. You shouldn't have to learn something terrifyingly complex just to make a few doors open in sequence or whatever. I still think that's a good philosophy, though in retrospect even FraggleScript's syntax seems overly heavyweight. I've even pondered the idea of making something like a "DoomBASIC" because for all its flaws, BASIC was trivial for most people to pick up in the 80s and most people scripting levels probably don't need anything much more advanced. Despite all the advanced source ports we see nowadays, it still seems like scripting is something of an inaccessible dark art. I'm a bit out of the loop with all the levels that are coming out nowadays but it seems slightly strange that people aren't using scripting more.
  3. To avoid any ambiguity: please don't promote the use of FraggleScript for anything. It's a badly designed language with a bad implementation. Maybe the Legacy version has been "hardened" but I doubt it addresses any of the fundamentally broken issues with the language or the codebase.
  4. They're both well done games but the tone is very different between the two. I'd compare it to the difference between Terminator 1 and Terminator 2. Doom is atmospheric and moody while Duke3D is far more light-hearted. Doom is far more abstract in level designs while Duke3D builds realistic locations: cinemas, burger joints, bars and you know the rest. I feel like there's an element of experimentality to both games. PC hardware had crossed the threshold where a fully-formed FPS was possible. There's a sense that the designers are slightly in awe of the fact that they can build these virtual worlds people are going to be able to run around in, but it drives them to make different things.
  5. I don't know if it's possible to do access control like that with this software. But Linguica will be able to answer better than I can. I'm glad that you want to take this measure though, since it's clear that this thread is in disarray. I was worried that something like this would happen (see my earlier comments). I think what's needed is either private discussions with a limited group, or an open discussion where participation is restricted or heavily moderated. I'd also suggest any discussion threads need to be narrowly-focused (many small ones) rather than wide-scoping and grandiosely-titled like this one is. I think you need to define some process and/or ground rules. It would help if you started out by forming some consensus on what you even want to achieve. Maybe write down (and get others to agree upon) something that describes: What your goal is - for example, defining a new set of minimal extensions to the Boom "standard". Be as specific as you can. Any essential requirements you can think of. For example, one might be that linedef types should not conflict with those already in use. The scope of the work. For example you might declare "we only want to define new linedef and sector types". Clarify what is not in scope - I'd suggest "we are not planning to change the level format" and "we are not planning to define a new scripting language" as examples. Agree upon the rules by which you will reach consensus and make decisions. For example it might be that "all source port representatives must agree", or it might be "if three source port representatives agree". Rules of discourse. For example, reach a consensus about general approach before proceeding to the detailed design - no dumping huge, complicated detailed design proposals into threads. Maybe this all sounds too laughably bureaucratic but the truth is that reaching consensus on something like this is an exercise in political negotiation. Different Doom source ports represent different design philosophies, so there will inevitably be tension between people with radically different points of view (could GZDoom and Chocolate Doom be any more different for example?). I'm still optimistic though. Lay down some ground rules and a limited scope, and I don't see why people shouldn't be able to reach some consensus on things.
  6. All standard medikits and stimpacks for their brazen violation of the Geneva convention.
  7. It's not that 320x200 made for some compelling screen mode and the id guys specifically wanted non-square pixels. Rather it's just what the VGA hardware present in early '90s PCs was capable of. Generally speaking with VGA the "standard" modes were either 320x200x256 colors or 640x480x16 colors (you could achieve other modes but they were kind of undocumented hacks). With the extra color depth 320x200 clearly won and I don't know that 486es would have been able to manage rendering Doom at 640x480 anyway. The next logical question is "why does VGA have 320x200 instead of 320x240 which would result in square pixels"? The answer is a series of answers, each of which boils down to "backwards compatibility with older systems": VGA had 320x200x256 presumably because it matched EGA's 320x200x16 - it was an extension that added more colors. EGA had 320x200x16 presumably because it in turn matched CGA's 320x200x4. CGA had 320x200x4 because its hardware was designed around displaying an 80x25 character display. All the CGA modes are essentially multiples of 80x25 in some way - tradeoffs between color depth, pixel count and number of characters in different dimensions. CGA targeted an 80x25 because 80 columns was the golden standard for a computer display in the '80s. 80x24 / 80x25 (extra line for input) was the de facto industry standard for computer terminals in the '70s, driven to some extent by IBM's own terminals like the IBM 3270. Using a compatible standard means that the PC can interface to all IBM mainframes, etc. If you follow it back further than that, the '70s display terminals were the successors to '60s teleprinter terminals which used 80 columns, and those to IBM punched-card machines which operated on cards standardized in the 1920s which had 80 columns x 12 rows (ie. half of an 80x24 display). So uh, that's why Doom has non-square pixels.
  8. I don't choose frame numbers myself - the library does it all automatically, including choosing frames which can have action pointers for frames which need action pointers. The actual frames are configured using a variant of the DECORATE syntax - it was actually fairly simple to convert the DECORATE version of the smooth weapons mod: mostly just cut and paste with a few fixups. No, but I'm not sure the sprites I am using are the best ones - I think the weapon sprites people are using nowadays have had some improvements based on eg. fixups from the minor sprite fixing project, and I'm not sure I have those. The fist sprites in particular look weird.
  9. While I appreciate your desire for ~~~authenticity~~~ I do think perhaps you're taking things a step too far in the opposite direction. Some of these things things are popular things to see for legitimate reasons, and if this is a once in a lifetime trip you might regret not seeing them later. I'm talking about things like: The clock tower of the Houses of Parliament ("""Big Ben"""). I used to live in Westminster a few years ago, and it's a pretty stunning piece of architecture. I never got tired of seeing it whenever I passed it. The British Museum, with all the (stolen) Egyptian mummies, Greek marbles, the Rosetta Stone, etc. The Louvre in Paris - forget about the Mona Lisa but there's a ton of really famous stuff in there. I remember being particularly captivated by da Vinci's St. John the Baptist, which is stunning in person. Rome - The Sistine Chapel? Up to you of course but Europe has a lot of culture and history. You might be missing out. A lot do, but it goes a long way if you at least make an effort to try to learn at least a few words. Particularly in France.
  10. Working with the limited frames is certainly a huge problem with vanilla dehacked (there are only five free frames in vanilla Doom's tables). I've devised an assortment of different strategies to reclaim additional frames in ways that should be subtle or undetectable. My version of the mod isn't finished yet - I used a different version of the Perkristian sprites, but I should probably be using yours instead. Notably there's no BFG yet, and the plasma rifle has a weird hovering chainsaw sprite when you play it in *ZDoom ports. But I think it makes for a nice proof of concept that shows that a vanilla port is possible. The mod is intended to serve as a demo for my Python Dehacked library, which I haven't yet released (I'm planning to release them both together). One of its most interesting features is its ability to automatically identify which entries in the frames table are unused, and use the reclaim strategies I mentioned above to acquire extra frames on demand (they can acquire about 200 frames, but the more desperate strategies will be more noticeable to the player). That's the idea, yes. I haven't (yet) tested it with proper vanilla Doom under DOS, but mainly just because it's a pain to set up and Chocolate Doom is an authentic enough test bed. It should work fine with Chocolate Doom: "chocolate-doom -merge vsmooth.wad -dehlump" should work as intended.
  11. Slightly off topic but I'm working on a pure vanilla version of the smooth weapons mod.
  12. Simon the Sorcerer, definitely. Most of the Space Quest games probably match your description of absurd humor. Day of the Tentacle was recently re-released in a remastered form.
  13. Previous thread where Laz Rojas himself commented on some of this: Probably read his post there before jumping to any unfounded assumptions.
  14. Not clockwise?
  15. With a bit of work I imagine you'll probably be able to get most SDL-based source ports running on Haiku. It's the "bit of work" that's the key thing though. It's great that you're interested in trying out OSes like this and I don't want to dissuade you, but for something like this that's experimental there's probably going to be a lot of learning you'll have to do.