mchlnix / smb3-foundry Goto Github PK

Block transparency is only necessary, so blocks with some transparency can be displayed already. Blocks with only transparent pixels, should block, however, since those are explicitely used that way.

Just a little bit of usability.

For example level 5-2.

Sometimes the type of an object is called an index, sometimes not. This should be made consistent. Index could also mean the position inside the level.

Vertical Levels are not really supported all that well.

To save a level into the ROM it needs to have an object and an enemy offset. So there needs to be some way to input those before saving.

Maybe some check for the available space would work.

Or should the world and level numbers, that are in the m3l file be used instead?

It seems like some or most object sets just draw a ground into the level no matter what. That should be accounted for in the editor.

For some reason, the program doesn't like when i try to open a rom that is not stock, vanilla SMB3. It has opened some modified roms before, but most of the time, it will simply close the program after not finding something it was looking for. It allows me to try to open the rom, of course, but upon clicking 'open', it will shut down.

Edit 1:
I opened a stock rom, then tried to open a 'troublesome' rom and i saw this in the command prompt:
"IndexError: list index out of range"

Edit 2:
It seems to be fine opening levels up until it reaches one whose stock boundaries are no longer intact (where there is overflow of data or enemies, maybe?).

Especially import would need some changes to the Level structure. Saving would only be possible to M3L again, or the user would have to manually set an offset.

And even then there would need to be a check for size, or just "Hope you know what you are doing.".

list.xlsx
Add this list of all Enemys, objects and Items to the "docs" folder.

The Level object has a lot of information and functionality, which is needed in several places. Instead of having it guarded and in some cases wrapped by the LevelView object, it should be a central object, which only gets passed by reference to the widgets, that need it.

Stuff like graphic set, music, level length etc.

A search field would be good, so Creators don't need to remember the particular object indexes, or have to scroll through until they find the one they are looking for.

Maybe even a little preview field, which would make it necessary for each LevelObject to return a small bitmap representation of it. Kind of like the object viewer already.

There would need to be an optional level height parameter, for objects, that expand towards the ground, for those to not be gigantic.

There are some GUI glitches in the windows version left. Let's reduce them as much as possible with wxPython.

From BlueFinch:

I know that as a programmer, UI is not top priority, especially when you're in the thick of making it functional. That said, you seem to be nearing that first release version, and i have an idea or two about UI.

quick-access toolbar underneath menu (perhaps modeled closely after Workshop, but with fewer green-colored icons, as to avoid confusion).
zoom and undo/redo moved to toolbar
header menu cleaned up by sorting the different sections into a tabbed interface.

Image 1 - Header Dialog
Image 2 - Pointers Dialog

