Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411275 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 05:36:31 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Beginning programmer working in Flash
Pages: 1 [2]
Print
Author Topic: Beginning programmer working in Flash  (Read 1868 times)
MTaur
Level 0
**


View Profile
« Reply #20 on: November 27, 2015, 03:13:44 PM »

How long ago did you check it out? Haxe/OpenFL today is lightyears ahead of where it was 2-3 years ago. Back then it was more trouble than it's worth.

I checked my unused NME folders' creation dates, they're going far back to 2011, wow. Perhaps I should check openFL again in my spare time.



I'm not totally up to date on how vector graphics work, but I remember mouse transparency being a nightmare before I converted an asset to vector once.  I'm aware that there's a button class, or alternately, you can just add an invisible child who catches clicks for its parent.  Is that one way of getting around performance issues - by using png or bitmap assets instead?  Or is the real issue that rotation properties/methods are a costly beast, or something like that?

Sorry I'm not sure I understood your first paragraph. There are manys ways to do buttons as you say, but if they don't cover a very big area I don't think any of them would affect performance in a visible way in modern machines. Also if your game will be like final fantasy tactics, my guess is it can work properly without much effort because it shouldn't be much graphically intensive.

As I said before, the most common performance problems I see is related to flash's default screen rendering being made on CPU, instead of your fancy video graphics card. Thus, users can get angry when they can play Skyrim in full settings but can't play your seemingly simple flash game without hickups, because CPU is not primarily made for proccessing graphics. In that mode, no matter what you use, the ceiling room for adding new things is low, this is always a concern (at least for me since visuals are important for me). And some features reach that ceiling faster obviously. There are a lot of tips/articles on getting performance from the default flash rendering that piled up in years, it would probably be unnecessary to try writing every single thing here.

Also, I found that now you can target GPU (graphics card) with a single click, of course complying with some limitations. Details are here: http://help.adobe.com/en_US/as3/mobile/WS901d38e593cd1bac-3d719af412b2b394529-8000.html

My problems are extremely basic.  Mouse transparency never works the way that I want it to, and the last time I made an object that I only wanted to click the visible part of, I had to rasterize as a vector, which was an awkward process to go through and resulted in a somewhat chunky-looking image.  I'm not really that worried about performance for reasons you've brought up, which is why I was looking into invisible children as target areas, which also sounds like and annoying and pedestrian solution.  At the moment, I'm just trying to get things to work, and mouse transparency is a pain.
Logged
UmutD
Level 1
*



View Profile WWW
« Reply #21 on: November 27, 2015, 04:41:10 PM »

@MTaur, I guess I didn't understand your concern before because of my own obsessions, sorry lol. What do you mean by mouse transparency? Are you hiding default mouse cursor and making your own custom cursor?

You don't need to turn vector to raster in order to make mouse-clicking work only for visible areas of an movie clip, that should already work that way for vectors. The one exception I can think of is if the invisible part is actually a fill with alpha set to zero, then you can simply delete it and solve the problem.

Opposite to what you are saying, when you move your mouse on a raster, mouse doesn't understand if you're on the invisible part (a transparent pixel), so mouse_overs & clicks register whenever you're inside the borders of the raster image. So your solution didn't make much sense to me.

Another wild guess: If you are using a movieclip as a custom cursor, if you don't set its "mouseEnabled" and "mouseChildren" properties to false, it can receive mouse events instead of the movieClip you're trying to click to. Also, if you have nested objects in movieClips, they can mess up with mouse events too, you can overcome this by changing those properties of the childs or the parent.

...

@InfiniteStateMachine, @Photon, thanks for the info guys, I guess I need to check openFL again sometime!
« Last Edit: November 27, 2015, 04:47:07 PM by UmutD » Logged

MTaur
Level 0
**


View Profile
« Reply #22 on: November 27, 2015, 04:52:30 PM »

