Forums

As Blast Arena is now almost complete, just awaiting music and release for playtesting, I've started planning a new game.

This one will be slightly bigger in scope and with horizontal scrolling (no vertical). I hope to post progress and any questions here (hopefully not as many this time).

This will be more work but without a lot of the learning and setup of the previous one it won't be too bad.

Here's an initial mockup, this is mainly to test colours and requirements. I've decided to go for 16x16 for the player, which is considered small compared to other games, but I'm planning for the stages to be compact and have a lot of obstacles and platforms, unlike say Wonder Boy III.

I'll also have to do something else with the pickups shown here, as they will be tiles so will need to blend into any background tilemap better than they do here.

mockup-01.png (8.52 KB)

Looks very nice.

Will the pickups have to work on different backgrounds? I see no reason why you can’t just continue the brick pattern behind them like you did with the spikes. You’d have to create different pickup graphics for each tileset, but I don’t really see that as a problem. Of course you could also implement them as sprites if there aren’t too many of them.

Kagesan wrote

Looks very nice.

Will the pickups have to work on different backgrounds? I see no reason why you can’t just continue the brick pattern behind them like you did with the spikes. You’d have to create different pickup graphics for each tileset, but I don’t really see that as a problem. Of course you could also implement them as sprites if there aren’t too many of them.

Sprites might be an issue. I'm planning to use the lower half of tiles for sprites so want to keep those empty, and I think the play area will be too crowded to use sprites.

Backgrounds behind each one would be OK, but I'd have to align them to the brickwork (or whatever the background was).

I tried to put a decorative 16x16 box around each one but I don't think it looks as good.

It would be easiest if I can load the powerups separately to each BG tileset.

One thing still to try is draw a large treasure chest which covers 3x3 tiles and then create the pickup within that.

are you planning of creating a background engine based on 16×16 pixels metatiles or will you just use a tile based one?

I was toying with the latter idea these days, and to write a simple column-major exporter for BMP2Tile is a 5 minute work for me, and it would easily work with SMSlib's SMS_loadTileMapColumn...

sverx wrote

are you planning of creating a background engine based on 16×16 pixels metatiles or will you just use a tile based one?

I was toying with the latter idea these days, and to write a simple column-major exporter for BMP2Tile is a 5 minute work for me, and it would easily work with SMSlib's SMS_loadTileMapColumn...

I was planning to just use tile based one for things like tile collisions etc.

The maps will be made up of mostly 16x16px meta tiles but I don't see a need to create anything special for it. Speed or space won't be an issue as the maps will be quite simple. Unless there's some other advantage I'm missing?

For any object that does not move around, I think that using the BG layer is a must. Otherwise you will very quickly fill in the 8 sprites available on a single line.

You will also not have to update their position separately when you will scroll the screen.

So you might want a column-major raw exporter from BMP2Tile :)

I attach here one I just wrote... as you can see from its source it's very simple.

So when you need a new column, you just use SMS_loadTileMapColumn pointing to the right location in the map.

gfxcomp_column_major_raw.dll.zip (66.23 KB)

BMP2Tile export plugin for column-major tilemaps

gfxcomp_column_major_raw.c (942 B)

source file (C)

For the pickups graphics against backgrounds, I suppose you could also create the "background + pickup" tile at load time ?

You'd need to format your graphics for the pickup to have a "transparent colour". Then you would be essentially creating a new tile by first copying the "background" and then copying the pixels of the "pickup" that are not a transparent colour into this, and you have essentially a programmatically created tile ! The disadvantage is that you would be limited to the same palette you're using for the background.

Does that make sense ?

cireza wrote

For any object that does not move around, I think that using the BG layer is a must. Otherwise you will very quickly fill in the 8 sprites available on a single line.

You will also not have to update their position separately when you will scroll the screen.

Oh yea I've planned to do that already. I just wasn't sure what "a background engine based on 16×16 pixels metatiles" was, other than a separate array of 16x16 meta tiles? I think that might be overkill for what I need though.

sverx wrote

So you might want a column-major raw exporter from BMP2Tile :)

I attach here one I just wrote... as you can see from its source it's very simple.

So when you need a new column, you just use SMS_loadTileMapColumn pointing to the right location in the map.

Oh I see! I haven't looked at scrolling yet, I thought that this kind of function might already exist, but thanks for doing this! I'll start coding soon once inital designing is done.

armixer24 wrote

For the pickups graphics against backgrounds, I suppose you could also create the "background + pickup" tile at load time ?

That's a good idea. I think I'll combine the BG tile and the pickups but I'll probably do it manually for now. If I need to optimise it later then I could do this, thanks!

badcomputer wrote

Oh yea I've planned to do that already. I just wasn't sure what "a background engine based on 16×16 pixels metatiles" was, other than a separate array of 16x16 meta tiles? I think that might be overkill for what I need though.

Definitely don't use metatiles if you don't have to.

Using 16x16 metatiles instead of the standard 8x8 tiles leads to a big economy in term of ROM size.

A standard tilemap uses two bytes to define one tile (number, palette, flipping etc...)

If you use a 16x16 metatile, you can use a single byte referencing a dictionary. This is already a x2 gain. And of course, you also need less tiles to cover the same area, adding a x4 gain. So with 16x16 metatile maps you gain x8 times the size. You simple have to manage dictionary of your metatiles, it will take a bit of ROM but not a lot really.

