Posted By: Alan
Suggestions for improving some lite-c standard functions - 08/24/09 14:21
Hi there,
I've been working with panels during the past few weeks a lot. As we all know, a panel is defined like this:
Okay. In a screen resolution of 320x240px that would be the center of the screen. Now let's say we switch the screen resolution to 1024x768px. The absolute position of the panel on the screen would change and be somewhere on the upper left. So, I tried to improve the code and did something like this:
In theory, this makes sure that the panel is always at the center of the screen. However, it cannot be compiled since lite-c NEEDS a numeric value in the "pos_x" parameter. A var parameter is NOT accepted, which would be very useful. You might say that a var parameter there would cost a lot of CPU power because whenever the var changes, the position of the panel has to change as well - I claim that it would be enough if the panel reads its position out of the variable at the time of its creation and then maintains that position, no matter what the var's content might be later on, until the "pos_x" or "pos_y" parameter is changed manually.
Another example of where a var parameter is impossible: the WINDOW command for panels.
bmap, varx and vary can be given a variable or pointer. dx and dy, however, expect a numeric value. However, it would be so *VERY* useful if dx and dy could be given variables as parameters. Why? Let us assume we have an energy bar. Its bitmap displays a color gradient from red (on the left side) to green (on the right end). Currently, we can only "move" the window within the bitmap. If we do so, the red and green end and all the colors in between would change their position, making the entire color gradient senseless. However, if we were able to manipulate the actual SIZE of the window on the bitmap, the colors always maintain their position (if the player has high HitPoints, the right end of the bar is green, the lower they get the more red the right end of the bar gets as the size of the window is decreasing as well).
Do you know what I mean? Basically what I would suggest is: free the parameters! Expect the user to enter numeric values OR variables for EVERY parameter a function/struct has. I don't know whether this is possible or not, but after all, this is just a suggestion ^^'
Greets,
Alan
I've been working with panels during the past few weeks a lot. As we all know, a panel is defined like this:
Code:
PANEL* mypan =
{
pos_x = 160;
pos_y = 120;
[...]
}
Okay. In a screen resolution of 320x240px that would be the center of the screen. Now let's say we switch the screen resolution to 1024x768px. The absolute position of the panel on the screen would change and be somewhere on the upper left. So, I tried to improve the code and did something like this:
Code:
PANEL* mypan =
{
pos_x = screen_size.x / 2;
pos_y = screen_size.y / 2;
[...]
}
In theory, this makes sure that the panel is always at the center of the screen. However, it cannot be compiled since lite-c NEEDS a numeric value in the "pos_x" parameter. A var parameter is NOT accepted, which would be very useful. You might say that a var parameter there would cost a lot of CPU power because whenever the var changes, the position of the panel has to change as well - I claim that it would be enough if the panel reads its position out of the variable at the time of its creation and then maintains that position, no matter what the var's content might be later on, until the "pos_x" or "pos_y" parameter is changed manually.
Another example of where a var parameter is impossible: the WINDOW command for panels.
Code:
window(x, y, dx, dy, bmap, varx, vary);
bmap, varx and vary can be given a variable or pointer. dx and dy, however, expect a numeric value. However, it would be so *VERY* useful if dx and dy could be given variables as parameters. Why? Let us assume we have an energy bar. Its bitmap displays a color gradient from red (on the left side) to green (on the right end). Currently, we can only "move" the window within the bitmap. If we do so, the red and green end and all the colors in between would change their position, making the entire color gradient senseless. However, if we were able to manipulate the actual SIZE of the window on the bitmap, the colors always maintain their position (if the player has high HitPoints, the right end of the bar is green, the lower they get the more red the right end of the bar gets as the size of the window is decreasing as well).
Do you know what I mean? Basically what I would suggest is: free the parameters! Expect the user to enter numeric values OR variables for EVERY parameter a function/struct has. I don't know whether this is possible or not, but after all, this is just a suggestion ^^'
Greets,
Alan
