Super Mario Bros. X Forums

Hoeloe wrote: ↑

Sat Apr 12, 2025 12:41 pm

Supermario1313 wrote: ↑

Tue Apr 08, 2025 6:29 pm

[*] OpenCL/Compute shaders for GPU programming

I would be careful of this one - while it would be awesome for a lot of things (like making Particles more performant), it'll also massively increase the minimum required spec to run SMBX2. I'm not saying not to do it, but... it's worth being cautious about!

I have to second this concern. The most recent Chocolate Contest had some problems related to computer performance, as an example.

Rixitic wrote: On that note, it's high time I set a proper date for the end of this thread. Does the 19th still count as mid-April? I'm counting it. Let's have this thread locked on the 19th, whatever time is most convenient for the staff member who handles it. That gives folks roughly a week to make further nominations, volunteer, withdraw, or just add to what folks have already said about the repo, basegame, etc.

Turns out there's going to be a Hands Off protest on the 19th, and then the 20th is Easter, so I'm changing the closure date for this thread to Monday, April 21st.

ShadowStarX wrote: ↑

Sun Apr 13, 2025 6:39 am

Hoeloe wrote: ↑

Sat Apr 12, 2025 12:41 pm

Supermario1313 wrote: ↑

Tue Apr 08, 2025 6:29 pm

[*] OpenCL/Compute shaders for GPU programming

I would be careful of this one - while it would be awesome for a lot of things (like making Particles more performant), it'll also massively increase the minimum required spec to run SMBX2. I'm not saying not to do it, but... it's worth being cautious about!

I have to second this concern. The most recent Chocolate Contest had some problems related to computer performance, as an example.

The concern isn't that adding compute shader support has the potential to make performance worse for some players; it's that people with sufficiently-powerful computers would generally get better performance while the rest of the player base would just not be able to play a good chunk of SMBX2 content, or even SMBX2 content period.

Compute shaders are shaders that exist primarily to offload heavy calculations from the CPU to the GPU. They can be used to render things, but mostly they're for handling absurd amounts of math so the rest of your system resources can be put toward other aspects of running the game. It's just that you need a GPU that can actually run compute shaders, and while I don't know the exact specs across the board, here's the requirements from an older version of Unity as an example:

On PC it requires Windows Vista or later and a GPU capable of Shader Model 5.0. Compute shaders are also supported on capable consoles and OpenGL ES 3.1 mobile devices.

So if compute shader support gets added to SMBX2, either

• that would need to be factored in to the minimum required specs for running SMBX2 at all,

or

• there would need to be some sort of compatibility mode the engine would automatically fall back to on weaker computers, which would still mean some levels and episodes just wouldn't work properly on those computers unless their creators put in the work to implement support for the compatibility mode.

I'd like to be a bit more concrete about exactly what would happen if I were the "owner" of the repo, because there is a bit of a distinction between "repo owner", "project lead", and "team member". While I'm writing these in the first-person, I'd also recommend that whoever the owner is should take steps similar to these.

(0) I'd try to get access to Sarn's "X5 Project" C++ port source code (with all due credit going to Sarn). My understanding is that they don't currently have the bandwidth to work on this, but the new team might, and I really don't want their work to be forgotten.
(1) I'd reach out to possible team members -- from this thread there's clearly no shortage of talent! I see that these people have volunteered in the thread: MegaDood, MrDoubleA, and Supermario1313. I'd certainly invite all of you to join the team.
(2) We'd select a platform to host the code (GitHub, GitLab, Forgejo, etc) and set up an organization on whatever platform we're using. X2 would be "owned" by a cooperative entity and not by my personal account.
(3) In consultation with the new team, we'd decide what to do with the assets (non-code files) currently in X2's repository. I think there are a number of significant advantages to separating the code and the assets and I'd talk with the new team about our options here. Regardless, there would still be a way for users to download a development snapshot of the engine (see below!).
(4) I'd set up a continuous integration [CI] build for the engine that takes the current source code of X2 and all of its dependencies and turns it into an extractable (or installable) package. The latest package would always be available to users. For a sense of what this looks like, you can take a look at https://github.com/TheXTech/TheXTech/actions (the CI) and https://builds.wohlsoft.ru/ (the builds). (Note that it's totally possible to do this without depending on GitHub.) At this point there would be no 'mysterious knowledge' needed to make a release.
(5) We'd open up a thread inviting public comment about the project vision and future direction of the engine. There's been a little discussion in this thread but it would be nice to have more. Like this thread, the new thread would not be *voting* exactly but instead the new team would reach a consensus based on public opinion.
(6) I'd sit back and take a limited role as a team member. I'd review code when requested and contribute C++/OpenGL/PGE-FL bugfixes. If the new team wanted me in a leadership position (this is totally separate from whether I become the repo owner initially) I'd also maintain goals and rough timelines for each release based on the project vision.

