KBDoom Questions

20 minutes ago, kb1 said:

Scripting language for game startup

What does this mean exactly? Do you mean content definition language?

slopes ?

38 minutes ago, kb1 said:

Scripting language for game startup

Do you mean something like DECORATE or ZScript?

Where do all these sourceports coming from? Spawning vats I suppose.

Vanilla demo compatibility is important feature though.

I guess this could be a difficult question to answer, and I appreciate it might sound a bit lazy, but for simplistic's sake, could you outline if there's anything specific KBDoom does that no other source port does?

I thought new projects were supposed to have screenshots/demos/vids/downloads/proof of concepts

1 hour ago, Gez said:

What does this mean exactly? Do you mean content definition language?

I think so. During startup, I load up text lumps that replace Doom's hard-coded data, like sound defs, weapon defs, thing and frame defs, etc. I added a simple scripting language that allows some decision making during the loading of those resources: You know, IF, ELSE, ELSEIF, and whatnot. It supports simple math, a bunch of standard numeric, boolean, and string functions, as well as some Doom-specific functions. This allows conditional definitions. For example, if a weapon PWAD is loaded, define the weapons. If certain flats are loaded, add Terrain definitions. There is a LumpMD5 function that lets you check if a resource is vanilla (from the IWAD). I can add new monster death animations, and only add them if that particular monster has not been modified. This can simplify the mix-matching of resource PWADs without conflicts.

The script language is interpreted, so, although it's pretty darn fast, you wouldn't want to use it for much runtime scripting. I am slowly working on a byte-code converter and run-time engine. This has been done a thousand times, and there's plenty of free code doing this very thing. But, this is a labor of love for me, and I am trying my hand at implementing it myself, without using anyone else's code. It's a pet project of mine. Adding it to KBDoom was an experiment that turned out to be very useful. The goal is to have 3 versions: Interpreter: Done, Byte-code converter and VM: 50%, and native x86-16, x86-32, x64: A pipe dream :) I could talk about it for hours.

57 minutes ago, hawkwind said:

slopes ?

I want to add them. Slopes are nice, not just for the cool things in buildings, like support beams, ramps, etc. But, I'd also love to see some nice walkable mountain paths, or twisty, curvy caves, river beds, etc. The possibilities are endless! Slopes are on the list. If I get them done, they will of course be compatible with current implementations.

37 minutes ago, Decay said:

I thought new projects were supposed to have screenshots/demos/vids/downloads/proof of concepts

Oh, goodness! Difficulties in comprehension, huh? Let me help:

• I was not promoting my port, I was asked a question.
• A screenshot of DEMO1 in KBDoom is so much different than a screenshot of DEMO1 in, say, PrBoom+.
• It's not a new project. But, yeah, I'm just dying to give you the results of my work...
• I requested a PM, if anyone was interested in more. Didn't see that, huh?
• Your post got the previous thread locked. Not subtle enough?

You know, I'm no expert, but if I had to guess, I'd have to say that randomly attacking strangers is probably not a viable strategy to cure what ails you. I'd help, if I could.

12 minutes ago, kb1 said:

I added a simple scripting language that allows some decision making during the loading of those resources: You know, IF, ELSE, ELSEIF, and whatnot. It supports simple math, a bunch of standard numeric, boolean, and string functions, as well as some Doom-specific functions. This allows conditional definitions. For example, if a weapon PWAD is loaded, define the weapons. If certain flats are loaded, add Terrain definitions. There is a LumpMD5 function that lets you check if a resource is vanilla (from the IWAD). I can add new monster death animations, and only add them if that particular monster has not been modified. This can simplify the mix-matching of resource PWADs without conflicts.

Ah, interesting.

The first thing I thought upon seeing "scripted startup" was a whole thing to customize the game loading screen, to replicate stuff like Heretic, Hexen, or Strife's loading screens, or write your own. Which, while neat, seemed to be a lot of effort for something excessively niche; so I thought content definition seemed more likely. Conditional loading, a sort of preprocessor for the game definition, seems useful for putting various enhancements in autoload without worrying them about breaking the game when loading something with dehacked actors or whatnot.

1 hour ago, Bauul said:

I guess this could be a difficult question to answer, and I appreciate it might sound a bit lazy, but for simplistic's sake, could you outline if there's anything specific KBDoom does that no other source port does?

