Solarus Forum

Solarus => Bugs & Feature requests => Topic started by: Satoh on November 23, 2017, 11:49:51 pm

Title: hero:set_size
Post by: Satoh on November 23, 2017, 11:49:51 pm
This one just keeps being a problem every time I have an idea to use solarus for.

LTTP is a sot of odd game in that its the only free movement game I've ever played where the hero actually takes up a full 16x16 collision rectangle.

Every other game I can think of from Chrono Trigger to Seiken Densetsu, to almost every 2D Zelda game has allowed the bounding box to be smaller than a full map tile and also allowed the player's sprite to clip into the wall a little bit.

For example, I know that Link's sprite in both Oracle games and Link's Awakening ( and LADX ) is 16x16, but his collision area is only 8x10, focused at the bottom center of his feet. He doesn't clip into the wall from the bottom, but he has a little room to walk around inside a 1x1 tile (16x16px) box, and a bit of space to gently kiss the walls.

In Minish Cap, Link's bounding box is 11x8 while his sprite is 18x24.

In The Legend of Zelda (NES) Link is 16x16px in sprite size, but his bounding box is only 16x8.

This is a feature that is extremely important to me for both accuracy and game-feel, as well as aesthetics.

I tried adding the set_size function to the hero entity list and recompiling solarus, but with all the library dependencies and compiler quirks, I couldn't get the thing to compile. After 8 hours (no I'm not exaggerating) I gave up.

Could you be so kind as to consider making the player's size alterable. The engine seems to be coded well enough that it shouldn't break anything, since it doesn't cause any problems for other entities.


EDIT:
I notice now that this has been recently discussed partially in another thread.
I'm leaving this here for emphasis and potential discussion of why it would be useful.
Title: Re: hero:set_size
Post by: Christopho on November 24, 2017, 09:42:20 am
There is already an issue for that: https://github.com/solarus-games/solarus/issues/528
It won't be very easy to do it yourself because unfortunately, the size of 16x16 is hardcoded in a lot of places of the source code.
Title: Re: hero:set_size
Post by: santiago_itzcoatl on March 04, 2018, 12:50:24 pm

┬┐does that mean I cannot work with bigger sprites?
Title: Re: hero:set_size
Post by: Diarandor on March 04, 2018, 03:08:07 pm
Sprites do not have a restriction in size. It is the bounding box which has restrictions. I think it is possible to code from scratch in Lua a smaller or bigger hero, but it is complicated and a lot of work. Someone with nice skills in programming could code it. However, it would be simpler to wait until the engine allows it, and work on different things at present.
Title: Re: hero:set_size
Post by: santiago_itzcoatl on March 08, 2018, 01:31:04 am
thank you.
Title: Re: hero:set_size
Post by: MetalZelda on March 18, 2018, 06:18:02 pm
There is a workaround where, you can make a custom entity that define the hero's collision size and make all collision detections through that entity
Title: Re: hero:set_size
Post by: Satoh on April 12, 2018, 02:49:02 am
There is a workaround where, you can make a custom entity that define the hero's collision size and make all collision detections through that entity
That's certainly true, yes, but at that point one would be rewriting a significant part of the engine in lua, which is slower and more prone to logic errors (by way of being self coded rather than a meticulously bugtested project under review of multiple coders and testers)... and considering how much of the engine is already contact based, it would essentially be almost as fast to start without an engine at all.

I had considered (as I'm sure many who have wanted to change the collision size have) rewriting the collisions, but once I realized how many functions would have to also be recoded, I realized it wasn't worth the effort, for my purposes.

If I could figure out how to get my build environment to fully compile (which is my problem to deal with, not a complaint) I would probably look into the C++ side of things to try modifying it that way.
I did look briefly at one point, but as the environment wasn't completing the build, and the code itself seemed to have a lot of places where the collision was a hard coded real value instead of a named constant, variable, or object reference to be altered from a single source, I was never able to really determine what needed changing, or whether said changes would even work.

As I am currently having new ideas for potential zelda-styled games, I may try again in the near future... assuming I can ever get mingw to stop fussing.
I'm still eager to see the feature, but for now I'm just hoping it'll be addressed in the next public release.