itch.io

Issue fixed

Hi!

I'll check what's going on in the forums with recovery email, lately it has been giving some troubles.

For the "world scaling" suggestion I guess you're already using "world mode" introduced in release 2.9, right? In theory it should be possible to add this feature to "world mode", but I guess there may be some tricky edge cases when trying to make all elements correctly aligned. But let me check it when I come back, it's an interesting feature to have!

Have a nice holiday time you too!

Hi!

I'm out on holidays trip right now, I'll check the issue next week when I come back.

Thanks for highlighting this one

No, this is a programming library you use to implement realtime 2D retro graphics. You need to be a programmer to use it:

https://en.m.wikipedia.org/wiki/Library_(computing)

This is a programming library that you include in your own programs in order to create retro-style graphics. The installer just copies the library in suitable target folders. Next step is build and run the examples in /samples folder, and then write your own games using it

Hi!

That's right, Tilengine is a graphics-only component. Think of it as a virtual 2D graphics chipset. You have to pair it with other components like sound, physics or netplay. You can use any sound library of your choice, SDL-mixer is a very good option. Tilengine uses SDL2 for windowing, but that doesn't mean you have to pair it with SDL-mixer.

For example my demo project PythonPlatformer uses python tilengine binding and pysdl2 for sound playback:

https://github.com/megamarc/TilenginePythonPlatformer

Hi!

That's just like @exelotl explained. The library only includes the rendering engine. Assets must be authored in standard external tools, and high level gameplay mechanics must be provided by the application layer. Same for sound effects support. That's why it's called a "graphics engine" and not a "game engine".

"Mode 7" in Tilengine works very similar to how it works on a real SNES or GBA. These classic consoles require providing an affine transformation matrix whose coefficients must be computed by the game developer, in order to scale/rotate/skew the background plane. Altering this transformation matrix on each scanline, progressively varying scaling factor, creates the illusion of 3D projection. In Tilengine I eased a bit the process, as you must provide the translation, rotation and scaling factors, and the engine computes the affine matrix for you. But the working principle is the same. So you won't find a pre-made "3D projected mode-7" function, as the original SNES doesn't have it either. It's just a clever trick.

You can setup Tilengine to render to a 32-bit RGBA texture instead to a window, so you can compose its output with other engines. I know it has already been done with Unity without much effort, I don't know about Godot capabilities in this regard.

Hi! Thanks for your positive feedback :-)

However I'm afraid you're wrong about the number of palettes in SNES: According to official Nintendo development books for the SNES, it has 8 palettes of 16 colors each, selected with 3 bits in OBJ (sprite) and BG (background) registers. Here are the documentation pages:

Hi!

What compatibility issues did you find? I always try to keep API/ABI compatibility with older versions as much as possible, however sometimes it's inevitable making some breaking changes to allow the project advance. Let me know what issues did you find so I can take them into account for future releases

Hi!

I've found the cause, now I can proceed to write a fix. Quick fix for now: just open "layer_background.tsx" with Tiled version 0.13 or newer (released on August 2015) and save it without editing anything.

Tilengine relies on a tsx property called "tilecount" to determine how much memory the custom properties array will need. This property was introduced on Tiled 0.13. It seems that I created come of these tilesets long ago with an older version, so this property is missing. The loader doesn't check this value, so it allocates a 0 bytes array that gets filled with random garbage padding (legit arrays are properly zero-filled). This garbage causes that some tiles get priority property randomly set, making them appear in front of the front layer.

Regards,

Hi vonhoff!

I revised your possible fix. I can't see the logic behind it, I'll share my thoughts here:

• block around line 100 is called for every xml attribute found inside the main "tileset" tag. Here the loader is just gathering all the attributes
• block around line 167 is called after the last "tileset" attribute has been issued, but before starting to process the next xml tag. Here the loader has all the xml attributes, so it proceeds to allocate memory for the required structures
• "property" and "tile" xml tags are always found after main "tileset", so the required structures are always found to be already created.

Moving the creation of structures inside the parsing of a single attribute before the whole set of attributes has been gathered would be premature, and potentially dangerous. So I won't do a pull request with a fix until we don't understand why it works.

That said, you're right wit the assumption that nondeterministic (random) behaviour happens with memory management issues, as well as with threading. These two components change their state outside the control of the application, so they can present a different state each time if not properly managed.