It is difficult to answer. Yes, there's a few unique "woah!" features that I'm hoping to surprise people with. I guess it's more about how things are done, vs. specific features. Here's a subtle example:

In Doom, the pistolguy and the shotgunner are unique, in that they have multiple chase sounds, that are chosen at random. All other monsters have but one sound. In KBDoom, I rolled that unique custom feature into the standard definition, allowing any monster to have multiple sounds for any of their actions, if desired. This may not sound like a big deal when viewed in isolation. But, this process has been applied as much as possible, in a user-configurable way. The goal was to take all of the little, subtle, hard-coded behaviors from vanilla Doom, and turn them into generic, "standard" features. The modder no longer needs to remember that the pistolguy has multiple chase sounds. Instead, the modder is presented with a "clean" interface. Instead of starting out with the specific, highly-tweaked vanilla Doom experience, the engine starts with a blank slate, and, via user-modifiable config lumps, this blank interface is tuned and tweaked to become the game "Doom" that we all love, with all of it's special-cases and quirks. Any custom abilities are explicitly represented as such in the config. I feel that this attention to detail might help KBDoom stand apart somewhat.

But, essentially, no. It's a port that plays Doom, which means it's 99.9% just like any other port. :)

Just now, Gez said:

Ah, interesting.

 

The first thing I thought upon seeing "scripted startup" was a whole thing to customize the game loading screen, to replicate stuff like Heretic, Hexen, or Strife's loading screens, or write your own. Which, while neat, seemed to be a lot of effort for something excessively niche; so I thought content definition seemed more likely. Conditional loading, a sort of preprocessor for the game definition, seems useful for putting various enhancements in autoload without worrying them about breaking the game when loading something with dehacked actors or whatnot.

Yes, you really nailed it with that last sentence! I actually do use it to load custom monster deaths, which only get applied if the monsters are 100% stock. There's nothing more jarring than seeing a cool custom monster, shooting it, and having it switch to a dying imp!

I do like the "loading screen" idea, though. The new UMAPINFO lump might be able to serve dual purpose in that regard. After all, it must handle building the tower, showing full intermission backdrops, animating small sections, showing text, etc. It almost contains all the capability as-is, though I don't think it's ever been done that way before. Instead of "MAP01", it could have a "STARTUP" section. Seems like a logical place for it. Hmmm.

Sounds great, can't wait to get a look at it.

Hey kb1, thanks for answering my question!

That is all.

18 hours ago, kb1 said:

 

The script language is interpreted, so, although it's pretty darn fast, you wouldn't want to use it for much runtime scripting. I am slowly working on a byte-code converter and run-time engine. This has been done a thousand times, and there's plenty of free code doing this very thing. But, this is a labor of love for me, and I am trying my hand at implementing it myself, without using anyone else's code. It's a pet project of mine. Adding it to KBDoom was an experiment that turned out to be very useful. The goal is to have 3 versions: Interpreter: Done, Byte-code converter and VM: 50%, and native x86-16, x86-32, x64: A pipe dream :) I could talk about it for hours.

 

So your end goal would be to have the game logic clearly separated from the game engine, while still running as fast as native code. Have you considered the approach as seen in the Quake II engine, where the game logic is written in plain C, compiled by the mod developer into a separate gamex86.dll, which is then loaded runtime by the quake2.exe?

Will it have bots?

Have you solved generalising the menu in a different way to ZDoom? I'm interested in seeing your implementation if so, I need to tackle menus in my own doom engine very soon and I'm still deciding how to approach it. Same goes for the statusbar, but I'm tempted to just hardcode it for Doom until further notice.

1 hour ago, Arno said:

So your end goal would be to have the game logic clearly separated from the game engine, while still running as fast as native code. Have you considered the approach as seen in the Quake II engine, where the game logic is written in plain C, compiled by the mod developer into a separate gamex86.dll, which is then loaded runtime by the quake2.exe?

Honestly, the big drawback of the Quake II approach is that it inherently lacks portability.

1 hour ago, Arno said:

So your end goal would be to have the game logic clearly separated from the game engine, while still running as fast as native code. Have you considered the approach as seen in the Quake II engine, where the game logic is written in plain C, compiled by the mod developer into a separate gamex86.dll, which is then loaded runtime by the quake2.exe?

