Canvas2D Main Post

[Pryme8]

I keep getting a weird error when I try to use this,  I had it working on one local example but now its not... I'm running the most recent Babylon im pretty sure as I just got it from the CDN.

TypeError: BABYLON.ScreenSpaceCanvas2D is not a constructor

and I get it with new BABYLON.Size(#,#) as well..

see: https://github.com/Pryme8/NeatFlax/blob/gh-pages/Tutorial_2/index.html#L454

[Kemal UÇAR]

Hi Nockawa ;

is it possible to video texture on canvas2d rectangle ?

just wondering

[Nockawa]

16 minutes ago, KemalUCAR said:

Hi Nockawa ;

is it possible to video texture on canvas2d rectangle ?

just wondering

please create a brand new topic and mention me for faster reaction, this thread should not be used for questions. thanks!

otherwise I think you'd like to use a Sprite2D with a video texture, I'm sure bjs can handle that.

[Kemal UÇAR]

Thanks Nockawa i will

[Nockawa]

Hello people, it's been a long time I didn't update this thread!

It's not that I'm not working, well, I've recently worked less than expected, but many different things are going on, so it takes longer to release one particular.

Stabilization

The latest weeks were spent on keeping stabilizing the Canvas2D feature, fixing bugs and adding feature only when necessary. Overall bug fixes were concerning Positioning Engine (alignment), StackPanel Layout Enigne, pointerEvent observable (leave/out now works better), some dispose issues solved, you're supposed to have no more opacity/transparency issues (well, let's say, "less").

One new feature

One new feature was developed recently, during the creation of a ScreenSpaceCanvas you can now specify the renderingPhase setting, allowing you specify for which camera and which renderingGroup the Canvas is supposed to be rendered to.
Simpler version: you can now interleaved 3D layers (which are renderingGroup) with 2D layers (which are ScreenSpaceCanvas). Many people requested it ( @MasterK, @HenryPeng, @stormwarestudios) to render 3D content above UI for FX (particles) or simply some 3D preview (like a 3D character preview in a UI). This playground  is a very raw demonstration of the feature.

Modularization

Oh, by the way, I nearly forgot to tell something pretty important: we have recently extracted the Canvas2D feature (and the forthcoming GUI Lib first code lines) from the main babylon.js file. This is the first step of what is going to be a modularization of babylon.js, Canvas2D/GUI being obvious (and easy) candidates.

What is changes for you?