@MTaur, I guess I didn't understand your concern before because of my own obsessions, sorry lol. What do you mean by mouse transparency? Are you hiding default mouse cursor and making your own custom cursor?

You don't need to turn vector to raster in order to make mouse-clicking work only for visible areas of an movie clip, that should already work that way for vectors. The one exception I can think of is if the invisible part is actually a fill with alpha set to zero, then you can simply delete it and solve the problem.

Opposite to what you are saying, when you move your mouse on a raster, mouse doesn't understand if you're on the invisible part (a transparent pixel), so mouse_overs & clicks register whenever you're inside the borders of the raster image. So your solution didn't make much sense to me.

Another wild guess: If you are using a movieclip as a custom cursor, if you don't set its "mouseEnabled" and "mouseChildren" properties to false, it can receive mouse events instead of the movieClip you're trying to click to. Also, if you have nested objects in movieClips, they can mess up with mouse events too, you can overcome this by changing those properties of the childs or the parent.

...

@InfiniteStateMachine, @Photon, thanks for the info guys, I guess I need to check openFL again sometime!


What I mean is that if I import a .png or whatever, the transparency layer will be see-through, but it will still catch (unwanted) clicks.  I don't really use any vector tools.  The only time I ever dealt with vector assets was when I turned a tile into a vector asset just so the mouse wouldn't catch on the transparent region.  It was the simplest solution I was able to Google at the time, but I'm starting over and considering using a child object to catch clicks instead.  The tiles are diamonds and everything else should probably be rectangles or text fields, as far as clickable objects go, so it should be relatively simple to implement clicking on child objects instead, at least this time around.  But at the same time, I don't like not knowing how to handle something this basic in other ways.
Logged
UmutD
Level 1
*



View Profile WWW
« Reply #23 on: November 27, 2015, 05:02:27 PM »

Ah, you said you had to rasterize which means turning a vector to raster/bitmap, so I thought you were trying the opposite.

Yes, you can simply make a vector area to catch mouse events behind the tile bitmap, and put them inside a container sprite, in different layers for the sake of simplicity. That's what I would do. Or you can detect the pixel you're clicking on and check it's alpha value perhaps, if you want to avoid vectors completely.
Logged

UmutD
Level 1
*



View Profile WWW
« Reply #24 on: November 27, 2015, 05:07:09 PM »

By the way, there are already isometric libraries for as3 that might make your overall job easier. http://www.emanueleferonato.com/2010/02/23/11-flash-isometric-engines-you-can-use-in-your-games/

Probably some may be defunct after all these years but anyway...
Logged

MTaur
Level 0
**


View Profile
« Reply #25 on: November 27, 2015, 06:58:15 PM »

Ah, you said you had to rasterize which means turning a vector to raster/bitmap, so I thought you were trying the opposite.

Yes, you can simply make a vector area to catch mouse events behind the tile bitmap, and put them inside a container sprite, in different layers for the sake of simplicity. That's what I would do. Or you can detect the pixel you're clicking on and check it's alpha value perhaps, if you want to avoid vectors completely.

Oh, putting a check for alpha value sounds cool.  But if it were a complicated setting, it would have to eat resources.

Sorry I got my vocabulary backward.  It's bound to happen a lot for who knows how long... X-P
Logged
MTaur
Level 0
**


View Profile
« Reply #26 on: May 16, 2016, 09:05:35 AM »

I got busy and discouraged after my last post, so I sidelined this for a while.  I have the Summer off, though, and I'm going back to work on this project.  But I'm really taking it slow and trying to really understand OOP before I even do anything engine-specific.

It took me about a week to untangle events enough to implement a transparency-respecting and depth-respecting scheme enough to write a beta version of a transparency-bypassing custom click handler for very general purposes.  It's tricky and uphill, but seems to be shaping up.

I couldn't do it just by extending MouseEvent with a logic check.  The tendency of mouse clicks to be intercepted by the invisible part of a higher sprite was a bit of a pain.  I had to add a MouseEvent.CLICK listener to the stage that then checks in with all of the subscribers to see what the cursor is doing with them locally.

