Super Mario Bros. X Forums

Hoeloe wrote: ↑

Sat Oct 09, 2021 8:31 pm

The point is that we're trying to keep backwards compatibility in order to ensure that older episodes don't suddenly break.

The fact, Me and my friends were doing the same work on the TheXTech side, therefore the flexible compat.ini system was been designed to manage this, and the most recent compatibility modes sub-system got implemented also to enforce the specific compatibility level by user-side global option (i.e. disable all bug-fixes to represent the full SMBX 1.3 behavior, or disable the most of bugs except these got been fixed at SMBX2 side while the native TheXTech mode got already fixed tenths of vanilla bugs that still bugs on SMBX2). We had played bazillion of old episodes here, and all bugs that actually breaks the compatibility got been fixed already (note, there are bugs having three categories: "bug" - exclusive bugs of TheXTech, my personal fault. "vanilla bug" - these bugs existed since Redigit's build, and they are bugs. "vanilla peculiarity" - the "feature" based on vanilla bugs, should be taken carefully, don't fix it or keep disabled by default at compat.ini). And I personally confirm, that all these episodes I and my friends played, do work the same on every processor I had to use: x86_64, x86, ARM64, ARM-v7. Also, PPC64LE at my friend's friend too. If behavior starts to be different - this is a reason to report the bug.

Wohlstand wrote: ↑

Sat Oct 09, 2021 8:42 pm

therefore the flexible compat.ini system was been designed to manage this

Oh you mean like our glitch toggle functions that we have because fixing glitches conditionally is not something that's impossible for us?

Enjl wrote: ↑

Sun Oct 10, 2021 5:43 am

Wohlstand wrote: ↑

Sat Oct 09, 2021 8:42 pm

therefore the flexible compat.ini system was been designed to manage this

Oh you mean like our glitch toggle functions that we have because fixing glitches conditionally is not something that's impossible for us?

Yes, the similar thing one. And I see while you have such system, you still reject on making more fixes with a worry to break the compatibility, etc.

Wohlstand wrote: ↑

Sun Oct 10, 2021 6:23 am

you still reject on making more fixes with a worry to break the compatibility, etc.

That sounds awfully accusatory. Do you have any specific examples?

Enjl wrote: ↑

Sun Oct 10, 2021 6:41 am

Wohlstand wrote: ↑

Sun Oct 10, 2021 6:23 am

you still reject on making more fixes with a worry to break the compatibility, etc.

That sounds awfully accusatory. Do you have any specific examples?

I don't remind exact cases, some of them partially discussed with Rednaxela, I told him about vanilla bugs I fixed at TheXTech side with an explanation of their nature, and he told in some moments that he would try look on that at SMBX2 side. But nothing on that was changes because of understandable reason being backlogged by other tasks. I do remind something about the scull raft related stuff, but very unclear...

Hoeloe wrote: ↑

Sat Oct 09, 2021 8:31 pm

If the criticism were more generally about platform independence that would be one thing, but it's the specific element of "it's only valid if a user can compile it from scratch at source" that's just weird.

That's the only way to ensure long-term platform-independence. Unless PCs become much more powerful and x86 Emulation becomes feasible. But, I don't see that happening.

Hoeloe wrote: ↑

Sat Oct 09, 2021 8:31 pm

Also note that "platform independence" is very difficult to do while maintaining the backwards compatibility we have right now. It's probably possible, but it would mean likely a year or longer delay to anything else on the engine, which is not something we're wanting to do at this point.

Can you elaborate on this? How could platform-independence be accomplished? How would sticking to backward-compatibility delay development?

Hoeloe wrote: ↑

Sat Oct 09, 2021 8:31 pm

Again, sure, but Wohl keeps bringing up the same few points despite the fact we've already answered them all many times, and it's just to do with priorities.

Sure. If you (the X2 devs) are clear about your priorities, and acknowledge the downsides they entail, that's fine. It's not what I'm seeing though. What I observed on this forum is talking down issues, attempts to de-legitimize alternatives without them, and denial that those have an audience.

These things don't contribute to a hospitable discussion climate.