One thing that will be simpler with the base 8x8 tiles is your streaming when scrolling : you will only have to stream one column and be good with it.

If you are using 16x16 metatiles, you do not have room to fit an entire column. So you have to stream the left column, then the right column. And then move on with the next tile. This adds to the calculations you have to do.

Now that I think about it, a very convenient way to gain memory while retaining the ability to stream one column at a time, would be to use metatiles that are actually 8x192 (or 8x176 if you use the first 2 lines for the hud). So an entire column. This would work very well in a game that only scrolls right/left. You could also use smaller chunks for more flexibility, like 8x32 for example. I will keep this in mind for the future lol.

Hey!

A Wizard Platformer in work here, almost similar (very similar screen layout, with indicators on top, and horizontal scrolling only, too) xD

Nice graphics, dude, I see you use a line interrupt to fix the first four lines. It is not an easy thing. I was testing the interrupt functionality about three-four days until I had it working without corruption.

Have a nice time developing it!

cireza wrote

One thing that will be simpler with the base 8x8 tiles is your streaming when scrolling : you will only have to stream one column and be good with it.

I think this alone is enough to keep the 8x8 tiles! I'm all for making the development process easier.

eruiz00 wrote

A Wizard Platformer in work here, almost similar (very similar screen layout, with indicators on top, and horizontal scrolling only, too) xD

Nice graphics, dude, I see you use a line interrupt to fix the first four lines. It is not an easy thing. I was testing the interrupt functionality about three-four days until I had it working without corruption.

Oh cool! I haven't see it, do you have a thread for it?

I haven't starting coding yet, so I expect that to be difficult then!

Anyway, here's a more clean mockup. I redesigned the HUD to fit more of the initial game mechanics design but still need to test it properly. I redesigned the main tiles too to allow quick map making and development, so for different tilesets I only need a few different tiles.

mockup-02.png (9.56 KB)

badcomputer wrote

I redesigned the HUD to fit more of the initial game mechanics design but still need to test it properly.

Nice. If your HUD stays at 16 pixels height, you can set the horizontal scroll lock bit in the VDP register and don’t have to worry about line interrupts at all.

Kagesan wrote

badcomputer wrote

I redesigned the HUD to fit more of the initial game mechanics design but still need to test it properly.

Nice. If your HUD stays at 16 pixels height, you can set the horizontal scroll lock bit in the VDP register and don’t have to worry about line interrupts at all.

Not to mention that it's a way more efficient use of the screen space, which means more space for the actual game area. And, as Kagesan said, it uses the hardware features of the SMS' VDP, so you can save the line interrupt for other effects.

With SMSlib, to lock the topmost two tiles row so that the horizontal scroll doesn't affect them you simply call:

SMS_VDPturnOnFeature(VDPFEATURE_LOCKHSCROLL);

also, since you'll be using the horizontal scrolling, you also have to hide the leftmost column so you might even issue a single call:

SMS_VDPturnOnFeature(VDPFEATURE_LOCKHSCROLL|VDPFEATURE_LEFTCOLBLANK);

Sega used a margin on left and right side of the screen. To compensate for CRT overscan.
And if you look at the title screen of Sonic 1, you can see it is not centered but quite far to the left. So apparently they assumed more of the right is cut off due to overscan than the left.

Your screenshot is 248x192, so 8 pixels have already been shaved of on the left side + the 8 pixels margin that you added. That is 16 pixels margin on the left. But there is only 8 pixel margin on the right.

Long story short, maybe you want more margin on the right for your status bar :).

On the other hand, i think the chance is very small that anyone will have a problem with this nowadays. It is not a problem on LCD tvs. And I assume anyone who uses a CRT today, will have tweaked the geometry so there is little overscan.

The left 16 and right 8 pixels are at risk of being cut off, except on really old TVs with massive overscan/curved tubes. The remaining 232 pixels are pretty well centred in my experience.

Why was the Sonic title "centered" to the left, if there is less crop at the right?

It’s a good question :) I have no idea why, maybe it was a mistake. See the attached image chosen at random from the internet - it’s not centred on the CRT either.

The second photo shows an in-game scene which is the right 248px (left column blanked), with a clear border area (sky blue border in the stage 2 cave section) which helps you see how it’s nearly centred (and not cut off at all on this screen).

IMG_0231.jpeg (496.03 KB)

IMG_0232.jpeg (22.46 KB)

Castle of illusion has 16 pixels margin on both sides. Even more if you count the white border of the hud.
This picture is 248x192 so 8 pixels are already cut of on the left.

Thanks for the advice everyone.

Yes, I reduced the HUD height to 16 as it seemed to be convention, obviously seems much easier to deal with scrolling.

For the width I'll leave it at 248 as it seems to be the popular choice too.

Some more polishing to the design. I decided to do the pickups with a white box like this as it solves two problems - no need for different backgrounds for each stage, and it differentiates them from the player/enemies.

mockup-03.png (10.36 KB)

badcomputer wrote

For the width I'll leave it at 248 as it seems to be the popular choice too.

That's the only resolution we have actually, but the suggestion of not putting anything important on the leftmost and rightmost tiles on screen remains.

