WohlSoft Forums

I don't have enough time to read all the posts on this topic, so I write my suggestions directly.

• Background movement: in level editor of SMBX, when you move around the level, the background have a slower movement than blocks and other things, and this create a particular profondity effect. In PGE Editor this there isn't.
• Auto-align: in SMBX's editor if is checked the checkbox "auto align", when you go over the editor window, the white hand have a free movement as you move your mouse, but the block/npc/bgo etc. will be already positioned in the "invisible grid" of the level. In PGE editor you can choose a function like auto-align, but in both cases (checked or not checked) the block have a free movement and only when you place a block it will be aligned with the grid, and it is a bit annoying.
• The grid: I don't remember well if this is already implemented, but in case of no, I think is a lot useful have a visible grid in the level window.
  These are my suggestions sorry for my weird english

You can add this functions:
Add more custom npcs, blocks, bgos, tiles, backgrounds, scenes, levels, players and paths than original
Resize tiles, levels, paths, scenes and bgos
Custom functions and time limit without LunaLua and LunaDll
Custom sounds
Autoscroll
Teleport area definition.

Yoshimoto wrote:Resize tiles, levels, paths, scenes and bgos

PGE already supports those things of any size: just put any image ad CGFX and enjoy

Yoshimoto wrote:Custom functions and time limit without LunaLua and LunaDll

Every new thing works in PGE Engine natively

Yoshimoto wrote:Autoscroll

Already improved:
- you can toggle autoscroll in same section just witb block hiting
- you can set another section to be autoscrollable and then enter into it to begin you wall with scrolling screen
- you can return to scrollable section and stay scrollwalk again without level restating

Yoshimoto wrote:Add more custom npcs, blocks, bgos, tiles, backgrounds, scenes, levels, players and paths

