[Request] Castleboy Port (Castlevania clone on Arduboy)

Join a team / help wanted!
21

@wuuff Hello and any help is good help! Right now, I finished up coloring the sprites. As this is my first team project and first time doing pixel art, I’m sure there will need to be some tweaking and updating after we get the coding ported.

As for the coding, it seems that @jonne and @Pharap have a way to use the arduboy 2 library and a color porting method to put it on the pokitto. This is a very basic overview, because I have no coding or programming experience.

I’m not sure what has been done yet, it is early on. If you have knowledge in scaling and expanding it to the proper pokitto screen size, that would be very appreciated. Even helping with the coding. @jonne and @Pharap What are your thoughts on moving this forward? and how to contribute?

22

Just to clarify I probably won’t be able to contribute much to the coding itself because I’ve got other projects on the go, but I can make suggestions, help to solve problems and explain anything that needs explaining, and hopefully I’ll be able to contribute bits here and there.

As I mentioned briefly in the other thread, that might be a bit difficult because the Arduboy screen is 128x64 and the Pokitto screen is 220 x176.

What could be done though, is to alter the code so it’s ‘aware’ of the larger screen being used and draws the world to fit a 220x176 screen instead of a 128x64 screen.

(Technally that means it’s more than just a simple 1-to-1 port, but then so does adding colour.)

23

Well, at the moment I am travelling (until wednesday) so I can’t do much yet.

But I already took a look at the code and porting it should not be an issue.

I propose we decide first on resolution (110x88 or 128x64 or 220x176) and then make a few mock-ups of the screen.

@TokyoBatman do you think we could ask the origial author to give an idea of how 110x88 should look like?

@pharap color is supported in the “color version” of the Gamebuino routines. The way its done is to store 4 x 1-bit screen buffer and combine that at drawing time. It sounds very inefficient but its actually OK at 110x88 resolution. I don’t remember if I implemented it in the Arduboy version yet but thats 30 min of coding max

24

That doesn’t necessarily sound inefficient.

Are you saying that can be done without modifying the source code of the game though?

Or are you thinking that could be the way to solve adding colour drawing functionality to Arduboy2?

25

@jonne That’s great to hear. If arduboy games can be ported with a fairly easy process (the graphics didn’t take me so long)… The Pokitto will be much more enticing for people that just want it as a gaming device.

Two big differentiating factors of the Pokitto are the screen size and color.

If we could port this to the full screen size in color, it would stand out.

If it’s possible to use a scaler like hq2 to smooth out the blocky look, that would be nice…

I guess we should shoot for full screen, but if there is slow down, tearing, or just looks awful… Try a different approach.

I think once we nail this project, it will be easier to use that knowledge on others more quickly.

26

Yes. That is the whole point. You can use the original 1-bit bitmaps and just setColor to palette index before drawing. Pretty clever eh?

27

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

28

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.

29

@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?

30

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
31

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

32

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%

33

@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
34

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.

35

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
36

I’ve done it. Works pretty well actually.

1 Like
37

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
38

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).

39

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.

40

wich sprites are using masks and whatfor?