Nah, if I ever get my language fully featured enough to justify going down the native compile path, it would be its own project. For Doom, I'd be happy with a byte-code compiler and VM. My scripting would *tightly* couple the game logic and engine. My approach would leave all the original code pointers as-is. By default, the game engine would call the original pointers. But, you'd have the option to edit an original action pointer. Upon doing so, an equivalent script language version of the C function could replace the original function, yet still be demo-compatible (until modified). This approach provides the best of both worlds: Performance (for original monsters) and flexibility (for custom monsters). This would extend to player actions, weapons, pickups, etc. Some builtin script variables would be coupled to engine-side variables. I would probably go with what externally looks like an event-driven model. But, I would definitely NOT expose everything, just enough to allow lots of modder control. The engine should continue to function, even with crappy scripting, I think :)

Implemented correctly, byte-code VMs can run pretty fast - nearly the speed of unoptimized, or even somewhat optimized native code. That's because the functions that the VM hosts are native compiled. The slowdown is in getting the next instruction, collecting the right number and type of arguments, and calling the optimized function with those arguments. That's plenty fast for scripting, in most all cases. And it's an approach that can work on multiple platforms without having to recompile scripts. I would like the Doom language to abstract as many technicalities away as possible. I believe that you shouldn't have to be a seasoned programmer to get a few game scripts running. The 2 main goals here are simplicity, and performance.

But, don't get me wrong: KBDoom has no byte-code VM or game scripting at all yet! Only an interpreted script engine that runs at startup while defining global data.

44 minutes ago, printz said:

Will it have bots?

Sure! Seriously, I would *love* to have smart bots in there. AutoDoom has wonderful bot technology. It can actually complete levels, from start to finish, which is a massive accomplishment. I would love to try to make my own, but, man, AutoDoom is an awesome implementation. I haven't done any bot work yet, but it's one of many "would-be-nice" features on a very long list :)

43 minutes ago, jmickle66666666 said:

Have you solved generalising the menu in a different way to ZDoom? I'm interested in seeing your implementation if so, I need to tackle menus in my own doom engine very soon and I'm still deciding how to approach it. Same goes for the statusbar, but I'm tempted to just hardcode it for Doom until further notice.

Menus have been internally rewritten, and "generalized" is a good word to describe it. But, currently, the modder cannot modify them. They were rewritten after the major task of exposing hard-coded data into lumps. For some reason, menus were not included there. KBDoom has a lot of nested menu levels, which is why it needed to be rewritten. Menus are an issue, cause each port has different menu options at different levels. And, I'm big on trying to use generic definitions that could work in many ports.

Because of that, I think the best areas of the menu to expose are the episode menu (UMAPINFO might play a role here), the skill menu, and maybe a menu inside those that would be used to set global script variables that can be read by scripts. But, that last one assumes that a script engine exists, so that complicates a "universal" approach.

KBDoom's menus are table/data-driven, so they could be modder-exposed. But, that's not exactly what's needed, I don't think. I could send you some menu code to show you my approach, but it may not provide you with what you need.

I'm compiling a bunch of Doomy stuff this week, so I'll add this to the list.

OK yeah, seems like my best bet is to just code in the menus for now.

5 minutes ago, jmickle66666666 said:

OK yeah, seems like my best bet is to just code in the menus for now.

