Streets of Rage X

In Progress Streets of Rage X Beta 36

No permission to download
The project is currently under development.
I have a question. Will the CPU partners operate based on the preset setting?
In other words, if, for example, the SOR 1 preset is enabled, it should behave accordingly.

Because right now, no matter which preset is selected,
it tries to behave as if the same SOR X preset were enabled.
 
I have a question. Will the CPU partners operate based on the preset setting?
In other words, if, for example, the SOR 1 preset is enabled, it should behave accordingly.

Because right now, no matter which preset is selected,
it tries to behave as if the same SOR X preset were enabled.
Friend, I need more details about the behaviour you are mentioning.

In short, most of the game settings options are shared between playable characters and cpu partners, so it will be applied automatically. Like, if you change the special moves to "sor3 ok bar", automatically it will be enabled for the cpu partners too.

However, other things that are in the "controls" section are exclusive for players, because this option changes the controller interaction and not native behaviours.
 
Would it be possible to provide an ARM64 build compiled with SDL2 video output only (KMS/DRM), without the X11 dependency? This would make SoRX playable on the whole family of H700/RK3566 handhelds (RG35XX/40XX series, R36S, Powkiddy, TrimUI...), which is a huge and growing user base for beat 'em ups.
@Madus I found a way to compile the arm build with a hybrid mode, having both the SDL2 (KMS/DRM) and X11. At least the tests using the TTY mode (without graphics) in a RPi3 went well, but I'm waiting for my Anbernic RG35XX H to arrive, then I can do a complete test and homologate it for the SORX.

I believe it's because your AppImage requires libfuse.so.2, which is deprecated on modern Linux distros. I believe there is a workaround, but I thought I'd post because I wasn't sure if you were aware of this issue. I believe if you rebuild the AppImage using the newer AppImage runtime, this will allow it to run on systems that ship with fuse3.
@Arkwelder For the next version, I'm testing a way to play the game without the appimage, just using the pure binary and a .sh to run the engine pointing the dependencies to an external libs folder.
If the tests go well, we will not have fuse conflicts anymore.

Thank you. I don't think so but I'll ask.
His main concern visually was with things that flash because he has light sensitivity.
@Blit-X- TV [LIVE] Buddy, I was thinking about the SOR3 stage 2b (the dance club). Did your friend say something about this level?
I'm asking because there's a lot of blink effects there.
 
@Madus I found a way to compile the arm build with a hybrid mode, having both the SDL2 (KMS/DRM) and X11. At least the tests using the TTY mode (without graphics) in a RPi3 went well, but I'm waiting for my Anbernic RG35XX H to arrive, then I can do a complete test and homologate it for the SORX.


That's great man, many thanks.
 
I had a thought - do you think Break should be able to throw heavy/fat enemies over his head? Considering he's a robot, it would make sense for him to have that ability, unlike Axel who can't.
 
Currently I'm rushing to finish the beta state and during the process I ended adding all the remaining cpu partners, as well as a random selection too.

Plus I also added at least knife/pipe weapon models for the cpu heroes. I didn't add all weapons because usually players manage them better than the cpu partners, and both knife/pipe are the most common in all the 3 routes.

In addition, I moved the cheat menu to the game settings. This way now it's possible to enable/disable them in an easier way, plus the changes now are saved and don't need to be enabled every time the game is booted.

I will launch the next beta 36 in a few days.



I had a thought - do you think Break should be able to throw heavy/fat enemies over his head? Considering he's a robot, it would make sense for him to have that ability, unlike Axel who can't.
Friend, I understand your point, but the weight system is connected to the power level and since Break is based on all Axel attributes, he also carries the same power level which doesn't allow to throw/slam Big-Ben, at least in the SOR3 route.
 
Friends, I didn't have too much free time lately, but at least finally I was able to make the SORX work on a Anbernic RG35XX-H using muOS.
I still need to test in a modified Stock OS because it didn't work on the original. After that, then I will proceed to Knulli, but for now I will stay with the muOS.

The only thing I didn't like too much is the screen proportion, I had to stretch it vertically in the video options. But since it's only for tests and considering that the game will work fine in other widescreen devices, it's enough for now.