The 'next area' pointer in Image 1 is for telling the level what to load next when player goes through a warp pipe or a door.
The 'pointer properties' in image 2 is to tell the following:
Entrance Horizontal: WHERE the door or pipe is in the level (70-7F meaning 'somewhere, anywhere, between x position 70 through 7F).
Exit Horizontal: WHERE exactly the player is spit out into the 'next area' (horizontally)
Exit Vertical: WHERE (from a specific set of Y locations only, for some reason) the player is spit out vertically in the next area.
Exit Action: HOW does the player appear in the next area. (if the player enters a pipe, he must come out of a pipe: either up, down, left or right; that doesn't matter. he cannot enter a pipe then come out of a door though)

It would be nicer if objects could be resized like little windows with the mouse, instead of over the type or length spinners. The objects would never change it's type by this operation and depending on the orientation and if it is a 4 byte object, the dimensions could be given to the object and translated into valid values, before being rerendered.

The .py files get a bit crowded and messy. Time to organize the project a bit more.

The object should just be able to poll the level in some way, instead of keeping a ground map.

wxPython seems to not be as platform independent as it wants to be. Pyside2 looks promising and the project is small enough to pull it off in a day or two.

If you have objects extending to the ground, which hit nothing, the game breaks. We can detect this. How should the error be displayed, if at all.

Maybe a different hue (red) in the object list?

https://www.blog.pythonlibrary.org/2019/03/19/distributing-a-wxpython-application/

Can you add a Metatile editor to this just like in LM? Along with Metatile Set Exporter and Importer buttons?

Output will be .BIN (Binary) or .ASM (Assembly, perferrably NESASM v3 or ASM6)
Input will only be .BIN (Binary)

This will be a awesome thing to add!

Still disabled in current version.

If we remove an object, like the ground, some objects need to rerender, that doesn't happen until we move them, or otherwise change the object itself.

Therefore a method to "manually" trigger this would be helpful.

I know that as a programmer, UI is not top priority, especially when you're in the thick of making it functional. That said, you seem to be nearing that first release version, and i have an idea or two about UI.

1. quick-access toolbar underneath menu (perhaps modeled closely after Workshop, but with fewer green-colored icons, as to avoid confusion).
2. zoom and undo/redo moved to toolbar
3. header menu cleaned up by sorting the different sections into a tabbed interface.

also, this isn't a UI issue, but i will include it here:
Undo/redo seems to only be triggered after a copying and pasting, but isn't triggered when you just move an object. It would be useful for any change to be registered so it can be undone or redone (moving an object or enemy, copying and pasting, changes to the header or jumps even?)

It would be easier to rearrange the objects, if we could select them with a selection box or something, moving them together.

As long as the changes (to the ground map for example) are made sequentially in the right order, there should be no problem with the rendering.

There is a difference between the screen x and y of the LevelView Panel and the x and y of the level itself. For better use all methods of the LevelView should accept screen coordinates and all Level methods should accept level coordinates exclusively.

The objects load the wrong blocks for some reason. Maybe a problem in the romobj*.dat file?

Prove me why they aren't.

Should be doable, if pretty elaborate. In order for this to work flawlessly, we need to have our ducks in a row under the hood.

When wanting the byte representation of objects that grow upwards or to the left the adjusted x position is saved in the byte representation, not the actual x position (in the middle).

The leads to problems in Level 4-5 and saving in general, I imagine.

In vertical levels objects can inhabit the same on screen position by having different different x,y values, because of screen wrapping.

That results in switching from horizontal -> vertical -> horizontal does not preserve the original position of objects. Is there maybe a way to remember the original positions inside an object and transform those, instead of the on screen x,y being changed?

MainWindow has a lot of functions that need not be in it.

Strangely this is the same as Workshop, so probably a bug in the object definitions, since the data.dat seems fine.

Resizing and moving are continuous and need to save the initial position of an object. That is in level coordinates, which make for a lot of converting outside of level view. That should not be.

I think a lot of function calls of mainwindow are there to facilitate undoability, when they could be handled in level view. That is from a time, when the main window held the level info exclusively, which is not true anymore.

So see what functionality can be put into level view, but also check, if there is a way for the many responsibilities of level view to be modularized. Not sure, if necessary, but I like small classes.

Parsing graphics data for world maps is not slow, and even if it is, there shouldn't be too much of a problem with an initial loading screen on startup.

So I imagine reading in the rom, parsing the world maps and then displaying them in little squares for the user to select.

From there they can click on any enterable tile to select that level, or change the world map around, for example assigning new levels to tiles or changing the tiles around.

The Levelobject object has to do a lot of things, which makes it hard to test it. It is entangled into wx, when it shouldn't be, just like Tiles and Blocks.

Is there a way to make an Objectdrawer. Maybe even a Leveldrawer?

Separate concerns to make the interface between the game reality and the GUI reality minimal.

Aren't objects not just a bunch of pixels to the GUI, with a reference to the game logic?

Maybe have each Levelobject degrade down to an array of pixels, which can get turned into a Bitmap object and blotted onto the Panel, instead if doing that with each individual tile.

Possible things to warn about:

• too many enemies
• too many objects
• items that could cause a crash #20
• objects outside of level bounds
• contradicting objects (two autoscrollers maybe?)

This could be a little warning emblem in the toolbar which shows a panel of warnings or errors when clicked.

instead of showing the region of a pointer, why not just show it on the object that would be impacted, like a pipe or door?

This would hide the information, that the pointer is valid for the whole screen, but make it an easier association.

This might make it necessary to identify different pointers with some kind of symbol, so that two pipes at the screen edges are easily identifiable, without having to select the pointer.