Wohlstand wrote: ↑

Sat Oct 09, 2021 8:42 pm

The fact, Me and my friends were doing the same work on the TheXTech side

You know full well I was referring to POST 1.3 episodes - ones with LunaLua code attached.

0lhi wrote: ↑

Sun Oct 10, 2021 2:06 pm

That's the only way to ensure long-term platform-independence. Unless PCs become much more powerful and x86 Emulation becomes feasible. But, I don't see that happening.

It's not. WINE exists and runs SMBX2 fairly well by my understanding. Obviously not as well as native, but from our perspective it's a "good enough" solution that works and doesn't require us to basically rebuild SMBX2 from the ground up.

0lhi wrote: ↑

Sun Oct 10, 2021 2:06 pm

Can you elaborate on this? How could platform-independence be accomplished? How would sticking to backward-compatibility delay development?

The problem with platform independence is that SMBX2 is built as an addon to a specific pre-compiled executable, and much of its code (and the code of some episodes, which is why I reference backwards compatibility specifically) relies on a specific layout of memory structures in this executable. Recompiling the code from source would re-allocate everything, and effectively cause older episodes and basegame code to not just break, but likely cause the game to outright crash to desktop. SMBX 1.3 was only ever compiled to run on Windows, and since SMBX2 is built on top of that, we can't do much about it. If we DID want to make the game truly platform independent, it would mean reimplementing a good chunk of basegame code, and installing some sort of memory emulation to ensure backwards compatibility with episodes, which would take an awful lot of work to do.

0lhi wrote: ↑

Sun Oct 10, 2021 2:06 pm

Sure. If you (the X2 devs) are clear about your priorities, and acknowledge the downsides they entail, that's fine. It's not what I'm seeing though.

We do in fact do this quite a lot. We just don't actually do most of our discussion here, since this isn't really the "home base" for SMBX2 development, so to speak. Most of this happens over in Codehaus.

0lhi wrote: ↑

Sun Oct 10, 2021 2:06 pm

What I observed on this forum is talking down issues, attempts to de-legitimize alternatives without them, and denial that those have an audience.

These things don't contribute to a hospitable discussion climate.

