Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Gibbon

ReBOOM 2.06um (Updated November 19th 2021)

Recommended Posts

1 hour ago, Gibbon said:

I admit I was very nervous about adding it, but seeing that UMAPINFO was assumed to be only on advanced engines made me want to do it.  But I made sure it is optional and it won't affect Boom demo's if you use -numapinfo.

 

One thing I disliked about the spec was the assumption that every port has MBF features, which to me was a total 'wtf' moment.  Admittedly until now there was no 'Boom' in the historic sense and so MBF features were in every source port that wanted it.  Obviously, I turned that upside down with ReBOOM and so one thing to point out is that the MBFHelperDog actor type is removed.

I mean, it makes sense. UMAPINFO is a modern feature, so usually for a port to support it, it would have had support for quite a few things aswell. This Boom 2.02 with UMAPINFO is cool as heck though, and it fits the TeamTNT spirit.

With ongoing discussion centering around standards lately again, more broad UMAPINFO support is one way to ensure some kind of universal-ness amongst ports.

1 hour ago, Gibbon said:

 

I will also start doing monthly updates since now ReBOOM really needs to have a refactor.  I've patched it as much as I can but there is old code there that basically has to go.  I'll do this in a private branch as it will be broken for a long time I think :) but for proper cross platform portability it has to happen.  It's going to be kick ass at the end of it though, no other features just getting it 100% perfect.

Don't go overboard or ReBoom Experimental has to be brought back from the dead :P

1 hour ago, Plank_Guy_89 said:

I like Umapinfo because I hate MBF Sky Transfers because I can never seem to get it to actually work.  It always displays the corpse texture in map 16 as the skybox for whatever reason no matter what I set it as.

I am actually at odds, how are UMAPINFO and MBF Sky Transfers related? Unless MBF added on the effect, sky transfers are inherently a Boom mechanic.

Share this post


Link to post
1 hour ago, Plank_Guy_89 said:

I like Umapinfo because I hate MBF Sky Transfers because I can never seem to get it to actually work.  It always displays the corpse texture in map 16 as the skybox for whatever reason no matter what I set it as.

 

Remember that the sky transfer linedef action uses the UPPER texture, not the middle texture. What you're seeing is the first texture defined in Doom 2, AASHITTY, which technically uses that corpse texture as a patch. It shows up if no upper texture is defined.

Share this post


Link to post
4 minutes ago, maxmanium said:

Remember that the sky transfer linedef action uses the UPPER texture, not the middle texture. What you're seeing is the first texture defined in Doom 2, AASHITTY, which technically uses that corpse texture as a patch. It shows up if no upper texture is defined.

Thanks a lot.  

Share this post


Link to post
11 hours ago, Gibbon said:

I will also start doing monthly updates since now ReBOOM really needs to have a refactor.  I've patched it as much as I can but there is old code there that basically has to go.

WELCOME TO HELL! HAHAHA. our personel hopes that you will enjoy your stay, because you have no choice and no escape anyway.

Share this post


Link to post

Would it at all be possible to add ACS compatability to ReBoom? I know that's kinda crazy sounding, and I am no programmer, so excuse my ignorance. I suppose it would require BEHAVIOR lump compatibility too. If you could use the features of Boom and ACS / MAPINFO the level of detail and intrigue you could add to a level wpuld be mind blowing. 

 

Yet again, if that's weird and would never work, ignore me lol.

Edited by Dusty_Rhodes

Share this post


Link to post
19 minutes ago, Dusty_Rhodes said:

Would it at all be possible to add ACS compatability to ReBoom? I know that's kinda crazy sounding, and I am no programmer, so excuse my ignorance. I suppose it would require BEHAVIOR lump compatibility too. If you could use the features of Boom and ACS / MAPINFO the level of detail and intrigue you could add to a level wpuld be mind blowing. 

 

Yet again, if that's weird and would never work, ignore me lol.

It would technically be possible and I could pinch it from Choco Hexen as that doesn't have assembler for it (other ACS projects use DOS Assembler for most of it).

 

Alternative is a strict subset of DECORATE but I don't want to port C++ back to C (it never ends well usually).  But yeah it can be done, but maybe in the future.

Share this post


Link to post
29 minutes ago, Gibbon said:

It would technically be possible and I could pinch it from Choco Hexen as that doesn't have assembler for it (other ACS projects use DOS Assembler for most of it).

 

Alternative is a strict subset of DECORATE but I don't want to port C++ back to C (it never ends well usually).  But yeah it can be done, but maybe in the future.

