Something about backgrounds

Got a cool idea that should be in R'n'D? Let's hear it!

Moderators: Flumminator, Zomis

User avatar
Eizzoux
Posts: 567
Joined: Wed Oct 30, 2013 5:32 am
Location: Russia
Contact:

Something about backgrounds

Post by Eizzoux »

As you all know, we can set backgrounds for many of the game screens, like background.MAIN, background.SETUP, background.INFO[ELEMENTS], background.titlescreen_1 and etc.
The feature is, of course, pretty neat, but there's one little problem at least I personally kinda can't get over with: we can set the file for the background, but we can't exactly use specific .x and .y position and the dimensions of it in the file. In other words, you can only assign separate files for each background, unlike, weirdly, background.PANEL, background.TAPE, background.TOOLBOX and background.PALETTE. Why can't we use specific part of image for background like with (almost) everything else? And, by the way, sorta same thing is relevant for "global.border" and, if I remember correctly, titlescreen_X and titlescreen_initial_X, even though the border one is probably that important in that case, I'm not sure.
π’ˆŸ
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Something about backgrounds

Post by Holger »

Absolutely reasonable request.

Especially the predefined settings for "background.TOOLBOX" etc. suggest that it can be generically used with (at least) directives ".x", ".y", ".width" and ".height", which absolutely makes sense. This is even more expected behavior as background images are drawn "tiled" over the whole backgraound area if they are smaller than the background area, so it probably seems quite artificial to be forced to store small tile graphics in single files instead of larger image maps as most other images that come with standard R'n'D.

So, yes, I really should add support for what's definitely expected behavior here.
And, by the way, sorta same thing is relevant for "global.border" and, if I remember correctly, titlescreen_X and titlescreen_initial_X,
For the "titlescreen_X" and "titlescreen_initial_X" directives, specifying x, y, width and height is already supported.
even though the border one is probably that important in that case, I'm not sure.
Did you mean "probably NOT that important" here? Because in fact I think that it's not too important for the (usually window sized) global border graphics, for which it seems to be quite natural to put it into its own image file. But for orthogonality's sake, it also should support x/y/width/height, of course. :)
User avatar
Eizzoux
Posts: 567
Joined: Wed Oct 30, 2013 5:32 am
Location: Russia
Contact:

Re: Something about backgrounds

Post by Eizzoux »

Holger wrote: ↑Mon Jan 30, 2023 11:35 pm For the "titlescreen_X" and "titlescreen_initial_X" directives, specifying x, y, width and height is already supported.
Yeah, true, I forgot I tested that myself, like, years ago.
Holger wrote: ↑Mon Jan 30, 2023 11:35 pm Did you mean "probably NOT that important" here? Because in fact I think that it's not too important for the (usually window sized) global border graphics, for which it seems to be quite natural to put it into its own image file. But for orthogonality's sake, it also should support x/y/width/height, of course. :)
Yeah, I guess I said that just because I'm too used to have border always at [0,0].

Also, just asking, will there also be a possible support for .scale_up_factor and maybe even bg animation as well? And also-also, a weird idea - only horizontal and only vertical scaling. (scale_x_factor and scale_y_factor) Is that possible?
π’ˆŸ
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Something about backgrounds

Post by Holger »

So, yes, I really should add support for what's definitely expected behavior here.
Just added support for parameters ".x", ".y", ".width" and ".height" for all border and background images.
Also, just asking, will there also be a possible support for .scale_up_factor and maybe even bg animation as well? And also-also, a weird idea - only horizontal and only vertical scaling. (scale_x_factor and scale_y_factor) Is that possible?
I thought that all images support using ".scale_up_factor", but apparently some do not. Will check this...

Background animation will not be available any time soon, I think, due to the way R'n'D currently draws its screens and graphics (very oldschool, that is, not completely redrawing the whole screen for every frame, but changing an existing frame buffer).

