Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Diarandor

#1
Hi! Although I'm not active these days, I have a question about the default blend mode.

The engine v1.6.x currently uses the following as default blend mode (called "blend"):
Quote"blend" (default): This drawable object is alpha-blended onto the destination surface.
dstRGB = (srcRGB * srcA) + (dstRGB * (1 - srcA))
dstA = srcA + (dstA * (1 - srcA))
Link to the Lua API: https://www.solarus-games.org/doc/latest/lua_api_drawable.html#lua_api_drawable_set_blend_mode

Why was this blend mode chosen? I do not like it because it is not associative, which is a bad property because this is not what happens in the real world. Let me explain this. In our real world, when you overlap 3 semitransparent surfaces A, B and C, the associative property
(A * B) * C = A * (B * C)
is satisfied, where "A * B" means putting or drawing A above B.

However, the "over" blending mode (https://en.wikipedia.org/wiki/Alpha_compositing) does satisfy the associativity, and is given by
newA = srcA + dstA - dstA * srcA      // This is equivalent to the current alpha in "blend".
newRGB = ( srcA * srcRGB + (1 - srcA) *  dstA *  dstRGB ) / newA.

Note that if newA is 0, the denominator in newRGB should be replaced by 1 (or whatever, because the new surface becomes transparent) to avoid a NaN error.

So these are my suggestions:
1) Add a new blend mode to the engine, called "over".
2) Set the "over" blend mode as default, if this does not produce incompatibilities with the old "blend" mode.

If you like the idea, we could open an issue for this. If there is a reason to keep "blend" as default, I would like to know, just by curiosity.
#2
Development / Re: how do you save a number?
April 01, 2020, 12:29:04 AM
I will try to explain this with more detail:

1) Use game:set_value("win", win) to store the value of the local variable win of your script in a built-in savegame variable called "win". This does NOT save your variable in a file. This updates the value of the built-in variable "win" (which is not the local variable in your script). Only buit-in variables are saved in files, and to do that it is NECESSARY to call game:save().
2) Save your game with game:save(). In the games of the Solarus Team you will find a menu to save the game, and that menu, in its code, is calling that function. If you don't call that function in any way, your savegame built-in variables will not be saved into a file. So, please, don't skip this part.
3) When your game is restarted and your savegame is reloaded (make sure that your savegame is loaded! I don't remember where this is done or if this is automatically done), you can recover your variable with:
win = game:get_value("win") I insist that in your code above you don't need any conversion because Solarus can save strings, booleans and numbers, and your variable is a number.
4) Read the errors in the console and learn to understand them. Always fix them. Never ignore them. This is crucial. If you don't understand an error, you can ask us.
5) Please, read the API of those functions and absorb its knowledge. If you don't understand something, don't hesitate to ask. If you want to learn, you need to consult the API. We all use it all the time, and it's very well written and with many examples.

Remark: in this code you wrote
win = tonumber(game:get_value(size))
the compiler is complaining that size is not a string. Since the conversion to number is not necessary, that line could be replaced with this:
win = game:get_value("size")
although what you need is this:
local win = game:get_value("win")
#3
Development / Re: how do you save a number?
March 31, 2020, 05:03:17 PM
Savegame values can be strings, numbers or booleans. His problem is just that he is not saving or loading the variable correctly. As I pointed above, the savegame functions get/set_value use a string in first parameter as a variable name, and he is not using a string, so he is getting an error.
#4
Development / Re: how do you save a number?
March 30, 2020, 07:42:09 AM
I think that error means that
win = game:get_value(win)
should be replaced by
win = game:get_value("win")
Note that "win" is a string and win is a variable. You need to fix all errors where the console complains, or your code won't work.
#5
Development / Re: how do you save a number?
March 30, 2020, 04:27:44 AM
Please, first read carefully the savegame functions in the Solarus Lua API. That's the only way you can understand what those functions do. Again, this is the link for what you need:
https://www.solarus-games.org/doc/latest/lua_api_game.html

Also, reading code from others is very useful to learn.
#6
Development / Re: how do you save a number?
March 30, 2020, 03:04:27 AM
You forgot to load your savegame variable. Use this:
Code (Lua) Select
win = game:get_value("win")
You don't need to use
Code (Lua) Select
game:save()
since I guess that is being done in your menus when you save your game (isn't it?).
Savegame variables are saved and loaded with the functions: "game:get/set_value", which are the ones you need to use.

(By the way, the command "game:save()" has no parameters and saves ALL savegame variables:
https://www.solarus-games.org/doc/latest/lua_api_game.html#lua_api_game_save)

Always use the Solarus Lua API when you don't know how to do something. Usually the answer is there.
#7
Development / Re: how do you save a number?
March 30, 2020, 01:51:18 AM
To debug, try some prints:
Code (Lua) Select

print(size)
print(type(size))

If your variable is null, check if you used the saving function "game:save()" or if the savegame was really loaded when restarted.

EDIT: i don't think others can really help you if you don't post the real code of that  function.
#8
As mr froggy asked above,did you check that all sprite and enemy properties are correct?
Some things to check: position of the sprites in the image and of the enemy in the map, that the enemy and sprites exist, the sprites' origin point, etc. Make sure that you start an animation and that it does exist. Remember that the engine in many cases starts automatically the walking animation on enemies, and if that one does not exist you may see nothing at all (it is easy to override this built-in behavior using sprite/entity events, as I do with my enemies).
#9
Your projects / Re: Long Steel
February 12, 2020, 08:21:21 PM
Awesome work! I will ask you for a link when I find some free time to play it. Thanks for sharing it.
#10
Game art & music / Re: Original art
October 18, 2019, 06:41:19 PM
New chiptune again!!!
Song name: Dubious Riddle
https://youtu.be/IosW0yqaiIY

Give me some Thumbs Up to support my motivation. Thanks!
#11
Game art & music / Re: Original art
October 06, 2019, 12:58:24 PM
Added new wendigo enemy to the Free-Resource-Pack.
It will also appear in our secret project Children of Solarus. :)

These are almost pacific enemies, but be careful, their fast counterattacks could be lethal.
https://youtu.be/mo8hl_jTOzA
#12
Game art & music / Re: Original art
October 05, 2019, 03:10:52 PM
Another new chiptune: "Hope Scent".
https://www.youtube.com/watch?v=KIZ_SXl2SWw
#13
Lol, thanks! I get it now.
I am not good at puzzles with pieces hidden below the carpet. I had even tried to move the torches and thought the puzzle was broken XD.
#14
Cool, thanks!
#15
@Christopho:
I got this error while playing this game. I was using an old version of Solarus: v1.6.0.
I believe this is an engine error: "Fatal: This state is already stopping: pulling" (see image below).
Was this fixed in v1.6.2? By the way, I've just downloaded the last engine version now, just in case.

@Zeldo: I'm still stuck in that puzzle. I believe I've become a casual player... :'(