Wow that's awesome. I'd love to see it sometime, but for now I'm really happy that MAPINFO got added. I can play some things in old school Boom that I never thought I be able to. Good stuff :D

Share this post


Link to post
49 minutes ago, Gibbon said:

It would technically be possible and I could pinch it from Choco Hexen

but note that you will have to implement the whole set of Hexen line specials, because Doom-in-Hexen maps aren't using Doom specials anymore. so it's not only about having ACS VM, alas…

Share this post


Link to post
4 hours ago, ketmar said:

but note that you will have to implement the whole set of Hexen line specials, because Doom-in-Hexen maps aren't using Doom specials anymore. so it's not only about having ACS VM, alas…

Exactly hence the 'technically' but doesn't mean 'absolutely'.  It is possible but with a sh*tload of baggage too.  Would it be worth it..  not sure.  Anyone using it are likely using ZDoom or some derivative of it.

Share this post


Link to post

but if you will do that, you would be able to add Hexen support. because all important parts will be there. ;-)

Share this post


Link to post
1 hour ago, Gibbon said:

Exactly hence the 'technically' but doesn't mean 'absolutely'.  It is possible but with a sh*tload of baggage too.  Would it be worth it..  not sure.  Anyone using it are likely using ZDoom or some derivative of it.

This exactly. ACS support is kind of backwards here. In a opposite direction, one could take Choco Hexen and then implement Boom mechanics into it?

 

I do not think its worth the effort though: ACS is but one script language and there are many superior alternatives for that.

 

If you were to, i would rather take PrBoom 2.02 and see how far you could go with ACS support. Since PrBoom 2.02 is just barebones Boom on Windows, that could be worth experimenting for.

Share this post


Link to post
25 minutes ago, Redneckerz said:

This exactly. ACS support is kind of backwards here. In a opposite direction, one could take Choco Hexen and then implement Boom mechanics into it?

 

I do not think its worth the effort though: ACS is but one script language and there are many superior alternatives for that.

 

If you were to, i would rather take PrBoom 2.02 and see how far you could go with ACS support. Since PrBoom 2.02 is just barebones Boom on Windows, that could be worth experimenting for.

I did a 64bit port of prboom 2.02 as part of the initial process with ReBOOM.  Never touched it though as ReBOOM at the time just worked better.

 

The code would be a better match for porting the original Hexen code to it but then Choco already has it and might be more accessible to experiments as more developers would be willing to hack on Choco then on 21 year old prboom 2.02 :) if Ketmar is anything like me, he'd be just as disgusted the moment he looks at that code.

Share this post


Link to post
2 hours ago, Gibbon said:

I did a 64bit port of prboom 2.02 as part of the initial process with ReBOOM.  Never touched it though as ReBOOM at the time just worked better.

 

The code would be a better match for porting the original Hexen code to it but then Choco already has it and might be more accessible to experiments as more developers would be willing to hack on Choco then on 21 year old prboom 2.02 :) if Ketmar is anything like me, he'd be just as disgusted the moment he looks at that code.

That's what i mean. I know ACS is powerful (Powerful enough that you can make minigames with them that can run back into DOS Hexen) but the trouble bringing it to a Boom source chassis seems numerous. You might be better off starting at a ZDoom-derived build where most of the real hard trouble has been resolved already.

Share this post


Link to post
24 minutes ago, Redneckerz said:

That's what i mean. I know ACS is powerful (Powerful enough that you can make minigames with them that can run back into DOS Hexen) but the trouble bringing it to a Boom source chassis seems numerous. You might be better off starting at a ZDoom-derived build where most of the real hard trouble has been resolved already.

Someone can use these :)

 

https://github.com/atsb/zdoom/releases

Share this post


Link to post
39 minutes ago, Gibbon said:

Someone can use these :)

 

https://github.com/atsb/zdoom/releases

LMAO. I totally missed that. It does not appear a build of 2.8.1, but rather. 2.8.9999.0, or 2.9.pre. What ZDoom source are you building this against? The very latest before ZDoom was discontinued (so beyond 2.8.1)?

Maybe call it ZDoom64.exe or something to that effect? Because a straight 64 bit build of the very latest ZDoom might be useful, though i should mention that @drfrag has kept several ZDoom offsprings aswell.

 

Just a heads up, the Win64 version of that wont run because of a missing VCRUNTIME140_1D.dll file, a missing VCRUNTIME140D.dll file and a missing MSVCP140D.dll file. It also misses ucrtbased.dll.
 