Independent horizontal and vertical scaling could be useful for displaying old Amiga HiRes formats like 640x256 (which was displayed with stretched pixels, as if it would be 640x512 with pixels that were double as high as wide), but I think it is too exotic to add it to R'n'D (even though it could be used for quite a number of title screens of the EMC collection which have exactly this format, but I think I prefer to correct aspect ratio before using it in R'n'D to be able to correctly view it also outside of R'n'D -- I don't think that PNG supports such weird formats, and the SDL library is notoriously buggy when using ILBM files, which is an old Amiga image format that most people cannot display or edit on their systems nowadays anyway).
User avatar
Eizzoux
Posts: 567
Joined: Wed Oct 30, 2013 5:32 am
Location: Russia
Contact:

Re: Something about backgrounds (not this time)

Post by Eizzoux »

Ok, good.

Also, I've got yet another idea that might be useful mostly for global anims.
Let's say, you want to make a custom animated tiled background for your title screen, but for that you have to rather have a texture which has that big area of bigger size than the game window itself full of same tile cloned across the entire screen. What if you could somehow use just a single small tile and "stack" it game-wise across the screen without without using lots of texture space. And also, maybe, with draw_x/yoffset, you could add space between the stacked segments.
fgh1.png
fgh1.png (7.85 KiB) Viewed 6175 times
fgh2.png
fgh2.png (3.56 KiB) Viewed 6175 times
π’ˆŸ
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Something about backgrounds

Post by Holger »

Let's say, you want to make a custom animated tiled background for your title screen
The idea is quite interesting, and I definitely can see its potential use cases, but for now there are no animated backgrounds for title screens (although you could workaround this by using two global animations on a title screen, one for the animated background, and one for the titlescreen itself).
I thought that all images support using ".scale_up_factor", but apparently some do not. Will check this...
I have found and fixed a bug that could cause graphics with ".scale_up_factor" not being scaled up if there are other graphics definition using the same image file, but not using the ".scale_up_factor" option. In such cases, it depended on the internal numerical position of the graphics definitions if the image was scaled or not, which was bad, of course. Now it works in a way that the image is always scaled up if at least one graphics definition for that image file has this option. Which also means that it is still not possible (just as before) to use the same image file in original and in scaled up size, as it is always either scaled up or not scaled up, but it will not be duplicated to two images with different sizes.
User avatar
Eizzoux
Posts: 567
Joined: Wed Oct 30, 2013 5:32 am
Location: Russia
Contact:

Re: Something about backgrounds

Post by Eizzoux »

Holger wrote: ↑Sun Feb 05, 2023 11:08 am The idea is quite interesting, and I definitely can see its potential use cases, but for now there are no animated backgrounds for title screens (although you could workaround this by using two global animations on a title screen, one for the animated background, and one for the titlescreen itself).
Well, I meant if you would want to make a custom tiled background using global anims. It was kind of my point here. Stackable 32x32 global anim which is being multiplied in quantity by the game instead of just having few frames 640x480 each stacked into one huge image.
π’ˆŸ
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Something about backgrounds

Post by Holger »

Yes, I understand how it would be implemented and used. I just meant that the main problem is that you cannot display global animations behind "normal" screen content, so creating tiled background graphics and/or animations using stacked global animations (as you described them) would only make sense if the foreground is also only made of global animations, because normal title screens or text made of normal fonts would be displayed *behind* all global animations (even those which are meant as background graphics).

It would indeed be cool if global animations could be displayed in the background (with all normal screen graphics in front of them, including those that have alpha-channel transparency), but this would require a complete rework of the antiquated screen redraw system, unfortunately.

Nevertheless, I like the idea of stacked global animations as you described them (and I can see that they would solve the problem with those huge textures in the first version of your "Reflektor" demo), so I will see what I can do about them. :)
User avatar
Eizzoux
Posts: 567
Joined: Wed Oct 30, 2013 5:32 am
Location: Russia
Contact:

Re: Something about backgrounds

Post by Eizzoux »

Not such a big problem if the title screen is global anim by itself anyways. The title screen might be just a small black texture, and everything visible is purely global anims.
Speaking of, while working on global anims for Reflektor, I noticed that ".draw_order" doesn't quite seem to be working for me. And I mean the ones from one screen/multiscreen instance (such as .TOONS).
I was trying just to reorder them in, as example, such a way:

Code: Select all

global.anim_4.TITLE.draw_order: 6
global.anim_5.TITLE.draw_order: 5
And yet it still renders anim 5 over anim 4 as if draw order was never used. Am I forgetting something? I mean, I found a simple workaround which just allows me to render them in needed order if I'm using them in same order as their numerical order (anim_5 over anim_4, anim_2 over anim_1, etc.), but... Wasn't it working before? I honestly forgot already.
π’ˆŸ
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Something about backgrounds

Post by Holger »

Not such a big problem if the title screen is global anim by itself anyways. The title screen might be just a small black texture, and everything visible is purely global anims.
Yeah, this would work indeed! :)
Speaking of, while working on global anims for Reflektor, I noticed that ".draw_order" doesn't quite seem to be working for me.
I've done some tests with this, and I am not able to reproduce this problem. Please have a look at the attached example, which also uses the ".draw_order" option on global animations on a title screen.

Are you able to reproduce the problem with this example level set?
Attachments
test_menu_anim_draw_order.zip
(80.22 KiB) Downloaded 156 times
User avatar
Eizzoux
Posts: 567
Joined: Wed Oct 30, 2013 5:32 am
Location: Russia
Contact:

Re: Something about backgrounds

Post by Eizzoux »

Yeah, it seems to be working for me indeed. Perhaps, I just might be doing it wrong, I'm not sure. Maybe I'll try it again later anyways, thanks.
π’ˆŸ
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Something about backgrounds

Post by Holger »

Nevertheless, I like the idea of stacked global animations as you described them (and I can see that they would solve the problem with those huge textures in the first version of your "Reflektor" demo), so I will see what I can do about them. :)
Implemented as you described it. :-)

From the commit message:

