MODULE: Flashlight v2.0 [FINAL] - Updated 16 January 2009!

[monkey0506]

Hmmm...I forgot about deleting the DynamicSprites I had to create to make the GUI version work. I'll set up a function to delete all the sprites instead.

Previously I had thought that Overlays could support alpha channels, but I'm wrong. The GUI version should support sprites with an alpha channel, although apparently you can't use the transparency if you do this?

I'll look into this to see what can be done about it.

As for Flashlight.CharacterToFollow, GarageGothic pointed out to use the Flashlight.FollowCharacter (if "Enforce object-based scripting" is turned on, Flashlight.SetCharacterToFollow if it is not) function instead. I had to change this to keep track of when the flashlight was supposed to be following the player (which can change) instead of just one Character.

I'll also look into your trying to set the radius to 0, however you must note that 1) the radius is a float, not an int, so you must set it to 0.0, and 2) there is an enumerated value eFlashlight_MinimumRadius* which defines the minimum radius of your beam. If you try to set the radius any smaller than this, it will automatically be resized. However, I don't see why that would cause this problem, so I will look into it for you.

[EDIT:]

@Da_Elf:
If you would read the documentation (or any of what I have said) you would realize that if you do not have "Enforce object-based scripting" turned on, you will NOT have the Flashlight.FollowCharacter option available. Instead you will have Flashlight.SetCharacterToFollow. Seeing as you said it worked, I can only assume that you actually did turn this option on, however, you still failed to read the parts I've written about the changes made to the way this property is set. Also, if you had noticed, the autocomplete will show you that Flashlight.CharacterToFollow is now read-only (writeprotected). See the red X over the symbol by the property? That means you can't write this property directly!

I get no problems when setting the radius to 0.0 (with the code in-tact as distributed (eFlashlight_MinimumRadius set to 2)). Changing eFlashlight_MinimumRadius to 0 and then trying to set the radius to 0.0 did however generate errors. The DynamicSprite must be resized to a width and height greater than 0 pixels. I'm currently looking into how to fix this.

As for the strobing issue, I can't replicate it. Maybe if you posted the exact code to tell me exactly what you've done I can find a problem.

*Although this is defined, by default, as 2 (an integer type), it will automatically be converted to a floating-point decimal to be consistent with the Flashlight.Radius property. I cannot, however, convert this value if you are trying to manually set the Flashlight.Radius property to an integer, which should produce errors.

[Lt. Smash]

It would be a bit of work, but if you use a second gui with no transparency as the flashlight gui(the other one as the background gui), it would probably be possible to use alpha transparency and the transparent background at the same time. Or am I wrong?

[GarageGothic]

I haven't checked out the code, but if you still create the other black sprites by cropping the top left pixel from the cone sprite and then resizing it, it should retain any alpha channel (for that pixel) present in the original. Thus, if the edges of the original cone sprite is created to be 50% transparent, the other buttons should also be 50% transparent due to the alpha channel.

[Da_Elf]

all I'm doing is using the code

Code: ags

Flashlight.Enabled = true;
Flashlight.FollowCharacter(cEgo);
if (GetGraphicalVariable("torch") == 0) {
Ã,  Ã,  Flashlight.Radius = 0.0; 
Ã,  }
Ã,  else {
Ã,  Ã,  Flashlight.Radius = 50.0;
Ã,  }

in the when player enters room before face in.
Then when my character walks from one room into another room i get this flashing of the elements that make up the dark area

here is the compiled game with it srobing, walk down to get to the next room and in that room walk left.
also is a template of the game. (this isnt my full game its just a recreation with 2 rooms)
http://www.elfpro3d.com/Asterix/Flashing.exe

[monkey0506]

As best as I can tell, DynamicSprites apparently don't support alpha channels. I've imported a sprite with an alpha channel, and have used it as a static sprite without any problems, however, as soon as I make a DynamicSprite from it, I lose the alpha transparency.

It's essential to use a DynamicSprite in order to allow the radius of the flashlight beam to be changed. Otherwise you would have to use a different static sprite for each and every size you wanted your beam to be.

So I guess that this won't, in fact, support alpha channels at all. I'm sorry for saying it did without actually testing it. 'Cause we all know what happens when we make assumptions. Poor, poor Mumptions.

As I've said, I can't seem to replicate either of Da_Elf's errors, so until he posts some code, I suppose my work here is done...unfortunately.

[EDIT:]

Okay Da_Elf, I think I've seen something similar to that, but it should have been fixed by the 2.0 BETA 1. The only thing I can think of now to try and help you solve this is to ask that you send me a copy of your game so I can take a look at it...?

P.S., I've already told you that setting the radius to 0.0 won't work. Even if you set eFlashlight_MinimumRadius to 0, your game would crash. So don't expect that bit to magically start working.