As I can tell from your mockup-03, you're already doing that so there will be no problem :)

How should the below function be working?

SMS_loadTileMapColumn(1, 2, stage_tilemap_01_bin, 22);

I'm using it as above. It's loading 22 vertical tiles on the screen but taking 22 tiles in order (horizontally) from the tilemap. In this case taking the first 22 tiles from the top row and placing them vertically starting from tile 1x2.

I was expecting the function to take a vertical slice of 22 tiles from the beginning of the tilemap and place them vertically?

Edit: I think this post from sverx is the answer, as it seems to store the tilemap column first? But then why does the function/macro SMS_loadTileMapColumn already exist but not load a column as it seems to imply?

Yes, SMS_loadTileMapColumn() expects your source data to point to the data you want to update in a column, not the whole source map.

For instance, if you update a column writing 22 entries in the tilemap in a column, the source data is 44 contiguous bytes, because each entry is two bytes.

That's why you either have to prepare that data in RAM beforehand when your level map is organized in a row-major arrangement or when your level map uses metatiles... or you could have your map data in ROM provided it's already arranged in a column-major arrangement and you load one column at a time.

So to load the initial image you actually have to issue SMS_loadTileMapColumn() 32 times, but you of course do that before turning the screen on, in the preparation phase.

sverx wrote

That's why you either have to prepare that data in RAM beforehand when your level map is organized in a row-major arrangement or when your level map uses metatiles... or you could have your map data in ROM provided it's already arranged in a column-major arrangement and you load one column at a time.

Ah, that makes sense. Thank you, sverx (again)!

After some head scratching the tilemap scrolling and collisions are working now.

I'm now thinking about using 16x16 meta tiles and store the map in RAM, as I will want to modify the map quite a lot.

scroll-coll-test-export.gif (869.55 KB)

A couple of thoughts on what to do next.

- Meta tiles
At the moment I'm planning to store regular 8x8 tile maps in ROM and at runtime generate a 16x16 meta tile array that I can manipulate and use during gameplay.

I haven't found anything else to use to create meta tiles but appreciate any pointers if there's something out there or examples.

- Map making
In my last game I only had one main map and some small pieces, but this game will have several wide (e.g. 2048x176) maps.

I know how to create tiles and maps in bmp2tile but how would I create additional maps that use the same tileset?

I've used Tiled a lot in the past and I know I could write an exporter for that in Python (does that already exist?) but I also found an old post from 2016 recommending to use Mappy and the GBA converter to C array. Just not sure what is the common way to do this for SMS.

badcomputer wrote

I know how to create tiles and maps in bmp2tile but how would I create additional maps that use the same tileset?

A workaround could be to put all your maps in the same PNG and export the tiles and the tilemap, then cut & paste the tilemap file into separate files for each map.

Regarding metatiles, AFAIK each one solved the problem his own way so far. Unfortunately there's no custom SMS-targetted tool available as of today.

I'm used to Tiled and writing Python exporters, but that's far from being the only option as you've read already.

badcomputer wrote

I'm now thinking about using 16x16 meta tiles and store the map in RAM, as I will want to modify the map quite a lot.

Oh, I had missed this message. Yes, that's the way to go, especially if you need to pickup items/powerups 'baked' in the BG or you want destructible blocks etc...

sverx wrote

badcomputer wrote

I know how to create tiles and maps in bmp2tile but how would I create additional maps that use the same tileset?

A workaround could be to put all your maps in the same PNG and export the tiles and the tilemap, then cut & paste the tilemap file into separate files for each map.

Thanks sverx. That's a good idea.

Thinking about this further I think what I'll try first is have a set of global tiles that appear on most maps I can regularly load with the HUD etc, and a small unique tileset for each map, that way even if there's reptition in tilesets it won't be much.

If I find it's too much then I can go with the cutting up of one large tilemap file into separate maps.

If you use a map editor then it might want to define the tile set, which you then convert as-is with BMP2Tile. Trying to base your maps on PNGs as the source file is appealing but ultimately means you have a hard time ensure the pixels match, splitting the data up, and defining the metadata. This is partly why BMP2Tile has never tried to become a level map editor.

Basically once you switch to metatiles and a map editor (such as Tiled) then you likely won't have your level maps addressing VRAM tiles directly, but they will use your metatiles instead, which brings a few advantages but at least one complication: it will no longer be straightforward to load a new BG column when scrolling left or right.

It feels a bit overkill for this game, although I definitely see the convenience of Tiled. I currently use Aseprite which is a dedicated pixel art app but it has palettes, tilesets and tilemap layers, it's perfect for simple maps.

It was a headache getting the scrolling and collision working nicely too, so I don't want to mess with that anymore if I can help it!

Well I gave in and implemented 16x16 meta tiles which allowed me to start making maps in Tiled and modify tiles during the game easier. This is just a test of changing tiles.

I hope this was the most difficult part!

wizard-beta-export.gif (2.28 MB)

Added some player stuff and basic mechanics.

I want to try and move the tiles around so the player can get crushed if they move under a tile, but I'll probably add enemies first to see how it performs.

wizard-beta02-export.gif (1.18 MB)

Another small update. I spent some time on the player jump and decided to store the velocity frames for jumping and falling to create a nice smooth arc.

