repro:

1. clear local storage
2. load the editor and choose example level
3. paint a tile
4. press undo

expected: painted tile goes away
actual: entire level goes away

seems something is off about undo when first start a level.

TiltPlatform should have a details pane where the user can choose either tilt or spin.

Currently fill only works for cells, it should work for sprites too.

if a pool of water is only one tile high, the game does not add the sparkles, but the editor does.

If a room has multiple chests in it, all will take on the payload of the last chest. Enforce this in the editor.

Said erasing stopped working until they refreshed the page, then it worked again.

Unfortunately don't have much more to go on. Might need to add error capturing.

either a separate entity type or give charging chuck a details pane?

charging: [0 x y 9b 0]
clapping: [0 x y 9b 1]

seems any value other than zero makes it clapping

Whenever grass is next to water, it doesn't look quite right

Nintendo solved this by having a second version of grass intended to be next to water.

If the user puts grass next to water, switch to the water-grass version automatically.

To repro: just head to https://smaghetti.com/compatibility/Flutter/

Currently CoinChallenge is hard coded to 4 coins. Add a detail pane to allow this to be configured.

The switch to requestAnimationFrame in gba.js does get a pretty nice 60fps if

• the machine is pretty powerful
• the user is using chrome
• their monitor refresh rate is set to 60hz

if any are untrue, then gba.js will very likely not run at 60fps. In the case of the refresh rate being greater than 60, it's possible for gba.js to run way too fast.

For now, just went back to setTimeout(callback, 16), but this is not very accurate.

Figure out a way to get

• 60fps on powerful machines with refresh rate set to 60hz
• 60fps on powerful machines with refresh rate above 60hz
• best possible performance can muster on lower end machines

The conveyor belt details pane only allows changing its size. Allow changing its direction too.

Also, the way it does size is pretty hokey, switch it to be drag based.

Once the example level is loaded into the editor, head to room two. The triangular blocks on the right side do not have the correct angle setting, but the setting is in the data.

Save states made it so audio no longer works in the emulator.

Sprites can overlap all they want. But usually objects clobber each other. Have editorSlice do the clobbering to better show the user what their level will really be like.

Vertical, warpable, double ended pipe is object id 0x2c on bank 1. But so far, have not found a non-warpable version. This means double ended pipes can't yet be put into smaghetti because if the user doesn't add a warp to both of its ends, then it is a soft lock of the player goes into the pipe.

The brute force dump shows pipes at other object ids, including 0 for a double ended pipe, but it looks like they need different object sets. Possibly one of them is a non transportable double ender.

Possibly one doesn't exist? Do all double ended pipes in SMB3 allow warping?

Draw a vertical column from top to bottom like the boos below. Then run the level. Only two boos will show up. This is true of any sprite based entity.

I know entities need to be sorted by x, but maybe they need to be then sorted by y in some way?

Some entities. most notably WoodDoor, have different ids in different object sets. Support this so they can be used in more situations.

todo:

• have these entities have a map from id -> objectSets in their objectSets.ts file
• have them flatten the objectSets into a single list inside the entity
• have toObjectBinary pass in the chosen objectSet
• choose the id based on the objectSet that was passed in

Seems entites larger than one tile render incorrectly

For example the bowser in the center of the bricks is only one tile in size

This is because it needs the sixth to last byte of level settings to be 1, instead of 0.

Need to figure this out. Possibly there's really 12 or more graphic set bytes instead of the assumed six? some brute force dumps would probably help shed some light.

dragging an actor on top of something in stage will clobber the stage entity. Clobbering should only occur within the same layer.

This is a specific example of a more general problem.

When clicking on a part of the editor that has occupants in both actors and stage, often bad things happen. If you just want to move one, you can't. If you want to get the details pane, you can't.

a work around is to lock one of the layers, but this only works if the two entities are on different layers.

to choose its behavior: up/down, left/right, etc

I think it would be useful in documenting object parameters if existing levels could be loaded - entities that aren't documented yet could use fallback graphics/settings boxes (e.g. just using a raw hex view rather than the "friendly" settings box)

In room 4 of this level, a p-switch was added, but it's not compatible. How did it get added?

https://smaghetti.com/make/LDkUq_k7/

Pipes are a big missing feature. Add a pipe entity with a detail pane that can configure its size, orientation, color and whether it is a warp.

If a room has more than one CoinChallenge in it, then when the level loads the last CoinChallenge to load is the value that gets set.

ie

1. add a CoinChallenge set to 10
2. add another CoinChallenge, set it to 30
3. run the level