I'll do some tests, as the "cliffs" tileset is very prone to exhibit this behaviour.

Thanks a lot for your support!

Hi!

I'm out on holydays for a week without my laptop so I can't check your theory. But I wanted to thank you for your interest on this issue and your help for improving and polishing Tilengine.

I'll check what happens with these missing tiles hiding behind the background layer. Let's keep in touch.

Regards and happy holidays!

Hi!

Glad to know you're enjoying Tilengine so far :-)

I've observed missing random missing tiles in my own "Python Platformer" sister project, that uses the same assets you're using in your test project for the C# binding. However, your screenshots suffer much more from this effect than mine. I don't know the cause because the effect is random, but I'll do a small test in C with these assets, hoping to reproduce the issue and debug into the library (I can't debug from a foreign language binding).

Hi,

TLN_PauseSpriteAnimation() (and companion TLN_ResumeSpriteAnimation()) were introduced in release 2.9.5, but I guess this release wasn't uploaded to itch.io, it's only in GitHub repository. I'll update it and notify you.

Regards,

Hi,

It costs a symbolic donation to support development and hosting fees if you want the prebuilt binaries ready to use. However, you can can clone the full source code from public repository at GitHub and build it yourself, you'll get exactly the same result.

Regards,

Hi ChrKoval

Thanks for trying tilengine and supporting it with a donation :-)

I can't give support specific on Code::Blocks as I don't use this environment so I don't know where are the project options. I assume you're using Windows, usually you have to set-up two items:

* add the folder where "Tilengine.h" to the include search path
* add Tilengine.lib to the list of included libraries.

Code::Blocks uses gcc as the build backend, so the options are always the same no matter what IDE you're using.

Good luck!

querylayer sample is a console application that outputs text information about loaded layers. It doesn't generate any graphic window. To see the output, run it manually from a command-line terminal instead of double-clicking the icon.

Thanks to you for you patience and understanding! Your tests have been very helpful to identify and address issues, and to make a better project. Don't be afraid to contact again if you have suggestions or need more support. The fact is nobody is using resourcepacker library, I use it internally inside my own Tilengine, so I don't have feedback of real usage in the wild.

Hi,

I've uploaded a new release. You must run respack.exe again on your assets, but it should work now. Can you please confirm it?

Quick fix in the meantime: can you recompile the respack executable (from github) using the same toolset as the library? In my case just building them with Visual Studio, the encryption works as expected

Hi,

I've done a quick test, and it seems to be some problem with the decrypter. It works without encryption, but the assets aren't returned when using a key. At this very moment I can't fix it, but I'll push a fix as soon as I have a moment -it shouldn't be difficult-. As I sad, I have now more knowledge about cypher than when I started the project. Sorry about it, and thanks for your understanding!