The gif is only 30FPS so doesnt show it as well but it feels good now. Will only tweak it small amounts from now.

wizard-beta03.gif (82.34 KB)

definitely looking promising! keep us posted please :)

Work continues, today I added palette cycling management. Here I added a lightning effect and a fire torch on the wall with palette cycling.

This background is starting to feel done so will be doing enemy and player spells next I think.

wizard-beta05.gif (510.04 KB)

badcomputer wrote

Work continues, today I added palette cycling management. Here I added a lightning effect and a fire torch on the wall with palette cycling.

This background is starting to feel done so will be doing enemy and player spells next I think.

It means that you are reserving colors for the cycle. For the flame, you could also update the tile(s) in memory instead, this would free the color(s) you have reserved for the flame animation. Of course this is slower though.

cireza wrote

badcomputer wrote

Work continues, today I added palette cycling management. Here I added a lightning effect and a fire torch on the wall with palette cycling.

This background is starting to feel done so will be doing enemy and player spells next I think.

It means that you are reserving colors for the cycle. For the flame, you could also update the tile(s) in memory instead, this would free the color(s) you have reserved for the flame animation. Of course this is slower though.

I don't need anymore colours on this stage, that's why I made the colour cycling animations last. Also as you say, this way I don't have to change the tiles.

The backgrounds will be muted/desaturated and need less colours, so I'm planning to reserve 1-2 background palette colours for cycling on each stage. Almost everything else will use the sprite palette (HUD, collectables, projectiles, player, enemies, etc).

I should be coding but I started work on a new stage tileset instead. Here's a spooky forest mockup.

It's a lot easier to design graphics now that I know what the specifications of the stages and gameplay are.

forest-mockup01.png (15.48 KB)

badcomputer wrote

I should be coding but I started work on a new stage tileset instead. Here's a spooky forest mockup.

It's a lot easier to design graphics now that I know what the specifications of the stages and gameplay are.

Wow, gorgeous graphics! Keep it up!

badnest wrote

Wow, gorgeous graphics! Keep it up!

Thanks, I'll try!

Small update today, enemy spawning/culling is now working and things still feeling smooth with many basic enemies.

Next I may start adding map transitions.

wizard-beta06-export.gif (1.43 MB)

badcomputer wrote

badnest wrote

Wow, gorgeous graphics! Keep it up!

Thanks, I'll try!

Small update today, enemy spawning/culling is now working and things still feeling smooth with many basic enemies.

Next I may start adding map transitions.

Wow, this and the forest looks awesome, you're doing an incredible job with the colors.

Thanks!

Work continues, here's a mockup for a potential underground stage and colour cycling waterfalls.

mockup-underground-waterfalls-01.gif (31.32 KB)

Really nice mockup! I like the colours and the contrast :)

Been following this on Twitter, looks ace!

Thanks guys!

Work continues. I've integrated the forest tileset into stage loading and it's opened up a few more "todo" items, but I've been able to test it.

wizard-beta07-export.gif (1.42 MB)

Author	Message
badcomputer Joined: 19 Oct 2023 Posts: 140	[WIP] Wizard Platformer Posted: Sat Nov 04, 2023 9:27 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	As Blast Arena is now almost complete, just awaiting music and release for playtesting, I've started planning a new game. This one will be slightly bigger in scope and with horizontal scrolling (no vertical). I hope to post progress and any questions here (hopefully not as many this time). This will be more work but without a lot of the learning and setup of the previous one it won't be too bad. Here's an initial mockup, this is mainly to test colours and requirements. I've decided to go for 16x16 for the player, which is considered small compared to other games, but I'm planning for the stages to be compact and have a lot of obstacles and platforms, unlike say Wonder Boy III. I'll also have to do something else with the pickups shown here, as they will be tiles so will need to blend into any background tilemap better than they do here. mockup-01.png (8.52 KB)

Kagesan Joined: 01 Feb 2014 Posts: 878	Posted: Sun Nov 05, 2023 7:02 am
Kagesan Joined: 01 Feb 2014 Posts: 878	Looks very nice. Will the pickups have to work on different backgrounds? I see no reason why you can’t just continue the brick pattern behind them like you did with the spikes. You’d have to create different pickup graphics for each tileset, but I don’t really see that as a problem. Of course you could also implement them as sprites if there aren’t too many of them.

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Sun Nov 05, 2023 8:52 am
badcomputer Joined: 19 Oct 2023 Posts: 140	Kagesan wrote Looks very nice. Will the pickups have to work on different backgrounds? I see no reason why you can’t just continue the brick pattern behind them like you did with the spikes. You’d have to create different pickup graphics for each tileset, but I don’t really see that as a problem. Of course you could also implement them as sprites if there aren’t too many of them. Sprites might be an issue. I'm planning to use the lower half of tiles for sprites so want to keep those empty, and I think the play area will be too crowded to use sprites. Backgrounds behind each one would be OK, but I'd have to align them to the brickwork (or whatever the background was). I tried to put a decorative 16x16 box around each one but I don't think it looks as good. It would be easiest if I can load the powerups separately to each BG tileset. One thing still to try is draw a large treasure chest which covers 3x3 tiles and then create the pickup within that.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Sun Nov 05, 2023 2:18 pm
	are you planning of creating a background engine based on 16×16 pixels metatiles or will you just use a tile based one? I was toying with the latter idea these days, and to write a simple column-major exporter for BMP2Tile is a 5 minute work for me, and it would easily work with SMSlib's SMS_loadTileMapColumn...

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Sun Nov 05, 2023 3:02 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	sverx wrote are you planning of creating a background engine based on 16×16 pixels metatiles or will you just use a tile based one? I was toying with the latter idea these days, and to write a simple column-major exporter for BMP2Tile is a 5 minute work for me, and it would easily work with SMSlib's SMS_loadTileMapColumn... I was planning to just use tile based one for things like tile collisions etc. The maps will be made up of mostly 16x16px meta tiles but I don't see a need to create anything special for it. Speed or space won't be an issue as the maps will be quite simple. Unless there's some other advantage I'm missing?