MegaDood, MrDoubleA, and Supermario1313: you all have my full confidence as prospective repo owners and I would trust your judgement if it ended up differing from what I've suggested here. If I had to pick one of you as repo owner (though you are all excellent options), it would be MDA on the basis of your superb Battle Arena, which is both the most technically impressive and the most polished X2 project I've seen. The discipline and attention to detail that such a project requires bodes well for you as a project lead.

Rixitic wrote: ↑

Fri Mar 28, 2025 7:44 pm

...

Ok so before mentioning my concerns, I very much have some interest in being a repo owner for SMBX2, though i'd personally prefer having whatever is a more "minor" role in contributing in whatever it takes in managing said repo.

That being said, im quite iffy on actually participating, since im not sure what exactly is the specific requirements needed in order to properly manage the repo, especially since some people are vouching for me to be part of it & im worried that my current skills are not enough for what is needed.

As for nominations, i'd pick MegaDood, ds-sloth, supermario1313, MrDoubleA, & sarn for being the new owners of the repository.
As they are well experienced in managing projects in general, have extensive programming knowledge, & for the last 2 mentioned, have already been X2 devs

Hoeloe wrote: ↑

Sat Apr 12, 2025 12:41 pm

Supermario1313 wrote: ↑

Tue Apr 08, 2025 6:29 pm

[*] OpenCL/Compute shaders for GPU programming

I would be careful of this one - while it would be awesome for a lot of things (like making Particles more performant), it'll also massively increase the minimum required spec to run SMBX2. I'm not saying not to do it, but... it's worth being cautious about!

That's a valid concern, ultimately I think it would be a good idea to consult the community to decide whether adding this feature at the expense of backwards compatibility is worthwhile or not.

Edit 2025-04-14: Something I had in mind (I think we discussed that on Codehaus a while ago) was to use an early version of OpenCL in order to keep the minimum requirements reasonable. OpenGL compute shaders are too recent for that purpose.

A bit late to the party, as I haven't been as active in this community as I would like to due to real life obligations. Nevertheless, I want to say, I would strongly back MegaDood and MrDoubleA as leaders/maintainers: for the former, he has been excellent to work with on the SML NPC pack, showing strong leadership skills, thus I am sure he would be quite capable to steer the ship in the right direction for the project as a whole, too. For MrDoubleA, I think his reputation precedes him, and thus he needs no introduction. I don't have any comments towards anyone else as I'm not as intimately familiar with things as I would like, but for one last note, I would strongly back Emral's suggestion of making the repo open whilst also carefully guarding it from excessive feature bloat. If you want one example that I've seen first hand works well, GZDoom is one such project that is publicly available and easy to contribute to on GitHub, but still heavily guarded by developers in terms of what external contributions actually get in. Recently that allowed an external contributor to appear out of the blue and contribute some much needed debugging code for their ZScript scripting language. I think, generally speaking, this community has a bright future ahead of it still, and speaking as someone who joined back in the early 1.3 days, and I'm looking forward to seeing where things go from here

I nominate ds-sloth and MegaDood.

I nominate ds-sloth

Okay so first of all, I'd like to thank the original X2 dev team. You all did an amazing work on the engine.
SMBX2 is the sole reason I got into programming and I'll forever be grateful to a majority of folks (including people from the original dev team) who helped me almost every time I needed help.

I'm really flattered that some of the members mentioned my name,

I'm willing to help on the lua side of things.
Unfortunately that's the only thing I'm good at and in which I'm able to contribute.

All of the current nominations are already really really proficient at lua so I don't think much help is needed on the lua side but, if needed, I'm interested in helping.

Also I nominate: MegaDood, MrDoubleA, Sarn and ds-sloth.

Howdy!

I went ahead and asked Squishy to unlock this thread again for some important follow-up discussion. Please read through the updated OP for the details!

so like, i do not think i'm much of an authority on this at all. i've never managed a project like. period? so apologies if i'm talking out of my ass

