Reflecting on its development

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