Comments (11)
Moving the layer property to Graphic is in my opinion a nice solution. This allows each graphic to render to an individual layer which would do wonders for top down perspectives among other neat tricks. However, just doing that is not backwards compatible.
To accomodate that minor inconvenience, and also add some additional functionality, the layer field of the entity could be changed to a property and a bool be added to the entity such as 'forceLayers'. This way, if forceLayers is true, the Entity sets the layers of its graphics to the same layer that the entity is, maintaining the same functionality that is in the current version of FlashPunk. And you can still hack in rendering code the the entity if needed.
But this poses a problem as well because the child graphics are now forced to change their layer. Being able to switch a graphics back and forth between its parent entities layer and its layer may also be needed. This could be addressed with an ILayerable/IRenderable interface that is implemented by Entities and Graphics, and also would clean up rendering code as there wouldn't have to be checks to see if some renderable Item is a Graphic or an Entity.
Another added benefit to the Interface approach would be that GraphicLists could also force layers for its children, or not.
My two cents. Hopefully I was clear...
from flashpunk.
But this poses a problem as well because the child graphics are now forced to change their layer. Being able to switch a graphics back and forth between its parent entities layer and its layer may also be needed.
Can you restate this? I don't think I follow you here.
This could be addressed with an ILayerable/IRenderable interface that is implemented by Entities and Graphics, and also would clean up rendering code as there wouldn't have to be checks to see if some renderable Item is a Graphic or an Entity.
When would there be ambiguity whether a renderable thing is a Graphic or an Entity?
from flashpunk.
The ambiguity I am referring to is in the render function of world which currently loops through a linked list of entities, but could loops through a LL of IRenderable.
But this poses a problem as well because the child graphics are now forced to change their layer. Being able to switch a >>graphics back and forth between its parent entities layer and its layer may also be needed.
Can you restate this? I don't think I follow you here.
Yeah that was a bad explanation...
The problem I am talking about would be that each Graphic has it's own layer Field. When its parent entity changes that field, that field cannot be reverted to its previous value unless its previous value was stored before it was changed by the parent entity.
And since I am revisiting this, an minimal example interface:
public interface IRenderable
{
function get forceLayer():Boolean;
function set forceLayer():void;
function get layer():Boolean;
function set layer():void;
function get next():IRenderable;
function set next():void;
function get prev():IRenderable;
function set prev():void;
function render(target:BitmapData, ...):void;
}
Having this interface opens the option to render objects whose class is something other than those that have a render function currently in Flashpunk.
EDIT: But interfaces are also counter to the current standards within Flashpunk.
from flashpunk.
Idea (which I don't think I necessarily like): Have graphic.layer be relative to the containing Entity's layer.
So entities are rendered at entity.layer
, and graphics are rendered at graphic.layer + graphic.entity.layer
This way, you don't need an extra boolean property lying around, and legacy code works because graphic.layer = 0 by default...
(Possibly you'd want to call it graphic.layerModifier or something better, to make it more obvious that it's always relative).
Also: the reason renderPrev/renderNext exists is actually a performance optimisation that would be negated by having them accessed by a getter/setter.
I'm not 100% opposed to interfaces: if the user never sees them then it doesn't matter so much if it matches the current standards.
from flashpunk.
I didn't think about the performance hit from the getter/setter. The interface was simply a suggestion to impose a standard. I don't necessarily think one is needed.
What if graphic.layer defaulted to -1 and graphics are rendered at:
graphic.layer == -1 ? graphic.entity.layer : graphic.layer;
That gets rid of the boolean and is a 'little' more intuitive than the graphic.layer being relative the it's entity. I'm kind of on the fence with this though because I can't think of anywhere in FP there is a default behavior if a value is outside of it's regular bounds.
Hmm. I'll think on it some more.
from flashpunk.
Definitely nope to -1: that's a perfectly valid layer value. If we had to use a magic constant it should be ridiculously large, but I'm uneasy about that still.
from flashpunk.
I'd rather use a bool than a magic number tbh. And I can't really think of any good way to get around having a bool other than your suggestion that a graphic render relative to its parent entity. But even that could be problematic because what happens when an entity changes its layer? How is the graphic informed so it can change to the proper layer? Maybe: graphic.updateLayer();
from flashpunk.
Entities always know which graphics are attached to them, so I don't see that as a problem.
from flashpunk.
I'm leaning away the graphic.layer being relative to its entity. It is an elegant solution codewise, but it is not particularly intuitive in use. It is inconsistent with common practices. Most people are going to be accustomed to layers being on a global context, not its parents context.
Why not just add the bool property instead of the function? Or maybe both even. It's not like it is creating a significant amount of bloat, especially considering the functionality that is gained.
from flashpunk.
Observation: if we're adding a boolean property that will need explaining, we could have it be Graphic.layerIsRelative
(or something more snappily named). That would basically combine the two options.
Why not just add the bool property instead of the function?
Instead of what function?
from flashpunk.
Instead of what function?
Graphic.updateLayer();
But in light of your observation, I am retracting that. I think that that right there would be perfect. It maintains the default functionality while offering two alternative, more capable methods of layering.
from flashpunk.
Related Issues (20)
- Sfx volume not changed when type's global volume is set to zero HOT 2
- onActivate/onDeactivate HOT 1
- PreRotation + Flip = Weird
- Is there a reason Input.update is called after update()? HOT 1
- Draw.text() eats up a LOT of memory. HOT 2
- Text Anti-aliasing through options HOT 2
- World's internal linked lists (as well as Entities') should be made public HOT 12
- Console.log() falls when arg is null
- When Tweens are completed, the target value should be exactly the one provided HOT 4
- FP utils functions need optimisation
- Add zoom function to FP.screen
- Entity.removeGraphic and World.removeGraphic?
- Document workaround for Text class that avoids tinted background color
- Worlds: controlling update sequence. HOT 1
- Fix Tween.tween() and autoStart HOT 5
- using 0 in Tilemap.createGrid() sets empty tiles as solid HOT 4
- We need milestones HOT 13
- recyleList() and collideLineInto()
- Behavior of 'color' and 'alpha' parameters in Draw.as functions inconsistent
- Worlds and Entities can have render() called before first update() HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from flashpunk.