But, i will say to me the idea of joint ownership sounds more stable than a single owner. like rixi said, ifan owner leaves the project, there'd be less complications. big thing to me is that there'd be less onboarding/preparations involved for replacing that owner, since the active owners can pick up where they left off. which also avoids further complications in scenarios where the retiring owner doesn't have time to or lacks interest in onboarding new members. or if they simply vanish from the internet. in addition it could in theory enable a steady stream of new repo owners as people leave and join.

course there's an argument to be made that this could open the door to a scenario where there's too many cooks in the kitchen. but i think if the owners are aware of that risk, and take measures to avoid such a situation (which i trust the current candidates to do) imo it would be a better choice overall

Bump to inform everyone that there’s a vote, go check it out.

If 2-Factor Authentication does not pose a risk I think this is a great idea. It's much more stable and allows for all co-owners to still make their own backups if needed.

I imagine 2FA wouldn't be an issue for organization accounts? Going by the Github docs, it's an account that multiple users can access and manage from their own accounts.

I just checked to see what the equivalent is on Gitlab -- it's the Groups feature -- and proceeded to set up a test Group with its own repo and Proloe as a co-owner accordingly. Here's how it shows up in my repo list alongside the X2 and documentation repos:

I Would love to support Mega Dood, MDA, Ds-sloth and sarn.

As for Mega Dood, i would say taking care and work under two SMBX projects is a HUGE responsabillity. That could also induce some pressure and stress, but renember, take a break! chill time is more better than working on stuff, being burnt out. Would probably nominate and vote for him.

MDA is also another great candidate because, well he works under a dev team i think and with all that programming knowledge it is a pretty solid option for a leader/co-owner.

Ds-sloth and sarn on the other hand, although i dont really know these guys much except for contributing in X2 and archives iirc

also i have a current vote list at the current moment, on vote order:
As for me, i dont think i can contribute that well not unless its something graphics. And even if i had some experience of coding, i dont have access to helpful communication apps (i.e Discord, since im underage at the time and i have to wait 10 months before turning 13.) Happy repo owning!

I definitely agree on having a shared dev account, although I'm not intimately familiar with how GitHub works in this regard. The releases function in GitHub would also take care of the aforementioned "previous releases" topic.

Going forward, it would be maybe desiderable to have a romset requirement (SMW and All Stars or All Stars + SMW) to extract the graphics from during the installation of SMBX2, just to make sure there's no legal hurdles with a public repo, but one thing at a time I suppose.

Dynam0 wrote: ↑

Tue Apr 29, 2025 1:12 pm

Going forward, it would be maybe desiderable to have a romset requirement (SMW and All Stars or All Stars + SMW) to extract the graphics from during the installation of SMBX2, just to make sure there's no legal hurdles with a public repo, but one thing at a time I suppose.

That's a valid concern. Possible solutions would be to keep potentially problematic assets in a separate private repo or to host the SMBX2 repo on a self-hosted Gitlab instance. However, I don't think it's necessary to remove these assets from the SMBX2 releases.

Dropping this before the thread closes: I fully support co-op ownership and backup forks. I imagined that, with allowing multiple nominations and X2 beginning with a core team (even if it wasn't very organized), joint ownership among the top three picks works better than having one repo owner. Especially in case the sole repo owner ever leaves the internet.

My only concern regarding X2's future is if sarn's SMBX5 ever releases, there could be confusion over what's the "main SMBX version." However, I trust sarn and whoever owns the repo to figure out a solution to avoid another X2 versus 38a/Xtech scenario. I have little to add without repeating what everyone else said. I'm excited to see how this new chapter in X2's development will look. Cheers!

Okay, I was ready to call it tonight, but it looks like I got the math wrong and set the poll to end tomorrow instead of today. So while I think it's safe to say that we're going with co-ownership at this point and our picks are all but locked in, still gonna leave that last bit of time for folks to get other last-minute thoughts and votes in.

After the poll closes, though, I'm not going to ask the staff to re-lock this thread after all; I didn't think about it until now, but it would be best if we could just announce the new owners here when it comes time without having to hassle the Peeps with the Proper Permissions again. And there's no reason to prevent further discussion as long as there's a clear cutoff for when it's no longer factoring into the decision, so if I'm not available tomorrow to mark that time myself then y'all can just go by this:

Don't want to sound impatient or anything, but have the new owners of SMBX2 been determined yet? Just curious because the poll ended well over a week ago.