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.

Messages - Nexys

Pages: 1
Ask a Question / Graphics File Size Optimization
« on: October 14, 2012, 07:41:54 pm »
Ok, so I'm trying to trim down the size of my game's SWF. I have a number of scrolling backgrounds that are meant to be out-of-focus silhouettes with things behind them, so I originally brought them into Stencyl as PNG-24s, since I need the transparency to have soft edges. These worked nicely.

Thinking they were probably having a negative effect on my file size, though, I came up with an idea - I could replace them with grayscale JPEGs that would serve as the alpha channels, and then work a little magic with them at runtime to generate the colored silhouettes. The JPEGs are 10-12 times smaller than the PNGs, so I figured I'd realize a significant savings.

Before digging into the code, though, I did a quick test. I published two SWFs - one using the PNGs and one using the grayscale JPEGs. To my bafflement, the one with the JPEGs ended up being a slightly *larger* file than the one with the PNGs.

So my question here is this: does the file size of the source images not matter once they're imported into Stencyl? Is it just the raw number of pixels that determines how much heft a particular graphic adds to the SWF? Or am I possibly missing something somewhere? If it isn't obvious, I'm somewhat new to this, so any advice on optimizing my graphics for file size is welcome.

Thanks in advance!

Old Bugs (1.x/2.x) / Re: Anchoring to screen from a custom event
« on: August 27, 2012, 08:15:13 pm »
Well, now I just feel silly. Though to be fair, it's not 100% intuitive that an actor's coordinates aren't converted to screen coordinates when anchoring.

Anyway, +1,000 to you for such an awesomely helpful response. May the force be with you!

Old Bugs (1.x/2.x) / Anchoring to screen from a custom event
« on: August 27, 2012, 09:55:42 am »
I have a boss at the end of a level, and when that boss dies, I have the boss actor message the scene so that the scene can display a "Level Complete" graphic and transition to the next scene.

There's a custom event attached to the scene that, when triggered by the death of the boss, creates an overlay graphic (in the form of an actor) and then anchors it to the screen. Here's how it's built:

It's a really simple construction, but the anchoring seems to hide the actor somehow. It simply doesn't appear. Here are some different scenarios I've tried:

1. If I move exactly the same blocks to a "when created" event, it works perfectly, but at the beginning of the scene instead of after the boss dies. I've been able to use this approach, hiding the actor's sprite until the boss dies. I'd prefer to create the graphic at the end, though.

2. If I remove the [anchor to screen] block, the overlay appears right on cue, although of course it doesn't move with the screen.

3. If I place an [unanchor from screen] block at the very end, it functions just like #2.

4. I thought that somehow the actor's sprite was being hidden, so after the [anchor to screen] block, I added a [show sprite for actor] block. No luck - it didn't show up.

5. Instead of using "last created actor," I saved the actor reference to an attribute and used that. It didn't seem to make any difference.

So, my conclusion so far is that the [anchor to screen] block doesn't work inside a custom event for some reason. Does anybody know if this is actually a bug in Stencyl, or am I missing something?

Ask a Question / Re: Using "grow" block disables screen space drawing?
« on: August 13, 2012, 08:07:52 pm »
Thanks ShivaFang! You're exactly what I was hoping for - someone who's already struggled with the issue and learned some work-arounds.

It seems pretty obvious now that actor space is more appropriate for my purposes, and it works like a charm. Because the drawing gets scaled, though, I'll have to split the debugging functionality between the two actors so only the thing that's actually being scaled will show a scaled bounding box (which might be useful to see in debugging mode). I'll probably also draw an unscaled box in a different color (from within the unscaled actor's logic) for the scaled actor.

Anyway, thanks for your insight on this - it helped immensely!

Ask a Question / Re: Using "grow" block disables screen space drawing?
« on: August 13, 2012, 01:14:05 pm »
Okay, it looks like moving the debugging event to the "host" actor instead of the scaled actor allows it to draw to screen space again. Still, it would be nice to have a way to do screen space drawing from an actor that's scaled. Anybody know if that's possible?

Ask a Question / Using "grow" block disables screen space drawing?
« on: August 13, 2012, 09:44:17 am »
So, I added a debugging event to a movement behavior that I created, which draws rectangles around a pair of actors that are supposed to move in unison. This worked fine until I introduced a [grow] block that affects the actor with the debugging behavior. With that actor scaled down, the [switch to screen space] block in the debugging behavior appears not to function, so the rectangles are drawn in the upper left of the screen, rather than around the actors.

