uhm. but if i use a local variable, then i can use it in an other method?
for example, in this case, now we have:
def initialize
[...]
$glow_logo = 0
$glow_logo_boolean = false
end
def update
[...]
if $menu == true then
if $glow_logo_boolean == false then
$glow_logo = $glow_logo + 2
if $glow_logo == 200 then
$glow_logo_boolean = true
end
else
$glow_logo = $glow_logo - 2
if $glow_logo == 0 then
$glow_logo_boolean = false
end
end
end
end
def draw
[...]
if ($menu == true) then
@immagini_logo.draw(0, 0, 0, factor_x=1, factor_y=1, ((0xFF - $glow_logo) << 24) + 0xFFFFFF)
end
[...]
end
I just tried to change $glow_logo_boolean in a local variable, but it doesn't work.
Well, for variables that need to be shared across methods, use an instance variable. They shouldn't need to be accessible outside of your object.
As for fading in and out, let me see if I can get the math right this time. I wrote an equation that was wrong and kept getting the corrections wrong a while ago because I was on a tablet and couldn't test it!
There we go. 0.5 + Math.sin(Math::PI * Gosu.milliseconds / 1000.0) / 2
should give you a float in the range 0 – 1 inclusive, with a period of one second. If you want toit to go faster or slower, change 1000 to something else—it's basically the period in milliseconds.
More usefully:
def draw
…
if @menu
alpha = (128 + 128 * Math.sin(Math::PI * Gosu.milliseconds / 1000.0)).floor
@immagini_logo.draw 0, 0, 0, 1, 1, Gosu::Color.argb(alpha, 255, 255, 255)
end
…
end
By il mietitore
Date 2011-09-27 22:47
Edited 2011-09-27 22:54
that's crazy.
it works but i can't understand what the heck is that >.<
what is PI? and that .floor? O___O
(thanks a lot =D )
PI is a math constant. You should know it from school.
.floor removes decimal, like (1.25).floor = 1
ah, the π!
what i'm trying to understand is: why this equation gives a different result at every refresh? i mean, there are no variables that changes each time... i suppose it's related to that Gosu.milliseconds, because all the other things are fixed >.< what is that Gosu.milliseconds, anyway?
By jlnr (dev)
Date 2011-09-28 13:16
The current time in milliseconds. The rdoc is ugly right now, but you will still be able to find all that here:
http://libgosu.org/rdoc
So here it is, now it's all clear.
Well thanks a lot to everyone in here ;) i suppose i'll be back soon, i'll surely find some other curious problem to fight with.
heya ;)
i tested the snippet and it crashes after some seconds.
>ruby test.rb
test.rb:13:in
argb': Wrong arguments for overloaded method 'Color.argb'. (ArgumentError)
Possible C/C++ prototypes are:
Gosu::Color Color.argb(Gosu::Color const *self)
Gosu::Color Color.argb(Gosu::Color::Channel a, Gosu::Color::Channel r, Gosu::Color::Channel g, Gosu::Color::Channel b)
Gosu::Color Color.argb(std::tr1::uint32_t argb)
from test.rb:13:in
draw'
from test.rb:18:in `<main>'
>Exit code: 1
By jlnr (dev)
Date 2011-09-28 20:08
The trick is to use 127.5 + 127.5 * ...
:)
Oops! Wow, that didn't happen for me even after many, many iterations. I had numerous previous versions that did. :D
@jlnr Can we get a constructor that takes normalized floats? I'm much more comfortable with those. C:
By jlnr (dev)
Date 2011-09-30 05:46
I thought about overloading it, but it would be confusing if passing 1.0 and 1 would make a difference. I could add a _f variant for everything on Color, but I am not sure about that.
It may be a bit clearer if you work with normalized floats and then do *255 in the end, though. Now if Color.argb only called .to_i on its arguments...sigh.
By jlnr (dev)
Date 2011-10-08 11:06
Color now (=in the next release) truncates and wraps all values into 0..255 automatically. That was a painless fix at least. :)
This is a good change. :D