cireza Joined: 27 Feb 2023 Posts: 136 Location: France	Posted: Sun Nov 05, 2023 3:31 pm
cireza Joined: 27 Feb 2023 Posts: 136 Location: France	For any object that does not move around, I think that using the BG layer is a must. Otherwise you will very quickly fill in the 8 sprites available on a single line. You will also not have to update their position separately when you will scroll the screen.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Sun Nov 05, 2023 3:56 pm
	So you might want a column-major raw exporter from BMP2Tile :) I attach here one I just wrote... as you can see from its source it's very simple. So when you need a new column, you just use SMS_loadTileMapColumn pointing to the right location in the map. gfxcomp_column_major_raw.dll.zip (66.23 KB) BMP2Tile export plugin for column-major tilemaps gfxcomp_column_major_raw.c (942 B) source file (C)

armixer24 Joined: 12 Aug 2021 Posts: 74	Posted: Sun Nov 05, 2023 5:07 pm
armixer24 Joined: 12 Aug 2021 Posts: 74	For the pickups graphics against backgrounds, I suppose you could also create the "background + pickup" tile at load time ? You'd need to format your graphics for the pickup to have a "transparent colour". Then you would be essentially creating a new tile by first copying the "background" and then copying the pixels of the "pickup" that are not a transparent colour into this, and you have essentially a programmatically created tile ! The disadvantage is that you would be limited to the same palette you're using for the background. Does that make sense ?

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Sun Nov 05, 2023 5:56 pm Last edited by badcomputer on Sun Nov 05, 2023 6:01 pm; edited 1 time in total
badcomputer Joined: 19 Oct 2023 Posts: 140	cireza wrote For any object that does not move around, I think that using the BG layer is a must. Otherwise you will very quickly fill in the 8 sprites available on a single line. You will also not have to update their position separately when you will scroll the screen. Oh yea I've planned to do that already. I just wasn't sure what "a background engine based on 16×16 pixels metatiles" was, other than a separate array of 16x16 meta tiles? I think that might be overkill for what I need though.

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Sun Nov 05, 2023 5:57 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	sverx wrote So you might want a column-major raw exporter from BMP2Tile :) I attach here one I just wrote... as you can see from its source it's very simple. So when you need a new column, you just use SMS_loadTileMapColumn pointing to the right location in the map. Oh I see! I haven't looked at scrolling yet, I thought that this kind of function might already exist, but thanks for doing this! I'll start coding soon once inital designing is done.

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Sun Nov 05, 2023 6:00 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	armixer24 wrote For the pickups graphics against backgrounds, I suppose you could also create the "background + pickup" tile at load time ? That's a good idea. I think I'll combine the BG tile and the pickups but I'll probably do it manually for now. If I need to optimise it later then I could do this, thanks!

cireza Joined: 27 Feb 2023 Posts: 136 Location: France	Posted: Sun Nov 05, 2023 8:54 pm
cireza Joined: 27 Feb 2023 Posts: 136 Location: France	badcomputer wrote Oh yea I've planned to do that already. I just wasn't sure what "a background engine based on 16×16 pixels metatiles" was, other than a separate array of 16x16 meta tiles? I think that might be overkill for what I need though. Definitely don't use metatiles if you don't have to. Using 16x16 metatiles instead of the standard 8x8 tiles leads to a big economy in term of ROM size. A standard tilemap uses two bytes to define one tile (number, palette, flipping etc...) If you use a 16x16 metatile, you can use a single byte referencing a dictionary. This is already a x2 gain. And of course, you also need less tiles to cover the same area, adding a x4 gain. So with 16x16 metatile maps you gain x8 times the size. You simple have to manage dictionary of your metatiles, it will take a bit of ROM but not a lot really. One thing that will be simpler with the base 8x8 tiles is your streaming when scrolling : you will only have to stream one column and be good with it. If you are using 16x16 metatiles, you do not have room to fit an entire column. So you have to stream the left column, then the right column. And then move on with the next tile. This adds to the calculations you have to do. Now that I think about it, a very convenient way to gain memory while retaining the ability to stream one column at a time, would be to use metatiles that are actually 8x192 (or 8x176 if you use the first 2 lines for the hud). So an entire column. This would work very well in a game that only scrolls right/left. You could also use smaller chunks for more flexibility, like 8x32 for example. I will keep this in mind for the future lol.

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	A wizard platformer? Posted: Sun Nov 05, 2023 9:23 pm
	Hey! A Wizard Platformer in work here, almost similar (very similar screen layout, with indicators on top, and horizontal scrolling only, too) xD Nice graphics, dude, I see you use a line interrupt to fix the first four lines. It is not an easy thing. I was testing the interrupt functionality about three-four days until I had it working without corruption. Have a nice time developing it!

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Sun Nov 05, 2023 9:59 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	cireza wrote One thing that will be simpler with the base 8x8 tiles is your streaming when scrolling : you will only have to stream one column and be good with it. I think this alone is enough to keep the 8x8 tiles! I'm all for making the development process easier. eruiz00 wrote A Wizard Platformer in work here, almost similar (very similar screen layout, with indicators on top, and horizontal scrolling only, too) xD Nice graphics, dude, I see you use a line interrupt to fix the first four lines. It is not an easy thing. I was testing the interrupt functionality about three-four days until I had it working without corruption. Oh cool! I haven't see it, do you have a thread for it? I haven't starting coding yet, so I expect that to be difficult then! Anyway, here's a more clean mockup. I redesigned the HUD to fit more of the initial game mechanics design but still need to test it properly. I redesigned the main tiles too to allow quick map making and development, so for different tilesets I only need a few different tiles. mockup-02.png (9.56 KB)