Any "universe" questions are going for config pack, but not for engine core which interprets config pack and animating your universe. PGE already supports abiloty to declare any number of elements in the INI files (configs/<pack name!>/*.ini)

Yoshimoto wrote:Teleport area definition.

Instant warps? Is planned to have "wide entrances" to don't spam with warp points to make a long teleport area

I wonder if it's possible to include an additional configuration pack which implements SMW game-play physics and behaviours instead of replicating all standards of SMBX.

I know it may be difficult to implement, because not only the data (graphics, blocks, power-ups (SMB3 feather vs SMW feather) will be different, but also the programming logics (e.g acceleration physics, flying physics, swimming physics) will be different from SMBX.

The following behaviour differences between SMBX and SMW are far from complete, but can serve as the examples:

1. In SMBX, while running, Mario's speed is accelerated constantly towards the maximum. While in SMW, Mario's horizontal speed accelerates from 0 to 36, and stay in 36 for 1-2 seconds, and jumps (not accelerates smoothly) from 36 to 48 finally. Remarks: Mario's normal walking speed on land is 20.
   
2. This's for swimming physics. In SMBX, pressing the jump button has the same effect as pressing the jump+up button. But in SMW, pressing jump+up button will swim upwards much faster than pressing only the jump button, and pressing jump+down button will swim only slightly upwards. Also, in SMW, while carrying items (Koopa shells, P-Switches, Spring-boxes, etc.), Mario's swimming horizontal speed increases from 16 to 32. Mario's walking speed under water is 8.
   
3. Remarks: The address for Mario's speed is 7E007B, and you can use Snes9x with LUA to monitor it.
   
4. For flying physics, it's obvious that SMBX's is different from SMW's, if you have played SMW.
   
5. In SMBX, we cannot carry items (Koopa shells, P-Switches, Spring-boxes, etc.) through pipes, which greatly limits the possibility of many puzzle levels. In SMW, we can carry items through pipes. Though, this behaviour can be implemented as a episode-wide config instead of different config packs.
   
6. Of course, we don't need to implement the glitches of SMW, such as the double yoshi glitch, wall jump glitch, etc. You may find the glitches in various Mario Must Die TAS.
   
7. We know Blue Beach Koopa (Blue Koopa without its shell) kicks any shell on its way, in both SMBX and SMW. But the different is, in SMBX, it kicks the shell immediately after encountering it, while in SMW, it stops and waits around 0.5 seconds before kicking the shell
   
8. We know there are animations when Mario is shrinking (after getting hit), when Mario is growing up (after eating a mushroom), when Yoshi is growing up (after its egg hatches). In SMW, during such animations, all other NPCs (and moving platforms) to freeze. But in SMBX, all other NPCs do not freeze during those animations.
   
9. Mario's acceleration is higher SMW than in SMBX, making Mario more agile in SMW than in SMBX. I prefer "difficulty due to strong enemies" (which is more interesting since Mario rocks in this way) rather than "difficulty due to slow Mario" (which is a fake difficulty and Mario sucks in this way).
   
   For reference, you can feel Mario's agility in the extremely hard final boss fight of Kaizo Mario 3 (https://www.youtube.com/watch?v=oYHlznTM2zo), where the Japanese player R.Kiba lost around 110 lives there, and at 7:30 Mario's agility is fully shown. As a comparison, one would expect the final boss of SMBX's Princess Cliche 2 would be much easier (even without the bullet bill gun nor the hammer suit) because in Princess Cliche 2 Bowser doesn't throw 5 hammers, doesn't spit 3 fire balls, doesn't jump quickly, and doesn't have Magikoopa and Thwomp as allies. But still it's not easy to fight, and I lost more than 150 lives in the final boss of Princess Cliche 2 simply because Mario in SMBX doesn't have enough acceleration and agility (even if Mario has enough max speed) to dodge the flying koopas. Mario also has a bigger hit box in SMBX than in SMW. To summarize, SMBX physics won't allow agile Mario movements similar to Kaizo 3 boss fight 7:30.
   
   With SMW physics, the final boss of SMBX's Princess Cliche 2 would be a piece of cake, and we can make it harder by putting more enemies or obstacles.

You may ask why implement SMW behaviours in PGE again while we can just play SMW rom hacks in emulators?
It's obvious, because I want to get rid of all those awful limitations in SNES. We know SMW in SNES will lag heavily when there're just 10 NPCs in one screen. We know SMW uses the location to determine whether the question block is a blue-switch or grey-switch. We know SMW will glitch if there are more than 5 spinning blocks spinning at the same time. All these limitations are awful.

sken130 wrote:

Spoiler

I wonder if it's possible to include an additional configuration pack which implements SMW game-play physics and behaviours instead of replicating all standards of SMBX.

I know it may be difficult to implement, because not only the data (graphics, blocks, power-ups (SMB3 feather vs SMW feather) will be different, but also the programming logics (e.g acceleration physics, flying physics, swimming physics) will be different from SMBX.

The following behaviour differences between SMBX and SMW are far from complete, but can serve as the examples:

1. In SMBX, while running, Mario's speed is accelerated constantly towards the maximum. While in SMW, Mario's horizontal speed accelerates from 0 to 36, and stay in 36 for 1-2 seconds, and jumps (not accelerates smoothly) from 36 to 48 finally. Remarks: Mario's normal walking speed on land is 20.
   
2. This's for swimming physics. In SMBX, pressing the jump button has the same effect as pressing the jump+up button. But in SMW, pressing jump+up button will swim upwards much faster than pressing only the jump button, and pressing jump+down button will swim only slightly upwards. Also, in SMW, while carrying items (Koopa shells, P-Switches, Spring-boxes, etc.), Mario's swimming horizontal speed increases from 16 to 32. Mario's walking speed under water is 8.
   
3. Remarks: The address for Mario's speed is 7E007B, and you can use Snes9x with LUA to monitor it.
   
4. For flying physics, it's obvious that SMBX's is different from SMW's, if you have played SMW.
   
5. In SMBX, we cannot carry items (Koopa shells, P-Switches, Spring-boxes, etc.) through pipes, which greatly limits the possibility of many puzzle levels. In SMW, we can carry items through pipes. Though, this behaviour can be implemented as a episode-wide config instead of different config packs.
   
6. Of course, we don't need to implement the glitches of SMW, such as the double yoshi glitch, wall jump glitch, etc. You may find the glitches in various Mario Must Die TAS.
   
7. We know Blue Beach Koopa (Blue Koopa without its shell) kicks any shell on its way, in both SMBX and SMW. But the different is, in SMBX, it kicks the shell immediately after encountering it, while in SMW, it stops and waits around 0.5 seconds before kicking the shell
   
8. We know there are animations when Mario is shrinking (after getting hit), when Mario is growing up (after eating a mushroom), when Yoshi is growing up (after its egg hatches). In SMW, during such animations, all other NPCs (and moving platforms) to freeze. But in SMBX, all other NPCs do not freeze during those animations.
   
9. Mario's acceleration is higher SMW than in SMBX, making Mario more agile in SMW than in SMBX. I prefer "difficulty due to strong enemies" (which is more interesting since Mario rocks in this way) rather than "difficulty due to slow Mario" (which is a fake difficulty and Mario sucks in this way).
   
   For reference, you can feel Mario's agility in the extremely hard final boss fight of Kaizo Mario 3 (https://www.youtube.com/watch?v=oYHlznTM2zo), where the Japanese player R.Kiba lost around 110 lives there, and at 7:30 Mario's agility is fully shown. As a comparison, one would expect the final boss of SMBX's Princess Cliche 2 would be much easier (even without the bullet bill gun nor the hammer suit) because in Princess Cliche 2 Bowser doesn't throw 5 hammers, doesn't spit 3 fire balls, doesn't jump quickly, and doesn't have Magikoopa and Thwomp as allies. But still it's not easy to fight, and I lost more than 150 lives in the final boss of Princess Cliche 2 simply because Mario in SMBX doesn't have enough acceleration and agility (even if Mario has enough max speed) to dodge the flying koopas. Mario also has a bigger hit box in SMBX than in SMW. To summarize, SMBX physics won't allow agile Mario movements similar to Kaizo 3 boss fight 7:30.
   
   With SMW physics, the final boss of SMBX's Princess Cliche 2 would be a piece of cake, and we can make it harder by putting more enemies or obstacles.

You may ask why implement SMW behaviours in PGE again while we can just play SMW rom hacks in emulators?
It's obvious, because I want to get rid of all those awful limitations in SNES. We know SMW in SNES will lag heavily when there're just 10 NPCs in one screen. We know SMW uses the location to determine whether the question block is a blue-switch or grey-switch. We know SMW will glitch if there are more than 5 spinning blocks spinning at the same time. All these limitations are awful.

Sounds like a massive idea for SMB Xtended, tbh. It can be done if you know what you're doing, but until then, just wait and it may sooner or later happen.
As for swimming, already like that in SMBX (you gotta try, man. it works already) and iirc, you can set warp options to allow carryable NPCs through the warp with you, even rides like Yoshi, but I haven't looked in a while, but I know for a fact that the swimming surely does work, just not in PGE yet, I think, but it does in SMBX.
One last thing...why add glitches? smh

mariofan 64 wrote:One last thing...why add glitches? smh

I have two reasons why:

1. Glitches can be exploited to create some pretty unique gimmicks and interactions.

2. There are a decent amount of levels that already exist which use and exploit the use of glitches. If not carried over, playing these levels in a "glitch" free game, effectively renders those levels unplayable. That said, I am not considering the "wall-jump glitch" or the "slide-through-the-wall glitch" in this as they have been shown to be not glitches, but purposely added. Wohlstand showed this a while back.

I have been lurking for a very long time in the mario modding scene. I have edited many games into full mods. Long story short, I can tell that PGE is a very, very promising engine and I want to throw my full support into helping you all succeed. I am certain that PGE will be a powerful and successful platforming engine once officially released.

I hope that I can be of use to the development team. I am afraid that I am not a programmer so I cannot help in the most critical forms of development. I will examine the support thread thoroughly for ways I can contribute.


I apologize if this has been stated previously. I am excited that the AIs are to be edited.

Can the Hammer Bros AI be edited to match the behavior of the actual games? The current 1.3.0.1 and 1.4.1 do not interact with blocks in such a way that they can jump onto them. Also the Hammer throwing behavior is vastly different.

SgwySpeedrcr wrote:I have been lurking for a very long time in the mario modding scene. I have edited many games into full mods. Long story short, I can tell that PGE is a very, very promising engine and I want to throw my full support into helping you all succeed. I am certain that PGE will be a powerful and successful platforming engine once officially released.

I hope that I can be of use to the development team. I am afraid that I am not a programmer so I cannot help in the most critical forms of development. I will examine the support thread thoroughly for ways I can contribute.

Thanks for support of us

SgwySpeedrcr wrote:I apologize if this has been stated previously. I am excited that the AIs are to be edited.

Can the Hammer Bros AI be edited to match the behavior of the actual games? The current 1.3.0.1 and 1.4.1 do not interact with blocks in such a way that they can jump onto them. Also the Hammer throwing behavior is vastly different.

Because PGE Engine designed to have NPC-AI's as Lua-Scripts, you can edit them freely, also you can make new algorithm from scratch to customize it (NPC.txt's "script" field)

I see I have a lot to learn about the project with regards to NPC scripts.

Wohlstand wrote:Thanks for support of us

I am reading up on the project through your wiki. As I am reading through, would you like it if I were to make slight English grammar revisions to it for clarity? You are a very proficient English speaker... there's no way I could ever speak Russian

I have career experience with formatting and tweaking the wording for proprietary documents. It is an enjoyable task, and I believe I will gain a greater understanding of your project as I am doing so.

Make it easier to add custom graphics. For example Tools>Palettes and Tilesets>Import Tileset(s). Then choose the directory your images, and .ini are located.
No longer replacing, but instead expanding your graphics options.

Added after 6 minutes 43 seconds:
Thanks for all of ya's hard work


Could I please have a link to all the classes that are used by NPC AIs.
Lua seems to be a simpler, more platformer specific version of java, so having a look at the base classes, and those accessible by AI scripts.
Something similar to this: https://docs.oracle.com/javase/7/docs/api/

SgwySpeedrcr wrote:As I am reading through, would you like it if I were to make slight English grammar revisions to it for clarity?..

I will say yes, go for it if you want to. We will appreciate your work since there are... quite a lot of pages that need to be fixed. I also fix myself some of the pages, but I can't do much because I'm not a native english-speaker. I do what I can do.

If you want to help though, just log in in the wiki by using your forum's username and password

I have a couple of minor suggestions:

1)Make it so you can place more than one of any item in a box, and decide if they come out one at a time or all at once when you hit the block. There could be an "infinite number" option as well, and a "randomizer" option. This option would allow you to make a random NPC of your choice come out. With this, you could limit the number of block hits so the player can't get everything that's in it.

2)This would sort of go with the other suggestion, but could be implemented in the current editor. There should be a counter shown in the editor for how many coins are in the block. This would appear on the bottom of the coin graphic that appears when coins are in the block.

My suggestions are minor and only for editor too So, since there's a SMBX 2.0 version of PGE Editor and the legacy SMBX editor will be disabled by default, maybe it would be better to finally move SMB2 pass-through block from SMB3 block section to SMB2 one? Block-289 is the block I'm talking about. Redigit put it in SMB3 section by an accident originally.

And another suggestion, maybe remove PGE testing from the editor for now, and only leave SMBX testing (with testing settings too)? I've seen a lot of people getting confused as of why when they tested their stages the engine just wasn't working correctly, since they had no idea they were doing PGE testing instead of SMBX testing.

Sambo wrote:1)Make it so you can place more than one of any item in a box, and decide if they come out one at a time or all at once when you hit the block.

This also suggested by Kevsoft long time ago (also he shown me a video where someone builds map in some RPG game, and where user selects multiple tiles and then places this mosaic to the map as it's alone tile), but still good idea, so, that will be kept in a mind until I will finish main sort of optimizations (QGraphicsScene sucks on maps with a big number of elements, therefore to resolve this I must implement interactive scene with items, multi-selction, dragging and moving, etc. That must not be hard, but requires time, experiments and then converting everything which implemented over QGraphicsScene into new-implemented editing scene)

Sambo wrote:There could be an "infinite number" option as well, and a "randomizer" option. This option would allow you to make a random NPC of your choice come out. With this, you could limit the number of block hits so the player can't get everything that's in it.

Since lua-API is presented, there is already possible to have programmable randomizers-NPC (like random power-ups, random vegetables, etc.)

Sambo wrote:2)This would sort of go with the other suggestion, but could be implemented in the current editor. There should be a counter shown in the editor for how many coins are in the block. This would appear on the bottom of the coin graphic that appears when coins are in the block.

...draw that number like WarpID drawn on every warp point, so, I'll add that, good idea

h2643 wrote:maybe it would be better to finally move SMB2 pass-through block from SMB3 block section to SMB2 one? Block-289 is the block I'm talking about. Redigit put it in SMB3 section by a mistake an accident originally.

Okay, you right (even a proof)

h2643 wrote:remove PGE testing from the editor for now, and only leave SMBX testing (with testing settings too)

That is totally unneeded. Instead I added a warning message box about in-development state of engine part. Also SMBX-Test plugged to F5 key by default in the SMBX Integration configuration package, because SMBX-Test is impossible without SMBX Integration package (except in-editor test while SMBX Editor is running in background). I working hard on engine and now it takes huge changes since february 2016: it finally took player API for lua and I finally can write lua-scripts to implement power-ups, ability to cure health, do some attacks without "chucknorris" cheat (until this, every big level is in "hardcore" difficulty, so, let bossedit8 try to play one of "The Invasion 1/2" levels in hard mode (no ability to restore health! )), it finally takes moving layers support, so, unbeatable in past levels are finally beatable now. (Anyway, if too much elements in a moving layer, because iterating of every element plugged in the moving layer, engine is going to lag while that layer in move. Examples are water-based levels with rising/downing water where lots of BGO's are plugged as moving layer. I think that in SMBX instead of every element iteration are modifiers variables which are defining offset of elements which are plugged plugged into moving layer. Anyway this way results some bugs known in SMBX, example is wrong offset of layers after level restart in some cases, etc. But this algorithm allows any number of plugged elements without CPU overloading).

Wohlstand wrote:

h2643 wrote:remove PGE testing from the editor for now, and only leave SMBX testing (with testing settings too)

That is totally unneeded. Instead I added a warning message box about in-development state of engine part.

Oh, that's great!

I would say it needs a way to change blocksize like in smbx-38A.

Pilzinsel64 wrote:I would say it needs a way to change blocksize like in smbx-38A.

Are you mean setting absolute value sizes?
Okay, I'll add a mini-dialog from context menu of resizing box where you can modify absolute geometry of block (and even section or screenshot zone selection box) (X/Y/Width/Height).
Or better: Item properties box will have editable Width/Height fields on already-placed block (in-placing disallows pre-defined sizes because new block will be drawn with dynamical size definition (from rectangle drawn by you) )

Wohlstand wrote:

Pilzinsel64 wrote:I would say it needs a way to change blocksize like in smbx-38A.

Are you mean setting absolute value sizes?
Okay, I'll add a mini-dialog from context menu of resizing box where you can modify absolute geometry of block (and even section or screenshot zone selection box) (X/Y/Width/Height).
Or better: Item properties box will have editable Width/Height fields on already-placed block (in-placing disallows pre-defined sizes because new block will be drawn with dynamical size definition (from rectangle drawn by you) )

Okay, thanks!

Here's an idea, perfect for the miscellaneous category on NPCs. What about adding the Mighty Eagle from Angry Birds, as a power-up to PGE. Say you hit a block and out pops the Sardine Can. You throw it, it hits the ground and in swoops the Mighty Eagle, which in turn defeats all enemies upon contact, destroys certain blocks/objects and kills all enemies on screen upon touching the ground, causing a POW Block explosion of sorts to simulate the earthquake he causes in Angry Birds.

- The Sardine Can only activates the Mighty Eagle upon hitting the ground after being thrown, like how the SMB2 Bomb explodes only after being thrown. Putting the Can down by dropping it at your feet would make it not activate. It would also disappear upon activation or after the Mighty Eagle passes so it cannot be used more than once.

- The Mighty Eagle swoops in from the top left, hits the ground, causes the earthquake and exits to the top right.

- The Mighty Eagle would be a one-time only item due to its power and can only be used upon finding another Sardine Can. Also cannot harm the player.

- Defeats all enemies on-screen upon contact, or by causing an earthquake. Destroys ? Blocks, Bricks and Turn Blocks.

Wohlstand wrote:

Pilzinsel64 wrote:I would say it needs a way to change blocksize like in smbx-38A.

Are you mean setting absolute value sizes?
Okay, I'll add a mini-dialog from context menu of resizing box where you can modify absolute geometry of block (and even section or screenshot zone selection box) (X/Y/Width/Height).
Or better: Item properties box will have editable Width/Height fields on already-placed block (in-placing disallows pre-defined sizes because new block will be drawn with dynamical size definition (from rectangle drawn by you) )

I mea like this: