Reflecting on its development

[vonhoff]

Hi Marc,

If you could go back to 2015 when you started working on Tilengine, how do you think your development process would have changed? With your current understanding of software development and the project itself, would you have chosen a different approach to create Tilengine? What do you wish you had known before starting to work on Tilengine?

I would like to express my appreciation for your remarkable work. I respect the passion you have for this project. Thanks

[megamarc]

Hi!

Good question.

I started Tilengine as just a test for myself because there was nothing similar out there, without any intention of releasing it. However as it started to grow and having more unique features, I pushed to release it. It's a lot of work, because along the engine itself, I had to:

• Write proper documentation and examples
  
• Hire web hosting and domain
  
• Create the webpage
  
• Create and manage the forum
  
• Create community sites (itch.io, Patreon, youtube channel... )
  
• Post on related forums
  

There also are the bindings and their examples, because its common to write games on high-level application languages, not directly in C/C++ (but of course they can)

Often all this complementary work keeps me from developing Tilngine itself. I'm a single individual doing this on my free time, that I also share with other activities that require time. Thtat's why from time to time it may seem abandoned, but in fact it never really is. One day I get a suggestion for a new feature, and if I think it fits on the project, then it becomes a challenge that drives me to complete it.

What I hate more of all is writing documentation. I know it is absolutely necessary, but even nowadays it is quite incomplete.
Regarding design choices, in these years I've learnt new technologies of course, but I won't go back and change anything. Being written in good-old C gives these features:

• can be compiled and run on every available 32-bit architecture
  
• can be integrated inside other frameworks
  
• high performance, low requisites
  

I wish I had more deep knowledge of how actual 2D chipsets work and their quirks, back then I had an approximate idea, but not the knowledge I have nowadays. It led to implement basic features on a way that I'm not very happy today, but than I cannot change them for not breaking compatibility. However nothing terribly wrong, just some details I would do different.

Nowadays it's still the only open-source engine of this kind. The only other similar engine I know about is Retro Engine, used to build Sonic Mania and Sonic Origins ports. But it is proprietary, closed-source, so it doesn't count here.

One thing I hadn't anticipated is community involvement. It's a small but enthusiastic community that has contributed so far:

• bindings to many languages
  
• integrations into other frameworks (i.e. Unity)
  
• suggestions for great features I hadn't think about
  
• beta testing and bug reports
  
• video reviews and articles, even on printed media
  
• being adopted as the underlying engine for some (not yet releasd) games
  

This community feedback makes me happy, I really appreciate it. So thanks to you for your kind words of appreciation and for being an active part part of this community!

[vonhoff]

Thanks for replying, it means a lot to me

You mentioned the Retro Engine before, and I looked into it. I found a project on GitHub that's working on taking apart and understanding Retro Engine v4. It seems interesting to explore, I also noticed that Christian Whitehead's website has been down since 2019. It might be cool to compare Retro Engine and Tilengine since both use SDL2 for windowing and input: 
https://github.com/Rubberduckycooly/Soni...ompilation

I understand that writing documentation is a pain, and I don't enjoy it either. These days I use ChatGPT to help me generate draft documentation or content for README's. I usually use it when I have to write lots of function documentation, although I try to keep my code as self-explanatory as possible, so I only write documentation when necessary.

Could you elaborate on the implementation of the basic features you didn't like? I'm very curious to know what changes you would make if backward compatibility wasn't a concern.

[vonhoff]

By the way, where did you learn the most about 2D chipsets? I'm really interested in graphics programming, and I'd love to know more about it

[megamarc]

Hi,

SDL2 provide just the underlying mechanism to use windows and input in a portable manner. But the inner workings of both engines must be quite different. I guess the Retro Engine is much more tied to Sonic gameplay mechanics -only 2D Sonic games have been developed/ported with it- whereas Tilengine use cases are more varied.

Things that I would change in the API? Some ideas:

• Have explicit context on API calls instead of a current/default context, this would ease object oriented bindings
  
• Remove the ambiguous time/frame parameter on draw/update frame.
  
• Windowing functions should have their own naming convention (i.e. TLN_UpdateWindowFrame())
  
• Streamline the setup / config / enable naming mess on some APIs
  

Got the idea. Nothing really wrong, but as C doesn't support function overloading, it's not possible to add or remove parameters to an existing function. You have two choices:

• Add a new function that does the same than the older one but with a new parameter and mark the older as deprecated, leading to API pollution,
  
• Add a new function that juts sets the new parameter, leading to fragmentation (having to call different functions to accomplish a single task)
  

The pain of writing documentation is not for the API reference, but for the pages that explain all the features with examples, screenshots, etc. This is what isn't updated as it should.

I don't know how the sources to Retro Engine have been leaked to GitHub, because it is proprietary, closed source. However it's cool to be able to peek inside, thanks for the link!

I've been gathering info from several sites. The official manuals from Sega and Nintendo for their consoles are one of them:

• https://segaretro.org/index.php?title=Fi...Manual.pdf
  
• https://gamingdoc.org/technical-document...-nintendo/
  

But also external ones with good explanations:

• http://emudev.de/ (good SNES articles)
  
• https://rasterscroll.com/mdgraphics/ (Genesis)
  

[RootBeerKing]

[*]https://rasterscroll.com/mdgraphics/ (Genesis)

Very interesting! Is Tilengine capable of the silhouette effect mentioned on that website? I really like the way the Mega Drive does this, had no idea it was a thing, but it's very inspiring as an artist, lol

https://rasterscroll.com/mdgraphics/grap...ilhouette/

[megamarc]

Hi!
The "shilouette rendering" thing is specific to the Sega Genesis and its way to process priorities. It's not a feature, but a quirk that gets exposed when its priority system is twisted in an inconsistent way. Tilengine doesn't emulate this quirk as it's not a Genesis emulator. But it's always cool to see how developers found defects in hardware and used them in creative ways, taking advantage of their side effects. Clever people!