Defining a new enhanced source port standard (Boom+/MBF+)

[Graf Zahl]

 

19 minutes ago, Da Werecat said:

When it comes to the automap, MBF has a solution: the OPTIONS lump. Eternity supports it. The problem is: PrBoom+ stubbornly refuses to acknowledge its existence for whatever reason. Then there are palette swaps - a minor inconvenience, but still.

 

If the OPTIONS lump is so unloved, then maybe there can be another solution. First thing to decide: would the new values always override the user's settings (like OPTIONS), or are they just the defaults that take effect once and then can be changed by the user? In the latter case: where to store the new values? We don't want to replace the settings that are good for the default palette in the config.

 

The OPTIONS lump is a dead end. Even if my PrBoom+ fork turns out into a separate port, this will be one definitive no-go.

 

You cannot make an engine specific configuration file part of any standard. ZDoom couldn't use the vast majority of its content, not to mention that much of it has no place in a mod configuration. It's par for course for MBF which, despite some interesting features suffers from some of the most hackish and short sighted feature implementations ever. Strange that Eternity keeps this around, it would have been the first thing I'd have disabled.

 

 

[Gez]

For hardcoded palette colors, you could imagine a COLORDEF lump.

 

What would go in there? Automap colors, and translation start/stop indices. Anything else?

[Da Werecat]

I think palette swaps can be externalized with color tables. Font recolors are already done this way, AFAIK.

[Coraline]

 

@Graf Zahl For these custom lumps, I can imagine I would just adapt the new idea, for example: (COLORDEF) to be parsed to a DDFCOLM DDF (sort of like how our Dehacked plugin works)..unless I have the wrong idea here.

 

I see lots of mention of ACS in the UDMF spec... I'm assuming the 3DGE equivalent, RTS, is out of the question. To be compatible with the others, would we be "forced" to write an ACS parser? Just wondering the best way to handle this. .

[esselfortium]

59 minutes ago, Coraline said:

 

@Graf Zahl For these custom lumps, I can imagine I would just adapt the new idea, for example: (COLORDEF) to be parsed to a DDFCOLM DDF (sort of like how our Dehacked plugin works)..unless I have the wrong idea here.

 

I see lots of mention of ACS in the UDMF spec... I'm assuming the 3DGE equivalent, RTS, is out of the question. To be compatible with the others, would we be "forced" to write an ACS parser? Just wondering the best way to handle this. .

ACS isn't part of UDMF itself and I don't think it's being seriously considered as part of the phase 1 plans here, though a shared scripting standard would be pretty cool to have.

[Graf Zahl]

1 hour ago, Coraline said:

 

@Graf Zahl For these custom lumps, I can imagine I would just adapt the new idea, for example: (COLORDEF) to be parsed to a DDFCOLM DDF (sort of like how our Dehacked plugin works)..unless I have the wrong idea here.

 

For every new lump there will be a reference parser. Normally you should just be able to take that parser and redirect its output to where you need it, if you already support the feature it implements.

 

 

1 hour ago, Coraline said:

 

I see lots of mention of ACS in the UDMF spec... I'm assuming the 3DGE equivalent, RTS, is out of the question. To be compatible with the others, would we be "forced" to write an ACS parser? Just wondering the best way to handle this. .

 

ACS is only relevant for ZDoom and ZDEE namespaces. There's some mention because these namespaces need some traits defined how ACS interacts with UDMF's properties. The base 'Doom' namespace does not contain any ACS and would not even be able to use it.

 

If we wanted to add a scripting language, what would be other options? RTS? FraggleScript? I could port FraggleScript to PrBoom, but I'd take out string variables because they cannot be cleanly implemented without a working garbage collector - but that'd limit the feature set quite dramatically. I'm also not sold on the language. It's a relic from the past better left shrouded in obscurity. And about RTS I simply do not know enough to even decide if it's a viable option.

 

[jeff-d]

The Automap colours are trivial. My port looks up the colour rgb in the standard palette and then finds the closest match to that rgb in the changed palette in the pwad.

 

[Graf Zahl]

ZDoom is doing the same thing when rendering the automap on a paletted display.

 

[wesleyjohnson]

It is not surprising that there is another animated switch idea.  I could accept some alternative way to do the same thing.

Could the people that propose using such actually write up something so the rest of us can judge its merits too.

Is this going to be overkill like the DECORATE thing.

 

Please allow me to point out one counter-arguement, without someone jumping down my throat.

At least my idea only extended the existing naming convention, and did not require any lump writing to use it or any lump parsing to implement.  Why does every put down of one of my ideas have to automatically assume that a two-ton sledge hammer version in some other port or format is always the way to go.  My ideas are claimed to be way to complicated for this phase, but the alternatives proposed are way more complicated.  I could implement one of my ideas in a weekend.  I have no idea when I could actually implement these overly complicated lump formats.

 

What good does it to say that Hexen has this covered, if we are not using Hexen.

 

I know that DoomLegacy has some switch definition lump handling, but only adding switch definitions.

I think it is a SWITCHES lump but I am on the wrong machine to check right now.

It is hard to find or know what is in there until know what I am looking for.   I do not remember any animated switches.

 

[kb1]

On 5/25/2017 at 3:55 AM, Graf Zahl said:

 

I don't think there's any need to bother with the hard coded section at all. The first thing any port should do here is to export the internal definitions so that there's one less concern. IIRC even Boom moved these tables to an ANIMATED and SWITCHES lump

 

One thing should be clear here:

ZDoom's ANIMDEFS better die. It is based on the original Hexen format and lacks sufficient structure to be used as a universal definition lump. If we go at it my suggestion would be to use something based on UMAPINFO syntax. I think for everything (except DECOLITE which has different needs) we should stick to that if possible.

But please let's not to a 'one size fits all' format like EDF, DDF or DED. These inevitably carry too much baggage around. If the various things are properly separated it will be a lot easier to support them because you can do one without the other.

 