Checking the tracker entry here, it would seem DynamicSprites do in fact make use of alpha channels. So can anyone tell me what I've done wrong? Even something as simple as:

Code: ags

DynamicSprite* newMouse = DynamicSprite.CreateFromExistingSprite(28);
mouse.ChangeModeGraphic(eModeWalkTo, newMouse.Graphic);

Shows no alpha transparency, while RawDrawImage(50, 50, 28); does.

My initial line of thinking here would be that the alpha channel gets destroyed when I resize the DynamicSprite (as in the module), however, in the above example which shows no alpha channel, I haven't resized it. So that's not actually the issue.

[Da_Elf]

opps. you posted while i was typing and i didnt notice. here is what i modified above....

here is the compiled game with it srobing, walk down to get to the next room and in that room walk left.
also is a template of the game. (this isnt my full game its just a recreation with 2 rooms)
http://www.elfpro3d.com/Asterix/Flashing.exe. when i set radius to 0 the game sets it to 2 for me since you set minumin to 2 so thats not the problem even when using 2 the borders of the black areas dont reach the border of the screen

EDIT

the work around i had to use was set radius to 3. setting to 2 gives me the problems i was facing. but 3 and up works fine

[GarageGothic]

This is very interesting news to me, monkey. I've been having problems with an alpha-channelled DynamicSprite for some days now, and this could very well be the reason. Well, I've asked CJ to implement a function to remove alpha channels from DynamicSprites, so perhaps it will be possible in the future.

As a workaround for the antialiasing (but too hack'ish to implement in the module, I think), you could let the module handle the totally black areas (still with option of GUI transparency), and then add an alpha'ed sprite for the inner part of the cone as a character in the room. You would of course need to add a bit of code to make that character follow the GUI around.

Edit: Just saw your addition. I'll check it out myself now.

[monkey0506]

@Da_Elf: 404'd!! (Edit 1: ) Nevermind. You fixed it. (Edit 2: ) Except...you've included a Compiled folder...but no Compiled EXE. I'll take a look at your AGT file you've included.

@GG: It wouldn't be too hard to set the Character's x and y properties instead of the GUIControl's X and Y ones, I would simply have to check that the Character wasn't moving (via Character.Move) first. I'm also a bit reluctant to require the user to designate a GUI and a Character for the flashlight effect. I'll give it some consideration, though I'm not sure how I'll handle this (for now). Plus, it would be much more difficult to handle the size of the radius this way (I would have to manually determine the proper scaling level for the Character to set the sprite to the correct size). But I'll mull over some thoughts before I make my final decision.

[GarageGothic]

In regards to using a character - I didn't mean that it was difficult to align character and GUI, I meant it would be a bit of work for Lt. Smash if he was going to use that option. Because, as I also said, it is a bit hack'ish, and I agree with you that it's probably not a good idea to include in the module.
I don't think that the scaling/radius calculation would be very difficult, though the alignment may be off by a pixel or two. It's just a few lines of code:

Code: ags

cFlashlight.ManualScaling = true;
cFlashlight.Scaling = (radius/Game.SpriteHeight[flashsprite])*200;

Of course the vertical/horizontal scaling would have to be the same, but I don't know if the current module even allows them to be set individually. And it can't be bigger than double original size, but usually you don't want to scale sprites up too much anyway.

To follow up on the DynamicSprite issue:

It would actually seem that the alpha channel DOES disappear when the DynamicSprite is created. I could swear that this has been a problem in previous version, but I see nothing in the changelist to indicate that it's been fixed. Very strange. On the other hand I always have many problems with imported alpha'ed sprites, so perhaps this was due to some other conflict. This is an excellent discovery for my purposes, but now I must go add a comment to that tracker entry. Weird.

[Lt. Smash]

I wouldn't bother if I have to use a GUI AND a character.

But wouldn't the whole thing work with RawDraw?

[GarageGothic]

RawDraw would draw the darkness behind characters and objects in the room. That was the original problem and the reason for using Overlays.

[Lt. Smash]

Oh yes I forgot that. sorry

[monkey0506]

GarageGothic: Okay, I understand now. I guess I was just overthinking the scaling (like I was doing when trying to figure out the scrolling issue heheh).

It's good to hear that I'm not just retarded/completely incompetent when it comes to the DynamicSprite issue. Thanks for following up on that.

As for you Da_Elf...I can't seem to figure out what the problem is. I've checked your code...and there...shouldn't be anything wrong with it, though I have seen the problem in action. Trying to replicate the problem in a game I've created independently, I still can't figure out what's wrong.

I'm not giving up on this problem, but I just wanted to give you an update thus far.

[EDIT:]

Only 3 posts while I was reading my brother's *to me* messages on MySpace. Not too shabby.

[Lt. Smash]

only a question:

monkey are you going to make a character for the flashlight as GarageGothic suggested or have you found a simplier solution for that Alpha blended problem?

[monkey0506]

I haven't yet decided Lt. Smash. It doesn't seem like it's really a good idea...though if it's required for the module I could attempt it. Right now I'm working on my dialog module, and then I intend to work on getting that implemented better into my MonkeyTemplate module...but somewhere I will find time to take a look at this.

[Da_Elf]

i give up. ive tried the module with other scenes and i always get that 'flashing" when the character changes room. i cant figure it out.

[Da_Elf]

oook. i think i have a solution to my flashing problem. it seemed the flashing starts when i change the room but in the first room its fine. therefore i setup a flashlight variable to let me know if the light is on or off so in the rooms which are supposed to be dark it checks the variable to see if its on. when my character leaves the room i turn off the flashlight but dont change the variable. then on entering the new room i check the variable, see the lights supposed to be on, so i then turn on the light. so in the new room i cant walk into it with the script already working it seems. this work around seems to be fine however the other problem i face which isnt too much of a problem is that i use the script in the "when player enters room before fade in" seems the dynamic sprite doesnt work with fade ins. the room fades in (letting the player see the layout) then it applies the black. like i said, easily fixed by not using fade ins.

EDIT

ok. I'm now trying to add my own piece of code to take care of the scaling issue by using
Flashlight.Radius = (GetScalingAt(player.x, player.y));
now researching how to get a int from a float

EDIT

hmmm. ive used in the past

Display("you have %d senturii", GetGraphicalVariable("getmoney"));

this was all i could find about it in the help file and the wiki but the %d thing doesnt seem to work

EDIT (captians log stardate blah blah blah)

none of the % things seem to be right sigh im just stupid i guess hehe

[monkey0506]

For several reasons I haven't had much time/energy to devote to AGS for the past several weeks. If I'm reading what you've written correctly, then the strobing error only occurs if you have a fading room transition between two rooms with the flashlight effect enabled? I can take a look to try and see if there's anything I can do to fix this on my part and I'll let you know.

Regarding the "scaling issue" are you wanting the flashlight to be scaled to the height/width (greater of the two) of the Character? Perhaps you could do something like this:

Code: ags

ViewFrame* frame = Game.GetViewFrame(player.View, player.Loop, player.Frame);
float fr = IntToFloat(Game.SpriteHeight[frame.Graphic]);
if (Game.SpriteWidth[frame.Graphic] > Game.SpriteHeight[frame.Graphic]) fr = IntToFloat(Game.SpriteWidth[frame.Graphic]);
fr *= (IntToFloat(player.Scaling) / 100.0) / 2.0;
// fr += 1.0;
Flashlight.Radius = fr;

As for your problems with "the % things", you seem to have shown a proper implementation of them. How aren't they working (though this has nothing to do with the module, I'm willing to try and help)? What is happening, and what's not?