both CoinChallenges will set the count to 30

enforce this limitation in the editor

It really should only show after the user chooses to the save the level to the backend. Don't show "Level Saved" after a localstorage save.

Horizontal sizing is described here: https://github.com/city41/smaghetti/wiki/Rooms#width-of-level

todo: figure out vertical sizing.

ManageRooms: allow resizing of rooms with a drag handle

So far fire bar only comes in one configuration. Add a details pane for choosing size, direction and pivot point.

gbajs only needs cloneDeep, just pull that in and not all of lodash.

Since pile driver goomba just looks like a brick after a graphic set dump, have not yet figured out its entire graphic set.

Do a special run, or figure out a more flexible way to do dumps for situations like this.

This grass setup in the editor

leads to this in game

the editor should auto tile grass in the same way Nintendo did to help the user understand what their grass will ultimately look like.

object sets can go all the way up to 0xff. After testing this with WoodFloor, it was found in far more object sets, sometimes with different (but usable) palettes.

To increase the chances of entities being compatible, should do full dumps for all entities up to 0xff. Sadly this means each dump will take about an hour, so wonder if can speed this up somehow.

the first object in a level to claim a spot in the map wins. later objects will at best work around that spot.

this is essential for things like allowing terrain to be in front of the end of level backdrop. The end of level backdrop should probably have lowest priority.

assign priorities to objects and sort them by priority before creating the level data.

When createLevelData was using the real level name, it would cause a new level to get added to the save file instead over overwriting the old when the level name was changed. For now, went back to a canned name.

todo:

• have injectLevelIntoSave stop mutating the array in place and always create a fresh save array
• OR: have injectLevelIntoSave have a mode/version that always overwrites the first level

NOTE: injectLevelIntoSave's ability to add a new level next to existing ones is good and should not be thrown away, it will be used in the future.

A level can have at most 5 ace coins in it. This is accounted for when using normal ace coins, but not when an ace coin is a bubble payload.

When the editor is in pan ("hand") mode, you can select entities and even interact with their details panes.

That's because the Chargin' Chuck sprite is supposed to be 5-byte, if the fifth byte is set to 1 it will be a Clappin' Chuck

Since the music block becomes a sprite while it is bouncing, need to calculate the proper sprite graphic set for it.

Classic bowser can be configured to throw hammers, as well as probably other things (such as which enemy is pretending to be him)

repro:

1. load the example level
2. click on the transport dest that is right there
3. choose a new dest, then click ok

expected: new dest is set as the transports dest
actual: no change occurs

Hello Matt! How are you doing?

I found out about you after reading a post on your blog "Javascript is a pass by value language". So I ended up checking your profile here and I am impressed by your work with this project! Congratulations on the amazing work!

I am just messaging to make a suggestion in case you haven't used it already, the Projects tab. I've only recently found out so I'm starting to use and thought it was a nice way to create task issues, link PRs and manage everything here on github just like we do on Trello. In case you haven't opted for that forget about my message, just thought about helping :)

Keep up the good work! Cheers :)

Palette has gotten way too crowded and tedious to use. The new palette should

• fill the entire width of the screen, and open up just below the toolbars.
• have a text search that can be invoked by typing / then the search term
• remove the notion of "add" and "remove", instead the quick palette should just have the 10 or so most recently and/or most commonly used entities.

If the byte that controls the rotating object gfx (like rotating blocks, seesaws, etc.) is set to 2, sprite e3 (FloatingBlock) will resemble a yellow-brown beach ball (which I'm pretty sure isn't used by anything else, it looks like ArrowLift without the arrow on it but it uses a different graphic) rather than the rotating blocks from Vexing Doors. Its collision also support this, and if you play a level with it in an emulator it makes ocean sound effects when it's moved around.

When Mario stands on top of FallAwaySpike, it gets wrong tiles once it becomes a sprite.

FluffyCloud takes a length parameter and extends the cloud accordingly.

The editor should support this. Will probably end up working like conveyor belt.

Sprites in HexTree are always one tile in size now. Fix it so they appear at their correct size. Easiest way is probably to call Entity#render()

The current destination definition was built with doors in mind. It has the x/y coordinate of a tile that is the warp destination. This makes sense for doors, as you can warp anywhere with them.

But pipes must warp to other pipes. Explore defining a pipe specific destination which stores the dest pipe's id. Then if the dest pipe moves, the transport moves automatically with it.

This would also mean a new "PipeDestinationModal" for choosing the dest pipe, as the current TransportDestinationModal chooses tiles.