I like the idea of using the same parser for most all text lump needs (I understand that DECORATE/LITE needs something more). On the "one size fits all" thing, let me be more clear:

So you want to use the same parser, right? If we simply require a header line:

type UMAPINFO
{

}

type ANIMDEFS
{

}

The data could *optionally* live in one lump, or in separate lumps, and the parser could handle either one. I suppose, if using single lumps, the lump name could serve as the header line. The data within each type can be formatted however necessary - no baggage. If the type exists, it gets parsed, otherwise not. It's of course easy to support both: A lump, called CONFIG or something, would look like the code box above. The one lump per type version would omit the header, and use the lump name to denote type.

 

Treat this as just a suggestion, for maximum flexibility. This is the route I took with KBDoom, and it's worked out pretty good so far. What's nice is that, with one lump you can configure the whole game (for the most part). Cause, otherwise, we need to come up with different, unique names for all these lumps - all the good names have been taken! Please consider it. It's a logical result of using one parser, so it makes sense to me. It's up to you, though - I'll roll with whatever you think is best.

 

On 5/25/2017 at 7:43 AM, Da Werecat said:

I have a proposition that could benefit the artsy types.

 

Right now anyone who's trying to make a new palette from scratch is faced with certain challenges. A lot of the colors are reserved by the engine for certain things, namely palette swaps and the automap. They need to be accounted for when creating the palette layout. Now, while the palette swap ranges are pretty easy to work with, automap colors are a giant mess, especially considering that different ports have different default values for them.

 

One way to deal with this right now is to make a sensible, convenient palette layout, develop the graphics, and then mangle the palette so that it works with the default values of the target engines. One drawback is that once the palette (and all the related lumps) is mangled, you'd better be sure that it's finalized, because otherwise you'd either have to work on the mangled version (major PITA) or re-mangle it again.

 

Another drawback is that any user who has custom automap colors will have to go and change them. This problem can only be solved by making the layout exactly like Doom, preferably with similar hues in their respective ranges. Yuck.

 

When it comes to the automap, MBF has a solution: the OPTIONS lump. Eternity supports it. The problem is: PrBoom+ stubbornly refuses to acknowledge its existence for whatever reason. Then there are palette swaps - a minor inconvenience, but still.

 

If the OPTIONS lump is so unloved, then maybe there can be another solution. First thing to decide: would the new values always override the user's settings (like OPTIONS), or are they just the defaults that take effect once and then can be changed by the user? In the latter case: where to store the new values? We don't want to replace the settings that are good for the default palette in the config.

 

User settings are one of the most unique things in ports. Trying to dictate what settings a port has is against the philosophy of this standard. And, what you describe would make that a necessity. The OPTIONS lump cannot be made generic - it will always be a port-specific thing. I guess what you meant was being able to change the automap colors to match your new palette scheme by using the OPTIONS lump. Personally, I find the idea of a WAD changing my user settings a bit repulsive, in most all cases, with a few exceptions. I could see a WAD dictating if jumping is allowed or not, for example. But I believe that could be done in a more straight-forward way, like a MAPINFO lump, for example.

 

Regarding the palette, it is already user-configurable in a standard way. I do agree that tools to make it easier to work with would be nice, and I recognize that changing the palette affects a lot of things: The menu, for one. Also the automap. But both of those things are also extremely port-specific. This is something that requires a huge amount of planning, and careful execution. I am open to suggestions, but I must say that I am not comfortable trying to squeeze a palette remapping scheme into a Phase 1 spec. There's just too many things to research, and such a change would be difficult to gain universal acceptance for. It raises to many concerns: How would it work with true-color rendering? Custom colormaps? Translucency? Keeping the map and menu readable? Split-screen faked palette flashes? Real palette flashes? Ports that recalculate palette values? To make this universal requires an understanding of how *every* port's renderer works.

On 5/25/2017 at 0:01 PM, Coraline said:

 

@Graf Zahl For these custom lumps, I can imagine I would just adapt the new idea, for example: (COLORDEF) to be parsed to a DDFCOLM DDF (sort of like how our Dehacked plugin works)..unless I have the wrong idea here.

 

I see lots of mention of ACS in the UDMF spec... I'm assuming the 3DGE equivalent, RTS, is out of the question. To be compatible with the others, would we be "forced" to write an ACS parser? Just wondering the best way to handle this. .

Scripting is *way* down the line for this spec. Every port dev that wants to do scripting has their own ideas for what would be the ultimate script engine. I have my own plans. But ACS is actually a standard, at least the original Hexen version. To render Hexen, you need an ACS VM (or the ACS needs to be converted at runtime to your favorite script engine).

On 5/25/2017 at 1:22 PM, Graf Zahl said:

 

For every new lump there will be a reference parser. Normally you should just be able to take that parser and redirect its output to where you need it, if you already support the feature it implements.

 

ACS is only relevant for ZDoom and ZDEE namespaces. There's some mention because these namespaces need some traits defined how ACS interacts with UDMF's properties. The base 'Doom' namespace does not contain any ACS and would not even be able to use it.

 

If we wanted to add a scripting language, what would be other options? RTS? FraggleScript? I could port FraggleScript to PrBoom, but I'd take out string variables because they cannot be cleanly implemented without a working garbage collector - but that'd limit the feature set quite dramatically. I'm also not sold on the language. It's a relic from the past better left shrouded in obscurity. And about RTS I simply do not know enough to even decide if it's a viable option.

 

@Graf Zahl Why would you switch away from ZScript? From what I read, it seemed to be rather fully featured. I must say that, to me, it seemed like it requires some pretty advanced programming skills to master, but, at the same time, extremely powerful. Just out of curiosity, did you build it from scratch, or was it a package that you tailored for Doom's specific needs? Either way, it's quite impressive.

 

