kb1

Members
  • Content count

    1311
  • Joined

  • Last visited

Community Reputation

38 Neutral

2 Followers

About kb1

  • Rank
    Ask me about my source port
  1. Theoretically, older maps should not be using linedefs that have never been defined, which is why it makes sense to have new features use new identifiers. I suppose a map or two may have some bad linedef nums, by accident, but those have to be extremely rare, as there's useful no reason for them to exist. Of course, PrBoom+ behavior will be preserved. You make a good case for going C++ for better parsing, more code flexibility, and for add-on modules. But for core doom source, for me, C++ is way down the road. I wanted to ask about the UMAPINFO: Earlier I talked about putting some per-map identifiers into the format: MapType, Port, and maybe PortVersion, and/or StandardVersion. Have you given these any thought, or considered their usefulness? (The description is in the 4th post of this thread). This was in reference to the idea of converting port-specific linedefs to common numbers. I also asked how ZDoom accomplishes this. It may be possible to encourage port devs to start using unique numbers for their new linedefs that don't conflict. But even if that doesn't happen, a protocol for conversion could provide another way to solve the problem. Can you share your thoughts? Technically true. But there can be a standard for data. Good, interesting stuff! I have to agree with Graf, though, on adding as much of that as possible using existing, or generic code-pointers and linedefs, etc, even if you intend on the new objects being standard equipment. KBDoom has its core WAD file that it needs to run, but it also comes with a non-user-editable Effects wad file, that defines things like extra blood effects, smoke, fire, etc. This file defines all the new things, which use custom code pointers, sounds, pickup and weapon sprites, that all get dynamically added to the engine. However, this file is completely removable, or can be turned off with a command-line switch, leaving the game running in a completely stock manner. This is a good way to add the kinds of thing content you describe, when combined with some useful, but generic code pointers. It's a lot of work to set up, but very nice to have.
  2. I know. All I mean is that it is deflating and depressing to hear that something you've poured your heart and soul into for years is shit. Maybe it is, but all I ask is to take it down a notch, out of common courtesy. Not everyone has your mad programming skills :)
  3. Yes, it is a bit early to seriously consider adding any new specials, but I do appreciate people discussing them and brainstorming about what's possible: It helps me stay focused on what we're trying to do here. To be honest with you, I did not expect that you were considering spending any appreciable amount of time on PrBoom+ - I thought your commitment was on UMAPINFO (nice job, by the way!) If you are doing more with it, we should prepare to be very careful to synchronize, because I am committed to creating the first rough draft of this new specification, as well as porting my KBDoom code underneath this specification, as a fork, into the latest PrBoom+. Everyone has been "asking me about my source port", and as everyone knows, I've been holding off. A lot of that was due to procrastination, but mainly, I didn't want to just release yet another conflicting source port. Instead, I want to contribute something that encourages cross-port compatibility. C++ and Hexen Format: I can't say that I agree with two of your major goals: Conversion to C++, and Hexen support, especially in this phase. Both of these goals conflict with the idea of keeping it simple, and widely adoptable. Many ports have no immediate plans to support Hexen, Heretic, or Strife, for example. And there's a large learning curve going from C to C++, which conflicts with wide adoption - again, some people want to start with something that resembles the Vanilla/Linux 1.10 source release. I don't want to convince you to inhibit your efforts, but I'm going to be going in a different direction. Having said that, I do not intend on writing code that conflicts with your goals, quite the opposite, in fact. But, I will not be converting my source to C++ any time soon. Back to the Hexen issue: If the map editors do not yet have sufficient UDMF Doom support, that can be added. Yes, Doom editing will hit a brick wall. The fact that you cannot specify a thing Z coordinate without hacking (KBDoom optionally interprets the lower 3 bits of the Angle field as Angle, and the upper bits as Z * 8, to support thing placement on 3D floors) is a big issue. Because we are defining a new standard, I suggest taking the Doom format to its limits, before forcing a map format upgrade. Personally, I want my port to support all the other idTech1 games, but not all ports do. At that stage we can discuss a Heretic/Hexen/Strife set of specifications. However, UDMF *can* eventually apply to this spec, but it's too big for a Phase 1. @traversd: Interesting ideas! This is good stuff. But, instead of fixing existing linedefs with a complevel, creating a new linedef special that has different/fixed behavior solves the issue, without adding to the dizzying number of complevels. Complevels are there to support differences in ports that are no longer maintained. Can you imagine the confusion that can be caused by having a "original Boom 2.02" complevel, and a "Boom 2.02 + Boom Phase 1" complevel, etc.? You'd be half-way through an hour-long map, only to have a sector not operate - this is a nightmare. I intend on having a clear separation of duties, between demo version indicators, complevels, and the modification of any existing data structure, functionality, etc. Using PrBoom+ as a base instills an awesome sense of responsibility, to avoid disrupting the demo sync apparatus, the gameplay feel, etc. @Da Werecat: I must be clear about this: Having stated what I did about complevels above, I am not totally against adding a complevel in principle, but it must be for the correct reason. And, it may eventually make sense to do so, with one caveat: Only PrBoom+ supports complevels, so requiring that we, for example, must choose -cl 20 to use the new standard seems misguided. Again, complevels are there to tell the engine to emulate an OLD port. There will be fixes, but they will be in the form of new linedefs, which none of the old ports understand, so there is no conflict. @Liberation: Yes, you've got the right idea: Phase 1 must remain simple and focused, and easy to add support for, if we are to expect its wide adoption. Looking at your bullet points: Full Boom/MBF, and BEX: Yes, this should be a prerequisite. And, BEX comes from Boom and MBF, it can be included as well. UMAPINFO: This is a wonderful, useful addition to Phase 1, as it provides lots of immediate mod capability, and it's relatively easy to implement (once written), and applies universally to any port. Extended specials: This can provide the incentive to add Phase 1 support to your port, so I think it should be included. The number of added specials is not so important. What is important, is the feasibility of adding support, without causing conflicts in port philosophy. For example, any port that supports light transfer can handle the newly discussed ceiling/wall/floor light transfer proposals. Complevel and demos: This standard will not ensure that a port can properly play back demos from any version - that's up to the port devs to decide how fluently the port can render demos. The standard will be independent of complevels, by design. They may seem like related concepts, but they're not.
  4. Please be nice - Legacy is being actively maintained :)
  5. This is great news! Great job, Graf! I have decided to operate on the assumption that most ports will adopt an enhanced standard, especially as the benefits become clear. Either way, there will be ports with the enhanced spec, in time.
  6. 16.16 gives you numbers in the range of -32768 to +32767 with a granularity of 1/65536. In machine language, you don't even have to shift, which was helpful in vanilla. Especially back then, divides and multiplies on ints were much faster than with floats, and Doom needs various amounts of fractional precision throughout the engine. And, it's not just 16.16, it used 12.20 and others. This is the essense of the Wiggle Fix code - it dynamically adjusts the ratio of whole to fractional units in specific wall accumulators to prevent a nasty renderer artifact that causes walls to shift around unnaturally. Essentially a home-grown floating point using fixed point variables.
  7. I don't think anyone tries to add bugs in their implementation. The bug you linked references a version of DECORATE that's beyond an initial "DECORATE-lite" as it mentions a code pointer with arguments i.e. an ACS code pointer. This would probably be considered too advanced for an initial global adoption of DECORATE, especially when many source ports don't even support Hexen - where ACS originated. But, yeah, good point: Be careful to implement DECORATE, and any other code, carefully, and do good testing.
  8. Graf is forking the source, making it a port all in itself. And, it will get picked up and advanced from that point, trust me! Yes, the database of port/map settings was my thread (I think). It's a huge problem, and it gets worse every year. Compatibility is a big issue, it makes things difficult for everyone involved. But, it doesn't have to remain that way. Please see this thread for the beginnings of a master plan to try to attack this monster once and for all. It won't be easy, or fast, but it's worth a shot. JSON is easily parsed in C, as long as it doesn't get too crazy. But, we're talking about name/value pairs - it really doesn't get much easier than that.
  9. You know, I was thinking about that: Maybe the linedef type should be internally represented as 32-bit, with a set of game, or even port enums to differentiate - something like this: #define GAME_DOOM (0x00000000) #define GAME_HERETIC (0x00010000) #define GAME_HEXEN (0x00020000) Maybe even in combination with this: #define PORT_VANILLA (0x00000000) #define PORT_LEGACY (0x00100000) #define PORT_ETERNITY (0x00200000) Most of these would map to the same effect, as with &0x0000FFFF, but lines with effect 272 - 500 could get mapped internally to unique linedef actions. For older port-specific maps, ports could auto-apply PORT_XXXX on map load, providing support. A new MAPINFO flag could specify PortType and MapType, with PortType defaulting to the actual port you're playing, and MapType being determined with heuristics. These could also be set via a command-line override,, or maybe even a special lump for each setting, allowing -file LEGACY.lmp to force a mapset to use Legacy-type linedefs. The idea being that, once the engine determined which game and port that map was for, linedefs could be interpreted based on which port ans game the map was defined for. This would suggest the need for something I've wanted to see for years: A map type, and port type identifier. This is easy in UDMF, and, of course, you can determine a Doom vs. Hexen format with heuristics, or the presense of the BEHAVIOR lump, but ZDoom's Doom-in-Hexen format might require more. A standard map type identifier could be part of the standard, and it'd make engines and editor's job a whole lot easier. ZDoom currently uses conversion tables to disambiguate linedefs and things, right? One more identifier that I think is important is Standard Version Number. This will provide a mechanism to handle compatibility in both directions: future and past. So, if implemented in MAPINFO, you could exactly describe a map as, for example: DOOM/ETERNITY/LEVEL 1 Standard. This would be a beautiful thing for map viewers, editors, and the game engine itself. For the first time, we could definitively tell the user "This map has features I don't understand. Load anyway?". With something like that, even if your port cannot support the map's features, you can tell the user. At home I have a launcher I've been working on, and a database of Doom WADs. The database program has a function that tries to determine which port to launch, for each WAD. That code is multiple thousands of lines long, and it only does a fair job at properly choosing the right port! It's a nightmare, but it could be avoided by marking the maps with identifiers. What do you think? Another possibility is simply to use the unused remaining linedef types, and not be concerned with being able to load an old port-specific map for Port X in Port Y. I think this kinda misses the point, and would be unfortunate. There's no reason why we cannot do better, except that it requires more careful planning. Boom tried to be wise, in the allocation of linedef types. They tried to put the most useful linedefs numbers below 256, to provide support to editors that only supported 8-bit linedef numbers. Similarly, we should put the most useful effects in the low 16-bits, and the more exotic effects can be only accessible via UDMF. I think UDMF and DECORATE should be part of this new standard, not as Phase 1, but for an eventual goal. There are good arguments for both: UDMF can specify any and all possible additions to the map format, by its very nature. And DECORATE is a complete, compact, time-tested thing/frame definition language. Even the addition of scripting could be compartmentalized by defining the script language type at the top. I'm big on global identifiers that can be used to define how to interpret what comes next, as it provides future flexibility. I noticed that from the other thread. This sounds like a good, easy-to-implement addition. There's another thread from a few years ago that has some more linedef suggestions, as well as thing codepointers. I'll see if I can't hunt it down.
  10. If something's worth doing, it's worth doing right.
  11. Yes, it makes the most sense to borrow off of the hard work that's already been done. Please see this new thread.
  12. Recent threads have revived discussion on the current state of compatibility between source ports that strive for limit removal and mod capability enhancement. Currently, the best a map author can hope for, in terms of modding capability, that can be expected to run in most all source ports, is the vanilla format, plus the additions afforded by Boom and MBF. After the release of Boom and MBF, port authors began adding features that, for whatever reasons, were not accepted and adopted by all source devs. Of course, this forces map authors to choose a port to mod for, if they want those extra capabilities, and it forces players to use that port to play these maps. There will always be advanced, port-specific features, and that's a good thing. It promotes continuous advancement. But, it would be nice if port devs could add some of those features in a standard way that all ports could take advantage of. This thread is to serve as a place where we can discuss a possible update to this standard, beginning with a narrow focus on which features can be readily added, without conflicting with each port's philosophy and direction. This idea has been attempted before, and failed, I think because the proposals did not encompass all possibilities, or did not take into account some capabilities of this port or that. Because of this, I suggest some ground rules: Start small - For this first phase, we should only include things that all ports can use. For example, 3D floors is out, as it requires drastic changes to the renderer, and game logic. But a replacement for, say 242: Boom water/prop transfer is a good place to start Future Extensibility - There should be no updates that prevent the ability to expand capabilities in the future. Use existing port-specific capabilities wherever possible - The new standard should leverage on the existing capabilities afforded by advanced ports such as ZDoom, Eternity, Legacy, Edge, Vavoom, etc. No need to re-invent the wheel. But we may have to modify how they are accessed, to fit into a global standard. Research each addition - We don't want to, for example, use a linedef number that a source port is already using. Boom took the bulk of linedef numbers, leaving a small subset. We should compile lists of unique scarce resources per port, to see what's available Dev Review - For this to succeed, the devs need to be involved. The port devs intimately know how their port works, and they have plenty of good ideas to contribute. We must collaborate like never before, if this thing is to get off the ground. Eventually, after converging on what this update should entail, these ideas can be compiled into a specification, which will be submitted for modification/approval. That can, in turn, be turned into a source code module, which, not unlike Boom, can be dropped into a project with minimal changes, improving the chances of wide adoption. But, we're nowhere near there yet. This thread can be a place for new ideas to be included in that standard. Please restrict replies to discussing ideas for an upgrade to our current standard, if possible.
  13. Thanks so much for this - I hit the same brick wall. This is helpful. This is used to regular expressions against demo filenames, for the automatic setting of complevel, right? Did you write a parser to read that data I posted, and replace the hard-coded values with variables populated from the parser? If so, very cool! When I made that, the goal was to simply get hard-coded values out of the executable, into a lump. This is Priority #1 for upping the port standard: The removable of hard-coded values from the exe.
  14. I'm curious about getting the data in and out of the graphics card. That seems like a time-consuming ordeal...unless you plan to somehow get the level data itself unto the graphics card. I can't claim to know much of what your possibilities are, but I wish you good luck!