Code: Select all

    added support for stacked global animations
    
    This extension of global animations adds "stacked animations" that are
    created by "stacking" the same global animation multiple times, either
    horizontally, vertically, or both, with additional options to use some
    empty space between two adjacent stacked animations, as follows:
    
    global.anim_X.stacked_xfactor: <x-factor>
    global.anim_X.stacked_yfactor: <y-factor>
    global.anim_X.stacked_xoffset: <x-offset>
    global.anim_X.stacked_yoffset: <y-offset>
    
    This would stack global animation X <x-factor> times horizontally and
    <y-factor> times vertically, while adding empty space between stacked
    animations of <x-offset> pixels horizontally and <y-offset> vertically.
I've changed the option names a little bit, especially the "draw offset" options, to make it more obvious that they belong together here (and because ".draw_offset" is mostly used to shift a complete graphical object relative to a the screen drawing position, but not for using it as an in-between offset; hope that makes sense).

When looking at what you attempted to do in your first game demo, I really think that this is a useful addition! :-)
User avatar
Eizzoux
Posts: 567
Joined: Wed Oct 30, 2013 5:32 am
Location: Russia
Contact:

Re: Something about backgrounds

Post by Eizzoux »

Holger wrote: ↑Wed Feb 08, 2023 10:26 pm When looking at what you attempted to do in your first game demo, I really think that this is a useful addition! :-)
Yeah, the feature will be pretty useful for such repeating patterns, especially considering that using ".scale_up_factor" is not always practical for such ideas, so stacking will be better even in such a way that you can stack a non-solid pattern across the entire screen without stretching it to infinity. And also you can make interesting patterns using several global anims first with no stacking offset as a main background, then second with some offset to scatter 'em around over the "background" of first anim and so on. Speaking of... Is currently stacking working correctly with other global anim features like... clicking, drawing order, (un)masked drawing, drawing class, step-by-step movement? I'm just curious if it won't be a trouble to sort of... correspond with each other correctly? I'm just starting to doubt if the stacking idea will damage other capabilities of anims...
Also, I wonder... Will it damage the game's performance? I'm asking because, ya know, the game will be basically placing hundreds of objects on the screen and, weirdly enough, for last several years it sorta became a thing that game can actually slow down on very high pressure, which, I think, some people notified about before? I don't exactly remember the ways I achieved actual game struggle years ago, but I'll try to find that out in some free time.
π’ˆŸ
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Something about backgrounds

Post by Holger »

Speaking of... Is currently stacking working correctly with other global anim features like... clicking, drawing order, (un)masked drawing, drawing class, step-by-step movement?
The new feature is nearly untested yet, so I cannot say for sure. The implementation is very simple and basic for now, and only replaces drawing the animation once with drawing it multiple times horizontally and vertically, that's all. For example, the code does not check if any of the additional stacked animations was clicked, but only just the first or "original" animation.

At least I added (or fixed) clipping global animations inside the target viewport also for the additional stacked animations (which was not done before, but really is required to make that feature reasonably useful).

Everything else, like drawing order, masking etc. should just work as it does for non-stacked animations. But there may indeed be unexpected limitations in border cases (like the original animation being off-screen, while the stacked animations are visible -- not sure if anything is drawn in such cases).
I'm just starting to doubt if the stacking idea will damage other capabilities of anims...
At least, if you don't use it, it should not have any unexpected side effects, as it currently only affects drawing output.
Also, I wonder... Will it damage the game's performance?
That's a very good and important question, of course, as screen-filling stacked animations like in your example above shouldn't render the game unusable. So one of my first tests was to rebuild a similar "full viewport" stacked animation like in your example, with a 32x32 animation filling the screen, using an animation delay of 2 (therefore being drawn every second frame), and checking how it works. At least for this test, I did not notice any performance problems on my 12 year old Linux PC that does not even have a graphics card (but uses on-board graphics), and CPU usage doubled from about 15 % in the "info screen" menu to 30 % on the "info screen -> title screen" where I used that stacked animation.

That's more or less what I expected, because the whole global animations drawing system uses GPU textures, not bitmaps like all the rest of the antiquated graphics system (like the game engine itself), so drawing speed should be fast GPU operations in this case, while all other drawing is done in slow non-GPU bitmaps.

Update: Full playfield viewport stacked animation with every frame update plus some more stacked animations on top result in about 40 % CPU usage on my old system, with no visible slowdown. So performance of stacked animations shouldn't be too big of an issue on average computers.
User avatar
Eizzoux
Posts: 567
Joined: Wed Oct 30, 2013 5:32 am
Location: Russia
Contact:

Global anim parts

Post by Eizzoux »

Speaking of, while working on global anims for Reflektor, I noticed that ".draw_order" doesn't quite seem to be working for me.
Actually, I just realized why was it problematic for me. I was mixing "anim_X" and "anim_X.part_X" together. "anim_X" seems to have higher priority over "anim_X.part_X", therefore such scenario won't work out:

Code: Select all

global.anim_1.draw_order: 1
global.anim_2.part_1.draw_order: 2
I know it's avoidable if I just add .part_1 to the first animation, so I guess it's just on me.
π’ˆŸ
Post Reply