I believe that the choice of script engine will be the most difficult thing for us to agree on. I've been slowly working on my own language that resembles BASIC with some C syntax for convenience. Eventually it will expose an event model and a set of pre-defined objects. I currently have it working in runtime, interpreted mode, so it not real fast, but it does work. The next step is to modify the interpreter to output byte-code, and to build a VM to execute the code. Eventually I'm going to try to get it to output x86/x64 assembly to build .EXEs and .DLLs, but that's a long ways away, and it's not needed for Doom. A byte-code compiler/execution engine is plenty fast for Doom, and cross-OS compatible.

 

My point is that fully-powerful scripting that has access to Doom's internal objects requires radical changes *everywhere* in a port, and I don't believe we will ever be able to define a spec that all ports will welcome. I could be wrong, though. I would like to study RTS and ZScript in detail though. I also want to see what Eternity is doing, but last time I looked, I think Quasar was switching to a new scripting engine, right?

4 hours ago, wesleyjohnson said:

It is not surprising that there is another animated switch idea.  I could accept some alternative way to do the same thing.

Could the people that propose using such actually write up something so the rest of us can judge its merits too.

Is this going to be overkill like the DECORATE thing.

 

Please allow me to point out one counter-arguement, without someone jumping down my throat.

At least my idea only extended the existing naming convention, and did not require any lump writing to use it or any lump parsing to implement.  Why does every put down of one of my ideas have to automatically assume that a two-ton sledge hammer version in some other port or format is always the way to go.  My ideas are claimed to be way to complicated for this phase, but the alternatives proposed are way more complicated.  I could implement one of my ideas in a weekend.  I have no idea when I could actually implement these overly complicated lump formats.

 

What good does it to say that Hexen has this covered, if we are not using Hexen.

 

I know that DoomLegacy has some switch definition lump handling, but only adding switch definitions.

I think it is a SWITCHES lump but I am on the wrong machine to check right now.

It is hard to find or know what is in there until know what I am looking for.   I do not remember any animated switches.

 

@wesleyjohnsonI can't speak for anyone else, but the only thing making me want to "jump down your throat" is that your taking the stance that your ideas have been rejected - they haven't. I have not put your ideas "down", I've put them into a spreadsheet, along with all of the other ideas in this 13 page thread, as well as the other 6-page thread, and the UMAPINFO threads, the UDMF threads, and a few ideas of my own.

 

You are brainstorming on ways to get Legacy to do what you want, and you are sharing those ideas. This is good. But, please note that I am developing a spec that must not only work well in other enhanced Doom ports, it must also work in ports that support Heretic, Hexen, and Strife. That's the ideal type of solution. I mentioned Hexen, because, yes, it does manage animated switches, so there is a precedent. To be universally accepted, any animated switch spec had just better be able to seamlessly handle animated Doom switches, animated Heretic, Hexen, and Strife switches.

 

Now, you may never want to add support for those other games in your port, and that's your prerogative, which will be respected by the spec. It is commendable that you've found a way to get animated switches to work without a configuration lump - that's a nice feature. But some other ports cannot use this method to satisfy all requirements to authentically, accurately render each game they support.

 

For example, in some games, each switch can have a different sound. Your method does not allow per-switch sounds, right? Requiring the config lump also requires ports to add fields to their structures to support arbitrary, unlimited creation of animated switches with custom sounds, custom timing. But, best of all, the config lump lets ports exactly emulate Doom, Heretic, Hexen, and Strife switches completely, without needing any more solutions - everything is covered.

 

Yes, it is a bit more complicated to have to get the info from a lump. But that parser is part of the spec, and it will be used for ALL text config needs, so it's a one-time cost, that provides access to animated switches, UMAPINFO, animated textures, custom sound definitions, ambient sounds, terrain definitions (for splashes), and everything else I can't think of right now.

 

The idea is that you keep your core engine logic clean of special-case conditional logic, because, instead, everything is clearly defined in the config lump - you simply follow the parsed data as-is. It removes all restrictions on, say, lump naming schemes, hard-coded timings, etc. Everything is user-defined, which is what allows all ports to take advantage of the configuration. The default configuration allows ports, like Hexen ports, to render the switches in a demo-sync-compatible way.

 

None of this prevents you from adding your animated switch scheme to your port. But, if you later accept the spec, you now have to handle 2 ways to define custom switches.

 

Yes, once it is complete, the first rough-draft will be visible to all, in a new thread, available to be judged, picked apart, modified, tailored, and tweaked to perfection. But, this is going to take time: As I have mentioned before, this is a huge project. I am logging, sorting, and cleaning up all the viable ideas in these threads. I have downloaded the Doom, ZDoom, and Eternity Wikis, and studying them. I have downloaded the latest source of all the ports I can find. I am doing my best to study the source of all these ports. I am discussing ideas with developers. I am trying to boil all of this information down into an inviting, approachable spec that takes each ports innovations into account, avoids stepping on anyone's toes, avoids conflicts, repairs inevitable conflicts, etc.

 

Furthermore, I will be implementing the first spec into my version of PrBoom+, to verify its correctness, and to provide a reference implementation. This reference implementation must maintain demo sync, both for old and new demos, and must preserve savegame compatibility. Once that is done and verified, I can confidently release the first rough draft of the spec, complete with fully-commented, working reference source, with key markers in the source making the spec-specific changes easy to find.

 

Once again, your proposal is quite clever, and a good solution for some ports, but I am trying to reach a bigger audience, and provide a solution that works for any advanced port, the same way in each port. That justifies building the "two-ton sledgehammer" once, and then calling *everything* a nail.

 

It's worth mentioning that, yes, ZDoom has excelled in capturing the needs of all of the idTech1 games, with a lot of their config structures. In other words, their methods have been proven to be solid, but some could claim that they were built hastily. We have an opportunity to build a clean method to handle all of the data needed by advanced ports. I don't just want you to implement the spec - I want you to want to implement it, because of the good things it will bring. The fact that you mention animated switches invokes me to realize that we need a universal way to handle them. I appreciate that you've done this. And the same appreciation goes to the linedef discussions, the "Doom2017" plans, etc. The spec will try to implement some of these ideas, if they can easily be supported universally.

 

