Meet TheXTech: a full working C++ port of SMBX engine

Hello everybody!

Did you see that I have done little work in my public repositories during February and at the start of March? So, I did a lot of work which I am going to present for you all: it's a full C++ port of the original SMBX engine which now works on multiple platforms (tested on Linux, Windows and macOS), and it does accurately represent original gameplay with the rest of features and bugs!

(To get downloads and see details, open a full post)

Feel free to try it out in action now:
There are ready-for-use packages, equipped with original SMBX 1.3 assets and "The Invasion 2" episode.

For Windows (XP/Vista/7/8/8.1/10+):
- 64-bit (modern platforms)
- 32-bit (old platforms and 32-bit operating system installs)

For macOS (10.12 is minimal, if not works even on 10.12, report me please):
- DMG image

Note: because of macOS specifics, using the game here is different than other systems: after installation, run a game,
and then, to add your custom episodes, look into your home directory and find the "TheXTech Episodes" folder, the "worlds" and "battle" inside is for your own stuff!
To replace default media, look inside the bundle and find the "Content/Resources/assets" folder!
Caution: bundle is unsigned, make sure you know how to deal with a Gatekeeper to make able to use this! On Catalina it may not start the first time after Gatekeeper's question, try to run the game again!

For Linux 64-bit (built on Ubuntu 18.04, may work on other systems, may not work if your libc is older than needed):
- Portable tarball

The full C++ source code repository:

If you have any questions, problem reports or suggestions, feel free to write to me!

How I made it?

Since February 2, SMBX's original source code is now open. This fact gave me a lot of helpful material which will help me to make the PGE Engine better and faster! However, dealing with the VB6 environment is not convenient, and at the same time, it's not stable on Linux (because of the graphical engine and the risk of VB6 IDE's crash due to the use of external DLL libraries). So, to get it to work easier, I remembered my very old idea to port the whole SMBX code to C++. So, after a week of initial research, I began working. After a week and a half, I got a fully working (but buggy in some places) thing. Then, I spent time debugging it and making it usable by everyone. It's the full replica of SMBX 1.3 with the rest of its logical bugs (with some exceptions: I did fix a number of crash bugs that were a big annoyance while playing a game). It works on multiple platforms: it works on Windows both 32 and 64 bits, on Linux, and on macOS, (also may work on Haiku and xBSD).

Frequently Asking Questions

This paragraph contains a list of several questions you would to ask me, I'll give answers to most of them.


What is this?

It's a port of an old VB6 engine, purely written in C++. It reproduces an old engine completely (except an Editor), and includes lots of its logical bugs (crashy bugs where they were found and then fixed).


Why did you make it?

Why? I have several purposes for why I made it:

  • It's a very convenient life model for research I want to use in PGE Engine development.
  • To make it work without it being necessary to use Wine on non-Windows platforms and allow it to run on any other than x86 platforms.
  • To be able to optimize it to make it use fewer hardware resources than the original VB6-based build of a game.

You have PGE Engine, why you have spent over one month crafting this thing?

I need it for PGE Engine development directly, it's much easier to hack and inspect rather than dealing with the old and inconvenient VB6 environment.

What's the future of PGE Engine as TheXTech now exist?

I'll continue the development of the PGE Engine as I still have to pass the second goal of the PGE Project. Since its foundation, PGE Project had two goals: 1) save SMBX; 2) give a flexible toolkit for new platform games. Opening SMBX sources and introducing TheXTech has solved the first goal: SMBX has been saved and now it's a free and open source cross-platform software. PGE Engine will be used to pass the second goal - giving a toolkit for new games. Unlike TheXTech, PGE Engine gives full flexibility that allows anyone to build something new from scratch without inheriting an old game base. However, TheXTech is needed for PGE Engine as a working research model to develop a 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 of modders; Chocolate Doom is an accurate port of the original game to a modern platform with the purpose to represent an original game including even bugs. The PGE Engine intends to be like a GZDoom while TheXTech is an analogue of Chocolate Doom to represent an original game on modern platforms.

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.


How to use this?

Here are many ways to play games with it:
- there are some ready-for-use packages, just take and use them as you did it with SMBX.
- [macOS users, skip this]: use by the same way as an original game: put an executable file into the game root folder with a "thextech.ini" that contains the next text:

force-portable = true

, music.ini, sounds.ini and additional "graphics/ui" folder. An important note: all default graphics must be converted into PNG, use the GIFs2PNG tool from PGE Project over your "graphics" folder with a "-d" switch. Don't use the "-r" switch to keep original GIFs together with new-made PNGs if you plan to continue the use of the original VB6-written SMBX.
- use it for debug mode: in your home directory, create the ".PGE_Project/thextech" folder (on macOS the "~/Library/Application Support/PGE Project/thextech") where you should put a full set of game resources and worlds stuff, this folder will work like a game root in the original game. This mode allows you to run an executable file from any folder location of your computer and use the same location of resources for all builds (except these are marked as portable by an INI file).


How to add custom episodes for the macOS version?

If you have a bundled build of TheXTech, all default resources are inside your .app: "Content/Resources/assets/". You can modify the content, but it's not recommended! Instead, after the first run of a game, in your home directory will appear the next directory:

   ~/TheXTech Episodes

In this directory, you will find an empty "battle" and "worlds" folder to put your custom stuff. At the "~/Library/Application Support/PGE Project/thextech" path logs, settings and game saves will be stored.

If you want to replace default assets with your own, you can modify the content of the app bundle or compile a new build by giving the necessary CMake arguments needed to pack your custom assets root and icon into the new bundle or make the assets-less build (if you give no arguments, the assets-less build will result). Therefore, you need to put the full content of the game root into the "~/Library/Application Support/PGE Project/thextech" folder, including default assets (graphics, music, sounds, intro and outro levels, default battle and worlds folders).


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

  • First off, it's written in C++ while the original (as we already know) is written in VB6.
  • Doesn't have an Editor. Instead, in nearest future, it will have deep integration with PGE Editor that will allow to use it with the same functionality as in the 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 (the original game had only 8bit ANSI support).
  • For graphics and controlling, it uses an SDL2 library while the original game used WinAPI calls and a GDI library.
  • It uses PGE-FL which has better file formats support.
  • 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 on-entering 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 the episode and level-wide music.ini and sounds.ini to override default music and sound assets.
  • World maps now support 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.
  • The 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).
  • The 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 (the next gamesave attempt will result in 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 as SMBX-38A does.
  • Checkpoints now have multi-points! You can use them in your levels multiple times without limits!
  • It has the use of a lazy-decompress algorithm to speed up the loading of a game and reduce memory usage.
  • For music and SFX, the MixerX library is used to give support for a wide amount of sound and music formats!
  • It doesn't embed any graphics: there are NO truly 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)


How to build it?

To build it, you need to have next things:

  • CMake
  • Ninja optionally (to speeds-up the build process)
  • Compatible C/C++ compiler (GCC, Clang, and MSVC haven't been tested yet)
  • Git (required to pull submodules and clone source of dependent libraries to build them in place)
  • Mercurial (required to clone an official SDL2 repository to build it in place here)
  • Optionally: system-wide installed dependencies: SDL2, libFreeImageLite (a modded implementation of the FreeImage), MixerX sound library, AudioCodecs collection of libraries. Having them installed in a system gives a major build speed up. However, it's possible to build all these dependencies in place here with the cost of extra build time being added.

Posted 03/14/2020 03:29 by Wohlstand

This page has been requested 3884 times.

Copyright © 2014-2023 By Moondust Team

Legal information and privacy policyAbout us