Well, not that much, if you use C2D/GUI you now have to use the "babylon.canvas2d.d.ts", "babylon.canvas2d.max.js", "babylon.canvas2d.js" that are sitting next to the "babylon.js/d.ts/max.js" files in the "dist" directory of your choice (right now only the "preview release" directory contains the Canvas2D related files, for obvious reason. The module's name is still "BABYLON", which will ensure you'll compile without changing anything.

On a repository point of view, the source code was moved from /src/Canvas2D to /canvas2d/src/. Our lovely boss made the move and the Gulp config to compile everything the same way babylon.js does so you don't be lost.

La surprise du chef!

And the "chef" is not me, but another core member @Temechon spent some very valuable time (and I can't thank him enough for that!) to work on a feature I desperately need for so long but that I'm unable to code (well, in the time frame it will took me) which is called: c2dinspector.js.

Basically the c2dInspector is a HTML Pane that is added on the right side of your HTML pane and that displays all the Canvas2D instances in your Scene (well, Engine to be more accurate) and their content as a tree of Primitives.
You can select a given Primitive to see its details on the Detail Plane below, you can even change some values (still work in progress).
In the tree, for each item there're two icons at the very left, an "eye" to show/hide the prim, and a "double frame" which is used to show/hide the debugDisplayArea (more on this below).

This feature will help you (and me!) debug and understand better what's going on and why! It's not released yet, but a beta will be very soon (tonight or tomorrow), it's still Work in Progress, but hey, it's better than nothing and it won't harm you.

The debugDisplayArea (the only thing I coded, bugs are to expect!): as you may know a primitive has four area: layout, margin, padding and content, this feature will display them with a given color code (layout being light red, margin is yellow, padding is magenta, content is cyan). This screenshot below is the same UI as above but with the debugDisplayArea on the "GUI Visual Placeholder of MainWindow", which has a margin of 50, 50, 50, 50 (the yellow area shows it) and padding of 100, 100, 100, 100 (the magenta area show it). The content in blue is the Windows' background, in light grey, which is here covered by the blue area.

GUI Library

I've started the GUI Library, it's going on very well, but I just can't work as much as I wanted on it the last couple of weeks, so there's delay: that's life. There's a separated thread about the GUI here so don't expect me to say more in this post, got watch the other thread if you care about it.

That's all folk, enjoy, as usual: feedback are welcomed, you can do it in this thread of course! I just don't want this thread to be a "bug tracker" one, if you have issue, keep creating a new post and don't forget to mention me as I don't look at the forum everyday to see if someone needs help (but DK does, happy him...)

[jerome]

im

pres

si

ve

[Nockawa]

Hey, me again, I just wanted to notify you of a small little dev that many of you would appreciate I guess.

Until now, pointerEvent occurring above a ScreenSpaceCanvas were also sent to the 3D Scene, many people (rightfully) complained about this so I decided to add the feature, which is called "allow3DEventsBelowCanvas" (which is false by default).

The PR is here for more info https://github.com/BabylonJS/Babylon.js/pull/1448 (preview files updated and PG not updated so far).

You have to realize that this is a change in behavior, now by default events won't be sent to the 3D Scene if they occurred above the Canvas, but I figured it made more sens this way. If you want them to be sent anyway, just set the setting to true!

[Nockawa]

Hello everybody,

I've been working the last couple of days to improve reliability of the different Canvas caching strategies, it's getting better and better everyday, I won't say it's bug free, but we're heading there!

On another note I've decided to rollback the allow3DEventBelowCanvas feature, because it's not as flexible as it should be in it's current state and it prevent you to operate the camera if you have a fullscreen canvas for instance.
I think I need a feature which will be more configurable, I don't have the time right now to do it. 

Just keep in mind that if you can to prevent pointerEvent to fall thru the 3D Scene, all you have to do in your canvas.pointerEventObservable's observer is to set 'skipNextObservers' to true in the EventState object.

Last note: mind that the current implem of the layout/positioning is worst than before...due to a bug fix...yeah, it's not common, but that's the way it is... I will work on it asap as people already report the issue ( @Swiftwork for instance).

But there's also another little surprise I've planned to work on, something that will be big for everybody using C2D. I just hope I won't spend too much time on it...

[Temechon]

Hello Canvas2D fans!

As it was said in a previous post, I was working on creating a debugger to Canvas2D with the help of its creator Nockawa. Here is a beta version : https://github.com/Temechon/canvas2d-inspector/blob/master/dist/c2dinspector.js
This tool can easily display all information relative to a Canvas2D and all its children in a right HTML pane. All data is reloaded in real time!

If you find a bugs, or if you are interested in another feature, please let me know by pinging me on this forum or Github.

I hope it will help you use this awesome 2D engine

 

[Nockawa]

Hello there!

I've got a very good news, well, I think I do!
I've spent the last few days to implement a feature called the Signed Distance Field for Text rendering. @davrous found about this technique few weeks ago and we all thought it would be a great addition to babylon.js and canvas2d.

TL;DR

You can find a small explanation video here.

If you want to see the immediate result in bjs, it's here. (check/uncheck to switch from SDF to regular rendering, see the change of rendering call in the profile view)

More explanation

So why this feature rocks!? There're two main reasons:

1. The text rendering quality is excellent, no matter the size it's displayed on the screen or its transformation (rotation, being not coplanar with the viewport). Because the way the FontTexture's character are generated make it now no more a bitmap representation of the character, but what we call a Signed Distance Field one: we store the distance of a texel from the edge of the Font. Then we rely on the GPU texture's interpolation unit to compute the most accurate value for the pixel to render and this way we have a great rendering fidelity.
2. Right now, if you don't use SDF (Signed Distance Field for short), your text will be rendered in a transparent pass, I cannot stress that enough, because transparent rendering is by far the worst in term of cost, I can't use Instanced Array for everything (even if I've optimized to use them when the sorting of primitive's part makes it possible), so it's many draw calls, and there's of course alpha blending which is not the cheapest thing.
   Using SDF will render your text in Alpha Test rendering mode, just think this mode as being like the opaque one: everything is rendered using Instanced Arrays, the drawing order being not relevant, so it's freaking fast: all the text2D characters of all the primitives using the same font will be rendered in one draw call: you can't do better than that!

Ok, there're no silver bullet, but SDF is close of being one, right now the only inconvenient are that :

• it won't look nice on text being rendered with one pixel wide, like lucida console 10pt, it's not ugly, but it's not perfect either. If you switch to 12pt instead of 10 then the quality is immediately there.
• it takes time to compute the FontTexture because it relies on an algorithm to compute SDF, it takes 80ms on my desktop and 160 on my mobile  phone to compute the ASCII map, well, you're the judge but I think it's fine.

Right now I don't support features such as Outlining or Shadow in FontTexture, so it's also not supported in SDF, but soon I intend to do so and SDF will also be supporting that.

So now you have three modes to render text:

1. Normal FontTexture
2. SuperSampled FontTexture
3. SDF (which ignore the SuperSample flag).

Make your experimentation, but SDF should be your primary choice as much as possible.

One last thing, the rendering quality is now using some kind of antialias, it may be perfectible and also I don't use the derivative functions of the fragment shader which could improve rendering quality when the text is not being co planar to the viewport, I'll see that in a second time.

Have fun experimenting the feature and as always, feedback is welcome (but please create a separated thread if you have issue or question).

 

[jerome]

impressive !

as usual ...

[GameMonetize]

We need a doc update then  (Yeah I know, I suck)

[Nockawa]

1 hour ago, Deltakosh said:

We need a doc update then  (Yeah I know, I suck)

I know I need to make big doc update, there are many features to document, I'll do asap.

[Kaisen]

Does Canvas2D support or plan to support any kind of 2d lighting system?
I'm guessing this can be achieved already, but i think there isn't a built in implementation.
If you render the sprite/2d Image as a texture on a plane inside the 3d render, then any 3d light will also have an effect on it.
But, what I'm talking about is something like this, there are other examples online.

Btw great job this new feature looks just awesome!

[Nabroski]

@Kaisen

I read in a previous tread that @Nockawa make some holidays, he wrote he wake up in the middle of the day, somewhere in south france, have a good meal, drink a lot french wine, and have fun with the girls. 

in your html5 example their is no light, he only adjust the grey level on switch between withe and black, strong contrast. so usually the one who requested a new feature has also to implement it. you can start a little playground with some shapes and some lines, so its highly that your idea becomes a collaborative work. when nockawa is back, he will probably code the rest in 2 min


Turner Whitted 1980

The idea of Ray Tracing is nothing new, a lot a material can be found on the web.

Gook Luck
 

[Nockawa]

@Nabroski Well, I wished I was on holidays, but unfortunately it's less pleasant...

@Kaisen Indeed, there's no illumination model right now and the link you gave is not about lighting, but more shadow. btw, the feature is really cool and typically something that we can afford in 2D but not in 3D.

Nabroski is right about the contribution approach, specially for features like this one, you have to implement it if you want it, but I'll be happy to give help/advises about how to do.

On the top of my mind I would create a "lighting" kinda plugin for RendarablePrim2D, then create a plugin for your lighting system and in runtime create a Group2D, set the plugin, and the lighting is performed using all the children primitives of the Group2D.

If you're willing to pursue this discussion, please create a new thread somewhere appropriate in the forum and mention me. Thanks

[Nabroski]

@Nockawa

as always: you have to fight for your right to party.

[Nockawa]

Hello people, it's been a while. I was unable to contribute the latest couple of months, I'm trying to get back on things slowly.

First thing I'd like to address is the Sprite2D class, its design issues and some new features. @MasterK @grayger @Wingnut @Dad72 and @BitOfGold you should be interested by this post

One thing in particular which is actual badly designed is the spriteSize/spriteScaleFactor/size/scale(x|y) properties. I made some mistakes and the price to pay to fix them will be breaking changes. I know it sucks, but it won't be hard to refactor for you guys whenever you use spriteSize and the change is necessary. Before developing/committing the code, I'd like to explain how these properties are working right now and how they will in the future :

• spriteSize: currently it's the size of the sprite displayed in the Canvas: that's a mistake (more on this below)
• spriteScaleFactor: a property created to balance the mistake of spriteSize (in a way), if you want your sprite to be displayed in the canvas with a size of (400,200) but the sprite's bitmap is (200,100) then you have to set a spriteSize of (400,200) and a spriteScaleFactor of (0.5,0.5). This is lame because if you don't know the real size of the sprite's bitmap, it's difficult to get what you want.
• size: right now size is initialized from spriteSize during construction, hence the behavior of spriteScaleFactor and this is also a mistake
• scale: it's something different from spriteScaleFactor right now but can be used to alter the size of the sprite on the canvas. To have both scale and spriteScaleFactor is currently a necessity, but it's due to bad design only.

Well, this is messy, and it's been a while I know it but couldn't find the time to address this. Now that I'm working on the Scale9Sprite feature and next the TextureAtlas, I'm willing to make things right for the sake of everybody as well as mine.
Here is how things are meant to be as of today :

• spriteSize: will be the size of the sprite as it it in the texture's bitmap. if you don't specify spriteSize, then the whole texture will be used. It makes sense to use it this way, it's more coherent with spriteLocation which is also a setting express for the sprite's texture bitmap.
• spriteScaleFactor: well, this should be at least deprecated and certainly removed for the 2.6 RTM. Because you will rely on the following two properties to get the job done.
• size: it will be the size of the sprite as it is displayed in the canvas. If you don't specify it, it will be the same as spriteSize. If you do, then stretching/resizing will take place to achieve the size you want. If you don't know spriteSize but wish to strech/resize, then you will have to rely on the following property. Note that size if a property of Prim2DBase and all primitive actually use size with this behavior, so it's coherent with the other prims.
• scale: let you display in the Canvas a sprite bigger/smaller as it is in the texture using a scale factor. Same as above, scale is a property of Prim2DBase and all prims use it this way.

So for me there are three main scenarios

1. You don't know the size of the sprite's bitmap, then you deal with scale if you want to display it bigger/smaller
2. You know the size of the sprite's bitmap, then you specify spriteSize and you can also specify Size to override how it must be rendered in the Canvas.
3. You rely on Texture Atlas, then you know the spriteSize and spriteLocation of your sprite and there are many Sprite2D instances sharing the same babylon Texture, it's simple and there are no big changes between the Texture Atlas mode and the regular one.

I don't want things to be overkill but I'm wondering if I should introduce lockRatioW and lockRatioH properties to let you guys the possibility to keep the ratio between spriteSize and size by recomputing either the height or width whenever spriteSize and size doesn't share the same ratio. Tell me if it's useful or not, I need feedback on this.

Well, I also need feedback on all of this, so please, take a little time to think about it and tell me what you think, anybody's feedback is welcomed of course.

If I make such change, then SpriteScale9 and TextureAtlas will be easier to code and especially easier for you guys to use and that's the most important thing right now. I was thinking about developing a new Sprite primitive, but there's no use, it's the current one that is not designed correctly enough.

[MasterK]

i think the param names can be discussed. other things just make them working~

"defaultFontColor" is the most bad...

[Wingnut]

Wow, thanks for all the info, Nockawa!  You want feedback in this thread?  This has sort of been your Canvas2D announcements-only thread.

I expected breaking changes... it's part of the dev process.  No problems for me, but I don't do big or commercial projects... so I'm not the last word on that.  I hope the impact for others... can be as minimal as possible.

I am a little concerned about containers.  I think, no matter what, a child should not be displayed outside of it's container.  Mainly, I'm talking about Prim2D's inside of rectangle2d's.  Currently, rect2D's are our border makers.  No other Canvas2D elements... can do borders... as far as I know.  createCanvasProfileInfoCanvas() has a border, but it has 2 children... the first being a rect2D, it seems.

Soooo... are rectangle2D's also going to be a "flow container"? 

Will things "wrap" within a rect2d?  (refuse to allow display outside of its bounding box?) 

Can we expect to use percentages inside a rect2d or whatever flow container gets invented in the future?

If we scale a rect2d or other flow container, will its children scale proportionally?

Could scaling one prim within a flow container... cause a re-wrap calculation?  (due to the new scaling of the child... possibly causing an overflow?)

Can we expect user-control over scrollbars when a flow container overflows?

To be blunt, I think it will be difficult to determine... what scaling tools will be needed for a Prim2d... without first designing the flow container that will be used to contain Prims.

The flow container will likely need to query the prims contained therein... to determine how to flow its children.  And through it all, the rect2d must maintain its perfect border, no matter how thick, no matter how curved its corner radius, no matter lots of things.  Rect2d or whatever the chosen flow container device... can also contain other rect2D's and other screenSpaceCanvas2d, both of which allow curved corners.  (curved corners on containers... is not friendly to bounding box calculating). 

For example, what happens when a square Prim2d is put in the corner of a rounded-corner ssc2d?  Which wins?  Does the ssc2d round corner... block part of the square Prim2d... from view?  Or does the square Prim2d sit top the rounded corner of the ssc2d, and hide its curved corner?  Would the "wrap this Prim2d to the next line"-trigger... when an overlap like that... happens?

Ya know, I would consider saying goodbye to rounded corners on screenspace and worldspace canvas2d. 

IF rect2d's are to be flow containers, then even rect2d's rounded corners could be a pain in the butt for determining wrap triggers and overflow triggers.

hmm.  Just maybe... create a new class called Border2d.  Then remove borders as an option for rect2d.  In fact, remove rounded corners for ALL Prim2d... except border2D.  Maybe even remove the rounded corner option for canvas2D (screen space and world space). 

Now give the new Border2D a whole bunch of brains and power.  Borders would become an add-on layer... and allowed on ANY prim2D or canvas type... but it isn't calculated into bounding box measurements, or into overflow/wrap considerations. 

Nockawa, all your calculations would become "square" again... no rounded corner hell at all.  The ONLY way to get a rounded corner or a border on ANYTHING in the canvas2d system... is to add a border2d.  Seeing border2d is not considered in wrap/overflow, a border-adorned prim2d positioned along the far right edge of a container... COULD lose the right side of its border (it lands outside the container), yet the Prim is not yet causing overflow.  The Prim itself has not yet moved far enough right to cause wrap/overflow.  But the border2d right side is not displayed.  Make it so borders can't cause overflow/wrap.  Only the Prim they "overlay" (surround) can cause wrap/overflow.

Borders (border2d) becomes a "special" thing.  An adornment.  A late-add.  Top-most layer.

NOW... your scale9sprite has changed, hasn't it?  Now, 8 images are put into a border2D prim, and one center image on the prim within.  *shrug*  Just thoughts.

Long ago, I proposed the same thing to the W3C CSS working group.  I told them that border width was fighting with margin width and padding width... for space.  If a box model had a padding of 10 pt (space between content and border)... and a margin of 10 pt (space between border and other nearby box models)... and then you set a border width of 6 pt... then does the border use 3 pt stolen from padding, and 3 pt stolen from margin?  In other words... the 6 pt border width FORCED padding and margin to be 7pt.  (because a CSS border is positioned "between" padding and margin.)

That's not the way it works, though.  Border-width is given power... power to wedge itself into the padding-margin intersection, and separate them.  With me?  Anyone?    A limp CSS "adornment" such as borderWidth... has the power to change the overall size of the entire box model... and box model size is what is used by browsers... to determine wrap and overflow.  Some of us CSS weirdos... think that is too much power to give to a CSS property.      Thoust shalst not allow Christmas tree ornaments... to change the size/shape of the tree itself.    (see separation of content from presentation, below)

I suggested borders be another HTML element... added late... and they sit atop the surrounded element... on another layer.  Now, ALWAYS... margin and padding intersect.  No longer did border width... affect the overall size of an element... and then you don't ever have to honor border-width in wrap/overflow calculations.

You see, it has to do with the separation of content, and presentation... something the W3C/CSS welded into our brains as a super-important thing.

SO... SHOULD a CSS property such as borderWidth... be allowed to have a say... in WHEN/HOW a span/div wraps/overflows?  Hell no.  Borders are a CSS "adornment" and they should NOT be honored in content "flow".  That's how to properly separate content (html nodes) and presentation (css style).

But here we are today... with border widths getting to have-a-say in when a line overflows/wraps... and the separation of content and presentation... has failed somewhat.  Make borders a "late-add"...  part of a "last layer painted" thing... and the screen flow becomes more sane.

Anyway, thanks for reading this, whomever did so.  Border width has always haunted me.  It gets in the way of things.  Does anyone else "feel" this same weird feeling?  Borders should be different from everything.  Special.  They know how to position themselves and scale themselves, and you can clone them, and wrap them around ANY content, and they have special powers to try to make themselves look perfect.  They don't have to follow the same rules as "content primitives" because they are an "adornment primitive"... a decoration.    Just a theory and possibility... likely not a good one.  heh

[stormwarestudios]

To the changes to Sprite2D, I would ask, "how are sprites typically authored for BJS games?"

I had done some work in the past with Phaser.js, and used tools like TexturePacker to compose / optimize sprite sheets; short version is it reorganizes sprites in a meaningful way, and gives you a JSON output file for locations and dimensions for sprites.

If the common behaviour is to use a tool like this which typically authors content as you see fit, then I'd say Scenario #3 would be the most common, and likely the most desirable in the long run (who wants to hand-code sprite dimensions? show of hands?) so I would say it makes the most sense to have that piece the most up-front, polished and pretty.

I don't know many useful situations for scaling sprites where ratio is not 1:1 but the forefront one in my mind would be skinning GUI elements, and using scaling backgrounds for borders of things (like CSS border-image-repeat, except stretched) but even that seems like a ... stretch lol. So maybe having the ratio lock on by default is more useful.

Great work so far, and thanks for all that you do for Canvas2d!

[Nockawa]

@Wingnut well, I was expecting feedback concerning Sprite2D, but well, I can try to answer some of your questions/remark. 

• Every Prim2DBase based Primitives (which is all primitives) are acting like container: they can have children Primitives. The content is not clipped by its parent shape mainly for performances concern: implementing such feature wouldn't be an easy task and the rendering perf would be drastically reduce. I would have to draw Primitives in a specific order (bye bye Instanced Array, which leads to many more Draw Calls) and using the Stencil Buffer to perform shape clipping.
  So I know this is a limitation right now, but it typically a feature with a very high dev/perf cost compared to its benefits, hence the reason not to dev it so far.
• A Rect2D with Round Radius will reduce its content area, if you want to test this, just go to this PG: http://babylonjs-playground.com/#2DD9TG#3 and play with the ShapeRoundRadius setting (initiale value of 10), you will see that raising this value for the green Rect will make its blue child rect smaller, so this is the kind of behavior you wish, it seems.
• Flow/Wrap/Scrollbar will be feature of the upcoming GUI Library if they must be implemented. Scrollbar will be for sure.
• For me, your Border2D proposal is what is doing Rect2D so far, but maybe I'm wrong and it's not totally accurate.
• At last, there's actually a bug which prevent to compute the content Area of any kind of Primitive when it's autoSized. Say a Group2D's size computed from the content it has: many Rect2D prim for instance. This bug is pretty hard to resolve but once it will be done people will be able to use hierarchy to build container of any kind very easily.

[Nockawa]

2 hours ago, stormwarestudios said:

To the changes to Sprite2D, I would ask, "how are sprites typically authored for BJS games?"

I had done some work in the past with Phaser.js, and used tools like TexturePacker to compose / optimize sprite sheets; short version is it reorganizes sprites in a meaningful way, and gives you a JSON output file for locations and dimensions for sprites.

If the common behaviour is to use a tool like this which typically authors content as you see fit, then I'd say Scenario #3 would be the most common, and likely the most desirable in the long run (who wants to hand-code sprite dimensions? show of hands?) so I would say it makes the most sense to have that piece the most up-front, polished and pretty.

I don't know many useful situations for scaling sprites where ratio is not 1:1 but the forefront one in my mind would be skinning GUI elements, and using scaling backgrounds for borders of things (like CSS border-image-repeat, except stretched) but even that seems like a ... stretch lol. So maybe having the ratio lock on by default is more useful.

Great work so far, and thanks for all that you do for Canvas2d!

Your first question is the point of my previous post, indeed, I can't imagine a serious game/app dealing with Sprite2D declared manually in the code and with one texture per Sprite. TexturePacker is a very good tool, I've played with it yesterday and the JSON Array data exportation format will be really easy for me to support. The free version seems to be already pretty good feature-wise and the complete version is not that expensive.

So basically my proposition is to create a bunch of Static methods in Sprite2D to create one/many Sprites from a Texture loaded along with a AtlasInfo object that would have been previously loaded from a file (with the possibility to handle more than one data format, JSON Array being the default/standard one). So typically, the user would :

1. Load the Texture manually
2. Load the AtlasInfo from a data file using a static method in Sprite2D (it may not be the best place for this method, but well, I can't see a better one). This method will be able to support third parties data formats to ensure that people converting from Unity, Coco2d or anything else will be able to keep their original asset. The AtlasInfo would also contain a reference to the involved Texture, I think they are tightly coupled: there's no reason to handle two objects, one is easier/enough
3. Load one/many sprites from the Atlasinfo using the Sprite's Name as Id. Maybe with the possibility of supporting wildcard, I don't know...

On the rendering/performance side, all Sprite belonging to the same Texture will be drawn in one DrawCall if Instanced Array is supported and if they don't require sorting due to transparency. If there's transparency, depending of the order it can still be pretty optimized. (e.g. if there's n Sprite using the same Texture having a consecutive order, which means without another prim in the middle of it, it will still be rendered in one Draw Call)

[Wingnut]

Thanks Nockawa... and sorry for wandering-off the sprite2d subject.  Thinkin'. 

I really don't have much experience with sprite2d, but, it would be excellent if all the prim2d's have similar/common properties. (and they do, to some degree... properties inherited from base class Prim2d). 

A property like spriteSize is special to sprites, of course.  Do you foresee rectangleSize, shapeSize and textSize properties for those 3 prims?

*shrug*.  It seems that spriteSize and spriteLocation "bastardize" the sprite2d prim, to a degree.  They are special to sprites... because images are special to sprites.  So is sprite animation.

But, doesn't this make you want to invent image2d/texture2d... and for users to create a sprite, some universal container needs an image2d as a child?  (I know, strange thought)

Rectangle2d is already a "universal container" to some degree... so a sprite2d could be a rect2d with an image2d/texture2d as a child.  errr... maybe not a child.  Maybe as a rect2d .background.  Then eliminate sprite2d forever.

Now the sprite's size and scale follow the same "template" for sizing and scaling... as rect2d.  Image2d would contain all the specialty stuff for image work... like imageSize, imageLocation, animation methods, etc.   *shrug*.  Image2D/texture2d then become a re-useable prim... for backgrounds of text2d, rect2d, and shape2d prims.  Just set their .background to be an image2d.

I dunno.  Too much thinkin' on my part.  heh

Probably a bad idea, and it would certainly make sprite creation... a multi-step act.  (no longer a one-liner).

I would love to see a movie of "Everything Nockawa ever thought about... during Canvas2d dev"    Probably a 36 hour run-time on that movie.

[lihis]

32 minutes ago, Wingnut said:

Rectangle2d is already a "universal container" to some degree... so a sprite2d could be a rect2d with an image2d/texture2d as a child.  errr... maybe not a child.  Maybe as a rect2d .background.  Then eliminate sprite2d forever.

Yeah i kind of like the sound of that.

I also agree with @MasterK about the naming of things, more cleaner names would be nice. defaultFontColor would in my opinion be better just as Color, fontName maybe just font, fontSignedDistanceField just SignedDistanceField or whatever. Stuff like that, get rid of the extra clutter. Then perhaps Rectangle2D fill could be called background (or remain fill i don't know whateves) and be like in CSS style where you can put either image or color as background.

About the atlas thing, i don't know where i'd use it yet so no idea how i would like it to work.

Edited December 29, 2016 by lihis
quote updated