search

megamarc / Tilengine

Free 2D graphics engine with raster effects for retro/classic style game development
https://www.tilengine.org
Mozilla Public License 2.0
847 stars 95 forks source link

Removed Code #80

Closed turric4n closed 3 years ago

turric4n commented 3 years ago

Hi Marc,

I began to improve my Pascal headers (again). So I managed to compile the library with latest version of VS2019 and latest libpng and zlib dependancies (I suggest you to add zlib dependancies into MS linker).

I see you removed a lot of library functions from Tilengine.h in your latest commits

So, my questions are :

Why you did this? These changes broke current bindings.

How to recover these functions? If somebody is still using these.

I put some delete functions here :

TLN _DisableAnimation TLN_SetTilemapnimation TLN_CopyTile TLN_SetTileSetAnimation TLN_SetTilesetAnimation TLN_DrawNextScanline

See ya.

megamarc commented 3 years ago

Hi Turrican!

Release 2.8.0 introduced a new animation engine, more capable and easy to use. These removed functions are part of the old one.

Yes, these kind of issues are tricky to handle. I always try to keep backwards compatibility, but sometimes in order to improve the API some things must be broken. I'm aware of the two games being developed using Tilengine, when something breaks I notify them about the changes. The modified/remove functions weren't actually used so that wasn't a big deal. In this state I prioritize improving the engine and keeping the API streamlined and clean at expenses of breaking something from time to time, instead of having it cluttered by dragging old and non-optimal functionality.

However this affects bindings that are usually out of my control. Due to its nature, bindings break even if changed/removed functions aren't ever used. Maybe a good practice would be to keep the entry points (function names) of removed functionality with an empty body instead of totally removing them, and issue a warning to the standard output alerting that the called function is not implemented. That at least wouldn't break ABI compatibility.

What do you think?

turric4n commented 3 years ago

Hi Marc,

Thanks for your fast and great answer as always!

I see, that changes you did have encouraged me to continue improving Pascal bindings. Maybe I will make another branch called old bindings or something and put the old code there. Btw I don't know if it's a good idea to have empty entry points in the headers file... maybe it could confuse more than help.

So, you make it clear, I'm with you. It's better to have improved code than old one. API changes are common in this world and bindings should be adapted to them.

From here I will continue the development of Pascal bindings and improve C# bindings also.

And last but not least, I want to appreciate your work!

Thanks for all Marc!

megamarc commented 3 years ago

Hi!

Thanks to you for your interest on this project, and your will to improve the Pascal bindings. I'm glad you agree with this point of view. I know that libraries used in production environments by third parties must be very careful not to break anything, backwards compatibility is mandatory and for good reason. However I think Tilengine is not in this situation, and we should afford to break something from time to time in order to make a better product in the future. Anyway I always try to make breaking changes as minimal as possible.

Are you planning on writing some small demo or game prototype using Pascal bindings?

turric4n commented 3 years ago

Sorry I didn't see your latest comment :D

Of course Marc,

Basically I'm doing it for fun as I don't code much in Pascal currently. But some friends of mine asked me to made Pascal bindings and I did so.

I ported some of your samples to Object Pascal, for example Thunder Force 4 to OOP approach. Results are quite fine.