My hope is that, after implementing the spec, some ports will gain a lot of functionality. And other ports will be able to load those same maps that use that new functionality, even if they already supported those functions. I want you on board with this - I'm not trying to bash your ideas - quite the opposite. Some of the resistance is that your ideas need to be expanded to be sufficient enough to supply the needs for all ports. Do you understand?

[Arctangent]

11 minutes ago, kb1 said:

Why would you switch away from ZScript? From what I read, it seemed to be rather fully featured.

For one, it's heavily built in a way that's based around how ZDoom handles things. But mostly, it's just entirely out of scope for a Boom+ thing.

 

The talk of scripting for this standard is for map-based scripting, ala what Hexen ACS is and what ZDoom ACS used to be before it got extended into oblivion. ZScript, on the other hand, is mostly based around everything else besides the particulars of each map. I mean, you can ( or will be able to? Haven't kept up with whether or not it's implemented or not ) create new thinkers - as in, the things that operate doors and floor movements and such - for use in maps, but when you script in ZScript, it's for the entire game. It allows for whole new action functions for actors, lets you hook into various game events to create your own effects when they occur, etc..

 

Basically, something I'm pretty sure most ports that stick around Boom-compat would have no interest in implementing and maintaining, since it's by far one of the best ways to make something completely un-Doom in Doom. Since the goals with this is just to have better capabilities to expand Doom, it's pretty inappropriate.

[kb1]

2 hours ago, Arctangent said:

For one, it's heavily built in a way that's based around how ZDoom handles things. But mostly, it's just entirely out of scope for a Boom+ thing.

 

The talk of scripting for this standard is for map-based scripting, ala what Hexen ACS is and what ZDoom ACS used to be before it got extended into oblivion. ZScript, on the other hand, is mostly based around everything else besides the particulars of each map. I mean, you can ( or will be able to? Haven't kept up with whether or not it's implemented or not ) create new thinkers - as in, the things that operate doors and floor movements and such - for use in maps, but when you script in ZScript, it's for the entire game. It allows for whole new action functions for actors, lets you hook into various game events to create your own effects when they occur, etc..

 

Basically, something I'm pretty sure most ports that stick around Boom-compat would have no interest in implementing and maintaining, since it's by far one of the best ways to make something completely un-Doom in Doom. Since the goals with this is just to have better capabilities to expand Doom, it's pretty inappropriate.

I think I misinterpreted what Graf was saying, and furthermore, I wasn't clear with my question. I know there's a "Z" in ZScript. I guess I was just surprised that Graf would consider adding yet-another script engine, for the sake of cross-port support. Naturally, I love the idea, but getting everyone to accept it seems like a pipe dream.

 

On the idea of FraggleScript, from what I read, it seems like a pretty sweet language. I would definitely implement string support. There's a few schemes to minimize garbage collection:

• Literal constant strings can stay where they are
• Fixed-length strings could be implemented, avoiding GC altogether.
• I like allocating blocks of, say 256 bytes for strings. That allows a lot of concatenation of the sizes most likely used in a Doom script: "Player " & X & " did something..." will totally fit in that block, and allow plenty of extra manipulation. If your string grows beyond 256, allocate another block. It typically wastes a small amount of memory, but the GC becomes shit-easy: You don't even need to move the strings - just mark deleted string's blocks empty and available. It's also faster when concatenating if done that way.
• Defer GC till the end of the map (unless you're running out of memory, which might suggest too much string manipulation by a crazy set of scripts), avoiding the delay

But, again, one of the joys of building an engine is in building a script engine to control it - it's something I've been thinking about for a long time. I imagine other devs feel the same. Regardless, however, a standard script language would be sweet...but, far away.

 

EDIT: On second thought: Here's the problem with a universal script language (USL): All ports are different. In KBDoom, I have a thing flag STOP_BOUNCING_IN_WATER, or something (I can't remember right now). ZDoom may have a similar flag, or it may not. If so, it's almost definitely named differently. So, USL must only be able to manipulate the original flags. If you add a port-specific extension to get to the other flags, BAM! your script is incompatible.

 

So, with USL, you're left with simple stuff: spawning a monster when crossing a line, triggering a door to open when a BOSS dies, playing sounds after some universal condition happens (like a monster death, line trigger, or so). Basically original ACS. You end up with a language watered down so much that it's not far ahead of voodoo doll scripting. A Doom script language should be able to utilize all the port's neat features, but a universal script just can't.

 

Short of adding all features to all ports, I don't have a solution to this problem - unless we go for the simplistic language. It's too involved and far down the road for me to consider it just now. I am getting a bit overwhelmed, and need to focus on the first phase.

[Death Egg]

Why not use Fragglescript as a base, change it up to suit things better and give it a different name to separate it?

[Da Werecat]

9 hours ago, kb1 said:

Personally, I find the idea of a WAD changing my user settings a bit repulsive, in most all cases, with a few exceptions. I could see a WAD dictating if jumping is allowed or not, for example. But I believe that could be done in a more straight-forward way, like a MAPINFO lump, for example.

Providing new automap colors serves the same purpose: preventing the problems that the user's settings might cause with the wad's content.

 

MAPINFO works. Anything would work, even the automatic translation mentioned earlier, although it might make the color-picking menu implementation less straightforward.

 

9 hours ago, kb1 said:

How would it work with true-color rendering?

What are the potential problems here?

 

9 hours ago, kb1 said:

Custom colormaps?

Should be provided by whoever made the wad with an altered palette. As is the translucency table, if the port in question requires it.

 

9 hours ago, kb1 said:

Keeping the map and menu readable?

Graphical assets should also be provided.

 

9 hours ago, kb1 said:

Split-screen faked palette flashes? Real palette flashes?

