[Request] Castleboy Port (Castlevania clone on Arduboy)

If you are able to specify how it should look in 220x176 resolution graphically, I can take care of the rest

Doesn’t that mean that if you want more than 2 colours you’d need more than one image?

Also it didn’t occur to me before, but with 4 buffers how to you know which colour was drawn most recently?

Do you set the corresponding bit in the other buffers to 0 or do the colours get mixed?

i.e.

setColour(red);
drawSprite(x, y, sprite);
setColour(blue);
drawSprite(x, y, sprite);

Resulting in a purple sprite.

@jonne That’s a good point. Some people are purists and would want the exact aspect ratio. I’m more of the mindset to utilize the hardware and screen size, maybe a 10% stretch will do the trick. With this stretch, we will be looking at 10%thinner and 10%taller. Can you go with 210x140? Correct me if I’m wrong on any of this @Pharap (my math is shaky at best) And center it for a widescreen effect?

210 is more than 10% thinner, it’s ~18% thinner.

The problem with scaling is that there’s an absolute number of pixels. You can’t have 0.2 of a pixel or even 0.5 of a pixel. You can try to be clever with colour to give the illusion of more pixels, but it often looks stretched or blurred.

It’s probably doable, but I wouldn’t want to be the one figuring out which algorithm to use.
It’s bad enough on a full colour screen, but most of the Pokitto’s display modes are paletted/indexed,
which would make it harder to make something that looks nice.


One of the things I was suggesting (which does mean a heavier edit to the code) is to fill more of the screen with the world than the original game.

So basically if the original looked like this:

Then the modified version would show more of the world, something like this:

It can’t be done for every game because it would be game-specific so it would need game-specific edits, but for Castleboy it should work alright.

1 Like

Ahhh my math… Ouch @Pharap. So actually 220 would be better at 14% thinner.

@Pharap, your suggestion of showing more of the world sounds good. How much smaller would things look though? Especially the main character?

If we stretch to 220x140 the characters and sprites will be bigger.

I’m wondering which will look better

My maths ability used to be pretty terrible before I started programming.
Programming and maths overlap a lot so I’ve had to relearn everything I thought I’d never need when I was finished with school.
Ironically I now know more maths than I would have needed to get an A* at school.

Depends on what they’re like currently, e.g. whether the tiles are 16x16 or 8x8.

(sorry I’m only specifying the width here, I got a bit lazy with the calculations.)

On a 128x64 screen, 16x16 tiles means 8 tiles across.
On 220x176 it’s ~13.75 tiles across (13 whole tiles and either 12 pixels of one tile or 6 pixels of two, each tile being ~7.2% of the screen width).

An alternative approach which might work better but is more effort would be to increase the tile size.
If you increased tile size to 24x24 then a 220x176 screen would fit ~9.16 tiles across (9 whole tiles and either 14 pixels of one or 7 pixels of two, each tile being ~10.9% of the screen width).
That would give you both more tiles on screen and a scale closer to the original (12.5% of the screen width).

(I’d put that all into a neat table but markdown tables don’t seem to work here.)


Basically:

Original:
Screen Width: 128
Tile Width: 16
Tiles On Screen: 8
Percent Of Screen Per Tile: 12.5%

More World:
Screen Width: 220
Tile Width: 16
Tiles On Screen: ~13.75
Percent Of Screen Per Tile: ~7.2%

More World & 1.5x Graphics:
Screen Width: 220
Tile Width: 24
Tiles On Screen: ~9.16
Percent Of Screen Per Tile: ~10.9%

@Pharap First off, thanks for the detailed and easy to follow explanation. Being that the Pokitto has a fairly small screen, the 3rd option would probably render the best results.

I’m just not sure how deep we want to get in the rabbit hole. Not knowing coding, how much longer this would take or if it would be shorter. The possibilities of greatness keep growing.

I was hoping this project could be a base for easy conversion of other arduboy games in a timely manner.