Share this post


Link to post
1 hour ago, Redneckerz said:

That's what i mean. I know ACS is powerful (Powerful enough that you can make minigames with them that can run back into DOS Hexen) but the trouble bringing it to a Boom source chassis seems numerous. You might be better off starting at a ZDoom-derived build where most of the real hard trouble has been resolved already.

Well, I was kinda thinking the ability to do Doom in Hexen Format maps on something other than ZDoom would be really cool. Of course, that might mess with the "vanillaness" of the gameplay, and Boom was always supposed to be a more conservative port. Maybe it's a dumb pipe dream, but I'm not really a ZDoom fan because I'm a boomer. So being able to use ACS for Doom on a different port is like a dream come true. And yes, I know Fragglesripct is better. 

Share this post


Link to post
10 minutes ago, Redneckerz said:

LMAO. I totally missed that. It does not appear a build of 2.8.1, but rather. 2.8.9999.0, or 2.9.pre. What ZDoom source are you building this against? The very latest before ZDoom was discontinued (so beyond 2.8.1)?

Maybe call it ZDoom64.exe or something to that effect? Because a straight 64 bit build of the very latest ZDoom might be useful, though i should mention that @drfrag has kept several ZDoom offsprings aswell.

 

Just a heads up, the Win64 version of that wont run because of a missing VCRUNTIME140_1D.dll file, a missing VCRUNTIME140D.dll file and a missing MSVCP140D.dll file. It also misses ucrtbased.dll.
 

Works for me :) but as a developer I have all VC runtimes installed so I never had the issue.

 

These are built against the bleeding edge version.

 

@Dusty_Rhodes

 

I was always thinking to port the QuakeC code to it for fun as part of the experimental stuff.  Not tied to any specific entities and you just plug it where you want it to interface against.

Share this post


Link to post
1 minute ago, Gibbon said:

Works for me :) but as a developer I have all VC runtimes installed so I never had the issue.

 

These are built against the bleeding edge version.

Yeah i think that's the issue right there. Are these absolutely necessary? Because i recall from my old computer i had a dozen or so of these Visual Redistributables, as they don't overwrite each other.

If they are, which runtime is required for these files?

That bleeding edge one is likely a fixed build since ZDoom is discontinued.

Share this post


Link to post
Just now, Redneckerz said:

Yeah i think that's the issue right there. Are these absolutely necessary? Because i recall from my old computer i had a dozen or so of these Visual Redistributables, as they don't overwrite each other.

If they are, which runtime is required for these files?

That bleeding edge one is likely a fixed build since ZDoom is discontinued.

I'll have a check and add the right ones.  I have only one Windows machine so I cannot test it on anything else :)

 

It wasn't fixed enough because I still had to make changes for compilation (see the commits I did).

 

I basically took the master of its git repo.

Share this post


Link to post
Just now, Gibbon said:

I'll have a check and add the right ones.  I have only one Windows machine so I cannot test it on anything else :)

 

It wasn't fixed enough because I still had to make changes for compilation (see the commits I did).

 

I basically took the master of its git repo.

Thanks :) If you want, i can post it to the ZDoom forums - I mean 64 bits is 32 bits more than 32 bit, so... :P

Share this post


Link to post
1 minute ago, Redneckerz said:

Thanks :) If you want, i can post it to the ZDoom forums - I mean 64 bits is 32 bits more than 32 bit, so... :P

If it won't invoke the wrath of Graf sure :) 

Share this post


Link to post
11 minutes ago, Gibbon said:

If it won't invoke the wrath of Graf sure :) 

I mean, a bleeding edge build of old ZDoom that includes almost a year of fixes compared to 2.8.1, in 64 bit, would be good. Although i do sitll remain you should just call it ZDoom64 2.9 or something to denote the difference.

 

I mean ZDoom 2.8.1 is getting some more attraction from the demo community now that the port is finally in a fixed state. A defacto bleeding edge build that does nothing else but implement 64 bit support (and include fixes post-2.8.1) is a good starter port by itself still.

It is the WinMBF64 tale all over again! :P

Share this post


Link to post

No, the latest master was unstable. I mean right after the ZScript merge there were a lot of bugs, it's mostly broken. I forked before the ASM removal and before ZScript and then you have to deal with the floatification aftermath anyway, a lot of fixes even from much later. ZDoom32 should compile with 64 bit but i haven't tried becouse i was not interested. BTW i keep a branch without the GL renderer too.