Palette flashes are contained in the palette lump. And if the port ignores them, doing them in real time instead, then what's the problem?

 

9 hours ago, kb1 said:

Ports that recalculate palette values?

Not sure what that even means and why would anyone want to do that.

 

It seems that most (if not all) of your concerns are aimed at the very idea of using modified palettes. But it's already happening - more and more with time, as the tools are getting better and the people are getting tired of the default palette's limitations.

 

Pretty much all that I'm asking for is to allow providing sensible automap defaults with the wad, instead of forcing the user to go to the menu and remap all the colors manually (screwing the previous settings if they forgot to back up the config).

[Blastfrog]

4 hours ago, Death Egg said:

Why not use Fragglescript as a base, change it up to suit things better and give it a different name to separate it?

That might not be such a bad idea. Worth some consideration, at the least.

 

3 hours ago, Da Werecat said:

But it's already happening - more and more with time, as the tools are getting better and the people are getting tired of the default palette's limitations.

Which is exactly why I started this thread. Perhaps it is time to revisit the idea? I'd just do it myself if I were a more capable coder, best I can do is hack some primitive shit on top of existing programs. :/

[wesleyjohnson]

Four times in a row that this thing has worked now, and I didn't change anything !

 

This is a dumbed down version of the sprite rotations, changed to use 9..g.   It has some pattern detection that I don't think that Edge has (which I cannot check because my Edge source went away during the OS upgrade).  I only got Heretic, prboom, MBF, and EternityEngine to compare against at this time.   I have seen no sign that any of those do this pattern matching.  If there is something wrong in there, please post such information without the insults.  I see no requirement from kb1 that only people familiar with ZDoom are allowed to post.

 

This post is long because it details everything exactly, not because it is that complicated.

Changes:

1.  use 9..g like Edge

2.  deleted some alternative implementation suggestions

3.  deleted some possible patterns just to make it shorter, and have some chance that at least one person will try to read it

4.  Put implementation info in one place, and took it out of each pattern, just to avoid confusing some people.

That makes it a little shorter but a little less explicit.

5. Like any specification it starts with a lot of boilerplate definitions, which are now separated slightly from the patterns.

The boilerplate is not new material, the patterns are actually what is new to the sprite drawing.

 

******** Object display
- any object can have sprite angles
- the angle positions are filled from the sprites present in the wad
  - NORMAL draw offset_45 = (ANG90*2) + (ANG45/2)
                          = (ANG45/2)*(8+1)
- pattern detection
  - the sprite angle positions are loaded from the wad
  - all sprite angle flip are also recorded
  - engine will detect the pattern of angles that are present
    - detected special patterns cause the missing angles to be filled out
      from the pattern
    - extra angles present will prevent a pattern from being detected.

- implementation
  - alt implementation
    - only store the lumps present and use adjusted draw rot
    - I have the information to implement this way, but am leaving it out
      in this version because some people seem to get confused when
      presented with alternative implementation details.
  - NORMAL rot
    - duplicate the lumps into the usual sprite structure using the pattern
    - what most implementations will do because can use the same rot for
      all patterns at draw time
    - sprite draw structure can have indirection to lump content, or
      can duplicate the lump content.
    - all NORMAL draws use
      - NORMAL draw offset_45 = (ANG45/2)*(8+1)
        - adds 45/2 to round to nearest 45
      - NORMAL draw rot = (rel_angle + offset_45) >> 29
      - this should match Boom drawing
  - sprite[0]..sprite[7] are the stored sprite draw textures in the usual
    sprite draw structure.

*** 8 rotation sprite patterns

- one angle
  - Doom existing (unchanged)
  - wad has sprite angle 0, it fills all angle positions from angle 0.

- two angle, alternating pattern
  - square boxes, pillars, 4 way symmetric objects
    - with flip, only need 1 lump
  - wad has sprite angles 1, 2
    - example
      xxx1
      xxx2
    - example
      xxx12  has angle 2 as flip of angle 1
  - pattern with NORMAL draw
    sprite[0] = lump_1
    sprite[1] = lump_2
    sprite[2] = lump_1
    sprite[3] = lump_2
    sprite[4] = lump_1
    sprite[5] = lump_2
    sprite[6] = lump_1
    sprite[7] = lump_2

- two angle, flipped pattern
  - quality of 8 sided, using inherent flip
  - wad has angle 1, 6
  - example 
    xxx1
    xxx6
  - pattern with NORMAL draw
    sprite[0] = lump_1
    sprite[1] = lump_6
    sprite[2] = lump_6 flip
    sprite[3] = lump_1 flip
    sprite[4] = lump_1
    sprite[5] = lump_6
    sprite[6] = lump_6 flip
    sprite[7] = lump_1 flip

- four angles, repeat
  - quality of 8 sided, but back and front are the same
  - wad has angle 1, 2, 3, 4
  - example
    xxx1
    xxx2
    xxx3
    xxx4
  - example
    xxx14
    xxx23
  - pattern with NORMAL draw
    sprite[0] = lump_1
    sprite[1] = lump_2
    sprite[2] = lump_3
    sprite[3] = lump_4
    sprite[4] = lump_1
    sprite[5] = lump_2
    sprite[6] = lump_3
    sprite[7] = lump_4

- incomplete angle pattern
  - if does not match any pattern above
  - display as eight angles
    - any missing frame is filled from nearest angle that is present,
      with preference to lower frame number.
  - may issue warning at load time when diagnosis mode enabled, or verbose
  - not an error, do not stop program

- rotation 0 mixed with other sprite rotations
  - could use rotation 0 as default
  - eliminates a whole set of errors and messages (having rotation 0
    with other rotations)

*** 16 rotation sprites
- alternative definition
  - My original idea had sprites 1,a,2,b,3,c,4,d,5,e,6,f,7,g,8,h
  - Edge has 16 sprites, but uses 1,9,2,a,3,b,4,c,5,d,6,e,7,f,8,g
  