I see... it seems that static library .a generated with gcc is not recognized by tcc. Building your sample with gcc (32-bit) instead of tcc works fine. I recommend you to clone source project on github (https://github.com/megamarc/ResourcePacker) and adjust its Makefile to build it to your needs. It's a really simple and small project.

Beware that since I released this project, I learned a lot about encryption, so It's possible that I make some changes on the future. Having it on github assures that you'll always get the latest release.

Sorry, it was my fault. I've uploaded a new resourcepacker.zip file that contains the packer executable, and the library with C header. Thanks for your support!

Hi, there's a standard Makefile inside the src/ subdirectory, you must run make from within this folder. It's the same as Linux platform

Hi,

32-bit version won't run due to architecture mismatch. Make sure everything in its path is 32-bit.

Without having your project (source code + assets) I can't guess why it's showing a blank screen. Please attach a download link to your project so I can take a look. You can register for free to the forums, there you can attach files and benefit from the Tilengine community:

http://www.tilengine.org/forum/

Regards,

Hi,

This error is due to mixing 32 and 64 binaries. Make sure that Tilengine.dll and SDL2.dll you put in the same folder than the executable file match the CPU architecture.

gcc in windows can only generate 32-bit binaries, that's why you get the linker errors when trying to link to 64-bit version. There's something called mingw64 that can work 64-bit binaries, but for my daily tasks I use Tiny C Compiler that supports both architectures, has small footprint and mostly a drop-in replacement for gcc:

https://bellard.org/tcc/

Here you can see a screenshoot building test sample:

• tcc builds correctly for both 32-bit and 64-bit bit
• gcc builds correctly for 32-bit but fails for 64-bit

Tilengine itself doesn't require any special hardware. You need SDL2 for the window, but that's an optional component. Going to the metal, your target hardware should provide a 32-bit RGBA framebuffer and video output bus. The Paspberry Pico doesn't have one. There are some high-end microcontrollers with framebuffer and video, but most common configuration is to use a specialized display controller with external RAM and a bus. So, if you ever manage to build an embedded system with such configuration and over 500 MHz CPU clock, you could compile and run Tilengine on it without any OS.

You will need an OS -be it Unix/Linux, Windows or whatever- to run any general-purpose application like an editor or an emulator. You go to the metal in plain C on a microcontroller when you do application-specific firmware tied to a particular hardware design. I'm sorry you don't like the idea of using a general OS to run applications, but it's how things are since the early 70s :-)

Hi,

The platforms you're proposing are too constrained, not for Tilengine itself, but even for the kind of "editors" you want to run on them. They're just microcontrollers with memory in the order of kilobytes -not megabytes-, and don't have display buses. All display kits for these devices are based on slow serial buses, so their screens are really small, mostly character based. So there's no way to use a microcontroller board as a general purpose development platform, they're simply not designed for that.

I would try the Raspberry Pi Zero (https://www.raspberrypi.org/products/raspberry-pi-zero/). It's a humble platform but powerful enough to use it a s a general purpose platform, if you stick to lightweight applications. I use a Raspberry Pi 3 classic (2016) that is more powerful than the Zero, but not much more, and it can run Tilengine samples 420x240 at 60 fps without stressing the CPU.

Hi,

Please tell what OS version are you using (Windows, Linux...) and a step by step sequence of what you're doing to try the samples. Does it give an error or just shows a black screen? Are you executing inside the correct folder so it can find the assets?

Of course, you can head to tilengine forums here:
http://www.tilengine.org/forum/

Dear buyer! Sorry to hear that. I cannot handle refunds myself, it's the itch.io platfrom who manages payments. Yo must contact them here: https://itch.io/docs/legal/terms#refunds and ask them a refund for your wrong buy. When they will contact me to authorize the refund, I'll give them permission to procedd.

Good luck!

Yes, you must provide libpng and zlib and place their headers and binaries in the expected folders (see visual studio project properties). Alternatively, you can download them here already prepared and just drop them inside source project.

Hi!

This is not a bug. You can still download source code from GitHub, setup dependencies and build the binary yourself for free. However, for accessing packaged prebuilt version with required dependencies, a small amount is asked. This was changed some months ago.

Thanks for your interest!

Hi, make sure that lib\Win32\Tilengine.lib is there. It should be, because the zipfile contains it, really.

You're welcome! Glad to know you have it working

Hi,
This reply is one year old. Back then, downloads were subjected to a voluntary donation. But I changed this some months ago, and now prebuilt binaries require a minimum fee of 5€ (not a fortune either), to support the project and at least cover hosting costs.

So you have two options:

1. build yourself from source,
2. kindly donate and get the binaries you expect to work :)

Hi Thorbjørn!

Yes, I've considered it already. However, Travis CI doesn't support building for i686 or ARMv7 architectures (Raspberry Pi), and AppVeyor required to bundle external dependencies (SDL2 and libpng development libraries for Windows) inside the repository, something I don't want to do. I tried to export 64-bit Linux build  on Travis with curl to a ftp server I have, but it failed most of the times, it's a documented limitation it has. So I ended up with a Raspberry PI and VM for linux and OSX, each one with a script that pull sources from GitHub, builds and sends the result to my ftp server. It's really just a couple of minutes.

I've checked Tiled repository and took a look to travis.yml and the deploy scripts to butler. They're a great example to follow in case I want to send at least Linux 64 and OSX builds directly to itch. I didn't know about GitHub actions. At this moment I'm more focued in finishing the main documentation of Tilengine, that's the big hole in my project.

Thanks a lot for your kind help, and congratulations for your Tiled editor! It's an outstanding tool and a key piece in Tilengine functionality.

Release 2.6.0 added support for 24 and 32 bpp png files. However keep in mind that they must have less than 255 unique colors each. Tilengine renderer is designed around 8-bit indexed color images used in pixel art and won't load true color images if they have more than 255 colors.