## What is different with this thing in comparison to the original VB6 build?
- First off, it's written in C++ while original (as we already know) is written in VB6.
- Doesn't have an Editor. Instead, in has a deep integration with PGE Editor that allows to use it with the same functionality as in original editor (the "magic hand" functionality was kept to allow real-time editing of the level while testing, it's needed to use IPC communication with PGE Editor to get the ability to use it better).
- Full support of UTF-8 in filename paths and internal text data (original game had the only 8bit ANSI support).
- For graphics and controlling, it uses an SDL2 library while original game have used WinAPI calls and GDI library.
- It uses PGE-FL that has better file formats support.
- A support for WLDX world maps are allowing unlimited credits lines and custom music without it being necessary to use a music.ini for music replacements.
- Some LVLX exclusive features now working: vertical section wrap, two-way warps, custom "star needed" message, warp enter event, ability to disable stars printing in HUB episodes for specific doors, ability to disable interscene showing when going to another level through a warp.
- Built-in support for episode and level wide music.ini and sounds.ini to override default music and sounds assets.
- World maps now supports a custom directory to store any specific resources like custom tiles/scenes/paths/levels and not spam the episode root folder with world map resources anymore.
- Default config format is INI, old config.dat format is no longer supported, mainly because of incompatible key code values (SDL_Scancode versus VirtualKeys enum of Windows API).
- Game saves now using the SAVX format instead of a classic SAV. However, if you already have an old gamesave, you still can resume your game by using a new engine now (next gamesave attempt will result a SAVX file, old gamesave in SAV format will be kept untouched).
- Built-in PNG support for custom and default graphics. Masked GIFs are still supported for backward compatibility, however, without making an unexpected auto-conversion like SMBX-38A does.
- Checkpoints now have multi-points! You can use them in your levels multiple times without limits!
- It does use of lazy-decompress algorithm to speed-up the loading of a game and reduce the memory usage.
- For music and SFX, the MixerX library is used to give a support for a wide amount of sound and music formats!
- It doesn't embeds any graphics: there are NO trurely hardcoded graphics, everything is now represented by external graphics!
- Some internal limits have been expanded.
- Built-in GIF recorder by F11 key (F10 on macOS, F11 is reserved by system UI for a "show desktop" action)
Woah. That's so many things. Thank you for your help.
ALSO:
- It works much faster: the loading of game is almost instant and no hang waiting
- It uses much smaller RAM (80~150 MB instead of 600~800 MB like usually), and it's free from memory leaks given by MCI interface used by VB6 SMBX originally.
- it doesn't overloads CPU (the reason was a bad way to process infinte loops, I did the fix of VB6 build too at my "smbx-experiments" branch)
- it able to work on ass-machine (a weak computer) while VB6-SMBX won't work
- it's fully cross-platform and doesn't depends on Windows, and it no longer depends on x86 processor: it can work on ARM and MIPS processors too (VB6-SMBX won't work on ARM at all, with x86 emulator it will 20x times slower than usual)
ALSO:
- It works much faster: the loading of game is almost instant and no hang waiting
- It uses much smaller RAM (80~150 MB instead of 600~800 MB like usually), and it's free from memory leaks given by MCI interface used by VB6 SMBX originally.
- it doesn't overloads CPU (the reason was a bad way to process infinte loops, I did the fix of VB6 build too at my "smbx-experiments" branch)
- it able to work on ass-machine (a weak computer) while VB6-SMBX won't work
- it's fully cross-platform and doesn't depends on Windows, and it no longer depends on x86 processor: it can work on ARM and MIPS processors too (VB6-SMBX won't work on ARM at all, with x86 emulator it will 20x times slower than usual)
Wolstand. Thank you so much,
Wohlstand for taking the time port SMBX to C++. This allows so many things to happen as well as preserving the game and allowing more players to enjoy the game on various platforms.
I love this game, yet I have been a Linux person for sometime and getting it to work on that platform was always painful. Now it can be compiled and ran on basically anything. I was so shocked when I first loaded the game from my Linux box and found it loads very fast and the gameplay is so much smoother than the old VBA code.
I personally would love to see it run on a Raspberry Pi 3 or 4 running RetroPie, but it would need to be complied for ARM for that to happen.
Thanks again for all your hard work.
Last edited by vintagegsmingsystems on Sun Sep 06, 2020 2:32 am, edited 1 time in total.
I personally would love to see it run on a Raspberry Pi 3 or 4 running RetroPie, but it would need to be complied for ARM for that to happen.
The game is already can be compiled to ARM directly, at first, I can test it's work on Android (PGE Engine even is WIP, works on Android already!). About Raspberry Pi, my friend has the Orange Pi thing, a similar to Raspberry, and I am curious to try run the game on it.
P.S. macOS since Catalina 10.15 release, no longer can use Wine with 32-bit applications, however, my ported game will work fine here, because it's native 64-bit macOS build .
I was so shocked when I first loaded the game from my Linux box and found it loads very fast and the gameplay is so much smoother than the old VBA code.
VB6*
That because I had to apply the lazy-decompression algorithm that also helps to use less RAM: 80~150 MB instead of 650+ MB originally (Task manager on Windows usually doesn't showing that, however, on Linux through Wine, I see that directly).
I personally would love to see it run on a Raspberry Pi 3 or 4 running RetroPie, but it would need to be complied for ARM for that to happen.
The game is already can be compiled to ARM directly, at first, I can test it's work on Android (PGE Engine even is WIP, works on Android already!). About Raspberry Pi, my friend has the Orange Pi thing, a similar to Raspberry, and I am curious to try run the game on it.
P.S. macOS since Catalina 10.15 release, no longer can use Wine with 32-bit applications, however, my ported game will work fine here, because it's native 64-bit macOS build .
I was so shocked when I first loaded the game from my Linux box and found it loads very fast and the gameplay is so much smoother than the old VBA code.
VB6*
That because I had to apply the lazy-decompression algorithm that also helps to use less RAM: 80~150 MB instead of 650+ MB originally (Task manager on Windows usually doesn't showing that, however, on Linux through Wine, I see that directly).
I really wonder how you'd want to fit such a wide complex interface on a small phone.
Do you think that 800x600 is too big? Let's look: because this game is usually played with 2x pixelized sprites, then, treat like the actual resolution is 400x300. Do you still think that 400x300 resolution is big? Btw, I think, this would look like a "GameBoy XD HD" (same or aproximal physical screen size, but with a bigger resolution ).
Modern smartphones for now are manufacturing bigger (in the rest of phone shops I see, there are bigger "shovel"-phones, smaller phones now are and cheap slow crap, unfortunately), and they have over 2k pixels resolutions, even cheap Xiaomi phones. However, while I experimented with PGE Engine on a smaller Samsung Galaxy S III phone, the game still being visible and playable, however, I guess, people who have a vision problems, may object.
I think he was talking about the editor, not the engine, although I'd bet you'd only want to port the engine (who would try to create levels on such a small screen?)
I think he was talking about the editor, not the engine, although I'd bet you'd only want to port the engine (who would try to create levels on such a small screen?)
Yes, I talked about engine. What about Editor, here was an experiment in 2016 where I built PGE Editor for Android, and the result was messy. Then I got, that Editor for Android if needed, must have completely different implementation and layout what should be convenient for touch screens.
I think he was talking about the editor, not the engine, although I'd bet you'd only want to port the engine (who would try to create levels on such a small screen?)
Yes, I talked about engine. What about Editor, here was an experiment in 2016 where I built PGE Editor for Android, and the result was messy. Then I got, that Editor for Android if needed, must have completely different implementation and layout what should be convenient for touch screens.
Some small news: I made the first working build of the game that works on Android (but not releated in public yet until I'll implement the touchscreen controller and the setup dialog to configure frame-skip and other global things).
The video where I ran the game on a weak and old Archos 70c Xenon tablet that has 2x 1300 Mhz CPU and 964 MB of RAM, and, it just works!
The only case game will lag, the level has many blocks and moving layers at the same time. This lag will happen on old computers too. I gonna to optimize this mess once upon...
Last edited by Wohlstand on Fri Jan 22, 2021 3:32 pm, edited 2 times in total.
Regarding both Super Mario Bros X and Visual Basic 6, both are for Windows.
I only have an Android device.
A) I found out that there is a Windows emulator called Exagear, but it is limited. Does anyone know if there is a better Windows emulator than Exagear?
B) If I save up and buy a Windows XP, would it be possible to program with it?
