Rocks'n'Diamonds

Sorry again for my bad skills at English language, I just wanted to offer you something what breaks the logic of game. And also it will be extremely hard to do this in this game, I think...

• 1. Two-layered sprites

Sometimes we just want to see how player walks really 'inside' the element, not just under element without any masking for it. Maybe this is possible by adding new option "Walkable/Passable > Inside EX" in CE configuration 1 and one more sprite as a second layer (Main sprite hides the player, secondary is being hidden by him). That means that player will be between these layers, "inside" the element.

• 2. Oversized elements

Sometimes I just look at the same games with same gameplay and same point and see how some game elements are bigger than another ones. For example, Cave Chaos series (by Spam&Cheese) uses invincibility shields which are twice bigger than the player and Co. Is this possible to use this in Rocks'n'diamonds? Maybe, by scaling it? Just like this: But I have no idea about order of them. But I want show you my of course fake screenshot how could it look like: Yeah, sounds almost impossible but the chance is over 0...

This would really be a cool thing to have available. It could be made by massively extending the new global animations (to be able to control them by game elements).

Another possible option would be to add support for such animations directly in the game graphics engine. It could then indeed work like you described (using something like a ".scale" option). Currently such things are not possible, as the game's playfield is not completely redrawn for each new video frame (but only changes are made to individual tiles). As this slows down performance a lot (because all main drawings have to be done by the CPU in system memory instead of the GPU), a fundamental change of the playfield drawing system would be required, to be able to redraw the playfield each frame, which would make it possible to use such oversized tiles.

The two-layered sprites are also an interesting idea, and could then be done by enhancing the existing "walkable inside" to support "upper" and "lower" graphics layers.

Considering the fact that now the game got sprite tinting, there can be quite a few cases where you'd need to have a sprite have a part of it be color 1 and other a color 2, or maybe one part a color 1 and other without color tinting... In other words, I feel like we have another reason to have an option to build our elements out of several sprites stacked together to make up a more versatile sprite coloring.
A simple example: during the process of making player resprite, as an addition I just have a separate set of sprites for fully whitewashed player clothing as first set and his face, hands and shoes as another set, which, when combined together will have player wearing fully white.





Now if we just combine them together and tint both at the same time... Yeah, that won't look right, Rockford gets transported to hell and has to pay for his sins.




His face and hands should not be affected and therefore the second layer should be a separate sprite to keep it without color affection:




So I hope you get my idea, I think that could be slightly expanded to have both the "walking inside" expansion and the customizable coloration that only paints some specific parts of sprite without affecting other spots. Or maybe we could have a making system that determines which parts should be colorable, but that may be more complicated to use.

In fact, we have several quite different techniques (AKA feature requests) described in this thread. Some of them are:

1. Game graphics that have a different (in most cases: larger) size than the size defined as ".tile_size".

This is currently not supported in any way, but at least some effects could partially already be done using global animations that are controlled by game elements. I have attached an example (which is more focussed on alpha blending, but also shows some uses of game element controlled global animations in the second included level).

2. Color templates.

This is a new feature supported since version 4.0.0.0 which can not only be used for Boulder Dash style graphics (for which it was added in fact), but for all R'n'D game graphics. I have attached an example that shows coloring of sand and grass, where the color can be defined individually for each level in the level editor, on the "colors" tab on the "CONF" page.

Unfortunately, this new feature was never really explained anywhere so far, and I still have to describe how this works exactly in a forum post. In short: There are seven colors which can be defined for each level individually in the level editor, and which are used to replace the following colors in your PNG files:

- RGB value (x, 0, 0) / red
- RGB value (x, x, 0) / yellow
- RGB value (0, x, 0) / green
- RGB value (0, x, x) / cyan
- RGB value (0, 0, x) / blue
- RGB value (x, 0, x) / purple
- RGB value (x, x, x) / white

For example, RGB values of (255, 255, 0), (200, 200, 0) and (50, 50, 0) will be replaced with the defined color for "yellow", while pixels with color (255, 255, 1), (200, 201, 0) or (49, 49, 1) will be left untouched.

To use this, just set "sand.color_template: true" to use this for the "sand" game element (or any other game element for which you have custom graphics defined).

This can be used to achieve exactly the effect you described with player graphics (where the face always uses the same static colors, while the clothing uses dynamically defined colors for each different level).

While the original BD graphics only use "pure" colors to be replaced with custom colors (like RGB(255,255,0) or RGB(0,255,0)), R'n'D also supports color ranges like described above, so you can use many shades of the defined color in your graphics (making them look Amiga-style instead of C64-style).