[Da_Elf]

The flashing doesnt have anything to do with the fading, it had to do with entering a room when flashlight was turned on in another room. the problem with the fading is a totally different problem. while AGS executes the fade on the room you can see the entire room properly. When its fully faded in then the flashlight effect is added hiding the background. even though i have turned on the flashlight in the "before fadein" area of the room script.

as for the % thing it works in the area where i used it for the displaying the amount of money. however when i tried to use the % to convert fload and int it didnt work
example: Flashlight.Radius = %d (GetScalingAt(player.x, player.y));

i can kinda see where your going with your code but why cant it simply be something to find out what the scaling is where the characters possition is and apply that to the .Radius

[monkey0506]

The "%d thing" only works in string formatting. You can't just throw it into the script wherever you want.

Code: ags

int int_var = 5;
float float_var = 9.8;
Display("int var: %d", int_var); // display int variable
Display("float var: %f", float_var); // display float variable
int temp_int_var = int_var;
int_var = FloatToInt(float_var); // convert float to int
float_var = IntToFloat(temp_int_var); // convert int to float

Regarding the fading, I understand the issue now, but there's really no way for me to control that. If you're using the Overlay version, you may try using the GUI version, i.e.:

Code: ags

// Script header for module 'Flashlight'

//#define FLASHLIGHT_GUI gFlashlight  // CHANGE THIS
#define FLASHLIGHT_GUI gFlashlight  // TO THIS (WHERE "gFlashlight" IS THE SCRIPT O-NAME OF YOUR FLASHLIGHT GUI)

I'm not sure if that would work as I'm not sure how GUIs react during room transitions...(it's been a while and I don't have time to look)...but it could be worth a try.

It wouldn't make any sense to try and scale the radius of the flashlight based solely on the scaling of the room at any given co-ordinates, unless you really just wanted to force the flashlight to use the scaling of the room.

The way you're trying to implement it takes no consideration for the possibility of manual character scaling, and you haven't even actually applied the scaling to a base value, you're just *attempting* directly setting the radius to the scale at the room co-ordinates.