TheXTech

TheXTech

A cross-platform game engine for Mario-like platformer genre games. It's a C++ port and direct continuation of the SMBX engine originally developed by Andrew Spinks with Visual Basic 6 between 2009 and 2011 years. The project was founded by Vitaliy Novichkov (known as "Wohlstand") and first released to the public on 14'th of March, 2020, after the original engine's source code was been released on 2'nd of February, 2020.

Compared to the original Andrew Spink's engine, there are many new features added and several improvements of physics, performance, and stability done. Additionally, this engine maintains the powerful compatibility framework support (including the ability to re-enable old bugs when they needed to fix any broken mechanics) to allow playing of the old content developed for the original implementation with the minimal deviation.

It's a sister project of the Moondust Project developed and maintained in parallel with it.

English	Русский	Español

---

How to build it?

You can read a detailed guide on how to build this project from source for each supported platform here: https://github.com/Wohlstand/TheXTech/wiki/Building-the-game

To build it, you need to have the following things:

• CMake 3.5 and newer.
• Compatible C and C++ compilers toolchain (GCC, Clang, MinGW-w64, MSVC 2015, 2017, 2019, 2022).
• Git (to clone the development repository).
• (Optional) Ninja (to speed-up the build process).
• (Optional) system-wide installed dependencies: SDL2, libFreeImageLite (a modded implementation of the FreeImage), MixerX sound library, AudioCodecs collection of libraries. Having them be installed in a system gives a major build speed up. However, it's possible to build all these dependencies in place here with a cost of extra build time being added.

Localisation

