ACE Engine v2 - DOS Doom II [vanilla++?]

Mind blowing. This single wad will crank up vanilla Doom modding to a new height. Does it support multiplayer?

1 hour ago, ASD said:

Mind blowing. This single wad will crank up vanilla Doom modding to a new height. Does it support multiplayer?

Yes. You still need original ipxsetup or sersetup but now it has fancy startup menu!

21 hours ago, kgsws said:

Well, video and documentation will take a few more days so ...

 

https://doomshack.org/uploads/ademo0.zip
DOS Doom2 v1.9 only! (or ZDoom)
doom2 -file ademo0.wad

Yeah, it's a pure, WAD only exploit!

Now you can try it while i work on video and documentation.

What. The Fuck.

First you came with the original ACE, showing what awesome possibilities there were beyond the vanilla constraints yet still run in the vanilla container.

But this engine is both a new game at times and a million miles away from the home that is Vanilla Doom.

Things i have noticed and i feel must be mentioned:

• One of the absolute coolest things is actually a detail. When your health drops low (say, 2%), DoomGuy's movement speed is significantly reduced, to indicate that, yeah you are on your last legs. I love this.
• Scripted Doom64-esque intro sequence. Yup, love that
• Colored lighting, transparencies..
• Punch combo's that see enemies soaring through the air
• Additional weapons, like grenades
• Smoother animations
• Minigames!

This is the next big thing for Vanilla after Knee-Deep-In-Knee-Deep-In-ZDoom.

I am glad you are testing on 486 hardware, so that it runs both on period-correct hardware (Well very high end at the time then) and then some.

Definitely looking forward to your video and documentation of all its features.

Can you win a Cacoward for the same thing twice? I am not sure, but there has to be a first time for anything. This ACE Engine is deserving of that.

I said in my first post: You are a Programmer's Mondrian.

I have to change that. You are a Programmer's Da Vinci.

5 minutes ago, Redneckerz said:

I said in my first post: You are a Programmer's Mondrian.

  

I have to change that. You are a Programmer's Da Vinci.

He is Doom's Future Crew.

The chicken mini-game is really funny when you modify yourself to have all of DoomGuy's regular weapons, and make chickens spawn in like crazy :)

a blaster from q2 in ace demo :)

I saw this in my recommended and immediately rushed over here. Great work!! I've been silently following this but this is seriously something impressive!

I'm seeing how complex the whole demade Half-Life level is and i'm like "Damn no wonder i hadn't seen an update in a while"

This is really awesome what you made but none of the maps can be opened here with any version of Doom Builder. Slade also seems to screw up some map lumps that even file viewers can not open. After such slade extraction Doom Builder opens it a pack of mess.

Is there any guide on how to edit those. Also you said it supports zdoom, is it like it supports ZDoom UDMF?

@kgsws Are you planning some kind of integration with other ports, like Chocolate Doom, prBoom+, DSDA, Woof! or Doom Retro? And is it possible at all (well, it is possible, the question is how difficult it is to implement, and as I understand, it should be involved in the ports developers themselves)?

This is incredible! Lots to digest, but the recreation of the bit from Half-Life with the laser beam and destructible geometry was super cool. Even the little things like the coloured lighting are so impressive. 

10 hours ago, Test Tickle said:

I'm seeing how complex the whole demade Half-Life level is and i'm like "Damn no wonder i hadn't seen an update in a while"

I went a bit overboard with example WAD. But at least i have found and fixed a ton of bugs while making it.

10 hours ago, Darkcrafter07 said:

This is really awesome what you made but none of the maps can be opened here with any version of Doom Builder. Slade also seems to screw up some map lumps that even file viewers can not open. After such slade extraction Doom Builder opens it a pack of mess.

 

Is there any guide on how to edit those. Also you said it supports zdoom, is it like it supports ZDoom UDMF?

That's odd. I did all the editing in slade v3.2.1 without much issues.

No, UDMF is not supported. Hexen map format is supported and that's what my maps use.

4 hours ago, DRON12261 said:

@kgsws Are you planning some kind of integration with other ports, like Chocolate Doom, prBoom+, DSDA, Woof! or Doom Retro? And is it possible at all (well, it is possible, the question is how difficult it is to implement, and as I understand, it should be involved in the ports developers themselves)?