That being said. If we could get the algorithm for a stretch of 220x140. Would that be a quicker process than your option 3 for future projects. Trying to think about production line time efficiency.

1 Like

Thank you, I appreciate that.
I try to keep my explanations as accessible as I can.

The easiest way to do that would be to stick to the original resolution and simply draw the buffer’s contents to the centre of the screen.

It would be even easier to not even bother with colour.

It is indeed hard to find a balance between an easy technique and an impressive port. Putting extra effort in to modify the code will always outshine a simple “change libraries, change graphics and recompile” approach.

Personally I think it would be easiest to start simple and expand outwards;
to draw at the original resolution in the centre of the screen, but also add colour (initially starting with @jonne’s suggested technique perhaps).

When that’s been proven, that technique could then apply to other titles, but then when that’s done there’s nothing to stop going further and attempting the world and sprite scaling.

It would, but scaling algorithms are not easy, and most existing algorithms assume full 8 bit per channel colour, while the Pokitto is limited to only being able to do indexed colour for a full frame. Trying to draw the whole screen ends up being too slow (at least as I understand it).

On top of that there’s still the issue of stretching and warping.
The scaling algorithms used for emulators usually scale by a factor of 2 or 4, not 1.5 as we’d ideally need.


Hrm, I have had one crazy thought:

I might be possible to do a x3 upscale and then a x2 downscale (i.e. 1 -> 3 -> 1.5), but I don’t know how the results would pan out, and that would still have the indexing issue.

If so maybe AdvMAME3x would be suitable for the x3 part, or hq3x (though annoyingly the algorithm is described in words instead of code or even maths).

@jonne, does this seem like it would be possible or would it be too intensive for the Pokitto’s processor, or not work well with palette indexing?


Going on a bit of a tangent, the most impressive image scaling algorithm I’ve ever seen is the algorithm presented in this paper.
(It was presented in 2011 at SIGGRAPH which is a big sciency computer graphics conference.)

I’ve never actually read the paper properly (big scientific papers like this usually bore me to tears by the second paragraph), but the diagrams are pretty impressive.

once you start you cant realy stop and just build a new castlevania inspired game realy, we got loads more memory for sprites and we could load levels from sd card so it be more then a handfull of levels
old gamebuino meta post

credit to Drakker
http://legacy.gamebuino.com/forum/viewtopic.php?f=12&t=3682&start=50

1 Like

I’ve done it. Works pretty well actually.

1 Like

This:

In my opinion, tile-based games can usually be easily adapted for higher resolutions. It usually just improves the gameplay because you can see where you are going.

1 Like

Honestly I’m slightly surprised.
Sometimes it’s hard to tell which of my ideas are good, which are crazy and which are both.

Precisely.

I can’t remember where but I’m sure I’ve seen this done with ports of tile-based games before, where increasing the size of the window shows more of the map (or maybe it was just the same game for two different systems and one showed more map).

Yeah, that’s what I was talking about by expanding the viewport.

I took a longer look at the code, and there was a number of drawing functions that will need to be implemented. There’s some sprites with masks that need to be handled as well.

wich sprites are using masks and whatfor?

For transparency.

Yeah, when i was working on Pokit Wars, screen real-estate became a big problem to me. I was using 16x16 sprites where i might’ve been better off with 8x8.

1 Like

have you considered using high res mode?

@jonne and @Pharap It seems like you figured out how to optimize the screen, which is awesome! Can the Pokitto hardware handle filters (hq2x) without slowdown?

Btw, my Pokitto, is being shipped to Japan so I won’t be able to test for a week or so… I’m guessing.

@jonne’s still on the way back to Finland I’m guessing.

I haven’t tried it but according to @jonne (see here) the 3x then /2 idea works.

General filters like hq2x wouldn’t work unedited because they depend on the ability to have full 24-bit colour, but modified versions should work depending on the scaling involved.

@jonne

First, I wanted to say thanks. I got my shipping notice a few days ago. It will be coming to Japan so I’m guessing that’ll be a week at least.

Any chance of getting something testable by then?