Kagesan Joined: 01 Feb 2014 Posts: 878	Posted: Mon Nov 06, 2023 7:34 am
Kagesan Joined: 01 Feb 2014 Posts: 878	badcomputer wrote I redesigned the HUD to fit more of the initial game mechanics design but still need to test it properly. Nice. If your HUD stays at 16 pixels height, you can set the horizontal scroll lock bit in the VDP register and don’t have to worry about line interrupts at all.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Nov 06, 2023 10:12 am
	Kagesan wrote badcomputer wrote I redesigned the HUD to fit more of the initial game mechanics design but still need to test it properly. Nice. If your HUD stays at 16 pixels height, you can set the horizontal scroll lock bit in the VDP register and don’t have to worry about line interrupts at all. Not to mention that it's a way more efficient use of the screen space, which means more space for the actual game area. And, as Kagesan said, it uses the hardware features of the SMS' VDP, so you can save the line interrupt for other effects. With SMSlib, to lock the topmost two tiles row so that the horizontal scroll doesn't affect them you simply call: SMS_VDPturnOnFeature(VDPFEATURE_LOCKHSCROLL); also, since you'll be using the horizontal scrolling, you also have to hide the leftmost column so you might even issue a single call: SMS_VDPturnOnFeature(VDPFEATURE_LOCKHSCROLL\|VDPFEATURE_LEFTCOLBLANK);

slogra Joined: 09 Jun 2014 Posts: 378	Posted: Mon Nov 06, 2023 10:54 am
slogra Joined: 09 Jun 2014 Posts: 378	Sega used a margin on left and right side of the screen. To compensate for CRT overscan. And if you look at the title screen of Sonic 1, you can see it is not centered but quite far to the left. So apparently they assumed more of the right is cut off due to overscan than the left. Your screenshot is 248x192, so 8 pixels have already been shaved of on the left side + the 8 pixels margin that you added. That is 16 pixels margin on the left. But there is only 8 pixel margin on the right. Long story short, maybe you want more margin on the right for your status bar :). On the other hand, i think the chance is very small that anyone will have a problem with this nowadays. It is not a problem on LCD tvs. And I assume anyone who uses a CRT today, will have tweaked the geometry so there is little overscan.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Mon Nov 06, 2023 11:04 am
	The left 16 and right 8 pixels are at risk of being cut off, except on really old TVs with massive overscan/curved tubes. The remaining 232 pixels are pretty well centred in my experience.

slogra Joined: 09 Jun 2014 Posts: 378	Posted: Mon Nov 06, 2023 11:21 am
slogra Joined: 09 Jun 2014 Posts: 378	Why was the Sonic title "centered" to the left, if there is less crop at the right?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Mon Nov 06, 2023 11:31 am
	It’s a good question :) I have no idea why, maybe it was a mistake. See the attached image chosen at random from the internet - it’s not centred on the CRT either. The second photo shows an in-game scene which is the right 248px (left column blanked), with a clear border area (sky blue border in the stage 2 cave section) which helps you see how it’s nearly centred (and not cut off at all on this screen). IMG_0231.jpeg (496.03 KB) IMG_0232.jpeg (22.46 KB)