That's not quite feasible. You don't want code execution in modern source ports anyway.

Source ports would have to implement same feature-set i just did.

Though, after a few months implementing ZDoom stuff, i think it's not really worth it.

ZDoom, after so many years of additions, is kinda mess. For example, look at all the line specials. I have not implemented all of them.

I understand, it all stems from original Hexen map format limitations. Well, at least there's ZScript now.

But i feel like we need completely new approach. A new modding API for oldskool-ish Doom, beyond DEHACKED, beyond MBF and beyond ZDoom.

So, if anyone is interested in putting this together, i have quite a few radical ideas for new map format and new "decorate" format and so on. All much friendlier to implement to the original code base.

So, if anyone is interested, we can discuss this. (maybe someone involved in MBF21 ?)

4 minutes ago, kgsws said:

I went a bit overboard with example WAD. But at least i have found and fixed a ton of bugs while making it.

 

That's odd. I did all the editing in slade v3.2.1 without much issues.

No, UDMF is not supported. Hexen map format is supported and that's what my maps use.

 

That's not quite feasible. You don't want code execution in modern source ports anyway.

Source ports would have to implement same feature-set i just did.

Though, after a few months implementing ZDoom stuff, i think it's not really worth it.

ZDoom, after so many years of additions, is kinda mess. For example, look at all the line specials. I have not implemented all of them.

I understand, it all stems from original Hexen map format limitations. Well, at least there's ZScript now.

 

 

But i feel like we need completely new approach. A new modding API for oldskool-ish Doom, beyond DEHACKED, beyond MBF and beyond ZDoom.

So, if anyone is interested in putting this together, i have quite a few radical ideas for new map format and new "decorate" format and so on. All much friendlier to implement to the original code base.

So, if anyone is interested, we can discuss this. (maybe someone involved in MBF21 ?)

It's just all very cool and everything, I'm really excited about your work. But the problem is that in its pure DOS form few people need it, and ZDoom itself has enough functionality already.
 

I'm in favor of creating a new standard on the basis of ACE Engine, as the next step after MBF21. And that it should be very persistently and aggressively promoted to the masses. And I see your project as a potential breakthrough.

29 minutes ago, kgsws said:

But i feel like we need completely new approach. A new modding API for oldskool-ish Doom, beyond DEHACKED, beyond MBF and beyond ZDoom.

So, if anyone is interested in putting this together, i have quite a few radical ideas for new map format and new "decorate" format and so on. All much friendlier to implement to the original code base.

So, if anyone is interested, we can discuss this. (maybe someone involved in MBF21 ?)

You would need the people mentioned in the MBF21 credits, here.

IIRC MBF21 is the stopgap/intermediary compatibility between MBF and UDMF as well as the logical conclusion of the extension of the Doom map and DeHackEd (through DSDHACKED) formats according to their design language. Though I may be wrong. But on that I do have a question: Does MBF21 have features on par to Doom-in-Hexen or does it surpass/fall short of it?

3 hours ago, kgsws said:

But i feel like we need completely new approach. A new modding API for oldskool-ish Doom, beyond DEHACKED, beyond MBF and beyond ZDoom.

So, if anyone is interested in putting this together, i have quite a few radical ideas for new map format and new "decorate" format and so on. All much friendlier to implement to the original code base.

So, if anyone is interested, we can discuss this. (maybe someone involved in MBF21 ?)

I'd say the best buy-in would be from those who maintain/develop the source ports that currently don't use any content definition language besides Dehacked.

1 hour ago, PhoxFyre007 said:

IIRC MBF21 is the stopgap/intermediary compatibility between MBF and UDMF as well as the logical conclusion of the extension of the Doom map and DeHackEd (through DSDHACKED) formats according to their design language. Though I may be wrong. But on that I do have a question: Does MBF21 have features on par to Doom-in-Hexen or does it surpass/fall short of it?

MBF21's scope is totally different. While it adds a few new sector and line types, most of the additions are for Dehacked.

Doom-in-Hexen is also not a standard but merely the ability to load Hexen format maps. Several ports implement it, but their feature sets are quite different. However, since all active ports supporting this also support MBF21 I'd say there isn't anything MBF21 can do which Doom-in-Hexen cannot.

