An integrated tilemap editor

[blurymind]

Is your feature request related to a problem? Please describe. In order to create new tilemaps, it is currently required to manually do it in external software, which the image file that gb studio currently uses is simple enough to potentially keep the process in gb tudio's editor.

Describe the solution you'd like A suggestion is to use something like tilemap-edtior I made here https://github.com/blurymind/tilemap-editor

Since I wrote it, I can help with adding gb-studio specific parameters to it - to make it integrate better with gb studio.

There is a gb demo I made with it https://blurymind.github.io/tilemap-editor/?gist=e81f38830a67444c54adfb4f69c6538d

it also got a gb dev specific feature recently (file>analize tilemap)

Describe alternatives you've considered An alternative is to write a completely new tilemap editor specifically for gb-studio

Additional context I would be interested to hear what particularly needs to be done to tilemap-editor to make it usable as something that can be bundled and used within gb-studio's electron frame.

Does it need some options to restrict particular features? Such as map layers or multimap editing? The editor api already allows addition of custom exporters/buttons - which is demonstrated at its demo site, but feedback would be more than welcome :)

[darkhog]

First of all, the maximum number of tiles in tileset should be restricted to 192 as this is the maximum GBS can currently handle per scene (map) and since Gameboy does not have layers, the layers feature is also not needed.

Otherwise, you have my full support, especially if it would be deeply integrated into GBS engine, keeping maps and tiles separate in the rom. Did you know that even if you use the exact same tiles on two different maps, the rom will have two copies of same image? What a waste, really. Especially on a system where memory is important, where every byte counts.

[darkhog]

Now that I think of it, separating tilesets and maps would also have the added benefit of making animated tiles easier as you could define frames for an animated tile in a special tileset and use a placeholder tile in your maps. So saving memory and making implementation of advanced features easier.

//edit: And also we could set collisions on the tileset level, I just had a "fun" experience of my character walking on a newly added house walls (that used the same tiles as all the other houses in that map) because I forgot to setup collisions.

[maxoakland]

Now that I think of it, separating tilesets and maps would also have the added benefit of making animated tiles easier as you could define frames for an animated tile in a special tileset and use a placeholder tile in your maps. So saving memory and making implementation of advanced features easier.

//edit: And also we could set collisions on the tileset level, I just had a "fun" experience of my character walking on a newly added house walls (that used the same tiles as all the other houses in that map) because I forgot to setup collisions.

Now this makes me think that this might be a useful feature. So far it hasn’t been very necessary but allowing for more control like that would be very useful

[blurymind]

tilemap-editor still has no collision editing feature, but does already support animated tiles. The thing is though you dont need either feature atm. Gb-studio does not allow animated backgrounds and collisions are already handled in the scene editor

On Fri, Jan 28, 2022 at 3:56 AM Max Oakland @.***> wrote:

Now that I think of it, separating tilesets and maps would also have the added benefit of making animated tiles easier as you could define frames for an animated tile in a special tileset and use a placeholder tile in your maps. So saving memory and making implementation of advanced features easier.

//edit: And also we could set collisions on the tileset level, I just had a "fun" experience of my character walking on a newly added house walls (that used the same tiles as all the other houses in that map) because I forgot to setup collisions.

Now this makes me think that this might be a useful feature. So far it hasn’t been very necessary but allowing for more control like that would be very useful

— Reply to this email directly, view it on GitHub https://github.com/chrismaltby/gb-studio/issues/1021#issuecomment-1023862739, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRRWVMJJSPJ2M4W5TTJYJTUYIHVTANCNFSM5MTQZDMQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[darkhog]

tilemap-editor still has no collision editing feature, but does already support animated tiles. The thing is though you dont need either feature atm. Gb-studio does not allow animated backgrounds and collisions are already handles in the scene editor

Looks like we just need to combine the two! *insert DBZ fusion meme here*

[blurymind]

hehe yeah :) For now I will look into adding some parameters to it to introduce the needed limitations for the user:

• disable animated tiles
• disable map layers
• disable multiple maps
• disable ability to set tile size - so we can limit it to a constant (8x8)
• add maximum number of map tiles that can be used (what should that be?)
• add maximum number of tileset tiles that can be used (what should that be?)
• maybe get all of these limitations in place when running in mode=gb-studio- I can make a demo url with them in effect that way

disabled features will be hidden from the ui - to clean up the ui from clutter

its api already has hooks to add an ok button and do custom logic with both the base64 string of the actual map when saving and any of the other data.

For now I will leave out the collision editing stuff for later, since it will be harder to implement and the scene editor already has it.

Having the collision editing stuff happen on the scene allows using the same background, but with different collisions in two scenes. If you move the logic to the editor itself, you might lose that flexibility.

Maybe we should call it a "background" editor if its used inside gb-studio - since the resulting resource IS a background image - to be used as a map

[blurymind]

An alternative is to fork the existing sprite editor in gb-studio to make a background editor - it would need to have a grid snap turned on and the tiles should be 8x8 instead of 8x16

[darkhog]

Actually, I'd prefer a deeper integration with the engine as I've said previously since keeping tilesets and maps as separate resources inside the ROM would not only decrease the ROM size (since you would avoid storing two sets of identical trees for two different maps that happen to share the tiles, but also would make implementing advanced stuff easier. You made a town and now you want a winter version of it? Why make a new background when you just can swap the tileset at runtime?

Backgrounds should be kept as an option though, for one offs and stuff that wouldn't really make sense to be made as a map (like drawn cutscenes), and of course for legacy projects, but instead of duplicating resources, the backgrounds should then be converted into a map and associated tileset so the developer have a better control over what resources are shared and which ones are duplicated inside the rom.

[maxoakland]

add maximum number of map tiles that can be used (what should that be?)

I think you should make it show a count of the tiles in the scene and warn (a red square like in the scene window) if it gets over 192 but don’t set a maximum because of technical reasons I can explain if you want me to

An alternative is to fork the existing sprite editor in gb-studio to make a background editor - it would need to have a grid snap turned on and the tiles should be 8x8 instead of 8x16

That’s a really cool idea and it might be better since it could share code and would conform to the interface automatically. And that’s important

[DuendeInexistente]

and since Gameboy does not have layers, the layers feature is also not needed.

PNGs don't have layers either and workfile formats like KRA or PSD still have them. Layers are for organization above all.