Share this post


Link to post
31 minutes ago, Redneckerz said:

I mean, a bleeding edge build of old ZDoom that includes almost a year of fixes compared to 2.8.1, in 64 bit, would be good. Although i do sitll remain you should just call it ZDoom64 2.9 or something to denote the difference.

 

I mean ZDoom 2.8.1 is getting some more attraction from the demo community now that the port is finally in a fixed state. A defacto bleeding edge build that does nothing else but implement 64 bit support (and include fixes post-2.8.1) is a good starter port by itself still.

It is the WinMBF64 tale all over again! :P

I'll do some builds and name it then.

 

Bloody hell..  not another one :D

 

@drfrag

 

Sure it isn't perfect, no crashes though and it seems to work fine.  Mac M1 is busted though, that's a no go.  I fixed a few wrongdoings though.

Share this post


Link to post

For instance the chainsaw didn't work properly, that speaking of Doom alone. But really ZScript was very buggy at first (and most things were scriptified).

The latest ZDoom DRD Team devbuilds are still available BTW.

Share this post


Link to post
18 minutes ago, drfrag said:

For instance the chainsaw didn't work properly, that speaking of Doom alone. But really ZScript was very buggy at first (and most things were scriptified).

The latest ZDoom DRD Team devbuilds are still available BTW.

I'll check that later, I never use the chainsaw as I play with headphones and it's a horrible sound.

 

I prefer to do my own builds, as far as I know they just build and don't actually fix things that fail (I could be wrong).  For example, latest on 64bit had OpenAL failures due to a deprecation of a class in the latest versions on OAL.  I fixed that.

Share this post


Link to post
45 minutes ago, drfrag said:

No, the latest master was unstable. I mean right after the ZScript merge there were a lot of bugs, it's mostly broken. I forked before the ASM removal and before ZScript and then you have to deal with the floatification aftermath anyway, a lot of fixes even from much later. ZDoom32 should compile with 64 bit but i haven't tried becouse i was not interested. BTW i keep a branch without the GL renderer too.

That latter one could be worthwhile to have a build of, if unmaintained. Still with truecolor, no?

45 minutes ago, Gibbon said:

I'll do some builds and name it then.

 

Bloody hell..  not another one :D

 

@drfrag

 

Sure it isn't perfect, no crashes though and it seems to work fine.  Mac M1 is busted though, that's a no go.  I fixed a few wrongdoings though.

Thanks, i smell a cooperation with drfrag here, haha

But drfrag does have a point though. I think for pure gameplay, building from latest would be fine enough, but that's on you. But drfrag can help you point out very specific bug fixes - When it comes to source ports for low ends and ZDoom, he is your guy :)

Share this post


Link to post
22 minutes ago, Redneckerz said:

That latter one could be worthwhile to have a build of, if unmaintained. Still with truecolor, no?

Thanks, i smell a cooperation with drfrag here, haha

But drfrag does have a point though. I think for pure gameplay, building from latest would be fine enough, but that's on you. But drfrag can help you point out very specific bug fixes - When it comes to source ports for low ends and ZDoom, he is your guy :)

Sounds good, I'll check out the repo's.  My C++ is good but obviously a codebase the size of ZDoom's needs months to learn.

 

Maybe it needs its own thread for this.  ReBOOM is getting jealous ;)

Share this post


Link to post
10 minutes ago, Gibbon said:

Sounds good, I'll check out the repo's.  My C++ is good but obviously a codebase the size of ZDoom's needs months to learn.

 

Maybe it needs its own thread for this.  ReBOOM is getting jealous ;)

Should i make it? I mean, ZDoom64 may sound too much like a derivative of ZDoom32 and besides that, drfrag's work covers most of the low-ends. But a barebones 64 bit ZDoom build, can't hurt.

It might be more worthwhile to have 64 bit builds of older things like ZDoom 1.22 since quite a few ports are derived from that, or some off-market stuff like ZDoomGL. The first version is in fact ZDoom 1.22 with a OpenGL 1.1 renderer - Very unstable, and although v2 by a completely different dev improved upon it, it was the defacto GL renderer for ZDoom before GZDoom came alone.

Or... the GLBoom renderer backported to ZDoom. Its not the highest end, but it is a rather stable renderer. I am just spitting crazy ideas here, mind you :) Perhaps this is more worthwhile of a PM, as ReBoom is having second thoughts, i can tell ;)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×