MonoSMBX (far future)

General discussion about Super Mario Bros. X.
darkhog
Dolphin
Dolphin
Posts: 87
Joined: Sat Dec 10, 2016 11:17 pm

MonoSMBX (far future)

Postby darkhog » Thu Dec 15, 2016 8:18 pm

While I don't have time for it right now (doing my own SMBX world and also working on my indie 3d platformer as my main project) in future I'd like to do completely open-source replacement for SMBX engine, because it being a VB6 one poses few very severe restrictions on amount of stuff possible in a level or a world that cannot be easily overcome.

To do that, I've chosen MonoGame since it's multiplatform which would make it possible to release it on multiple platforms, such as all main operating systems (Windoze, Linux, MacO$X) and possibly even on smartphones (even if Google/Apple won't allow it for some reason, we could still build apk for sideloading and ipk for jailbroken devices) and also because C# is pretty cool and easy.

So why to write about it now even though it's way out? Well, to do that I'd need few things.

- Level format specification and other custom binary format
- LunaLua modules so I can integrate it with the new engine by default
- If Redigit didn't took it away when he left to make Terraria, access to current engine's source code so I can implement stuff using same algorithms, while increasing maintainability and removing bugs/limits of the current engine.

All of the above is needed to maintain backwards compatibility with current worlds. Obviously worlds that relied on exploiting bugs/glitches in the current engine wouldn't be preserved, but rest would need to work.

Another reason is maybe I'll inspire someone to start it already instead and then I could contribute when I'll have time to do so.

What I want to do with it:

- Add higher capacity for customization such as defining block info that gives possibility to set collision type (one-way or not and if one way, which side needed to collide) in similar way you can customize NPCs now
- Better, saner spritesheet format (legacy one will be preserved for compatibility reasons) where GIF transparency/png alpha channel would be used (the latter may already be used by luna lua, but not sure about that as I haven't used pngs in my level yet) while masks would be used for collisions.
- Ability to override title sequence with the custom one if the "customized" world is the ONLY world in the worlds folder which would allow for easy making of "customized" versions of SMBX containing one specific world. Kinda like you can replace title and menus in Doom WADs.
- With the above, no hardcoded graphics whatsoever, every single one would be able to be replaced with caveat that some replacements won't work if there's more than single world in the worlds folder.
- Ability to define custom events commands with Lua so if a programmer works with a designer who isn't particularly good with programming, he could make easy snippets to use within levels. *
- Overhaul of the event system so it would be similar to one used in RPG Maker and thus both easy and powerful. *
- New editor that is similar in usage to Mario Maker while being more powerful.
- Ability to stack enemies/enemies capable of taking modifiers/powerups. *
- Less bugs/exploits and no limits in terms of levels/worlds/tiles
- Better episode selection. Every episode would be able to have custom thumbnail/boxart. The menu would work similar to the one on the NES Mini.
- Ability to launch editor directly from the main menu (and possibly built-in one when new editor would be developed).

* May require new, extended level format - before that full compatibility with existing one is needed and existing one will be kept even after extended one is developed for backwards compatibility.

Someone may say "why not PGE then - we already are using the editor, may as well use the engine"? Good and perfectly valid question. The problem with the engine side of PGE is that it is being developed as general purpose platform engine, which is both a blessing and a curse since SMBX-specific stuff allows for making assumptions about how things would be progressing thorough the level instead of having to account for every single possible outcome in a platform game.

Another problem with PGE is that it is being developed in C++ which has very slow iteration rate and it's easy to introduce a tragic bug such as crashing while there is unsaved progress or invalidating a save file due to a forgetting to close a file.

C# on the other hand is easy and fast to develop for and most common "serious" bugs, such as buffer overflow or segfaults are very hard to produce there, unless you are actively trying to introduce those. Another thing is that you get access to the powerful .NET library which simplifies many things including networking (always PITA) and even handling zip archives (zipped worlds anyone instead of having to unzip those?).

So will you help me? I certainly I can't do it alone, even if I have all the time in the world and without these three things I've mentioned at the beginning it would be even hard for me to actually start (the best place to start with a project like this is to make simple world/level viewer and then slowly add features such as animation, sound/music and finally gameplay and menus).
Last edited by darkhog on Sat Dec 17, 2016 10:09 am, edited 1 time in total.

PixelPest
Raccoon Mario
Raccoon Mario
Posts: 7111
Joined: Sun Jul 12, 2015 5:38 pm
Flair: Tamer of Boom Booms
Contact:

Re: MonoSMBX (far future)

Postby PixelPest » Thu Dec 15, 2016 8:57 pm

This sounds like a ridiculous task tbh. A lot of the stuff you've mentioned is doable within LunaLua (via an API or the LunaLua source). Also, the source code for the SMBX engine is not available

Shadow Yoshi
Dark Knight
Dark Knight
Posts: 4291
Joined: Sun Dec 01, 2013 12:56 pm

Re: MonoSMBX (far future)

Postby Shadow Yoshi » Thu Dec 15, 2016 10:00 pm

SMBX file format specs: http://wohlsoft.ru/pgewiki/SMBX64#File_formats
LunaLua: https://github.com/WohlSoft/LunaLUA

We don't have the source code for SMBX at this time. It's cool that you want to do this but I would refrain from having a thread until there's enough progress made to warrant one.

bossedit8
Banned
Posts: 6838
Joined: Fri Dec 20, 2013 12:35 pm
Contact:

Re: MonoSMBX (far future)

Postby bossedit8 » Thu Dec 15, 2016 10:08 pm

PixelPest wrote:Also, the source code for the SMBX engine is not available
There was actually a source code for SMBX available back then but now it most likely doesn't exist anymore as a regular download... also the source code is a mess anyway as in you can't really do anything with it so yeah.

Shadow Yoshi
Dark Knight
Dark Knight
Posts: 4291
Joined: Sun Dec 01, 2013 12:56 pm

Re: MonoSMBX (far future)

Postby Shadow Yoshi » Thu Dec 15, 2016 10:41 pm

bossedit8 wrote:There was actually a source code for SMBX available back then
No, the SMBX source code was never made available. All that existed was a decompiled executable, which is not the source code.

darkhog
Dolphin
Dolphin
Posts: 87
Joined: Sat Dec 10, 2016 11:17 pm

Re: MonoSMBX (far future)

Postby darkhog » Thu Dec 15, 2016 10:50 pm

I see. Though even seeing decompiled version would be helpful as algorithms used would be clearer. And I don't plan on actually developing current engine further - I'm not crazy. Instead I want to make new one from scratch that is easier to maintain and open source while maintaining backwards compatibility. For that I'd need source of some kind (either decompiled or real one) so that I can get as close to algorithms used for gameplay as possible, while fixing (or rather avoiding in the new source) existing glitches and other bugs). Also knowing level format and other custom binary formats used by SMBX would be helpful.

But yeah, that's for the future, possibly few years unless someone feels inspired and wants to start this already. Not that I'm incapable of doing it, it's just that Real Life(TM) is getting in the way and I barely have time to do both my indie game and SMBX world.

Wohlstand
Van De Graf
Van De Graf
Posts: 2005
Joined: Tue Feb 11, 2014 4:44 pm
Flair: [ˈvoːlˌʃtant], 狐エンジニア
Pronouns: he/him
Contact:

Re: MonoSMBX (far future)

Postby Wohlstand » Fri Dec 16, 2016 3:32 am

darkhog wrote: Someone may say "why not PGE then - we already are using the editor, may as well use the engine"? Good and perfectly valid question. The problem with the engine side of PGE is that it is being developed as general purpose platform engine, which is both a blessing and a curse since SMBX-specific stuff allows for making assumptions about how things would be progressing through the level instead of having to account for every single possible outcome in a platform game.
You forgot about config packs system. Every config pack may have everything specific to some game: together with media, also in-editor plugins (WIP feature yet), and editor and engine would have almost any things or extra coded commands. So, config pack can produce almost 1:1 SMBX-like game with few differences. The reason why I wasn't started it as an SMBX-only engine, because I don't want repeat Redigit's mistake which caused a hard death of original project (soft death I mean abounding). If any bullshit will happen again, I just have to remove Nintendo's content, but the engine will be live by its own life. The compatibility kept while config pack is following the SMBX-64 standard I researched to provide the stuff of SMBX's internals. Every config pack declares the itemset and game logic of the specific game.
darkhog wrote: Another problem with PGE is that it is being developed in C++ which has very slow iteration rate and it's easy to introduce a tragic bug such as crashing while there is unsaved progress or invalidating a save file due to a forgetting to close a file.

C#, on the other hand, is easy and fast to develop for and most common "serious" bugs, such as buffer overflow or segfaults are very hard to produce there unless you are actively trying to introduce those. Another thing is that you get access to the powerful dotNET library which simplifies many things including networking (always PITA) and even handling zip archives (zipped worlds anyone instead of having to unzip those?).
The main reason of slow development - is a lack of my free time, because I'm employed and has limited free time:
- by luck, I have some free time while I'm at my job while I have no tasks
- while I'm at home, at evening or days off
- most of the free time I have at vacations

The also reason of slow work not because C++, because reverse engining of legacy SMBX Engine. The goal of PGE Engine to keep full compatibility with legacy SMBX engine and allow it be the drop-in replacement (to play a lot of old episodes with it same as with SMBX). If I would just create a playable game with no matter compatibility, it would be a very fast development (the in mind is the ready-to-use Box2D physical engine to have a real world like physics with various physical factors, joints, frictions, etc. I used it in early builds of PGE Engine, but Box2D sucks in case it doesn't allow me to repeat physics of old engine. So, since version 0.1-alpha PGE Engine has own physical engine coded from scratch. Try yourself, no matter language, logic is very hard and possible you will hate everybody in world until you will take working physics with avoiding any dumb things (also check closed issues for "which troubles are was").). Look at 38A engine which developed quickly, but it still to lack some compatibility. We (me, Kevsoft, Rednaxela and some other people) are doing deep reverse engining with using various disassemblers and custom unit tests to trace AI states of NPCs to have implement their logic accurate. We are not just codding engine, we are also doing a huge side work, so, keep that in mind.

If you mean pure STL C++, you totally forgot about lots of libraries and frameworks like SDL and Qt which are providing a lot of things and speed-up of development in total:
- SDL provides everything for gaming: graphics, controllers, joysticks, audio (and even haptic devices support!), and everything is cross-platform here!
- Qt is a powerful framework for GUI applications, it provides lots of features on it's API side, very similar to the dotNET and even lot more things. With QML you able to quickly design good apps for touchscreens (phones, tablets, terminals, etc.). The different from dotNET is pure native code in resulted binary while dotNET is trying to repeat Java, but because M$ failed to be cross-platform until Mono was made.

Agree that C and C++ are requiring extra knowledge and experience to start using it, but it's alone language allows you create native apps, drivers, and even operating system kernels! (it's better and nothing (I mean ASM)). Most of produced commercial (and not) games are coded in the C++ and a lot of games which are much more powerful than everything here we are here know. Yea, that also games using C# (Terraria), Java (Minecraft), pure Lua (Mari0), etc. The backends of Unity and XNA are coded in C/C++ theme selves and there are providing best performance (even a high level code is coded in C#/Java/Lua/etc). PGE Engine has much more backend side, but allows to program game logic and AIs in lua, which allows not only creating games by separate config packs, even allows making a pure custom NPC (with unique AI stored in the level custom folder)!

At the same time, C++ allows make programs which are will not lag on slow computers (if you coded logic well) (while similar program in C# or Java would lag a lot on same slow machine). PGE Engine itself has low system requirements, able to work on slow machines without lagging them. Even using software render it doesn't oveloads single-core CPU Pentium IV with 2.4 GHZ (at same time video card is ATI Radeom 9200 with very few video memory and GPU which can't have non-power-of-two textures). SMBX Engine (no matter LunaLua or pure Vanilla) at same time lags everything, even on powerful machine.

P.S. Fun fact: Many years ago someone tried to make SMBX Remake, but gone far far away and nothing happen, and no one even dummy enigines around: http://talkhaus.raocow.com/viewtopic.php?f=11&t=2397
Name of his attempt is "Radish Engine". Began in 2010'th year, last post in 2012'th. Then I wondered when author of Radish Engine in july 2015 for cooperating, even I confirmed cooperation, he is gone for a while, again.

(I myself began early works in end of 2013 and completely started PGE in 2014'th and still work. In 2015 I spent lot of time on my final project for diploma which I passed and got my diploma of engineer and after looking for job I have it now. C++ not only my hobby, also my job where I working on software for a medical hardware)

timocomsmbx2345
Nipper
Nipper
Posts: 848
Joined: Sat Feb 06, 2016 1:44 pm
Contact:

Re: MonoSMBX (far future)

Postby timocomsmbx2345 » Fri Dec 16, 2016 7:55 pm

what will it look like?
i thought you were helping out with the full release of SMBX by adding all the 1.4.x. features into the PGE

Kevsoft
Flurry
Flurry
Posts: 374
Joined: Sun Jul 27, 2014 8:03 am

Re: MonoSMBX (far future)

Postby Kevsoft » Sat Dec 17, 2016 8:31 am

darkhog wrote: C# on the other hand is easy and fast to develop for and most common "serious" bugs, such as buffer overflow or segfaults are very hard to produce there, unless you are actively trying to introduce those. Another thing is that you get access to the powerful .NET library which simplifies many things including networking (always PITA) and even handling zip archives (zipped worlds anyone instead of having to unzip those?).
Although you're right, that buffer overflow or segfaults ("hard crashes") are nearly impossible, you still can get soft crashes (NullPointerException, BufferOverflowException, ...) if you're code is poorly written. Making a game in C# is possible, but you shouldn't forget that you still lose some performance (even though it is jit-ted). I wouldn't put my hands on Mono, given that I heard some frustration with the Mono from the community (You may prove me wrong). I will look what Microsoft has to give with .Net-Core (Their Cross-Platform C#-Implementation).

darkhog
Dolphin
Dolphin
Posts: 87
Joined: Sat Dec 10, 2016 11:17 pm

Re: MonoSMBX (far future)

Postby darkhog » Sat Dec 17, 2016 9:25 am

Kevsoft wrote:Although you're right, that buffer overflow or segfaults ("hard crashes") are nearly impossible, you still can get soft crashes (NullPointerException, BufferOverflowException, ...) if you're code is poorly written. Making a game in C# is possible, but you shouldn't forget that you still lose some performance (even though it is jit-ted). I wouldn't put my hands on Mono, given that I heard some frustration with the Mono from the community (You may prove me wrong). I will look what Microsoft has to give with .Net-Core (Their Cross-Platform C#-Implementation).
I think this is the key takeaway:
if you're code is poorly written.
My code is not poorly written. If it was, I wouldn't even attempt thinking about doing it. And in few years when I actually have the time to do this, quality of my code will be even better because of all the experience I'll have by then. And I wouldn't lose my hair over performance especially in a 2D game such as SMBX (and remember, current engine is rendered in software while MonoGame uses hardware acceleration) unless it becomes a real issue. Most complaining about Mono was about licensing and performance of older, deprecated versions of the Mono runtime, both of which are fixed now.

And NPE/BO are easily fixable even if you get them, though bit annoying. In first case you have to check if variable in question is not null and if it is null instead of doing stuff either fail silently if it is of no consequence, try to reassign the variable with expected value or if it's really serious show a message. Second case is similar, but you check here for boundaries.

Kevsoft
Flurry
Flurry
Posts: 374
Joined: Sun Jul 27, 2014 8:03 am

Re: MonoSMBX (far future)

Postby Kevsoft » Sat Dec 17, 2016 9:46 am

Yea and that's the key point. The same goes for C++. If you're code is bad you do have crashes. It's not the langauge fault.
Yes C++ is hard to master right and the lack of a GC makes memory management a bit harder, but you can write crash-free and memory-leak-free programs if you use the right tools. C++ is getting better every year and it is evolving. At some point it will compete even better with other major language.

darkhog
Dolphin
Dolphin
Posts: 87
Joined: Sat Dec 10, 2016 11:17 pm

Re: MonoSMBX (far future)

Postby darkhog » Sat Dec 17, 2016 9:54 am

Kevsoft wrote:Yea and that's the key point. The same goes for C++. If you're code is bad you do have crashes. It's not the langauge fault.
Yes C++ is hard to master right and the lack of a GC makes memory management a bit harder, but you can write crash-free and memory-leak-free programs if you use the right tools. C++ is getting better every year and it is evolving. At some point it will compete even better with other major language.
The problem with C++ is that the C++ committee (there's a joke here, but I won't make it) is unwilling to remove any old cruft that gathered over the years, leaving new programmers confused about what they should use and also slowing down the development of bigger projects by experienced C++ teams due to all trivial decisions that has to be made. Do we use Boost or are we fine with using just standard library? If we use Boost, how much do we need to ship it with our program? After all Boost is quite a big library. Do we use malloc or RAII? If either, why not the other one? That the kinds of decisions C++ devs need to make all the time and I've just pointed out the obvious ones. With C# most of the time there's only one way to do one thing and that's what speeds up the development.

Most of programmer's time isn't wasted writing code or dealing with bugs, but spent on decisions about which path to take with a particular bit of code.

//edit: Anyway, this thread went off the rails too fast and for too long. Didn't want to start debate about merits of different programming languages. To recap, what I need to do this, is following:

Code: Select all

- Level format specification and other custom binary format
- LunaLua modules so I can integrate it with the new engine by default
- If Redigit didn't took it away when he left to make Terraria, access to current engine's source code so I can implement stuff using same algorithms, while increasing maintainability and removing bugs/limits of the current engine.
In the last case, decompiled binary is fine. I've disassembled it but x86 ASM!=VB6 source. Even decompiled one, VB6 source would still prove useful (and given it IS VB6 I doubt the code quality would be much better even if Redigit would hand me original sources which he probably won't).

Kevsoft
Flurry
Flurry
Posts: 374
Joined: Sun Jul 27, 2014 8:03 am

Re: MonoSMBX (far future)

Postby Kevsoft » Sat Dec 17, 2016 10:06 am

darkhog wrote:The problem with C++ is that the C++ committee (there's a joke here, but I won't make it) is unwilling to remove any old cruft that gathered over the years.
That's not completely true. In the latest C++17 they completly removed auto_ptr and some other bits and pieces. All other "dagerous" things are marked deprected.
darkhog wrote:Do we use malloc or RAII?
RAII is the quite obvious answer. (std::unique_ptr, std::shared_ptr for thing on the heap)

But hey, I don't want to get into a language fight here and drifting off-topic. My final word on it: Each language has their advantages and disadvantage.

Anyway, the PGE-Editor will go into a major rewrite and some point, but I think it is useless if people write their own editor/engine for the same purpose. It would be much better if everybody can agree on one language and work together. We can already see such a division in the "SMBX 1.4" vs "SMBX 2.0"-Topic. I don't want to see that happen again.

PS: Contact me at discord if you need infos for SMBX.

darkhog
Dolphin
Dolphin
Posts: 87
Joined: Sat Dec 10, 2016 11:17 pm

Re: MonoSMBX (far future)

Postby darkhog » Sat Dec 17, 2016 10:10 am

Kevsoft wrote:
darkhog wrote:The problem with C++ is that the C++ committee (there's a joke here, but I won't make it) is unwilling to remove any old cruft that gathered over the years.
That's not completely true. In the latest C++17 they completly removed auto_ptr and some other bits and pieces. All other "dagerous" things are marked deprected.
darkhog wrote:Do we use malloc or RAII?
RAII is the quite obvious answer. (std::unique_ptr, std::shared_ptr for thing on the heap)

But hey, I don't want to get into a language fight here and drifting off-topic. My final word on it: Each language has their advantages and disadvantage.

Anyway, the PGE-Editor will go into a major rewrite and some point, but I think it is useless if people write their own editor/engine for the same purpose. It would be much better if everybody can agree on one language and work together. We can already see such a division in the "SMBX 1.4" vs "SMBX 2.0"-Topic. I don't want to see that happen again.

PS: Contact me at discord if you need infos for SMBX.
Fair enough. And I would... if I had your Discord ID.

Cedur
Raccoon Mario
Raccoon Mario
Posts: 7073
Joined: Tue Jun 28, 2016 10:14 am
Flair: I'm gone, for chess and minesweeper
Pronouns: he/him

Re: MonoSMBX (far future)

Postby Cedur » Sat Dec 17, 2016 3:40 pm

Darkhog wrote:Fair enough. And I would... if I had your Discord ID.
Kevsoft is oftentimes online at CET day time, so if you live in the US you could catch him on the morning or the early afternoon.


Return to “General”

Who is online

Users browsing this forum: Max Flower and 0 guests

SMWCentralTalkhausMario Fan Games GalaxyKafukaMarioWikiSMBXEquipoEstelari