• Do not use Works in Progress as a way of avoiding the releases system! Works in Progress can be used for sharing early betas and for getting suggestions for improvement. Releases of finished content are not allowed in this forum! If you would like to submit a finished addon, click here for instructions on how to do so.

Zappy's Fabulous Fruitions

Status
Not open for further replies.
fruition, noun, meaning #1: the realization or fulfilment of a plan or project.

Welcome to one of the many threads about stuff people are/have been working on for SRB2.
Despite how many threads like this there are already (which is not a bad thing), I've still decided to post one of my own.

So, first up:
This image comes straight from SRB2, with no image editing involved:
xTeTu07.png
 
Last edited:
Ooh, nice!

(Any reason why MENU NAVIGATION CONTROLS isn't aligned like the rest of 'em?)
 
What? *Looks closely* ...I don't know, but in the P1 control menu, it's aligned correctly, so it must be a side effect of the grayed-out attribute it has when in the P2 control menu?
*Does stuff* Yeah, it was a side effect of using the "grayed out 2" attribute (which was what the other being-hidden stuff around it uses) instead of the "grayed out" attribute.
Fixed, it aligns correctly now. Thanks for noticing and mentioning it. And now off to fix more broken stuff.
 
Now having fixed the customizable menu controls not even working at all (they didn't when I made my previous reply on this thread), I would like to embed a YouTube video of it here followed by the "goOd sHit" meme thingie, but firstly, you can't embed YouTube videos on this forum (at time of writing), and secondly, I'd get an infraction for improper grammar or something like that, so I've put it in the description of the video instead.

So here's a link to the video. It shows me pressing a button on my controller, nothing happeneing, then setting up two of the menu controls onto it and using them, then that you can't bind two menu controls to the same key (despite setting the multiple control thing to "several").
What it does not show, though, is that the can't-bind-multiple-controls-to-same-key-thing doesn't cross over from the menu controls to the other game controls, meaning you can bind jump and confirm to the same key, for example.
It also doesn't show that I added a "setmenucontrol" command (for the same as "setcontrol" and "setcontrol2", just for menu navigation) or that what you set up does carry over if you close SRB2 and reboot it. And of course, it works with the keyboard and mouse as well, not just controllers.
Edit: It also doesn't show that if you bind two long key names to the same menu control, the added hardcoded control name at the start will overlap over the control name on the left, but with most key names, that won't happen, especially the practical ones to use.

I just need to do two more things before it's finished: Make the "open menu" key compare the "multiple controls" to the normal controls rather than the menu controls (you should be able to bind cancel and open menu to the same button, but not jump and open menu), and, unrelatedly, fix the "letting go of Shift while holding other Shift un-Shifts" bug I discovered while making this.
 
Last edited:
���� good shit go౦ԁ sHit�� thats ✔ some good����shit right����th �� ere������ right✔there ✔✔if i do ƽaү so my self �� i say so �� thats what im talking about right there right there (chorus: ʳᶦᵍʰᵗ ᵗʰᵉʳᵉ) mMMMMᎷМ�� ���� ��НO0ОଠOOOOOОଠଠOoooᵒᵒᵒᵒᵒᵒᵒᵒᵒ�� ���� �� �� �� �� �� �� ����Good shit ��������������������

I'd reccomend "increase" and "decrease" be renamed to "next" and "previous". The current terms only make sense for numbers, but the same controls are used for colours, level select, and game mode as well - none of which are supposed to appear numerical to the player.
 
Man, I really hope this gets put in vanilla, because hard coded menu controls was dumb idea.
 
I'd reccomend "increase" and "decrease" be renamed to "next" and "previous". The current terms only make sense for numbers, but the same controls are used for colours, level select, and game mode as well - none of which are supposed to appear numerical to the player.
...Oh yeah, I forgot about that sort of stuff. Oops. I'll be off to rename it now. Thank you again for noticing and mentioning more stuff.

Looking good so far, plus i didn't know you could map a Ps4 controller to srb2
Thank you. And while I believe you can map a DualShock 4 straight to SRB2 (and with better analog stick support than X-Input controllers until 2.1.12's SDL2 stuff), I use something called InputMapper to emulate my DualShock 4 into an X-Input controller, which helps for lots of XBox controller supported games.

Man, I really hope this gets put in vanilla, because hard coded menu controls was dumb idea.
Also thank you. And don't you worry, having it get in vanilla is my goal with this.
 
As much as I dislike posting twice in a row and such (not too much, but a little bit), I'd like some feedback/opinions. Which of the following do you prefer, or would you even prefer something different? I'd like to make the hardcoded menu navigation controls stand out from the user-set controls a bit.
Translucency:

5asaIjb.png



Orangecy:

R0hdofY.png



Translucent orangecy:

WeSHPyD.png
 
Orange translucent in my personal opinion, it looks clearer and generally the best choice
 
I'd actually reccomend white/grey translucent. White/grey is for menu text which doesn't change, translucent is for menu text you can't select, a combination of the two is perfect for hardcoded keys.

The orange is pretty, but I feel like it's trying too hard to be special.
 
I agree on the normal translucency looking the best. I do wonder what happens when you set it to three keys that all have text names, though. That's a lot of characters in not a lot of space.
 
I did consider white or translucent white, but because the controls would overlap on top of the control name if the key names set are too long, I didn't want to do that.
Then as I was explaining why I couldn't use the thin string functions if it got too long, due to the lack of a "," character in the thin font, I realized that since this is an EXE mod, and even intended for vanilla implementation, the "," character can just be added to the font without worrying about it.
Now that it can be white without blending in too much due to overlapping, I've made it white, and yup, I think that looks good too. As for the thin font... Well, it's better than overlapping the control names.

Without width check:

ucL057J.png



With width check:

fvg7OFG.png
...However, coding all this has put my sanity to a test, and I don't think it survived. And then I realized there are even more issues than I thought previously! Ack!
I could go do checks for whether it's short enough for just the hardcoded controls to be thinned down, but for now, this has worn me out. It took me a whole day to code just a "simple" width check. (Or, well, from when I came home to late evening.)
 
Last edited:
What if you made it so that when names get too long, it creates a new line break and continues on?
 
What if you made it so that when names get too long, it creates a new line break and continues on?
Both the non-menu controls and the menu controls menus go through a list of items one by one, and for each of them, it goes down by 8 pixels (by multiplying the current item number by 8). Adding in an extra linebreak everywhere would just cause issues, and only adding it when needed would be somewhat hard, not to mention it would even require a different menu listing code than what most of the rest of the menus use. And it would also look bad when it would be long enough to be wrapped to the linebreak, and also look confusing.

TL;DR: It's harder than and will (probably) look worse than thinning the controls when too long.
 
Last edited:
I've submitted menu controls to be merged for the "public next" version of SRB2 now. However, it won't be fully out to the general public before 2.2 (and even then probably not in 2.2.0), unless there'll be a 2.1.17. And no, I'm not going to release a mod of it, because it requires an extra lump to be added to the game and such (for a thin comma).

But for now, it's done, and works about as flawlessly as you would expect. (Pretty flawlessly, but nothing is 100% perfect... although I haven't found any issues with it in-game, neither for keyboard nor X-Input controllers.)



Edit: Customizable menu controls won't be a thing in 2.1.X (2.1 has been out for too long for such a change to the menu), but when 2.2 comes out, I'll definitely work hard to update it nice and fast and submit it for vanilla inclusion again.
 
Last edited:
Status
Not open for further replies.

Who is viewing this thread (Total: 1, Members: 0, Guests: 1)

Back
Top