What you're missing here is surrounding context, as a lot of these discussions occur partly here, and partly on discord servers. In terms of "delegitimizing alternatives", that's not the intent here. However, there have been MANY issues in the past with people getting confused over which version of SMBX is the one they should be using for a particular episode. People have tried plugging LunaLua code into 38A's Teascript editor, they've tried opening SMBX2 levels in 38A (and subsequently breaking them due to 38A's auto-conversion), they've tried opening 38A levels in X2, etc. etc. People get confused when there are lots of different versions of the same thing, especially when one is aiming for the same goal as another, and modelled on it too (NSMBX was originally planning to include Lua scripting, too, based on LunaLua). This has all been discussed a long time ago via Discord and this is basically the reason why the project was renamed to not be "another SMBX version", so as to not muddy the waters and confuse people. No-one on the SMBX2 team objects to people making their own forks of SMBX to do whatever with, but there are genuine issues that occur when people make lots of slightly different variations, all called "SMBX" in some fashion, and dealing with those back with 38A genuinely set back a lot of our development and actually catalysed a lot of rather unpleasant drama. The easiest way to avoid that is for new projects to set themselves apart, even if just by name, rather than be "another SMBX thing". There's a reason projects like Super Mario ReInvent and TheXTech don't contain "SMBX" in the name, and this is it.

As for "denial that they have an audience", the fact of the matter is that 38A and X2 have by far the largest playerbases of any of the SMBX projects, so in the context of "which version should I pick if I want people to play my episode?", it's absolutely sensible to suggest "maybe not one of the ones with a relatively low number of installs, maybe pick one that people already have on their computers."

Were those two posts you linked phrased perfectly? Probably not, but it's not as antagonistic as you seem to suggest.

Hoeloe wrote: ↑

Mon Oct 11, 2021 11:15 pm

It's not. WINE exists and runs SMBX2 fairly well by my understanding. Obviously not as well as native, but from our perspective it's a "good enough" solution that works and doesn't require us to basically rebuild SMBX2 from the ground up.

That works on Linux Mint, Ubuntu and other distros right. However:

• Right now, there is major issue on Manjaro distro, the game won't render at all. At the same time, my early OpenGL demo and random Direct 3D demo were works pretty well. There is a folk at my chat has major troubles with SMBX2 because of this on Manjaro.
• No longer works on macOS since Catalina. Needed to have the paid Crossover and make the system wide hack (to allow modify system files) to allow game work.
• While works well on x86 and x86_64 processors, you won't able to run this game if you have ARM, MIPS, PowerPC, etc. processor. Wine for these processors is only gives the winelib which allows you to compile applications built on it to run on these processors. There is even no way to run native ARM64 Windows apps yet as I heard. But probably they added some... Need to check out their news...

Other terms I'll reply later, I need to go now into the city...

Hoeloe wrote: ↑

Mon Oct 11, 2021 11:15 pm

It's not. WINE exists

Wine is not platform-independent. Emulators can grant platform-independence. Compatibility layers cannot. Like Wohlstand said, Wine doesn't help modern MacOS users or Linux users with non-x86 Hardware.

Hoeloe wrote: ↑

Mon Oct 11, 2021 11:15 pm

What you're missing here is surrounding context, as a lot of these discussions occur partly here, and partly on discord servers.

I never claimed to know the full context. I am merely commenting on what's visible in this forum. And that does not give a good impression.

Keep in mind that discussions are just one purpose of this site. Another is communicating information to the general public. I didn't see Wohlstand's posts as a call to discuss, but as an education on X2's downsides, that, while not important to you, may be important to some.

Hoeloe wrote: ↑

Mon Oct 11, 2021 11:15 pm

it's absolutely sensible to suggest "maybe not one of the ones with a relatively low number of installs, maybe pick one that people already have on their computers."

When phrased like this, it is an okay point to make. I would counter it with "Every Platform that supports X2/38A also supports XTech, but the opposite is not true. So, when it doesn't entail too many sacrifices, it should at least be considered." That's not what was said, though.

0lhi wrote: ↑

Tue Oct 12, 2021 5:59 am

Wine is not platform-independent. Emulators can grant platform-independence. Compatibility layers cannot. Like Wohlstand said, Wine doesn't help modern MacOS users or Linux users with non-x86 Hardware.

Sure, but it's a case of coverage. WINE covers a good portion of non-Windows users, and is a "good enough" solution for the time being considering the work involved in anything more substantial.

0lhi wrote: ↑

Tue Oct 12, 2021 5:59 am

I never claimed to know the full context. I am merely commenting on what's visible in this forum. And that does not give a good impression.

Keep in mind that discussions are just one purpose of this site. Another is communicating information to the general public. I didn't see Wohlstand's posts as a call to discuss, but as an education on X2's downsides, that, while not important to you, may be important to some.

And I agreed that perhaps those particular posts weren't ideally phrased. There's also the point that Wohl has a tendency to a) bring up downsides to X2 all the time, whether they're relevant or not and b) use such discussion to sing the praises of TheXTech. It gets a little tiring after a while, so I tend to be a little short when this comes up these days,

0lhi wrote: ↑

Tue Oct 12, 2021 5:59 am

When phrased like this, it is an okay point to make. I would counter it with "Every Platform that supports X2/38A also supports XTech, but the opposite is not true. So, when it doesn't entail too many sacrifices, it should at least be considered." That's not what was said, though.

I'm... not sure how that's relevant. Platform independence isn't really worth considering in its own right if the number of people making use of it is small. The fact of the matter is that the VAST majority of SMBX users (regardless of which branch) run Windows. Would that change if more versions were fully platform independent? Maybe, but that's not really going to happen within the lifespan of a single episode, and if someones main concern is "I want this to be available to a lot of people", it's sensible to choose a system with a high user base. On top of that, there's also the additional functionality to consider. TheXTech might be platform independent, but it's also just 1.3 with some bugfixes, and with everything that's been made in X2 and 38A over the past few years, that's frankly just not a very enticing offer to a lot of creators.