2 hours ago, PhoxFyre007 said:

Does MBF21 have features on par to Doom-in-Hexen or does it surpass/fall short of it?

They're not really comparable. MBF21 is a defined standard for a documented set of features that largely focus on creating custom actors through DEHACKED extensions. On the map editing side, it has a whooping two new sector types, two new line flags, and three, count 'em, three new line types for slightly different texture scrollers. That is all.

Doom-in-Hexen on the other hand merely means "using the Hexen map format, but for Doom" so basically it means using the Hexen map editing features including ACS. This lets you do things that even the craziest, Rube Goldberg-iest voodoo doll conveyor setups cannot even hope to replicate (such as making changes not on the current map, but on another map you'll visit later). But there's no real defined DiH standard, and so there's nothing really implied by it for custom actor definition. At some point when only ZDoom and mostly-ZDoom-compatible ports supported DiH, you could say that DiH also implied DECORATE; but this is no longer the case since now other ports like Eternity or DSDA-Doom also support DiH.

So, do you think there would be enough interest in new, radically different standard? I really mean radically different.

• new, universal, map format that is not UDMF
  • binary, for faster parsing, yet extensible
  • ditch old conventions (doom / hexen map formats)
  • with NODEs present, unlike UDMF which has missing BLOCKMAP
• new, universal actors/states definition
  • binary, for faster parsing, yet extensible
• new, sane line action system
  • ditch old conventions of doom / hexen / UDMF map formats

Basically, everything would need conversion tools from text format to new binary format. But it is gonna be much easier to handle converted output in source ports.

I already have working ideas. Everything should have easy integration to existing code.

I did not implement anything like that in ACE Engine  - that was not my goal.

If not full-fledged "ACE Doom" source port, but (at the very least) support of "ACE Engine" in things like "Woof!", "DSDA-Doom" and "Doom Retro" can be really nice!

14 minutes ago, kgsws said:

So, do you think there would be enough interest in new, radically different standard? I really mean radically different.

• new, universal, map format that is not UDMF
  • binary, for faster parsing, yet extensible
  • ditch old conventions (doom / hexen map formats)
  • with NODEs present, unlike UDMF which has missing BLOCKMAP
• new, universal actors/states definition
  • binary, for faster parsing, yet extensible
• new, sane line action system
  • ditch old conventions of doom / hexen / UDMF map formats

Basically, everything would need conversion tools from text format to new binary format. But it is gonna be much easier to handle converted output in source ports.

I already have working ideas. Everything should have easy integration to existing code.

I did not implement anything like that in ACE Engine  - that was not my goal.

Now I'm definitely in favor of any of your moves, I like your ideas.

@kgsws, I have updated Slade to version 3.2.3 (latest), then extracted every map lumps individualy into each correspondingly named folder and even packed every map data into separate wads called correspondingly to the folder names. It's like linedefs that don't read correct. I thought it was my system so I checked every drive I have, starting with my system's SSD and ending doing the same with two other HDDs and it's the same outcome.

Every time I try to load a map directly out of ademo0.wad or ademo1.wad, Ultimate Doom Builder and GZDoom BuilderBugFix will exit with an error:

Here is the archive with extracted maps attached.

ademo1_maps.zip

1 hour ago, RastaManGames said:

If not full-fledged "ACE Doom" source port, but (at the very least) support of "ACE Engine" in things like "Woof!", "DSDA-Doom" and "Doom Retro" can be really nice!

That's quite tough. After all the time i spent implementing subset of ZDoom features, i don't think its a good way forwad. So i would not recommend implementing this to other source ports.

Fortunately, my new proposal would allow same outcome.

31 minutes ago, Darkcrafter07 said:

extracted every map lumps individualy into each correspondingly named folder

I am not sure why do you need that. ACE Engine does not support ZIPs.

If you want to separate maps, you can just create new WAD file in SLADE and copy only map data.

31 minutes ago, Darkcrafter07 said:

Every time I try to load a map directly out of ademo0.wad or ademo1.wad, Ultimate Doom Builder and GZDoom BuilderBugFix will exit with an error:

That, to me, looks like it's complaining about PNAMES/TEXTURE1 exploit. Indeed, TEXTURE1 indexes out of bounds.

Make a copy of my WAD file, then delete PNAMES and TEXTURE1. Just note that it will no longer work in DOS as those lumps contain code execution exploit.

1 hour ago, kgsws said:

So, do you think there would be enough interest in new, radically different standard? I really mean radically different.

The problem will be getting both editor developers and port developers on board, and I don't really see that happening.

1 hour ago, kgsws said:

So, do you think there would be enough interest in new, radically different standard? I really mean radically different.

• new, universal, map format that is not UDMF
  • binary, for faster parsing, yet extensible
  • ditch old conventions (doom / hexen map formats)
  • with NODEs present, unlike UDMF which has missing BLOCKMAP
• new, universal actors/states definition
  • binary, for faster parsing, yet extensible
• new, sane line action system
  • ditch old conventions of doom / hexen / UDMF map formats

 

Binary (for 'faster parsing') will make the whole thing DOA.

You totally overestimate the time that is needed to parse text files. The downside would be that binary formats are hard to extend if the need arises. UDMF was designed from the ground up to add whatever you like. Parsing text really isn't the bottleneck. When I stress tested ZDoom's UDMF parser on a conversion of the first ZDCMP the pure text parsing was less than half the map setup time. Things like texture lookup and actor spawning were a lot more costly than scanning a few MB of text

Overall, I don't think this will work out. It's too much change for the sake of change and putting questionable performance concerns before ease of use.

The only thing in here that sounds interesting would be a sanitized line axtion system.

Concerning the blockmap, no it makes no sense to have it in the map, it'd be a lot better if we had a reference implementation of a blockmap generator that could be included into all interested ports. Generating a blockmap is so fast that loading it from a file makes little sense.

36 minutes ago, Gez said:

The problem will be getting both editor developers and port developers on board, and I don't really see that happening.

That is what i'm worried about. I think new formats would have to come first, with conversion tools. Then editor developers could catch up.

7 minutes ago, Graf Zahl said:

The downside would be that binary formats are hard to extend if the need arises. UDMF was designed from the ground up to add whatever you like.

I propose https://en.wikipedia.org/wiki/CBOR, it would allow any extensibility required while being easier to parse. And it offers features like knowing array size before parsing each element.

Also, most importantly, all the map data would not be shoved into a single lump, be it binary or text.

CBOR would also be used for states and actor definitions.

12 minutes ago, Graf Zahl said:

You totally overestimate the time that is needed to parse text files.

Well, i did try adding UDMF support to ACE Engine - i had map loading sorted out, without BLOCKMAP.

While this might be caused by my questionable text parser, it more than doubled map loading time.

Overall it's painful to work with since i don't even know how many elements i have allocate (linedefs, sidedefs ...).

Yes, it was on outdated hardware. But that's what ACE Engine is about.

21 minutes ago, Graf Zahl said:

Overall, I don't think this will work out. It's too much change for the sake of change and putting questionable performance concerns before ease of use.

It's not change for the sake of change. Well, for GZDoom, it is. But other source ports are still stuck in DEHACKED era.

To sum it up, i want to propose new, enhanced, editing feature-set that could potentially run on old hardware.

Leave it to Graf to shit all over good ideas.

18 minutes ago, kgsws said:

While this might be caused by my questionable text parser, it more than doubled map loading time.

Out of curiosity, how much longer is "doubled map loading time"?

I might be used to playing Doom on modern hardware for too long, but of all the limitations of the engine that people debate, map loading time isn't something I've seen much (if any) discussion around.  

18 minutes ago, kgsws said:

But other source ports are still stuck in DEHACKED era.

I'm no programmer so I might be getting confused, but how is DEHACKED (which AFAIK is a system for defining Things) related to UDMF (which AFAIK a format for defining maps)?  Is there a relationship here I'm misunderstanding?

2 minutes ago, Bauul said:

I'm no programmer so I might be getting confused, but how is DEHACKED (which AFAIK is a system for defining Things) related to UDMF (which AFAIK a format for defining maps)?  Is there a relationship here I'm misunderstanding?

There's not an explicit relationship, but all of the ports that initially supported UDMF also happened to support a post-Dehacked type of language (EDF, DECORATE/ZScript, et al)