New Adventuron Feature: Graphic Compositing

Adventuron now supports programmable graphic compositing (allow different layers of graphics to be made visible or invisible based on game state).

This feature could be used to build custom context sensitive maps, graphics that adapt to location manipulation, and more.

Previously Adventuron would allow games to switch location graphics for different graphics depending on the state of the game, but it was only really useful for locations with a very small set of state changes.

Where there exists a graphic that may have multiple changeable elements on the screen, switching graphics wholesale was not a viable solution. With this approach, for every Boolean element you require 1 additional graphic (e.g. a location with 5 changeable elements would require 1 + 5 graphics = 6 graphics). Previously, it would have required a location graphic for every combination of elements (2 to the power 5 = 32 graphics). It is also much much much easier to code now.

This feature is only available in the “betabeta” release for now, and should be treated as experimental for now.

Regards,

Chris

8 Likes

Is it JS code or something you’ve compiled yourself?

1 Like

Adventuron is a framework that (usually) runs in JavaScript. The code syntax itself is not JavaScript, but the runtime is.

1 Like

Your own code syntax eh? Would it be easy to learn?

Your own code syntax eh? Would it be easy to learn?

I think that’s down to the individual to decide.

Tutorial is here if you want to investigate:

2 Likes

This is really cool. You could even make a visual novel-esque game with this. :slight_smile:

My only concern with it is the command name: blit. I know what blit means because I used to do game programming in C back when the allegro library was popular. But I don’t think most people have heard of that word, and it seems a bit at odds with the rest of the library’s vernacular. It’d make it difficult for new users to search for, I think.

Interestingly, the in-development version of the command was “overlay”. Maybe it’s better to revert back to that.

2 Likes

I prefer that. I know that from coding too, but I think others may be able to make the connection to “layers” better than with blit.

But this is just my opinion, of course. Do whatever you think is best. :slight_smile:

1 Like

I tend to agree with @tayruh. To me, blit is related to bit block transfers, as used in animation. ‘Layer’ or ‘overlay’ sounds more descriptive of what it does. Check with the guys on Telegram and see what they think, as they’re the ones that are using it (or about to use it) at the moment.

1 Like

This is how I know blit: https://www.allegro.cc/manual/4/api/blitting-and-sprites/blit

It basically copies a portion of an image buffer and pastes it onto another image buffer (that buffer can also be the screen).

Wikipedia describes it as this:

Bit blit (also written BITBLT, BIT BLT, BitBLT, Bit BLT, Bit Blt etc., which stands for bit block transfer) is a data operation commonly used in computer graphics in which several bitmaps are combined into one using a boolean function.

So it does accurately describe what’s happening. I was just concerned that the average user wouldn’t be familiar with that term. You’d have to do graphic programming in order to be familiar with it, which is probably not something most people writing text adventures do.