Multiple Gamepad inputs? And a couple more buttons?

[Domarius]

First! In the whole forum, I think!

I'm super keen on this simplistic input system - where the only inputs are 4 directions and 4 action buttons, automatically mapped to the keyboard keys or a gamepad.

But I'm heavily into couch-multiplayer, where you have multiple controllers under the one TV / Computer and play co-op or vs games.

The current system looks like it's set up for 1 player.  While I realise I could find another input library, I'm a fan of this simplistic approach, and was wondering if you have plans to implement multiple "controllers"?

I imagine you could just forgo having default keyboard mappings for player 2, 3 and 4 and just rely on the gamepads, since no one expects to play a 2+ player game on the same keyboard.

Also I agree 4 action buttons (A,B,C,D) would cover most kinds of games, but it might be cool to have a 6 or 8 button limit instead, when I think of games that effectively use the shoulder buttons, like Star Fox, Mario Kart, Stunt Race FX, and a lot of the newer indie games on Steam.  It would be good to have at least 6, just to cover those kinds of games. I think at a bare minimum you want 4 face buttons and 2 shoulder buttons. Oh and a Start button to pause the game. So maybe 8 is better.

[megamarc]

Hi!,

You're right, the user input mechanism is very simplistic. Straightforward, but very limited. Originally I designed tilengine to be just a back-end renderer without any kind of windowing or user input, this part was meant to be implemented on top of it -it's a graphics engine, not a game engine-. This makes tilengine very versatile because it can be integrated into any existing or custom-built game framework, but soon I realized that it could be too demanding to do quick tests and evaluate it. So I built a basic windowing system to help in quick setups, but it's not really meant to be used in production systems.

I've thought seriously about extending it a bit: adding multiple players and some more buttons, but without putting too much effort on it. Anybody interested in advanced features like keyboard/gamepad remapping and so, should consider discarding the built-in windowing and go for some game framework that already has this functionality and integrate tilengine on it.

Finally, the source code is available and can be enhanced by anyone willing to do it:
https://github.com/megamarc/Tilengine/bl...b/Window.c

[Domarius]

Ah, if the windowing and input is just for testing, that changes everything! I'll keep that in mind.  Actually it would be good if they were marked as such in the documentation, that way I don't assume I should use them as an essential part of your system, and instead MUST choose something else.

On that note, can you suggest a combination of libraries that you'd put together to make a cross platform game using Tilengine?

So;

• Windowing
  
• Gamepad input
  
• Sound... (BTW I really like MOD/Tracker music files, keeps the file size down and keeps with the retro theme )
  

(Also BTW I'm the same guy who posted on the Facebook page recently.)

[megamarc]

I know that tilengine lacks in the documentation department, right now it's a big project with support for several programming languages and I have to figure out how to handle this...

Your best bet for "companion libraries" is the SDL ecosystem (SDL + SDL_Mixer): they're open source, cross-platform and give everything you need to build a game, including tracked music (I'm a longtime fan of MODs, since the early 90s ). Lots of commercial games are built on top of it, and the default windowing in tilengine uses it too, so its source code can be already used as a starting point:

https://www.libsdl.org/
https://www.libsdl.org/projects/SDL_mixer/

So are you Clint Hobson in facebook / youtube?

[Domarius]

Oh yeah that was me gushing over the YouTube videos as well, hahah. Yeah I've been doing this Alex Kidd "de-make" in Pico-8 and the restrictions are cool, and cute... (and I'll be uploading it soon) but for my next de-makes I just want a little bit more breathing room for resources while still keeping the low res, so I can have bigger levels, more sprites, and more code. That's the moment when I had the inspiration to google "2D retro game engine" and yours was the first result! Actually I kinda feel lucky, judging by your Facebook post it looks like I found this just as you put the Facebook page and Forum online, and it looks like I'm the first - I imagine this place will be crawling with registered users in a year from now.

SDL, perfect - I've been using SDL2 already for an arcade front end I'm making I can't resist - I technically can't afford the time to do this just yet, but I'm going to set up a test project of Tilengine and play with it soon...

[megamarc]

I hope to see your work soon! I tried to make tilengine easy to work with. Which one of the supported languages are you planning to use? C, C# or Python? The pascal and java bindings are outdated right now, I don't recommend them.

I released the first public version about two years ago, and the facebook page at the same time. However these forums are just one week old right now, you arrived just in time :-)

[Domarius]

Welp, if I'm using SDL2 I assume I'll be using C++. I remember trying to use the C# wrapper for SDL (to start the aforementioned arcade front end interface) but couldn't get it working... I figured it was time to brush up on C++ anyway, as I'd been working with C# for a while, on a Unity project.

I like that your API is in plain and simple C

Yeah I don't see a reason to program a game in Python or Java unless that's all you know... and even then I wonder why, it's not that much of a jump between any of C++, C#, or Java, if you know one of them it's not much work to learn about the others.

[megamarc]

I like python for its simplicity and direct approach: with very little setup you can get results quickly. That's why I'm doing much of the engine samples in python, because it's the least intrusive language. It reminds me of the BASIC in the 8-bit home computer era :-) And it's "de facto" standard in the Raspberry community, where I have a special interest due to its educational value.

For larger projects I prefer C#, its static typing and highly assisted code editors make it very productive and quite error-safe. What a pity you encountered trouble with the SDL bindings.

I don't use C++ at all, in fact I don't like it. For low level systems programming -like tilengine- I use the good old C: fast, efficient, portable, but with all its quirks (buffer overflows, dangling pointers, weak types...). For complex, high level end-user applications I use C#. But C++ sits between them, in the land of nobody, offering the worst of both without any clear advantage. But that's just my opinion...

Java lies in the same abstraction layer than C#, but its much more rigid and verbose. C# is cross-platform too, so I don't see a real reason to choose Java, at least for desktop application development. I wrote the Java binding just for the Android port because it's the main language there. But the Android/Java duo support is a bit in the dust for now, not being maintained.

[Domarius]

I completely agree with your assessment on the comparison between C, C++ and C#.  Honestly I felt I should brush up on C++ in case a job requires it, but after my arcade interface project, I won't be touching it again if I can help it.  I've always thought it was probably a stupid decision for this particular project... the thing is meant to be left running for long periods of time and C# would be safer for that... maybe I'll be re-writing it in C# in the future...

Well the truth is I haven't tried Python, but I have been developing in Pico-8 and it uses LUA which I've heard is similar, and I can totally appreciate that.  I'll have to give Python a go then.  Perhaps it's good for prototyping? I will check out the provided examples...

And yeah I have read about Java not being popular for game programming. I haven't used it since University myself.  Though I know there are some good engines made for it, like libgdx, which one of my favourite games "Delver" is made using, which is why I looked into it.  But ultimately steered away from it.

[megamarc]

I haven't tried LUA, but I think it's in the same abstraction level than python. Yes, I strongly recommend python for prototyping: dynamic typing, no source clutter with superfluous container classes, clean syntax, execute directly from source code (no separate compile/run steps as in C, C# or Java)... The tilengine python wrapper is fully object-oriented and has all the docstrings, so any smart python editor will assist you with auto-completion and inline help as you type.

In the main website there is a very basic sample in C and its equivalent in python, side by side, so you can check what I mean.