I was only waiting for the device to arrive to finish all the last tests, and then launch the beta 36.
PS: Also tested using a PS4 controller via bluetooth and the new controller code works fine.


1789937998385.jpeg
1789937964327.jpeg

However, at least for now the 32-bit arm will be dropped due to some reasons:

- in order to keep advancing par with the new 64-bit engine;
- the linux community is dropping the 32-bit support in general;
- due to some performance issues;
- basically all the modern devices supports 64-bit;

Sorx Is now playable on switch!
Check the openbor thread on gbatemp
@gungrave80 Cool! I saw that they are having issues with the engine version. I suggest waiting a little at least until some experimental updates are finished, otherwise they can have a lot of problems.
 
Friends, I didn't have too much free time lately, but at least finally I was able to make the SORX work on a Anbernic RG35XX-H using muOS.
I still need to test in a modified Stock OS because it didn't work on the original. After that, then I will proceed to Knulli, but for now I will stay with the muOS.

The only thing I didn't like too much is the screen proportion, I had to stretch it vertically in the video options. But since it's only for tests and considering that the game will work fine in other widescreen devices, it's enough for now.

I was only waiting for the device to arrive to finish all the last tests, and then launch the beta 36.
PS: Also tested using a PS4 controller via bluetooth and the new controller code works fine.


View attachment 16049
View attachment 16048

However, at least for now the 32-bit arm will be dropped due to some reasons:

- in order to keep advancing par with the new 64-bit engine;
- the linux community is dropping the 32-bit support in general;
- due to some performance issues;
- basically all the modern devices supports 64-bit;


@gungrave80 Cool! I saw that they are having issues with the engine version. I suggest waiting a little at least until some experimental updates are finished, otherwise they can have a lot of problems.
Wonderful, muos porting!!!
Is it possible to have black bars (like the PSP game) in order to preserve the screen proportion?

Regarding the switch port, I will send a message to Syphia (switch port developer).
 
Sorx Is now playable on switch!
Check the openbor thread on gbatemp
I took a look at the topic.
And—no offense intended—but there is some incorrect information there. The big problem with these ports is that they can give a misleading impression of the engine.

What really caught my attention was this:
"The issues affecting load times are likely bugs or design flaws in the original engine; however, they are not particularly noticeable on modern PCs"

That is nowhere near the truth. It doesn't happen in the Windows, Linux, or Android versions—which are the official ones. It only happens in this unofficial port.

That is one of the reasons why I believe @DCurrent isn't very fond of ports.
 
I took a look at the topic.
And—no offense intended—but there is some incorrect information there. The big problem with these ports is that they can give a misleading impression of the engine.

What really caught my attention was this:


That is nowhere near the truth. It doesn't happen in the Windows, Linux, or Android versions—which are the official ones. It only happens in this unofficial port.

That is one of the reasons why I believe @DCurrent isn't very fond of ports.
The developer is speaking about the loading times (and I saw them also on retroid pocket 5), but is not really a issue. For example, I noticed that loading times are faster in switch than on an Android mangmi air x.
Ports must be welcomed, they increase the possibility that this masterpiece, sorx, is played wider and wider
 
Ports must be welcomed, they increase the possibility that this masterpiece, sorx, is played wider and wider

That is entirely subjective friend. We do not have to welcome anything, we choose to, and ports have often as not proved far more trouble than they are worth. It is up to @Kratus to decide if he wishes to support a platform.

DC
 
The developer is speaking about the loading times (and I saw them also on retroid pocket 5)
Weird, I have a 2022 phone which runs Android 13, the same of Retroid Pocket, and I can run SORX without any issue or huge loading time.

Ports must be welcomed,
I’m not a native English speaker, but I think the right word here would be "could," not "must." When you use "must," it makes it sound like the game developer is obligated to do something, when they aren't—and neither are the engine developers.

I understand your excitement—I enjoyed seeing my Avengers project running on the Switch and 3DS myself. But that’s what I tell everyone who tests the game on other platforms: it’s not my intention to support unofficial ports; I have no way to test them.
And the problem with people claiming that the developer of a free game *must* do something is that it ends up being demotivating for them.

I was planning to post in that thread to clear up a few things, but something tells me it’s better not to.
 
Back
Top Bottom