TheXTech engine itself (the Android launcher, in-game menu, Editor's UI, system messages, etc.) can be localised into many languages, you can help to translate project into multiple languages using WebLate platform: https://hosted.weblate.org/projects/thextech/

To translate content such as levels and episodes, please follow this manual: https://github.com/TheXTech/TheXTech/wiki/Translate-episodes

Used software

• GCC, MinGW-w64, and Clang - main compilers used during the development of the game. The MSVC is used sometimes, primarily for Windows builds targeted to ARM64 processors.
• Qt Creator - IDE from the Qt toolkit, mainly used during the development.
• JetBrans CLion - Intelliji Idea based C/C++ IDE, free for the Open Source development.
• PVS-Studio - static code analyser for Enterprise (C, C++, C#, Go, and Java) and Web (JS and TS) development. Is used for periodical checking of the code for possible bugs. It's free for the Open Source development.

Code signing

Free code signing for Windows binaries provided by SignPath.io, certificate by SignPath Foundation.

---

Frequently Asked Questions

In this section I (Vitaliy Novichkov) wrote answers to the most frequently asking questions regarding the project.

What is this?

This is a direct continuation of the SMBX 1.3 engine. Originally it was written in VB6 for Windows, and later, it got ported/rewritten into C++ and became a cross-platform engine. It completely reproduces the old SMBX 1.3 engine (aside from its Editor), includes many of its logical bugs (critical bugs that lead the game to crash or freeze got fixed), and also adds a lot of new updates and features.

Why did you make it?

I have several purposes for making it:

• It's a very convenient research model I want to use in developent of the Moondust Engine.
• To provide a fully-compatible replica of the old engine for modern platforms, allowing to play old levels and episodes with the same feeling as if they were played on the original VB6-based SMBX game.
• To make it work without the necessity to use Wine on non-Windows platforms and making it available on non-x86/x64 platforms.
• Optimizing it to use fewer hardware resources than the original VB6-based game.
• It's a working production ready engine that I and other people can use to develop content before I will implement the first production ready version of the Moondust Engine.
• I really dislike how the mainstream SMBX2 project is built (a hack over the original SMBX engine's x86_32 binary), and I want to have the alternative and standalone engine which is built from the source code and not as a hack over the proprietary blob. Source code based engines are much more controllable and it's much more of possibilities including the native cross-platform support.

You have Moondust Engine, why you have spent over a month to craft this thing?

I need it for Moondust Engine development directly, it's much easier to hack and inspect than an old, inconvenient VB6 environment. And additionally, I want to keep this engine to maintain the compatibility for the old content when Moondust Engine can be developed much easier without the bagage of the Redigit's legacy.

In addition I want to have two separated engines: one that is direct successor of SMBX engine including all its legacy to maintain compatibility on modern platforms combining with new features and improvements; and second as the modern engine made from the scratch that will be compatible by content formats, but it will don't inherit all the physics bugs came from the original engine. Instead, it will have its own🐞️!

What's the future of Moondust Engine now that TheXTech exists?

I'll continue developing the Moondust Engine as I have yet to reach the second goal of the project. Since it's foundation, the Moondust Project had two goals: 1) save SMBX; 2) give a flexible toolkit for new platform games. The opening of SMBX's source-code and introducing TheXTech has solved the first goal: SMBX has been saved and now it's free/opensource cross-platform software. Moondust Engine will be used for the second goal - giving a toolkit for new games. Unlike TheXTech, Moondust Engine gives a high degree of flexibility that allows anyone to build something new from scratch without inheriting an old game base. However, TheXTech is needed for Moondust Engine as a working research model to develop the new engine. It will be similar to GZDoom and Chocolate Doom ports of the Doom game: GZDoom is a powerful and functional engine, the best choice for modders; Chocolate Doom is an accurate port of the original game to a modern platform with the purpose to represent the original game including even bugs. The Moondust Engine intends to be like GZDoom while TheXTech is an analog of Chocolate Doom to represent an original game on modern platforms.

Was any AI used to develop this?

None of AI (such as ChatGPT, Grok, Claude, etc.) was used to develop this project and its dependencies. Even more, the use of AI is prohibited in the scope of this project and its dependencies including for any contributions. See details at the AGENTS.md file.

How to use this?

You can learn all the details at this article: https://github.com/TheXTech/TheXTech/wiki/Running-and-playing-the-game

How to develop own levels and episodes?

The official way recommended to develop levels and episodes for TheXTech is the usage of the Moondust Devkit combined with the "TheXTech SDK" configuration package.

You can learn all the details at this article: https://github.com/TheXTech/TheXTech/wiki/Create-levels-and-episodes-for-TheXTech

What is different with this thing in comparison to the original VB6 build?

This list might be incomplete, so, there are most significant differences are shown:

• First off, it's written in C++ while original (as we already know) is written in VB6.
• Before the version 1.3.6, it had no Editor at all. Since the version 1.3.6, it has an embedded mobile editor that works in a full screen. It can be controlled by keyboard and mouse as well, as by gamepad or by touch screen. In addition, it has a deep integration with Moondust Editor that allows to use game with the same functionality as was possible in the original editor (the "magic hand" functionality was kept to allow real-time editing of a level while testing).
• 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 library 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.
• It has the completely reworked objects search algorithm which resolves the lag problem on slow systems after horizontal move of layers (See description of the DrPepper Problem).
• 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 (More sections, more placed objects, no texture size limits for background objects and world map elements, etc.).
• It has the SoundFX feature that allows enabling of per-section real-time reverbation or echo effects at levels.
• Built-in GIF recorder by F11 key (F10 on macOS, F11 is reserved by system UI for a "show desktop" action)
• It starts faster: the loading of the game is almost instant (depend on a computer and it's HDD/SSD performance).
• It uses less RAM (80...150 MB instead of 600...800 MB like usually), and it's free from memory leaks given by the MCI interface used by VB6 SMBX originally.
• it doesn't overload CPU (the reason was a bad way to process infinite loops, I did the fix of VB6 build too at my "smbx-experiments" branch)
• it able to work on "toaster" (a weak computer) while VB6-SMBX won't work.
• it's fully cross-platform and doesn't depend 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 usualy).

Can levels and episodes with LunaDLL Autocode work on this?

Yes, can. Since the TheXTech version 1.3.6, there is a built-in implementation of the LunaDLL Autocode language, called LunaScript. This system allows the running of LunaDLL-episodes on any hardware including non-x86 processor architectures.

Can LunaLua work on this?

No, LunaLua won't work: this project is binary-incompatible with LunaLua. This also means that SMBX2 content is incompatible. The planned lua-based scripting system won't guarantee compatibility. Therefore, after the possible appearance of the Lua scripts support, it will be reasonable to port, or create new from the ground up and target to TheXTech exclusively.

Why is the code here so bad?

The original author wrote most of the code in the "src" folder in VB6. I did a whole conversion of the code with an effort to accurate reproduction. So, a lot of the code is identical to what was written in VB6 originally. The VB6 platform had a lot of challenges and limitations such as:

• All variables are global and accessible from every module and form by default without any includes or imports. The reason why "globals.h" exists: it has a full list of globally available variables.
• Limited and inconvenient support for classes, therefore the code tends to abuse a ton of global variables and arrays (also an initial lack of experience of the original author was an another factor that lead to this mess).
• All functions in all modules are global and can be called from each module directly. Except calls marked as "private". Therefore I had an additional work to provide inclusions into files where these calls are requested.
• Why so much if-elseif-elseif-elseif-elseif-....? Yes, here probably will be correct to use switch() (in VB6 the Select Case analogue) operator. Another factor that shows the original author had a low amount of experience when he coded this project.
• Why the if() { if {} if { .... } } lasagna? Two reasons: 1) inexperience of original author, 2) workaround to not check all conditions of expression which may cause a crash. In C++ with multiple conditions splitted by && operator, never executing when one of them gets a false result. In VB6, ALL conditions in expression getting be always executed. This difference caused the next situation: in VB6, an expression if A < 5 And Array(A) = 1 Then will cause a crash when A is more than 5. In C++ the same if(A < 5 && Array[A] == 1) expression will never crash because a second check gets be never executed if a first check gave a false result.
• Why so long expressions like if(id == 1 || id == 3 || id == 4 || ... id == N)? Rather making a ton of conditions like this, it's would be better to use classes with a polymorphism and separate the logic of every object between different classes. Also should be solvable with having to use of function pointers (which aren't possible in VB6 without workaronds, but possible in C++). But, again, the original author's inexperience combined with a bunch of VB6 limits caused these constructions.

However, while time goes after the year 2020, a lot of ugly constructions gets refactored and optimised, so this legacy gets gradually away.