"UMAPINFO" discussion

[Ferk]

The problem is not C/C++ interoperability, it's mostly the adoption.

It doesn't really matter what language the reference implementation uses, but ideally the base spec should not be overly complex so it's possible for someone to port it to plain C for their C source port (eg. chocolate derivative) if they want. At least for the base spec, if extra stuff is added as optional extensions to the spec that don't mess too much with compatibility, that'd be fine.

 

If there were a C++ implementation in the prboom+ umapinfo port I could try and make a separate C version for it myself like I did for the umapinfo parser. Libretro prboom port sadly can't mess too much with compilers because it's ported to many platforms, some being awkwardly restricted consoles.

Edited August 15, 2019 by Ferk

[Graf Zahl]

The curse of needing support for hardware that for all intents and purposes has to be considered outdated and obsolete.

What platforms are there that do not support C++? I've been targeting the original Playstation with C++ in the early 2000's!

 

 

[Ferk]

I don't have the details, since I do not maintain or own myself all the platforms that the libretro buildbot compiles for. There's PSP, Gamecube, original xbox...
I bet it's perfectly possible to set up the toolchain to use the modified g++ for each platform, but it'd need involvement from those who do maintain it and feedback from those who can test it. It's just kinda troublesome to mess with the build system.

 

Anyway, this is not a problem for the umapinfo prboom-plus port. Just use whatever language is more comfortable or allows the most reuse. The point I was making is just that having simple structure could help the adoption from other source ports.

[Ferk]

On the topic of the spec: maybe it would be good to clarify the terminology.

 

The umapinfo spec implies that "intermission" is the name of the screens where the story text can be shown, which is what the original code calls "finale". Is that right?

 

The confusion comes from there being a "nointermission" option which, when enabled, still shows the "finale" screen, but skips the end-level statistics screen (which is what the original code calls "intermission").

 

There's also an option to change the music of the finale: "intermusic"
But there's no option to change the music of the end-level statistics screen, which the prboom code calls "intermission music".

[Shadow Hog]

10 hours ago, Ferk said:

On the topic of the spec: maybe it would be good to clarify the terminology.

 

The umapinfo spec implies that "intermission" is the name of the screens where the story text can be shown, which is what the original code calls "finale". Is that right?

 

The confusion comes from there being a "nointermission" option which, when enabled, still shows the "finale" screen, but skips the end-level statistics screen (which is what the original code calls "intermission").

 

There's also an option to change the music of the finale: "intermusic"
But there's no option to change the music of the end-level statistics screen, which the prboom code calls "intermission music".

Yeah, this probably should get hashed out sooner than later. I'll note it's also probably behind this still-open GZDoom bug report, because I was expecting the text screen's music to change but not the level stat screen's music. In PrBoom+/UM, that's exactly what I get, but in GZDoom, either it changes both or the level stat music will play over the text screen.

[Ferk]

Since the image shown in the end-level statistics screen is "exitpic", maybe there could be an "exitmusic" and change "nointermission" to "noexitscreen", for example.

 

So in the terminology the end-level screen could be considered the "exit screen".

 

I don't think Sigil umapinfo uses "nointermission", so renaming wouldn't break compatibility with it.

[fabian]

What's going to happen with this bug? 

 

https://github.com/coelckers/prboom-plus/issues/21

[Graf Zahl]

If you can turn this into a PR I could just add it. I'm sorry but I currently do not have time to set this project up for development again, even if it's just a single line of code.

 

 

[fabian]

Fixed now, thanks. 

[ReaperAA]

BTW when should we expect the release of 2.5.1.8um (or whatever the next build will be called)

[seed]

4 minutes ago, ReaperAA said:

BTW when should we expect the release of 2.5.1.8um (or whatever the next build will be called)

 

When Graf has more time me thinks, or when he manages to find someone else to help him maintaining the fork.

 

...something also struck me like 15mins ago... how difficult would be to set up daily builds for the fork?