- position numbers (as in Edge)
  1 .. 8   : the same positions as in 8 rotation
  9 .. g   : additional between positions,
             such that 9 is between 1 and 2, a is between 2 and 3, etc.

- the presence of any sprite frame position 9..g enables the 16 rotation
  sprite display (individually for that sprite frame)
  - has 16 position sprite frames  SPRITE[0..15]
  - 16-position draw rot = (ANG45/4) = 22.5 degrees
  - 16POS draw offset_22 = (ANG90*2) + (ANG45/4)
                         = (ANG45/4)*(16+1)

- implementation
  - alt implementation
    - only store the lumps prsent and use an adjusted draw rot
    - I have the information to implement this way, but am leaving it out
      in this version because some people seem to get confused when
      presented with alternative implementation details.
  - NORMAL rot
    - duplicate the lumps into the usual sprite structure using the pattern
    - what most implementations will do because can use the same rot
      at draw time
    - sprite draw structure will need to have indirection to lumps, or
      else will duplicate the lump content.
    - all 16POS draws use
      - 16POS draw offset_22 = (ANG90*2) + (ANG45/4)
        - adds 45/4 to round to nearest 22.5
      - 16POS draw rot = (rel_angle + offset_22) >> 28
      - this should match EDGE drawing

*** 16 rotation sprite patterns

- two angle, alternating pattern
  - square boxes, pillars, 8 way symmetric objects
  - wad has sprite angle 1, 9
    - example
      xxx1
      xxx9
    - example, 1 angle flip
      xxx19  has angle 9 as flip of angle 1
  - pattern with 16POS draw
    sprite[0] = lump_1
    sprite[1] = lump_9
    sprite[2] = lump_1
    sprite[3] = lump_9
    sprite[4] = lump_1
    sprite[5] = lump_9
    sprite[6] = lump_1
    sprite[7] = lump_9
    sprite[8] = lump_1
    sprite[9] = lump_9
    sprite[10] = lump_1
    sprite[11] = lump_9
    sprite[12] = lump_1
    sprite[13] = lump_9
    sprite[14] = lump_1
    sprite[15] = lump_9


- four angles, repeat
  - quality of 16 sided, but each corner is the same
  - wad has angle 1, 9, 2, a
  - example, 2 angle flip
    xxx1b
    xxxa2
  - pattern with 16POS draw
    sprite[0] = lump_1
    sprite[1] = lump_9
    sprite[2] = lump_2
    sprite[3] = lump_a
    sprite[4] = lump_1
    sprite[5] = lump_9
    sprite[6] = lump_2
    sprite[7] = lump_a
    sprite[8] = lump_1
    sprite[9] = lump_9
    sprite[10] = lump_2
    sprite[11] = lump_a
    sprite[12] = lump_1
    sprite[13] = lump_9
    sprite[14] = lump_2
    sprite[15] = lump_a


- eight angles, repeat
  - quality of 16 sided, but front and back are the same
    - with flip, only need 4 lumps
  - wad has angle 1, 9, 2, a, 3, b, 4, c
  - example
    xxx1
    xxx9
    xxx2
    xxxa
    xxx3
    xxxb
    xxx4
    xxxc
  - example, 4 angle flip
    xxxa3
    xxx2b
    xxx94
    xxx1c
  - pattern with 16POS draw
    sprite[0] = lump_1
    sprite[1] = lump_9
    sprite[2] = lump_2
    sprite[3] = lump_a
    sprite[4] = lump_3
    sprite[5] = lump_b
    sprite[6] = lump_4
    sprite[7] = lump_c
    sprite[8] = lump_1
    sprite[9] = lump_9
    sprite[10] = lump_2
    sprite[11] = lump_a
    sprite[12] = lump_3
    sprite[13] = lump_b
    sprite[14] = lump_4
    sprite[15] = lump_c

- 16 angles
  - wad has angle 1,9,2,a,3,b,4,c,5,d,6,e,7,f,8,g
  - pattern with 16POS draw
    sprite[0] = lump_1
    sprite[1] = lump_9
    sprite[2] = lump_2
    sprite[3] = lump_a
    sprite[4] = lump_3
    sprite[5] = lump_b
    sprite[6] = lump_4
    sprite[7] = lump_c
    sprite[8] = lump_5
    sprite[9] = lump_d
    sprite[10] = lump_6
    sprite[11] = lump_e
    sprite[12] = lump_7
    sprite[13] = lump_f
    sprite[14] = lump_8
    sprite[15] = lump_g


- 16 angles, incomplete
  - if does not match any pattern above
  - if it has any frames 9..g, then display as 16 angles
    - any missing frame is filled from nearest angle that is present,
      with preference to lower frame number.
  - may issue warning at load time when diagnosis mode enabled, or verbose
  - not an error, do not stop program

 

[Coraline]

One thing about Automap stuff, 3DGE implements a VM based on QuakeC for controlling both the HUD and Automap, so adapting automap functions for my port that would be a cross-port standard might get hairy on our end... but I can't imagine it would take much more than writing an interpreter that would adapt it to our CoalVM.

 

I like the ideas posted in this thread, I am learning a lot so if nothing comes from this at least there is that ;-)

[Gez]

23 hours ago, wesleyjohnson said:

I know that DoomLegacy has some switch definition lump handling, but only adding switch definitions.

I think it is a SWITCHES lump but I am on the wrong machine to check right now.

It is hard to find or know what is in there until know what I am looking for.   I do not remember any animated switches.

Let's go back to vanilla for a moment. Consider this and that.