slogra Joined: 09 Jun 2014 Posts: 378	Posted: Mon Nov 06, 2023 11:44 am
slogra Joined: 09 Jun 2014 Posts: 378	Castle of illusion has 16 pixels margin on both sides. Even more if you count the white border of the hud. This picture is 248x192 so 8 pixels are already cut of on the left.

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Mon Nov 06, 2023 12:50 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	Thanks for the advice everyone. Yes, I reduced the HUD height to 16 as it seemed to be convention, obviously seems much easier to deal with scrolling. For the width I'll leave it at 248 as it seems to be the popular choice too.

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Mon Nov 06, 2023 1:00 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	Some more polishing to the design. I decided to do the pickups with a white box like this as it solves two problems - no need for different backgrounds for each stage, and it differentiates them from the player/enemies. mockup-03.png (10.36 KB)

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Nov 06, 2023 2:33 pm
	badcomputer wrote For the width I'll leave it at 248 as it seems to be the popular choice too. That's the only resolution we have actually, but the suggestion of not putting anything important on the leftmost and rightmost tiles on screen remains. As I can tell from your mockup-03, you're already doing that so there will be no problem :)

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Mon Nov 06, 2023 10:17 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	How should the below function be working? SMS_loadTileMapColumn(1, 2, stage_tilemap_01_bin, 22); I'm using it as above. It's loading 22 vertical tiles on the screen but taking 22 tiles in order (horizontally) from the tilemap. In this case taking the first 22 tiles from the top row and placing them vertically starting from tile 1x2. I was expecting the function to take a vertical slice of 22 tiles from the beginning of the tilemap and place them vertically? Edit: I think this post from sverx is the answer, as it seems to store the tilemap column first? But then why does the function/macro SMS_loadTileMapColumn already exist but not load a column as it seems to imply?

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Tue Nov 07, 2023 7:54 am
	Yes, SMS_loadTileMapColumn() expects your source data to point to the data you want to update in a column, not the whole source map. For instance, if you update a column writing 22 entries in the tilemap in a column, the source data is 44 contiguous bytes, because each entry is two bytes. That's why you either have to prepare that data in RAM beforehand when your level map is organized in a row-major arrangement or when your level map uses metatiles... or you could have your map data in ROM provided it's already arranged in a column-major arrangement and you load one column at a time. So to load the initial image you actually have to issue SMS_loadTileMapColumn() 32 times, but you of course do that before turning the screen on, in the preparation phase.

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Tue Nov 07, 2023 9:29 am
badcomputer Joined: 19 Oct 2023 Posts: 140	sverx wrote That's why you either have to prepare that data in RAM beforehand when your level map is organized in a row-major arrangement or when your level map uses metatiles... or you could have your map data in ROM provided it's already arranged in a column-major arrangement and you load one column at a time. Ah, that makes sense. Thank you, sverx (again)!

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Wed Nov 08, 2023 6:05 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	After some head scratching the tilemap scrolling and collisions are working now. I'm now thinking about using 16x16 meta tiles and store the map in RAM, as I will want to modify the map quite a lot. scroll-coll-test-export.gif (869.55 KB)

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Wed Nov 08, 2023 11:16 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	A couple of thoughts on what to do next. - Meta tiles At the moment I'm planning to store regular 8x8 tile maps in ROM and at runtime generate a 16x16 meta tile array that I can manipulate and use during gameplay. I haven't found anything else to use to create meta tiles but appreciate any pointers if there's something out there or examples. - Map making In my last game I only had one main map and some small pieces, but this game will have several wide (e.g. 2048x176) maps. I know how to create tiles and maps in bmp2tile but how would I create additional maps that use the same tileset? I've used Tiled a lot in the past and I know I could write an exporter for that in Python (does that already exist?) but I also found an old post from 2016 recommending to use Mappy and the GBA converter to C array. Just not sure what is the common way to do this for SMS.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Thu Nov 09, 2023 8:14 am
	badcomputer wrote I know how to create tiles and maps in bmp2tile but how would I create additional maps that use the same tileset? A workaround could be to put all your maps in the same PNG and export the tiles and the tilemap, then cut & paste the tilemap file into separate files for each map. Regarding metatiles, AFAIK each one solved the problem his own way so far. Unfortunately there's no custom SMS-targetted tool available as of today. I'm used to Tiled and writing Python exporters, but that's far from being the only option as you've read already.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Thu Nov 09, 2023 8:18 am
	badcomputer wrote I'm now thinking about using 16x16 meta tiles and store the map in RAM, as I will want to modify the map quite a lot. Oh, I had missed this message. Yes, that's the way to go, especially if you need to pickup items/powerups 'baked' in the BG or you want destructible blocks etc...

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Thu Nov 09, 2023 12:47 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	sverx wrote badcomputer wrote I know how to create tiles and maps in bmp2tile but how would I create additional maps that use the same tileset? A workaround could be to put all your maps in the same PNG and export the tiles and the tilemap, then cut & paste the tilemap file into separate files for each map. Thanks sverx. That's a good idea. Thinking about this further I think what I'll try first is have a set of global tiles that appear on most maps I can regularly load with the HUD etc, and a small unique tileset for each map, that way even if there's reptition in tilesets it won't be much. If I find it's too much then I can go with the cutting up of one large tilemap file into separate maps.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Thu Nov 09, 2023 1:25 pm
	If you use a map editor then it might want to define the tile set, which you then convert as-is with BMP2Tile. Trying to base your maps on PNGs as the source file is appealing but ultimately means you have a hard time ensure the pixels match, splitting the data up, and defining the metadata. This is partly why BMP2Tile has never tried to become a level map editor.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Fri Nov 10, 2023 3:40 pm
	Basically once you switch to metatiles and a map editor (such as Tiled) then you likely won't have your level maps addressing VRAM tiles directly, but they will use your metatiles instead, which brings a few advantages but at least one complication: it will no longer be straightforward to load a new BG column when scrolling left or right.

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Fri Nov 10, 2023 5:50 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	It feels a bit overkill for this game, although I definitely see the convenience of Tiled. I currently use Aseprite which is a dedicated pixel art app but it has palettes, tilesets and tilemap layers, it's perfect for simple maps. It was a headache getting the scrolling and collision working nicely too, so I don't want to mess with that anymore if I can help it!

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Sat Nov 18, 2023 1:26 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	Well I gave in and implemented 16x16 meta tiles which allowed me to start making maps in Tiled and modify tiles during the game easier. This is just a test of changing tiles. I hope this was the most difficult part! wizard-beta-export.gif (2.28 MB)

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Sun Nov 19, 2023 12:43 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	Added some player stuff and basic mechanics. I want to try and move the tiles around so the player can get crushed if they move under a tile, but I'll probably add enemies first to see how it performs. wizard-beta02-export.gif (1.18 MB)

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Sun Nov 19, 2023 12:58 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	Another small update. I spent some time on the player jump and decided to store the velocity frames for jumping and falling to create a nice smooth arc. The gif is only 30FPS so doesnt show it as well but it feels good now. Will only tweak it small amounts from now. wizard-beta03.gif (82.34 KB)

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Sun Nov 19, 2023 3:11 pm
	definitely looking promising! keep us posted please :)

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Tue Nov 21, 2023 6:59 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	Work continues, today I added palette cycling management. Here I added a lightning effect and a fire torch on the wall with palette cycling. This background is starting to feel done so will be doing enemy and player spells next I think. wizard-beta05.gif (510.04 KB)

