kb1

Members
  • Content count

    1539
  • Joined

  • Last visited

3 Followers

About kb1

  • Rank
    Ask me about my source port

Recent Profile Visitors

641 profile views
  1. Hey, you're the one who said "I take it"...
  2. I sure hope so...for everyone's sake involved.
  3. Geez, way to follow guidelines: "Just a few more tweaks, and I'll be ready to release the contents of my PENIS on you guys..." There's a couple of good serious ones here. I'm not too keen on using "*oom", as it sounds like a port, and I'm not on the Boom team (which is an "*oom" name). Seems like "extended" should be part of the name. I like the idea of the 2-digit year at the end, though "17" sounds a lot more inferior than "99". And, I hope it doesn't take a year between releases, though the year is flying by... I was hoping to get some of these words in there, if we were going for acronyms: extended, enhanced, compatibility, compatible, common, community, standard, specification, baseline, mapping, mapper's, doom/boom.
  4. You use a lot of visual words to describe something you're supposed to hear: "scene", "image". Also, an emphasis on the listeners, and a need to grow. First of all, metal musicians are amongst the ugliest people in the world :) And, second, "metal" as a loose term is quickly approaching 50 - nothing juvenile about that. Finally, I don't want it to change. If it's good, it's good. Why does it need to grow? It's already as bad-ass as it needs to be. What happens when it "grows?" All those ridiculous labels I posted above. Good Lord, give me a wailin' riff or two, some tight percussion, and the ability to sing in key, and I'm set.
  5. So, is it exclusive to PNGs, or are tall Doom textures supported too? (max 509 pixels, I think).
  6. @zokum: Of course, a range can be reserved for non-specific port use, but you have to understand that this flies in the face of compatibility. Also, the rotated wall effect you mention will not work across all ports, as I understand, because some ports don't use those values for rendering - another stab at compatibility. Don't these types of walls have blockmap issues, where the player bumps into nothing, or can pass through portions of wall? Or, does the builder take this in account? I have to ask: What advantage does this give the mapper, that cannot be accomplished by simply drawing the wall at the intended angle in the first place? (Please understand - I am not trying to discredit the functionality, I just don't understand what's being accomplished. My goal is to be able to document what each linedef type does, as Jon suggests. @Jon: This is a great idea. I'd love to see it support all idTech1 games. I've been fiddling with a much less useful version of this for a while now.
  7. For 20 pages and counting, we've been discussing the project of creating a specification for a new mapping standard that extends the capabilities of Boom/MBF mapping. But, this project lacks a name. It's important to have a name, so the standard can be referred to easily. I am terrible at such things. Please help! This specification will be developed in stages, or "phases", starting, of course with Phase 1. So, it's ok if the name has "Phase X" as a suffix. But, what should it be named? Please limit discussion to this purpose, if at all possible. Suggested guidelines: Please avoid symbols, like "+", or any character that cannot exist in a filename. Does not need to be "*oom" Nothing too silly, please. "KaBoom" was mentioned, but I'd like to avoid that one - it's too close to "KBDoom". Please limit to one or two words.
  8. I might be wrong, but I don't think it's wise to include UDMF in Phase 1, if we're going for mass adoption - it'll scare everyone away! It's scaring me away, at the moment. UDMF is an optional add-on that some ports may not be willing to implement right away. It can be thought of as an isolated package without forward dependencies. UDMF will eventually become a prerequisite for later phases, but, as of yet, it's not essential, and we have plenty of things that are. Let me be clear: I fully intend on providing proposals to extend the Doom format as much as possible, provided that reasonable, practical solutions present themselves. There is no reason that this has to hinder other efforts, such as Hexen and UDMF mapping, and even Heretic/Strife mapping. I intend on supporting the broadest possible mapping capabilities, for all map formats. Having said that, it may make sense to work backwards a bit: Implement some Hexen/UDMF primitives, and "back-port" those into the Doom format. That might save some coding effort, and avoid some duplicate code. Let me please re-iterate the goal: The original goal is to update the baseline mapping capabilities that a mapper can reasonably expect to be able to use, in ANY enhanced port. That does not suggest UDMF, Hexen, ThingDefs, or any of that. I think we can eventually get there, and I'd love to get there. We both said it: We need to start small, and get some enhancements out there in the major ports. Your UMAPINFO was a huge step in that direction. As an idea thread, discussing eventual UDMF support is most welcome. Ideas are one thing, but implementation is another. We cannot rush into it - we need to produce easily adoptable stuff. If we are really careful, and if we plan ahead, we can pave the road, so to speak, so that the newer features can be dropped in without too much difficulty. But, if we rush, we could end up creating nightmares for the various port devs who believed in our plan. I want to avoid that at all costs. So, what can be easily adoptable? Again, UMAPINFO, some needed bug fixes/replacements on existing stuff, some new features in existing structures (read "Doom format"). So, a couple of questions for you: (Sorry if I've already asked, and/or if the info can be found elsewhere:) If I make a UDMF map, and mark it as a "Doom" map, I cannot set, for example, TIDs, or use any of the 5 special args? Even if my engine supports Hexen? Asked differently: Does the map type (namespace?) of a UDMF map simply tell the port to interpret a linedef type 1 as a Hexen linedef type 1 vs. a Doom linedef type 1? I'm not the best person to ask, but, if Subversion is difficult to use, why not move your fork to Git, provide entryway full access, and give the port a slightly updated name? (Still like "PrBoom+" ...hmmm - I have no idea. Maybe a new thread is required...)
  9. @Quasar: Yay! Quasar's in, with a nice set of proposed additions! These look very good. You also had some lighting linedefs that took up a semi-large range of linedefs, but you said that it didn't include everything you wanted. Are you still wanting those, and can you specify what else you wanted to see? I think I might need some help on some of the engine-specific ones, like the Strife, and more the Doom 64ish ones. If you don't mind, and can find the time, I'd like to spend some time writing up a list of questions for you, to help me understand exactly what you are describing. Finally, I wanted to ask: About the idea of providing a block of empty DeHacked slots and empty sound slots, is there a workaround that can allow this to be possible for Eternity? (You mentioned previously that it might conflict with EDF.) I appreciate your carefulness in sticking to a 'generically implementable' feature set - that falls in line with my hopes exactly. You asked: "how broadly is this intended to be adaptable?". For now, any port with good Boom and MBF support should be able to implement the first few phases of the spec, anyway. The feature set must be kept simple, because, at this stage, I want the spec to be able to be easily adopted by any "enhanced" (read Boom/MBF) port. Having said that, with the spec, I am also trying to pave the way for ports to rise to the occasion, so to speak, for more aggressive updating, like UDMF, Hexen w/ACS, and compatible Thing/frame/sound definitions. And, maybe more. As the Phase number gets higher, things become more optional. I am aware that some ports may never want to support Hexen or Heretic, for example. For that reason, later specs will be optional, and with careful planning, the omission of one phase will not prevent the adoption of another phase. We'll see if it can be done. @Graf Zahl: I fully intend to provide a clear upgrade path towards Hexen and UDMF support, while, at the same time, providing the most possible support for new features in the original Doom format. And, yes, getting some of these to work in Doom format will require overloading existing structures. There are actually quite a lot of ways to get that extra data into the Doom map format, and some a lot uglier than others. I am hoping to find a middle ground. I think it is important to support the Doom map format to its fullest potential. Our mappers are brilliant, bright people who are capable of handling some deeper concepts, for the ability to have extra capabilities. And, when that's not enough, they will have to use a newer format. But, we are far from exhausting the possibilities of the original format. Adding this type of capability might simply mean dropping in a new module. If we can provide this capability, why not? It's not going to be that ugly. A side-benefit is that we're getting ports to start to understand these new concepts, which will make the transition to Hexen or UDMF that much easier. I don't want to throw Doom format, or its mappers under the bus. I think we have an obligation to take the Doom format as far as it can be taken. Wesley has brought up a lot of ways this can be done. I admit that I haven't spent enough time comprehending some of what he described, but, from what I have seen, there's a lot of potential left untouched. But, this thread is not the place to decide on such things. I'll be sure to present some options in the spec, which we can hash over in depth, when the time comes :) I do intend on getting UDMF support into my version of PrBoom+ and KBDoom. @printz: Augment, not replace. There's lots of good Boom/MBF wads out there. I don't want to have to run them through some converter before playing them! UDMF support is intended, but, certainly not in Phase 1. It's too big, and it requires lots of preliminary work (var sizes, node formats, parsers, etc). @Jon: Entryway gave me his blessing to expand upon PrBoom+, as long as I took care not to mess up compatibility, so, I think we're good, there. I like your definition: "Things Boom could have included, but didn't." That sums it up well! @Coraline: Thanks for the list - that's very helpful. I would suggest keeping your numbers as they are. I have some ideas for handling compatibility within the spec. But, I might also suggest that you start using the in-between numbers just to keep your "impact" upon the range small. @VGA: I'd be a bit careful about proclaiming how easy it is to support new things. The devil is in the details. I'd be inclined to say "Hopefully, it will be easy." :) @Angry_Cat: Me too!
  10. Modern CPUs typically use the same IEEE ruleset when doing math, which means that it is likely that, for a given operation (like a divide), you'll get exactly the same value, to the smallest decimal point. It is when this is not true that desyncs could occur. And, yes, this is less of a potential issue when using fixed-point, which is integer math. Additionally, as Ladna says, compiler flags can let your code "cheat" a bit and not ensure 100% proper math, for performance reasons. And, this is an area where compilers for different platforms will differ in capability. One compiler's "optimize" flags won't necessarily do the same thing on different compilers/platforms. Here, it's best to choose the most conservative option.
  11. Should be ok. But, 300 of them? Will that always be enough? And, can you provide an idea of a definition for them, before you add the GitHub documentation? (Right now, I'm just wanting to get an idea of what different usages you envision.) Another question: If they're not to be used in game, can't you convert them back into normal numbers after the builder tools have run? (I guess maps that use those ranges could disturb tools expecting to use linedefs in that range for node/reject/blockmap effects. I guess I don't understand your usages). But, yeah, no reason those numbers cannot be reserved, but I'd like to know what to call that range, specifically. "ZokumBSP effects"?
  12. @CoralineYou'll get it going. Don't worry about conflicts - they will all be resolved in time. I am interested in what linedef numbers your port currently uses, outside of the Doom/Boom numberspace.
  13. I'd love to see a play-by-play description - a sort of "How-To" document that describes how your GL renderer works. I am sure that would be huge project itself! But it sure would be interesting.
  14. I thought I detected a bit of frustration on your part, in your July 21 @ 3:17pm post - what's that about? Hmmm. I don't think 'bothered' is the right word. Maybe 'concerned'... with the idea of replacing PrBoom+ There's nothing wrong with using features from different ports. And, there's nothing wrong with merging two ports. In fact, I am in the process of dropping KBDoom into a PrBoom+ variant, to take advantage of new control, sound, music, and video support (I'm still using MIDAS sound system from ZDoom 1.11, God help me). This is a big reason why I haven't released my source. But PrBoom+ is basically a finished product, whereas Eternity has goals that dictate that it must continue to grow. Nothing wrong with either approach. But, as it stands today, I can download PrBoom+ and have a stable, high-performance platform for playing standard, Boom, and MBF .wads. If I want to add something to the source, I know where I'm starting at. I can rest assured that I am working with features that are time-tested, and I can predict that this is the way PrBoom+ will always be. Eternity has VERY different goals...which is cool, but not the same thing. If the two were combined, and PrBoom+ development halted, I could not download a maintained version of the community-wide standard. And, here's the kicker: PrBoom+ represents the state-of-the-art compatibility model for Doom. PrBoom+ supports everything considered to be compatible across all enhanced ports, and only those things. That's what the new Boom+ specifications are all about! With the spec, we can add a bunch of new functionality, across the board, to all enhanced ports, and call it the new standard. PrBoom+ is the absolute best port to showcase this new standard in, since PrBoom+ supports the agreed-upon standard, and only the agreed-upon standard. That's why I want PrBoom+ to stay separate. It's the model for every other enhanced port out there. I hope you understand what I'm getting at - this is not a stab towards Eternity - Eternity is awesome! I am simply arguing that I don't believe a PrEternity+ should replace PrBoom+ and cause PrBoom+ development to halt.
  15. When I hear labels such as these... post-rock, math-rock, death metal, anarcho-punk, hardcore punk, alternative, indie, emo, screamo, post-punk, shoegaze, pop-punk, noisecore, industrial, art punk, jazz punk, goth rock, death rock, new wave, new romantic, black metal ...I'll be the first to admit that I have no effing clue what is being described. These are my minimum requirements: Melody - Lots of good muted chugs are great, but there's got to be some type of melody going on. It sucks when guitars are used solely as percussion. Harmony - Dual, harmonized guitar leads, or harmonized singers kick ass Singing - ...with an actual melody, and the ability to actually understand some of the words. Grunting like you're on the can can be effective for a few seconds, but, uhh. Dynamics - Quiet passages as well as all-out assault. Low-register as well as glass-breaking highs. Diverse percussion - Not just high-speed double bass Good technique bass - ...that's not turned way down in the mix Melodic skillful leads - Real leads, not just fast twitching fingers I guess "classic metal" would best describe my tastes, although I can get down on some good bluegrass too, as well as standard classical stuff. I want to like the new stuff, but each time I try, it usually just sucks. I always said I wouldn't go down the "hating what the kid's like" road, but I guess it's inevitable.