Now back to Boom. (I'm on a boat.) Consider, again, this and that.

Notice anything? They're the exact same thing! Boom's SWITCHES and ANIMATED lumps are merely a direct, 1:1 export of vanilla's internal tables to external lumps. The format is identical. You could directly extract the SWITCHES and ANIMATED lumps from doom.exe, just by copying bytes from the relevant offsets, without any sort of change.

 

Once you have support for external definition of switches and animations, what do you need to make an animated switch? The answer is very simple. Your switch is a pair of texture. Each of these textures can be animated separately. And it should just work.

 

In fact, the effect is used in Final Doom, which runs on vanilla Doom if you recall. Look at the TEXTURE1 lump from TNT.wad and you may notice some oddities. Contrarily to id Software's own IWADs, the textures aren't sorted alphabetically. And in particular, look at this sequence:

BLODGR1
SW1SKULL
BLOD3
BLODGR4
WFALL1
SW2SKULL
FALL3
WFALL4

BLODGR1 to BLODGR4 and WFALL1 to WFALL4 are animations defined in our hardcoded vanilla tables.  SW1SKULL to SW2SKULL is a switch defined in our hardcoded vanilla tables. What happens if a wall has SW1SKULL in TNT? It'll animate, because in the texture list it is between BLODGR1 and BLODGR4, so it is part of this animation. So it'll cycle SW1SKULL, BLOD3, BLODGR4, BLODGR1, and back to SW1SKULL. If you trigger it, it will swap to SW2SKULL because it's a switch. SW2SKULL is also part of an animation, so it will animate too.

 

If you support Boom's lumps, which are just an externalization of vanilla's tables, then you can already allow people to define animated switches. You can make switches that are not animated at all, that have an animated "on" state, an animated "off" state, or are fully animated for both "on" and "off". No more is required.

 

Unless what you want to animate is the transition between on and off; but that's a Hexen feature, vanilla Doom doesn't have this.

 

1 hour ago, wesleyjohnson said:

This post is long because it details everything exactly, not because it is that complicated.

Changes:

1.  use 9..g like Edge

2.  deleted some alternative implementation suggestions

3.  deleted some possible patterns just to make it shorter, and have some chance that at least one person will try to read it

4.  Put implementation info in one place, and took it out of each pattern, just to avoid confusing some people.

That makes it a little shorter but a little less explicit.

5. Like any specification it starts with a lot of boilerplate definitions, which are now separated slightly from the patterns.

The boilerplate is not new material, the patterns are actually what is new to the sprite drawing.

So, if I get this correctly, the point is to have 8 or 16 rotations even when you only provide two or four sprites.

 

The main criticism I could make is that it's a bit overengineered. By that I mean that I'm not sure it'll be useful often enough to be worth the effort of implementation. Otherwise, the idea is coherent and makes sense enough.

[wesleyjohnson]

Fragglescript:  DoomLegacy has Fragglescript and it is adequate.  I pretty much completely rewrote it to eliminate several problems.  Some things are still clumbsy but I did not see a reasonable better way to implement it better.

 

Scripting in general:  Now you are discussing a scripting engine which is a massive coding project in itself.

My first idea about a linedef sequencer would allow some sequential actions without having to have a specific scripting engine. --- That is the point of it. ----  Using what is already available and not requiring any special editor support.

It is simple enough that it is not much work to implement, and it can be implemented internally any way any port maintainer wants to.  They could even internally convert it to their version of a script.

It is NOT the all inclusive scripting engine that could do anything.  It is the minimal sequencer, simple enough that any port could implement it (if they wanted to, and that is the real problem).

 

It could even spawn objects, if a linedef that can spawn the objects were defined.   That would be wandering from the usage for which it was intended (which is simple linedef triggering), but it could be done without forcing anyone to adopt any specific scripting engine.  And it would not affect any other part of the sequencer and could even be port specific.   DoomLegacy has linedefs that can start a Fragglescript, so there is no limit to that combination.

 

For ease of understanding, the linedef sequencer is more easily used and understood than a scripting language.  Industrial Sequencers still have ladder diagrams for the same reason.  Non-programming users find them much easier to use, and visual.

 

All that of course won't make the slightest difference to those who are already decided on their own favorite script.

If there was a chance to push for their favorite scripting language to be adopted they would, but I see no reason in this forum to ever believe they would vote for other than their favorite scripting language.

 

The linedef sequencer was rejected by Gez so it is dead, and since he would have to vote on it, that actually is effective even if kb1 is still thinking about it.  That is how the politics of these community projects works.  KB1: writing it up in your proposal is a formality.    I have been through this procedure way too many times before to not see the real way things get decided.

 

I thought this project was about finding some enhancements that everyone would be willing to commit to adopting.  Towards that plan I have picked the simplest, most easily implementable ideas from my files.  If you are going to keep trying to get as much Hexen and ZDoom capability into it as possible, then that really begs the question of why is this a Boom+MBF enhancement.   Yeah, lots of capability, but also lots of work.  And it looks like work that duplicates Hexen or ZDoom.  Just switch to Hexen format or ZDoom and you get that capability.  But, it is not going to be inclusive for the Boom ports and I think it should not be described as a Boom+MBF enhancement.   Should we not just admit, that the people who want all that Hexen and ZDoom capability have already joined the ZDoom bandwagon and would not think of using any other port.

If you really want a HEXEN-LITE you probably should change the description of this project.

 

FYI:  DoomLegacy has Hexen support in DoomLegacy2.  Sooner or later that will make it to DoomLegacy1, probably.  But that is not a factor at all in what a Boom+MBF enhancement ought to be.

 

[wesleyjohnson]

Last night,  I went looking for a ANIMATED description that allowed animated switches.   Did not find any among PrBoom, EternityEngine.  I did not follow your this and that pointers, because I have a slow internet connection, and because you are describing the very ANIMATED code I was looking at in DoomLegacy last night.

 

DoomLegacy has support for the Boom ANIMATED lump and SWITCHES lump (after all they are from Boom).  I have even made SWITCHES available for Heretic.  But I cannot see how it is supposed to give animated switches.

 

I can only suppose that is is another ZDoom-ism for ANIMATED (or ANIMDEFS) to support animated switches.

 

Well, I can see how this would work, and I could implement it in a weekend without parsing any lumps.

 

It would even work with SWITCHES if it was accepted that the numbered versions of the switch name represents a sequence to be displayed.  That would not even require any change to ANIMATED or SWITCHES, just a semantic understanding.  How many people are going to define an animated switch sequence and name the individual switch textures as anything except the base name and a number.  Extract the base name and look for the numbered textures.  If any are found then they are animation sequences as I described using the convention.   Seems to work to me.

 

Of course it is not the ZDoom way of doing things, which seems to be more important.  I do not see why a more complicated lump based description is even useful.  Perhaps there are some more ZDoom-isms in the ANIMDEFS that are wanted, and someone should explain what they are so we all can see the usefulness of the more complicated ANIMDEFS way.

 

 

[wesleyjohnson]

38 minutes ago, Gez said:

The main criticism I could make is that it's a bit overengineered. By that I mean that I'm not sure it'll be useful often enough to be worth the effort of implementation. Otherwise, the idea is coherent and makes sense enough.

 

I must quote this because it is the first reply in 13 pages that clearly is a viable discussion of the merits of an idea.

I can dismiss just about everything else as "I like... " and "I hate ..." and "I want".   in this, I refer only to the relies to someone else's idea, not any presentation of any new idea.  I point this out so those that are only used to blasting away can actually see what a discussion looks like.  I am not foolish to believe that this will be widely adopted.

 

[Death Egg]

Should there be a new subforum in Source Ports dedicated to discussion of adding port-wide new features? There's already a good 10+ topics about it here already.

[kb1]

On 5/27/2017 at 5:54 AM, Da Werecat said:

Pretty much all that I'm asking for is to allow providing sensible automap defaults with the wad, instead of forcing the user to go to the menu and remap all the colors manually (screwing the previous settings if they forgot to back up the config).

I'm not opposed to your ideas, and I thought you were describing something more than automap defs. And, you started with OPTIONS, which is something that will never be able to be complete and standardized.

On 5/27/2017 at 11:13 AM, wesleyjohnson said:

Four times in a row that this thing has worked now, and I didn't change anything !

 

This is a dumbed down version of the sprite rotations, changed to use 9..g.   It has some pattern detection that I don't think that Edge has (which I cannot check because my Edge source went away during the OS upgrade).  I only got Heretic, prboom, MBF, and EternityEngine to compare against at this time.   I have seen no sign that any of those do this pattern matching.  If there is something wrong in there, please post such information without the insults.  I see no requirement from kb1 that only people familiar with ZDoom are allowed to post.

Thanks Wesley, I'll check it out.

On 5/27/2017 at 0:56 PM, Gez said:

Let's go back to vanilla for a moment. Consider this and that.

Now back to Boom. (I'm on a boat.) Consider, again, this and that.

Notice anything? They're the exact same thing! Boom's SWITCHES and ANIMATED lumps are merely a direct, 1:1 export of vanilla's internal tables to external lumps. The format is identical. You could directly extract the SWITCHES and ANIMATED lumps from doom.exe, just by copying bytes from the relevant offsets, without any sort of change.

 

The main criticism I could make is that it's a bit overengineered. By that I mean that I'm not sure it'll be useful often enough to be worth the effort of implementation. Otherwise, the idea is coherent and makes sense enough.

As far as my goals are concerned, I am trying to think of every addition as a stepping stone to eventually arrive at the most functional result. So, Hexen-type switches with unique sounds.

On 5/27/2017 at 0:59 PM, wesleyjohnson said:

Fragglescript:  DoomLegacy has Fragglescript and it is adequate.  I pretty much completely rewrote it to eliminate several problems.  Some things are still clumbsy but I did not see a reasonable better way to implement it better.

 

Scripting in general:  Now you are discussing a scripting engine which is a massive coding project in itself.

I should not have replied to scripting discussions - that's WAY off in the future, if at all, spec-wise.

On 5/27/2017 at 1:35 PM, wesleyjohnson said:

I must quote this because it is the first reply in 13 pages that clearly is a viable discussion of the merits of an idea.

I can dismiss just about everything else as "I like... " and "I hate ..." and "I want".   in this, I refer only to the relies to someone else's idea, not any presentation of any new idea.  I point this out so those that are only used to blasting away can actually see what a discussion looks like.  I am not foolish to believe that this will be widely adopted.

Is this directed at me?

[Da Werecat]

1 minute ago, kb1 said:

I'm not opposed to your ideas, and I thought you were describing something more than automap defs. And, you started with OPTIONS, which is something that will never be able to be complete and standardized.

Automap defs is the most important part, although anything hardcoded to use a certain palette index/range should be included, ideally.

 

OPTIONS was just one thing that already works - in some ports.

[wesleyjohnson]

Upgraded to FireFox 48 (no SSE2), lost most of my browser tools, and am back to broken reply behavior. Had two sets of ideas to post, but you won't be able to read them anyway. Will Try another day/week.

[Death Egg]

If it's that bad why not temporarily use something like pastebin to post in the meantime?

[Danfun64]

Personally I prefer paste.debian.net. Better for coding...

[Marcaek]

did anyone mention having a fence property for midtextures yet

 

because being able to block midtexture fences on the side but not over the top would be cool

[Graf Zahl]

4 hours ago, Marcaek said:

did anyone mention having a fence property for midtextures yet

 

because being able to block midtexture fences on the side but not over the top would be cool

Adding support for Eternity/ZDoom's 3DMidTex should be doable - of course it'd be one more thing other ports need to add, too.

 

[kb1]

15 hours ago, Graf Zahl said:

Adding support for Eternity/ZDoom's 3DMidTex should be doable - of course it'd be one more thing other ports need to add, too.

 

Is this a 2-sided line that blocks unless you're at a specific Z height? If so, it's just a couple of lines of code, right? I don't want to add it to Phase 1, unless it's shit-easy to add, you know.