Any chance of porting this to consoles that support c++ ? (sorry for bad english)
With homebrew SDKs and the compatible SDL2 build that is really possible.
At least, I see the possibility to run this on PS Vita (once upon I gonna buy some device to try the game work here, at least the PS Vita port was been requested by three persons). At the side, my colleague @ds-sloth works on the 3DS port of the game and there is the working alpha version (you can load it on the hacked console). I thought that it's hard to port the game into the older PSP because it has a too-small size of RAM, however, somebody noticed to me that it has a very good GPU.
What about bigger consoles like PlayStation 3 / 4 / 5, Xbox 360 / One / Series X/S, Nintendo Wii U, Nintendo Switch, that requires the homebrew SDK and the way to debug and test that. Speaking about older consoles I may use some sort of emulator, but newer consoles don't have the emulator yet, and therefore I'll be required to get these consoles and debug the game on them. Otherwise, other folks like ds-sloth would contribute the support for other consoles.
Any chance of porting this to consoles that support c++ ? (sorry for bad english)
With homebrew SDKs and the compatible SDL2 build that is really possible.
At least, I see the possibility to run this on PS Vita (once upon I gonna buy some device to try the game work here, at least the PS Vita port was been requested by three persons). At the side, my colleague @ds-sloth works on the 3DS port of the game and there is the working alpha version (you can load it on the hacked console). I thought that it's hard to port the game into the older PSP because it has a too-small size of RAM, however, somebody noticed to me that it has a very good GPU.
What about bigger consoles like PlayStation 3 / 4 / 5, Xbox 360 / One / Series X/S, Nintendo Wii U, Nintendo Switch, that requires the homebrew SDK and the way to debug and test that. Speaking about older consoles I may use some sort of emulator, but newer consoles don't have the emulator yet, and therefore I'll be required to get these consoles and debug the game on them. Otherwise, other folks like ds-sloth would contribute the support for other consoles.
My friend has a hacked 3ds, maybe he can test this alpha version, and if they make a version for wii u, i could test it
My friend has a hacked 3ds, maybe he can test this alpha version
Nice!
Also, we have a big discussion at my Discord server (Moondust Zone) where we all talking and experimenting with various magical stuff you would find interesting (if you didn't join the server yet, here is the link https://discord.gg/qPBsvMy, be aware anti-bot protection)
But in the case of Minecraft, they used an existing tool in the game, as opposed to running SMBX in notepad++, notepad++ is a standalone program that doesn't contain a game executable or anything like that, unless they create a plugin to be able to run the game, but it would be too much work and maybe not even worth it, so the SMBX version Owata's Big Adventure would probably not be possible
Hi Wohlstand , The X Tech is really great especially with its low requirements , flexibility
And the Android port make it payable anytime anywhere
I have 2 Requests :
1 - Can you add the (Vertical Wall Run from Super Mario World) please ?
2 - When you'll start to add the new and missing NPCs and Blocks from Super Mario series ?
I hope you'll start soon to increase the variety of Episodes with this great engine
I'm very interested in this engine and updating it regularly
Thanks for your efforts
I'm pretty sure TheXTech is supposed to be an enhanced multi-platform port of SMBX 1.3 to C++ and nothing else. Any of the new features are mostly just side things, like a speedrun timer and the SDL Mixer X audio backend.
With the full compatibility to SMBX 1.3, there are new gameplay features still been added, and there is a short list that explains them. The only way to make use of them is to make a new episode using LVLX and WLDX file formats. There are many bug fixes done, but to keep the full compatibility, the special compat.ini file was made to allow episode creators to tune the compatibility for certain levels or for entire episodes if the certain bug(s) were required for the work. With this, there is a command-line argument was added to choose the compatibility level being enforced globally. All these bug fixes were done to make the casual gameplay being more comfortable and less annoying, however, as these bugs in several cases were required for compatibility, the ability to switch them back was kept by a compat.ini per episode and per-level files.
2 - When you'll start to add the new and missing NPCs and Blocks from Super Mario series ?
I don't know yet, right now I keep all content being SMBX64-only, and I don't add new elements yet, mainly because I don't want to make one another incompatible standards (right now there are two incompatible resources standards exist: SMBX-38A and SMBX2). The SMBX64 is the only standard that allows making an episode that will be compatible with all SMBX branches.
So, then there are next ways on how to allow that, probably later I'll make the poll (I'll keep it without of deadline until the specific moment will happen) for this to let people choose the best option:
The probable question: "Which way I should follow to add new in-game elements out of SMBX64 standard?"
Replicate the SMBX2 standard (all new-added items must have the same ID as SMBX2 has)
Replicate the SMBX-38A standard (all new-added items must have the same ID as SMBX-38A has)
Build own standard of non-SMBX64 itemset (all new-added items will be added without looking at others)
Anyway, this set will be fully optional and will directly depend on the assets packs (mainly because I do keep the policy to keep the backward compatibility with older assets packs to allow quick updates with no pain).
EDIT:
And so, and that depends on which goal of episode maker is:
- Make the episode that can be played on all engines? Do it with following the SMBX64 standard.
- Just make the good episode using a specific engine fully? Yes, that will limit episode and its levels being closed on a specific engine and its standard and will be hard to port each level between engines (which is already a pain between SMBX2 and SMBX-38A). But this will allow the use of the complete functionality of the engine. There are several good examples that taking advantage of each engine making the technological and powerful levels and episodes.
So, the reason for this problem comes up directly from the case SMBX-38A and SMBX2 independent and incompatible standards. And so, the Moondust Engine's goal is still being the universal thing that allows you to have multiple independent and incompatible item sets and different gameplay/logic, but still using the same engine for all of them.
Actually the TheXTech is Very Important because a big problem with SMBX2 which requires (VC 2015)
And (VC 2015) needs a Windows Update
And where I live in a country thats impossible to find a Licensed Windows to upate it
Even if I did it will be a long Process to run a 2D Mario game
Thats made TheXTech the only solution to get a growable SMBX game
I have an openion about the New Elements and I think it's the best
First of all , Continue where 1.3 stopped but please Avoid those Two Big Problems
1 - 38A is Very bad as a SMBX continuation due its issues with shadow png's and 1.3 .lvl compatibility
So leave it completely
2 - SMBX2 needs (VC 2015) and (LunaLua) compatibility and it's impossible for me to get a Windows
Update for it
I think there's a lot of People share this problem with me
So The Best solution is to keep TheXTech (Simplicity & Low Requirements) features
So remaining this one choice Only
(Build own standard of non-SMBX64)
Make it compatible with (1.3) Levels even if you added (All SMBX2 Elements) due its huge variety
But please keep (VC 2015 and Lunalua) Out Completely , please never implement them
This is my opinion and situation
And Thank you Wohlstand for sharing Our thoughts
And I Wish for you to success in this great project
Last edited by horseoftroy on Thu Jun 10, 2021 10:47 am, edited 2 times in total.
Actually the TheXTech is Very Important because a big problem with SMBX2 which requires (VC 2015)
You may don't worry about VC runtimes at all, for Windows versions of TheXTech I do use the MinGW toolkit that ships its own runtime DLLs that make the built application being fully portable without additional runtimes being installed. This also allows the game to work on Windows XP and keep the support of modern C++ standards (using newer MSVC will obviously break the support of older Windows versions as it links DLLs that incompatible with XP by theme selves. Using older MSVC is sucks because they badly supported any modern C++ standards that MinGW, GCC, and Clang had supported much better). The only exception is the ARM64 Windows version that doesn't have any alternatives to build the game for ARM64, therefore MSVC 2019 is being used here, for x86 and x86_64 the MinGW-w64 toolkit is being used.
1 - 38A is Very bad as a SMBX continuation due its issues with shadow png's and 1.3 .lvl compatibility
So leave it completely
That how the 38A engine itself works against the graphical processing, which I don't need to repeat at all, I had spoken about itemsets mainly, I.e. which NPC is exists in 38A or at SMBX2 and which IDs they have, and how they behave on every engine.
2 - SMBX2 needs (VC 2015) and (LunaLua) compatibility and it's impossible for me to get a Windows
Update for it
I think there's a lot of People share this problem with me
Also, this is a big problem of any software built with the MSVC, in most they do require the VC runtime being installed and being up to date, which adds an extra pain.
Make it compatible with (1.3) Levels even if you added (All SMBX2 Elements) due its huge variety
As good news, TheXTech already has using algorithms that intended to save the RAM usage and speed up the loading of the game, mainly the lazy-decompression system (don't load texture until it got requested the first time). As a disadvantage of this method, it may add some lags on weak GPUs like the MALI400 (in a moment of texture loading I mean).
But please keep (VC 2015 and Lunalua) Out Completely
While I do have some plans to implement the compatibility with pre-SMBX2 episodes by adding the memory emulator, I don't plan to attach the LunaLua, which is absolutely impossible (mainly because it's a whole mess targetted to hack one single EXE file that was built at 2010'th year).
Instead, the absolutely new solution will be built from the scratch (with inspecting of the LunaLua side to give the compatible end-user API, but majorly different internality that will work cross-platform). No VC runtimes will be required as the code will be done in a platform-independent way, so, it will be able to work on Linux, macOS, Android, etc. also.
So remaining this one route Only
(Build own standard of non-SMBX64)
I had thought the same, but knowing the fact the pain against incompatible item sets between SMBX2 and SMBX-38A, the result should avoid people to confuse among different engines and itemsets. Mainly, episode and single-level creators will be REQUIRED to specify for which engine they target their levels and episodes being published (I guess, that should be already even now, as the fact SMBX2 and SMBX-38A engines already). Mainly to tell users which engine they should use to play certain episodes. Mainly because there is pain among people who get confused when attempting to run alien levels and episodes on incompatible engines.
I have noticed 2 Mechanics in 38A , doesn't available in v1.3 and SMBX2
1 - Wall Bounce Jump :
This mechanism makes the gameplay fast and exciting
It will be great if added to TheXTech
But it is a (Modern Play Style)
This lacks the risk of climbing a Vain or jumping on platforms while the NPCs like Goombas and Koopas walking and flying around you
Their is 2 Ways to implement it without interrupt the Old Play Style gameplay
You Can do both of them
A - You can add it but lock it as a parameter inside characters (.txt)
For Example in Mario.txt :
WallBounceJumping = 0
Wall Bounce Jump Disabled by default
For (Old Style Gameplay)
WallBounceJumping = 1
Wall Bounce Jump Activated
For the (Modern Fast Gameplay)
And so on For all characters
In This Way the Wall Bounce Jump will be Global for (All The episode)
B - (Level Name).txt :
WallBounceJumping = 0
OR
WallBounceJumping = 1
In This Way the Episode can have both styles some levels with Wall Bounce Jump , and some levels Without Wall Bounce Jump , Will be important for Level Contests
In this way TheXTech will have the both play styles available for the level maker with both old style and new style gameplays , Without interruption of both of them
What do you think ?
2 - Collecting 3 Stars :
Those collectable 3 Stars in the upper left corner of the screen of 38A
(No Need to add this to the screen of TheXTech)
Those looks like the 5 Dragon Coins in the SMBX v1.3 and SMBX2
I Suggest them to be added to the PGE level editor only as a counterpart to the 5 Dragon Coins
In a past, PGE Editor had experimental Android builds, however, the result was too clunky and hard for use (better to code a different thing rather than trying to reuse desktop version on a mobile device), and I no longer support it.
I've tried PGE and it somehow works for me. But I wonder if there are more controller keys available?
I've tried PGE and it somehow works for me. But I wonder if there are more controller keys available?
Right now there aren't more control keys yet, I'll add once they will be.
P.S. You can already see that TheXTech since 1.3.5 has the full Android support, and so, if you want to just play the game, I highly recommend you to use it and use the Moondust Engine for testing and playing levels and episodes targeted to be played on it. Once upon I'll take the major rework of the entire Moondust Project, and they're all improvements will be made here.
P.P.S. You may interest to see the full source code, right? It's here, and the Java file is only a small part of the wrapper, the whole engine is C++-coded.
Wohlstand, you create an Android version, can you create an Ios version?
Technically that is possible, BUT:
Thing will require the Jailbreak, because this game literally won't fit into AppStore politics
To publish anything at AppStore, need the very expensive payment for the developer ID account
Will need to implement the sort of "episodes catalogue" to simplify the deal with the damn of iOS' file system, otherwise play default only stuff packed with the game package
I don't own enough hardware to test, if I verify the work on simulator, the hardware will be needed to confirm it will work They cost expensive as the used car, I better buy the Nintendo Switch and run the game on it
At least, I can build the binary that people can try use with Jailbroken devices
Probably, it's possible to use the game without the jailbreak if you will follow the RetroArch's instruction
Hi! I have a modded o3DS and I'd like to try to play SMBX on it. Where can I download a 3DS build? Or if there isn't one, then how do I build it myself (pls explain in a way that I can understand, as I'm noobish in programming and stuff)?