This isn't a huge problem since it only affects a debugging behavior, but I think it might get in the way of other things I want to do if I can't scale an actor and also have it draw to screen space. Any thoughts?

Here's the debugging event:

And here's where I use the [grow] block to scale down the actor it's attached to (this logic is attached to the "Host" actor from the above logic):

Thanks for any help you can offer!

Toolset Extensions / Re: [Extension] TODOs
« on: September 11, 2011, 08:12:38 am »
I just tried and didn't run into any problem. Did you try to execute the extension with no game open? It shows a message telling you to open one first. Perhaps you mistook it by an error message.

Yeah, I got the "no game loaded" message, then I loaded a game, and it wouldn't do anything for me until I restarted. If you're not able to reproduce it, then it may just be some oddity with my particular system.  In any event, it works now, so I'm happy!

Toolset Extensions / Re: [Extension] TODOs
« on: September 09, 2011, 04:48:15 am »
This is really helpful to have within the SW environment itself - thanks so much for adding it! I'm actually pretty excited about (hopefully) seeing this grow into a more robust productivity aid.

Just one bug so far: the extension wouldn't open at all immediately after I downloaded it. I re-started SW, and that seemed to fix it. I'm using the windows version of SW.

A couple suggestions:

1. The TODO window is always on top of the main SW window, making it sort of awkward to switch between the two. It would be nice if the TODO window moved to the back when it lost focus.

2. This is sort of minor - the "Details" text box requires me to put in manual line breaks, or else I end up with everything on one line. Wrapping the text to the available space might make it a little easier to work with. I can imagine situations where you might want to maintain the formatting of the text, though, so maybe each entry could have a check box for enabling/disabling text wrap.

Anyway, thanks again!

Sweet!  Thanks a million!

So I was poking around in the API looking for solutions to some (somewhat aggravating) inaccuracies in tweening, and I found the "Tweener" class, which seemed to have all kinds of wonderful goodies for me to mess around with. However, I don't see caurina.transitions being imported at the top of the code preview, and I can't seem to access this class in my code. Is it still available to me? If not, is there any way to directly access the tweening data for a particular actor?

Ask a Question / Re: Identifying joint-linked actors
« on: July 17, 2011, 09:35:31 am »
Okay, for those interested, I think I managed to figure this one out:

Code: [Select]
var joints:Array = getScene().joints;
for (var jointIndex:int = 0; jointIndex < joints.length; ++jointIndex)
if (joints[jointIndex].actor1 == actor.ID)
else if (joints[jointIndex].actor2 == actor.ID)

In this case, _LinkedActors is a list attribute that I defined in design mode, and if a joint involves the actor that the behavior is attached to, the actor on the other end of that joint gets added to the list. If anyone can find a more efficient way to do this, or if you can see any potential problems with it, feel free to let me know.

Ask a Question / Identifying joint-linked actors
« on: July 16, 2011, 07:48:34 pm »
Hi all,

I'm looking for a way I can get a behavior to look for actors that are connected via joints to a particular actor. I'm a noob with Actionscript, but I've been browsing through the API and found the b2Joint and b2Body classes and thought they might be what I'm looking for.  Is there a way I could cycle through all the joints in a scene, comparing the bodies on either end with the body for the actor I'm working with? Is there a more efficient way?

If you could provide some example code, that would be fantastic, but even just a nod that I'm on the right track (or some direction on a better way) would be helpful.

Thanks in advance!

Ask a Question / Re: Finding a tangent circle
« on: June 20, 2011, 04:57:38 pm »
Thanks, Herby.

To be honest, I was sort of hoping there would be some nice pre-packaged equations I could use, but I've started putting together something that I think will work based on the intersection of lines like you mentioned.  I'll post again here if I run into trouble (or if I succeed, I guess).

Ask a Question / Finding a tangent circle
« on: June 19, 2011, 01:27:48 pm »
Okay, so here's the situation:

I have three actors that may be placed in any possible relation to each other, but they don't move. Thus, they are basically the three points of a static triangle. For each of these points, I need to find a circle that is tangent to the shortest adjacent side of the triangle at its midpoint, and also tangent to the other adjacent side (but not necessarily at the midpoint). Basically, I need a curve that fits nicely into each corner of the triangle.

I've been going back to my trig textbooks to try to pull this together, but so far the only leads on a solution that I've found seem like they'd be pretty computationally expensive (I may need to do this calculation a few times for each level of the game). What's the most efficient way to calculate the center point and radius of these circles?

Thanks for any help you can offer!

Pages: 1