cireza Joined: 27 Feb 2023 Posts: 136 Location: France	Posted: Tue Nov 21, 2023 8:29 pm
cireza Joined: 27 Feb 2023 Posts: 136 Location: France	badcomputer wrote Work continues, today I added palette cycling management. Here I added a lightning effect and a fire torch on the wall with palette cycling. This background is starting to feel done so will be doing enemy and player spells next I think. It means that you are reserving colors for the cycle. For the flame, you could also update the tile(s) in memory instead, this would free the color(s) you have reserved for the flame animation. Of course this is slower though.

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Tue Nov 21, 2023 10:18 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	cireza wrote badcomputer wrote Work continues, today I added palette cycling management. Here I added a lightning effect and a fire torch on the wall with palette cycling. This background is starting to feel done so will be doing enemy and player spells next I think. It means that you are reserving colors for the cycle. For the flame, you could also update the tile(s) in memory instead, this would free the color(s) you have reserved for the flame animation. Of course this is slower though. I don't need anymore colours on this stage, that's why I made the colour cycling animations last. Also as you say, this way I don't have to change the tiles. The backgrounds will be muted/desaturated and need less colours, so I'm planning to reserve 1-2 background palette colours for cycling on each stage. Almost everything else will use the sprite palette (HUD, collectables, projectiles, player, enemies, etc).

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Thu Nov 23, 2023 1:03 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	I should be coding but I started work on a new stage tileset instead. Here's a spooky forest mockup. It's a lot easier to design graphics now that I know what the specifications of the stages and gameplay are. forest-mockup01.png (15.48 KB)

badnest Joined: 26 Aug 2022 Posts: 21	Posted: Fri Nov 24, 2023 2:29 pm
badnest Joined: 26 Aug 2022 Posts: 21	badcomputer wrote I should be coding but I started work on a new stage tileset instead. Here's a spooky forest mockup. It's a lot easier to design graphics now that I know what the specifications of the stages and gameplay are. Wow, gorgeous graphics! Keep it up!

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Sat Nov 25, 2023 4:40 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	badnest wrote Wow, gorgeous graphics! Keep it up! Thanks, I'll try! Small update today, enemy spawning/culling is now working and things still feeling smooth with many basic enemies. Next I may start adding map transitions. wizard-beta06-export.gif (1.43 MB)

Chewrafa Joined: 28 Sep 2023 Posts: 9 Location: Castelló, Spain	Posted: Sat Nov 25, 2023 9:01 pm
	badcomputer wrote badnest wrote Wow, gorgeous graphics! Keep it up! Thanks, I'll try! Small update today, enemy spawning/culling is now working and things still feeling smooth with many basic enemies. Next I may start adding map transitions. Wow, this and the forest looks awesome, you're doing an incredible job with the colors.

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Mon Nov 27, 2023 12:04 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	Thanks! Work continues, here's a mockup for a potential underground stage and colour cycling waterfalls. mockup-underground-waterfalls-01.gif (31.32 KB)

armixer24 Joined: 12 Aug 2021 Posts: 74	Posted: Mon Nov 27, 2023 5:26 pm
armixer24 Joined: 12 Aug 2021 Posts: 74	Really nice mockup! I like the colours and the contrast :)

8BitBoy Joined: 15 Aug 2019 Posts: 262 Location: Lancashire UK	Posted: Tue Nov 28, 2023 1:10 pm
	Been following this on Twitter, looks ace!

badcomputer Joined: 19 Oct 2023 Posts: 140	Posted: Wed Nov 29, 2023 7:14 pm
badcomputer Joined: 19 Oct 2023 Posts: 140	Thanks guys! Work continues. I've integrated the forest tileset into stage loading and it's opened up a few more "todo" items, but I've been able to test it. wizard-beta07-export.gif (1.42 MB)

Forums

View topic - [WIP] Wizard Platformer