Tilengine step-by-step?

[Aerosol]

Are there any step-by-step guides on Tilengine using C/C++? I'm aware of the documentation, but it's a bit abstract. I'm also familiar with the samples, but they're not very commentated and I find them a bit hard to follow.

I'm cracking on trying to understand the Shooter sample since it features input and collision detection, but I'm having difficulty. About as far as I've comfortably gotten is understanding the general structure of Shooter.c.

I understand that every element that can interact with anything else is an actor, and Shooter.C is kinda like the maestro bringing everything together.

But more than that I'm a bit lost.

[megamarc]

Hello Aerosol, thanks for your interest.
Documentation is lacking, I admit it. The API reference is complete and up-to-date, but the "by chapter" manual is half finished, there is only one part done.
The "shooter" example you comment on is one of the first I did, but it's too complex to be there, honestly. Tilengine is a graphics library, and the examples should only illustrate in a simple way the different features it offers (which are many). The shooter example implements lists of actors with state machines and other elements that are part of the scope of gameplay mechanics programming, but that really have nothing to do with Tilengine and its purpose. If you want to learn how to do things with Tilengine, I recommend that you park this example for the moment and focus on other simpler ones, such as the background layers, the sprites, and leave the construction of gameplay for later.

[RootBeerKing]

Yes, I wish the documentation(the step by step part) was complete as well, at least the stuff on the Raster effects and Sequences, as those are the two things I'm really lost on as a beginner, lol.

[megamarc]

I totally agree, the documentation should be better. Being the developer of Tilengine, I am the only one who can explain everything that can be done, I cannot delegate this task to someone else. But since I'm a developer and not a technical writer, I'm delaying it. Although I recognize that the lack of complete documentation can put a lot of people back, and it is not good for the project. I should consider it an important task, right?

[RootBeerKing]

I totally agree, the documentation should be better. Being the developer of Tilengine, I am the only one who can explain everything that can be done, I cannot delegate this task to someone else. But since I'm a developer and not a technical writer, I'm delaying it. Although I recognize that the lack of complete documentation can put a lot of people back, and it is not good for the project. I should consider it an important task, right?

If you have the time it would be much appreciated if you could finish the step by step guide. 

Your engine is perfect for 16-bit game developement, and nothing like it really exists or comes close to capturing the core features Tilengine offers; unfortunately the most important features of your engine are the most under documented, which makes the barrier to entry a bit difficult.

 I understand that time is precious and it’s easier said than done, but if it’s something as little as not being a technical writer I would highly encourage you to just bite the bullet and finish writing it to the best of your ability. Even if it isn’t perfect, it would be better than nothing. No pressure though, as again, I understand finding the time to do these things can be tricky.

 But yes, please consider it an important task if you can. Thank you for all the time you’ve put into the engine so far, and thank you for keeping up with the questions on the forum.

Cheers and have a great day!

[Aerosol]

I would definitely consider it a priority task. Faster adoption will make it faster for people to report problems to you and refine Tilengine even more, and adoption is being slowed by the lack of documentation.

[megamarc]

Thanks for your words, I really value the appreciation you show to this project.

As you say, I should bite the bullet and finish it. I understand that I'm loosing adoption oportunities because of lacking documentation. It's a bit nonsense to have a great tool that nobody else can use to its full potential, right? I hope that once I have it completed and with markdown sources publicly available, other people could refine and improve it. It's now a priority task 

Thanks to you for your interest, for continue trying things and experimenting with it!

[Richard Kain]

I might be able to help out a little with this in the near future. I've been working on other projects for a while, and intend to continue working on them. But one of those projects has veered into using some SDL C++, which has gotten me back into some of the same development I did while playing around with Tilengine. I've also been trying to update my websites a bit more frequently, and one of my favourite things to make for my websites is tutorials.

When I recently dove back into to SDL, I discovered that the repositories for SDL 2 on the Raspberry Pi finally got updated to a decent release version. If you want to compile a Tilengine project on any of the Pi platforms, you don't have to download SDL 2 and build it manually any more. Just use the standard "apt get install" for whatever SDL libraries you need, and you're off to the races, full OpenGL support and all. This was always a bit of a hassle when developing with Tilengine and other game-focused libraries on the Raspberry Pi, so it is a big relief.

The one project that I've been meaning to dust off and possibly share is to create an SDL2-powered OpenGL ES 2.0 context with programmable shader support. I got a demo working about a year ago, but getting it to run consistently on the Pi was a huge pain, so I fell off a little. With a simpler and more stable environment, I'll dig it out and try again. After that a few basic tutorials on how to wrap Tilengine structures and procedures in a more OOP-friendly architecture would probably be a good idea.

[RootBeerKing]

 After that a few basic tutorials on how to wrap Tilengine structures and procedures in a more OOP-friendly architecture would probably be a good idea.

As someone who is still learning C/C++/games programming in general, I would absolutely love that if you did.

[Richard Kain]

A big thing to understand for more advanced programming is some of the structural approaches developers have come up with over the years. Basic programming just follows the order of execution in one long line. But this gets excessively long and can lead to spaghetti logic, so different alternatives were invented to allow for different ways of handling code.

Object orientation was one of the first major shifts that shook things up. And an OOP approach to programming allowed for new structural paradigms that became the foundation for a lot of modern structural design.

However, a lot of older, and especially C-focused libraries still adhere to original procedural design. You see this in SDL, in OpenGL, and also in Tilengine. This is partially just because they were originally written in C, and C was never designed to have OOP tools. It eventually got structures, but these were really just the precursors to objects. Thanks to this, most older procedural libraries focus more on functions than on objects.

The disadvantage to this is that it is an older and less user-friendly way of handling bundling code. The advantage to this, and a big part of why it hasn't gone away, is that it DOESN'T IMPOSE a programming methodology on the developer. C functions are so basic and so easy to re-use, that they can be incorporated into almost any project without requiring a particular approach. It is up to the developer how to handle their integration. That means less guidance and less hand-holding, but it also means WAY more flexibility. And it definitely means way better cross-platform support and compatibility. In some of the testing I've done over the past year, I've managed to compile SDL and Tilengine on numerous platforms. The cross-platform support of this older approach is real.