I hope do be able to write a decent description / documentation for this nice new feature some time...

Please let me know if it works for you, and if you have any further questions.

Holger wrote: ↑Sun Mar 23, 2025 10:58 am 1. Game graphics that have a different (in most cases: larger) size than the size defined as ".tile_size".

Yeah, we already figured we can do custom animations with global anims with alpha and stuff, just not exactly the ones that follow around player or react to anything unrelated to CEs. For now I don't see a lot of personal use in these (not saying that I won't try to use them, though)

Holger wrote: ↑Sun Mar 23, 2025 10:58 am 2. Color templates.

Yeah, I guess that makes sense, although it's such a strange way of implementation, but honestly better than nothing.
Here's me trying to figure it out until I realized that I the color gradient's first color better be just purely black. One thing I realized, though, is that I can technically now have background of any color without any kind of weird workarounds and shenanigans, although I'm not sure if that will work with MM engine, gonna try that some time later.

Yeah, I guess that makes sense, although it's such a strange way of implementation, but honestly better than nothing.

I'm sure that it's strange!

In fact, I just used what GDash used to implement (a limited number of) level specific colors, extending it just a little bit to (a) allow for seven instead of only five colors and to (b) allow for color gradients instead of just one single color.

The resulting implementation is (as you correctly named it) quite a bit weird (for today's graphics manipulation habits), has quite some limitations (number of colors that can be defined), but seems to work more or less OK to add some variety to level colors.

This is a very new feature that is not really used anywhere (besides in the BD cave collection, in its even more limited variant, as described). So please let me know if you have any thoughts or ideas how to improve this, for example, to use more colors, to add flexibility, to make it easier to create image files to be used for level specific colors. This could include new directives for the "graphicsinfo.conf" (GIC) files, or changed ways to define the colors to be used in a given level. Just let me know of anything that you could thing of that might be useful from your point of view. And don't be afraid of me doing any kind of "reality check" for such thoughts and ideas! I always try to find a highly generic solution that does not solve a fixed, limited problem, but that can be used in many different ways, if possible.

But I am quickly trapped in a solution that seems to work, not easily able to see that there might be better, more flexible or more generic solutions that are superior to what I have developed so far.

One thing I realized, though, is that I can technically now have background of any color without any kind of weird workarounds and shenanigans, although I'm not sure if that will work with MM engine, gonna try that some time later.

Is using a background color really a feature of the new color templates? Without having done any tests yet, I thought that this works independently from color template enabled graphics...

Well, you can see in the levelset I sent that the third level has it's own background color. I just added "empty_space.template_color: true" (although from what I see, template_color, much like tile_size, seems to affect the entire texture, which means all sprites in RocksSP will be colorable as well).

Also checked how it works with MM engine... weeeelll... Not really good unfortunately... Since beams are leaving black traces + empty spaces in mini tiles aren't affected by coloration, it starts to look like complete mess EDIT: Funny enough, this trick I have mentioned two years ago also works well with colorations so one of problems is fixed. The mini tiles, though... Since mini-tile empty space isn't using any kind of "actual texture", I can't really make it use color template to begin with.

EDIT2: One more thing that I forgot to mention that's obviously an unintentional behavior is that once I added the line "global.border.color_template: true", the game denies the levelset completely, crashing before even fully loading.

TheOnyxGuy wrote: ↑Sun Mar 23, 2025 7:35 pm Well, you can see in the levelset I sent that the third level has it's own background color. I just added "empty_space.template_color: true" (although from what I see, template_color, much like tile_size, seems to affect the entire texture, which means all sprites in RocksSP will be colorable as well).

Also checked how it works with MM engine... weeeelll... Not really good unfortunately... Since beams are leaving black traces + empty spaces in mini tiles aren't affected by coloration, it starts to look like complete mess
eksdhjgd.png

EDIT: Funny enough, this trick I have mentioned two years ago also works well with colorations so one of problems is fixed. The mini tiles, though... Since mini-tile empty space isn't using any kind of "actual texture", I can't really make it use color template to begin with.

EDIT2: One more thing that I forgot to mention that's obviously an unintentional behavior is that once I added the line "global.border.color_template: true", the game denies the levelset completely, crashing before even fully loading.

amazing C64 style

amirnatsheh7 wrote: ↑Sun Jul 13, 2025 7:02 am amazing C64 style

That wasn't really an imitation of C64 style, at least originally. It was just a perfect template for color template testing because of the colors used (#FF0000, #FFFF00, FF00FF and etc). Here's that levelset, by the way.