Yep, looking at the code now, I want to rewrite it again :(  It's not as clean as I would like it to be. All KBDoom menu options are pushed to all network peers as they change in real-time, which is cool because it allows network games to stay in sync during option changes. But it does make for a messier implementation than I care to admit. My menu code depends heavily on changes in other systems, like the keyboard/mouse code, the patch drawer, the sound system, font support, demo sync (allowing the user to change options while a demo is running, without causing desync), net sync, etc. Looking at it, its hands are into A LOT of the rest of the game. I forgot about that.

A port author almost needs to write his/her own menu system, come to think of it, to support all the unique options of the port. Sorry about that. Again, you're welcome to see it, but I'd have to publish the whole source for you to get much use out of it, and again, I'm not ready to do so.

I know I would have to write my own system, but I was hoping that you had a good approach to externalising the menus into definition files is all.

22 minutes ago, jmickle66666666 said:

I know I would have to write my own system, but I was hoping that you had a good approach to externalising the menus into definition files is all.

I'd suggest the following 2 subsystems:

1. A good text parser. This is easiest for modders to use, and it's not too difficult to get started. Something that can read nested blocks of key/value pairs. With care, you can use this parser for all kinds of user-moddable data sets. It would read a specially-named text lump, like "MENUDEFS", or something, and be able to navigate through each line of the lump, increasing the current depth, decreasing it, setting the current section name, or storing a key/value pair.

2. You'd need some lookup functions. Doom menus use code pointers, and menu items have pointers to other menu items. So you'd need a name-to-menu-func lookup, and a name-to-menu-item lookup.

My final suggestion is to get the menus working exactly the way you want *before* externalizing them. That will tell you exactly what properties need to be externalized. It is easy to get started, but, all-in-all, it is probably going to be a lot of work. You might be better off externalizing just a single menu page, or a limited couple of pages. I'd be asking myself: "Do I really need to expose the whole menu system, when it's much easier to just provide a customizable episode and customizable skill level menu?". Would you really need to add much more?

Sorry I couldn't be more help. Good luck!

My only question is whether or not this source port factors into the whole "enhanced Boom format" discussion from last year at all.

2 hours ago, Shadow Hog said:

My only question is whether or not this source port factors into the whole "enhanced Boom format" discussion from last year at all.

Absolutely. Good question. If I had enough time to accomplish my Doom goals, I'd be releasing the following:

• CDEX v1 (Compatible Doom Extensions version 1)
• A fork of PrBoom+, with CDEX v1 implemented
• KBDoom with CDEX implemented

I have committed to getting them done - it will happen, sometime, God willing.

I am going to be releasing what I have for CDEX in the next few days. It's nowhere as far as I wanted. But, a lot of people probably prefer me to do such an early release, so that it is more "open" in the beginning. My slow pace is not helping matters.

I am hoping we can hash it out, to the point where we see a few source ports implementing these extensions this year.

I demand screenshots. Even if they are "so much different than PrBoom+".

(for example, you can screenshot your powerful console :P)

Note that I'm not really asking for anything I wouldn't do myself. When I post a thread, I provide either code or a video. If too lazy to record, I at least put in a screenshot, here? Nothing! Looks like vaporware.

Do you plan to implement Bots?

On ‎3‎-‎1‎-‎2018 at 11:40 PM, kb1 said:

Nah, if I ever get my language fully featured enough to justify going down the native compile path, it would be its own project. For Doom, I'd be happy with a byte-code compiler and VM. My scripting would *tightly* couple the game logic and engine. My approach would leave all the original code pointers as-is. By default, the game engine would call the original pointers. But, you'd have the option to edit an original action pointer. Upon doing so, an equivalent script language version of the C function could replace the original function, yet still be demo-compatible (until modified). This approach provides the best of both worlds: Performance (for original monsters) and flexibility (for custom monsters). This would extend to player actions, weapons, pickups, etc. Some builtin script variables would be coupled to engine-side variables. I would probably go with what externally looks like an event-driven model. But, I would definitely NOT expose everything, just enough to allow lots of modder control. The engine should continue to function, even with crappy scripting, I think :)

 

Implemented correctly, byte-code VMs can run pretty fast - nearly the speed of unoptimized, or even somewhat optimized native code. That's because the functions that the VM hosts are native compiled. The slowdown is in getting the next instruction, collecting the right number and type of arguments, and calling the optimized function with those arguments. That's plenty fast for scripting, in most all cases. And it's an approach that can work on multiple platforms without having to recompile scripts. I would like the Doom language to abstract as many technicalities away as possible. I believe that you shouldn't have to be a seasoned programmer to get a few game scripts running. The 2 main goals here are simplicity, and performance.

 

But, don't get me wrong: KBDoom has no byte-code VM or game scripting at all yet! Only an interpreted script engine that runs at startup while defining global data.

Interesting! Thanks, I now have a much better understanding of how you're trying to implement the scripting system with both flexibility and performance in mind. Another advantage of such an approach is that you could easily implement it gradually. A first release could start with only a small subset of the modifiable function pointers. Later on more functions can be exposed without any backward compatibility issues.

Will Boom demos finally have a -longtics option?

you and your longtics obsession! :p

I don't really want precompiled game scripts.