Pixel modifications

[Domarius]

What I mean is - maybe a game like Worms, or Lemmings, where the terrain can be eaten away pixels at a time.

Or even a "blood/paint splat" system where colours can build up on a surface over time, but only ever take up as much memory as the final visible product (not an accumulation of particle objects), literally painting onto a surface.

I'm asking because I'm genuinely curious - Tilengine is a system built on tiles and backgrounds and sprites, but I'm wondering how we would go if we attempted to build a Lemmings game (a different sort of retro game) in this engine.  Is it outside the scope?


Perhaps, for the lemmings game, a "pixel bit mask" layer can be applied at the raster phase to eat away the background - one bit per pixel, if it's off, don't render that pixel of the background. And collisions need to take this bit mask into consideration.

Maybe a similar system for the colour layering, but each bit represents whether to draw the paint colour there or not.
Or a more expensive version which has RGB values for each pixel in the mask.

[megamarc]

I don't remember that original lemmings had this kind of environment modification. Worms had it, but it was based on a different kind of engine with full bitmaps, not tile based. You can read a great article about this topic here:
http://higherorderfun.com/blog/2012/05/2...atformers/

[Domarius]

Yeah that was the whole point of Lemmings It works the same as Worms. You can explode / dig / build in pixel amounts. And yes I know the article - it's quite good, but only briefly mentions bitmasking and is more of a layman's overview than a technical overview.

So of course I would have to create my own level background system using bit masking, but my question is;

Would I still benefit from using Tilengine to draw and animate the sprites and have it draw my level background somehow?

[megamarc]

Tilengine allows you to modify tileset pixel data on the fly at runtime (check TLN_SetTilesetPixels() function). You could work your playfield layer in a single, big bitmap, and slice it in tiles to update the final tileset. It is definitely possible, but tilengine wasn't designed with non-tileset based graphics in mind and it doesn't have much to offer in this field. In short, it is possible, but a bit awkward.

Maybe I should write a small demo for realtime tileset manipulation...

I barely played lemmings, but I spent a lot of time with the original Worms in 1995!

[Domarius]

Tilengine allows you to modify tileset pixel data on the fly at runtime (check TLN_SetTilesetPixels() function). You could work your playfield layer in a single, big bitmap, and slice it in tiles to update the final tileset. It is definitely possible, but tilengine wasn't designed with non-tileset based graphics in mind and it doesn't have much to offer in this field. In short, it is possible, but a bit awkward.

Maybe I should write a small demo for realtime tileset manipulation...

I barely played lemmings, but I spent a lot of time with the original Worms in 1995!

Hey again Megamarc - wow the smiley bug is still there, heheh.

So I have a game idea that I thought may be a good use case for TileEngine but I'll have to do some testing with a few engines including this one.  But before I do I thought I'd get your clarification;

I understand TileEngine won't help me with a bitmap background that allows modifications at the pixel level (like Worms, or Lemmings) but if I go my own way for making this bitmap background, will I still be able to render the game with TileEngine just the same, or will it be more awkward than if I used another engine?  Can I just give TileEngine a bitmap surface that it will render, or must I convert the background into tiles before handing it over to TileEngine for rendering?

The ultimate question is will it be worth using TileEngine if my background is one of these bitmap based backgrounds, will I still get the benefit of using TileEngine to render the sprites and handle the animations, or is it better to just use another engine?

[megamarc]

Hi Domarius!

In its current form, Tilengine is not suitable for bitmap-based backgrounds like worms. You may do it, but in an awkward and non-intuitive manner (just as it would have been in classic 2D systems not designed for this purpose).

BUT: it would be quite easy for me to implement bitmap-based background layers in Tilengine, in addition to current tile-based layers. With this kind of layer, you would have direct pixel access to a simple, large bitmap, with all the features of tilengine: scrolling, scaling, rotation, transparency, palette effects, raster effects... this is somewhat similar to the framebuffers of 8-bit and 16-bit computers, but greatly expanded.

So if you're really interested in developing your bitmap-based game using tilengine, I can release a new version in few days with bitmap layers. Just tell me

[Domarius]

Wow that is amazing that you could do it so quick!

I should make an attempt with Godot first, as I've been led to believe this sort of approach is reasonable with Godot's 2D pixel engine.  I don't want to have you do it if I decide not to go with Tilengine.  Though it would probably be useful to have on the roadmap, as those kinds of games are from that 16-bit time period

[megamarc]

Wow that is amazing that you could do it so quick!

I should make an attempt with Godot first, as I've been led to believe this sort of approach is reasonable with Godot's 2D pixel engine.  I don't want to have you do it if I decide not to go with Tilengine.  Though it would probably be useful to have on the roadmap, as those kinds of games are from that 16-bit time period

Don't worry if you end not using Tilengine! I thought that having full bitmaps was a good idea that could give much value while being easy to implement, so here it is :-)

[Domarius]

Don't worry if you end not using Tilengine! I thought that having full bitmaps was a good idea that could give much value while being easy to implement, so here it is :-)

That is so cool! I am going to have to have a play with this regardless! (When I have a bit more time after I fix my income issue, heheh.  Trying to get a game out.)

I noticed in the commit logs it rejects anything higher than 8 bits per pixel - away with that full colour garbage! We don't like their kind around here, heheh.

I also noticed rejection of non-power of 2 tile sizes. I assume this is all for old school style performance boosts and not just for the sake of it?

[megamarc]

I noticed in the commit logs it rejects anything higher than 8 bits per pixel - away with that full colour garbage! We don't like their kind around here, heheh.

I don't have anything against true-color images, but Tilengine is for "low-color" pixel art without alpha channel. "Low-color" with 8-bit palettes per item is misleading, as the ability to use unlimited 256-color palettes is more than enough considering that all 16-bit systems had a limited number of 16-color palettes. For example the Sega Megadrive had 4 palettes of 16 colors. It's impressive what can be done with a few well chosen and used colors!

I also noticed rejection of non-power of 2 tile sizes.  I assume this is all for old school style performance boosts and not just for the sake of it?

You're right, using power-of-two sizes allows addressing with just cheap shifts and masks instead of more expensive divisions and modulos. And it's easier to implement in hardware, that's why classic systems had this same restriction too.

Good luck finishing your game!