Anyway, this might be better than having to create vector child objects to catch clicks over and over again?  I hope so...

Thanks for the tip, if you're still around.   Gentleman
Logged
voidSkipper
Level 2
**


View Profile
« Reply #27 on: May 18, 2016, 08:08:31 PM »

I got busy and discouraged after my last post, so I sidelined this for a while.  I have the Summer off, though, and I'm going back to work on this project.  But I'm really taking it slow and trying to really understand OOP before I even do anything engine-specific.

It took me about a week to untangle events enough to implement a transparency-respecting and depth-respecting scheme enough to write a beta version of a transparency-bypassing custom click handler for very general purposes.  It's tricky and uphill, but seems to be shaping up.

I couldn't do it just by extending MouseEvent with a logic check.  The tendency of mouse clicks to be intercepted by the invisible part of a higher sprite was a bit of a pain.  I had to add a MouseEvent.CLICK listener to the stage that then checks in with all of the subscribers to see what the cursor is doing with them locally.

Anyway, this might be better than having to create vector child objects to catch clicks over and over again?  I hope so...

Thanks for the tip, if you're still around.   Gentleman

Sprites have a MouseEnabled property which you can set to false, causing all clicks to pass through the sprite and onto the next sprite.

The easiest solution would just be to set anything you don't want clicked at the time to MouseEnabled = false, I think.
Logged
MTaur
Level 0
**


View Profile
« Reply #28 on: May 18, 2016, 08:37:04 PM »

I got busy and discouraged after my last post, so I sidelined this for a while.  I have the Summer off, though, and I'm going back to work on this project.  But I'm really taking it slow and trying to really understand OOP before I even do anything engine-specific.

It took me about a week to untangle events enough to implement a transparency-respecting and depth-respecting scheme enough to write a beta version of a transparency-bypassing custom click handler for very general purposes.  It's tricky and uphill, but seems to be shaping up.

I couldn't do it just by extending MouseEvent with a logic check.  The tendency of mouse clicks to be intercepted by the invisible part of a higher sprite was a bit of a pain.  I had to add a MouseEvent.CLICK listener to the stage that then checks in with all of the subscribers to see what the cursor is doing with them locally.

Anyway, this might be better than having to create vector child objects to catch clicks over and over again?  I hope so...

Thanks for the tip, if you're still around.   Gentleman

Sprites have a MouseEnabled property which you can set to false, causing all clicks to pass through the sprite and onto the next sprite.

The easiest solution would just be to set anything you don't want clicked at the time to MouseEnabled = false, I think.

Think about the diamonds in isometric RPGs. Each tile sits inside of a rectangle that's 50% transparent, and the opaque sections tessellate the ground.

1. If you click in the transparent region of one tile, it will be clicked, even though you don't want to click it.  You can have a handler that knows to ignore the click, but...
2. Even after the upper tile has been correctly identified as having not been "clicked" (by detecting alpha level of the pixel), the mouse click has already been intercepted before it pass through to the one you actually wanted to click.

It's kind of a mess, but basically, only the stage needs to know about what the cursor is doing, and then click and mouseover conditions can be detected manually by storing mouse move or mouse click events and seeing whether the cursor is on a mostly-opaque pixel.  If two opaque parts overlap, though, they need to be depth-sorted so that the "higher" one still gets priority.

I want to clean up what I've got some more before I share it.  It's far from optimized, though it's probably innately expensive to do it this way.  One basic improvement would be to check bounding boxes first instead of exporting ALL clickable DisplayObjects as bitmap data every single frame.  The more small, clickable objects are all over the screen, the more that difference could matter.  (My clickable objects are expected to not be moving that much, not be that small, and not be too numerous.)
Logged
Pages: 1 [2]
Print
Jump to:  

Theme orange-lt created by panic