user471

Members
  • Content Count

    35
  • Joined

  • Last visited

About user471

  • Rank
    Advanced Member

Recent Profile Visitors

567 profile views
  1. Why couldn't it be cached? So it would need a recalculation only if one of the children changes its position or size.
  2. If I have complex tweens animation with many different objects and I need to use it many times I think sometimes it would be more efficient to convert it to spritesheet animation. Is it possible and does it make sense to do that?
  3. What do you mean? You can do something like this function waitAllOnce(signals: Signal[]) { const signal = new Signal() var count = 0 signals.forEach(x => x.addOnce(() => { count += 1 if (count == signals.length) { signal.dispatch() } })) return signal } Every time you need to use EventEmitter you have an asynchronous process and you need to wait for the value. So if a game doesn't use too much events it wouldn't be a problem. But if it's something like a puzzle game it's very similar to web app, just a complex UI. If it uses tweens for animations and you want to do something after this animations you can use Event Emitter, but it's just easier to use some abstraction over it.
  4. I know. The problem is promises doesn't fit because they doesn't support subscription and Rx is to heavy, so I am looking for something like Rx but lightweight.
  5. When JS is moving from callback hell to abstractions like Promise and Rx why would I what to use callbacks? It's much easier to work with Signals. For example when I need to wait all events to complete I can do something like this waitAll(x.onComplete, y.onComplete, z.onComplete).addOnce(x => ...)
  6. Phaser 3 uses eventemitter and callbacks and I want something similar to Signals from Phaser 2. What should I use?
  7. You can use onUpdateCallback, value should be equal 1.0 on hit
  8. I cannot reproduce the error and the game works fine for most users, but some users experience this error: Cannot use 'in' operator to search for 'imageSmoothingEnabled' in null And it occurs only in Chromium browsers. Game settings { width: 2080, height: 1280, renderer: Phaser.AUTO, parent: "game", transparent: true, disableVisibilityChange: true, failIfMajorPerformanceCaveat: true, } Object.getSmoothingPrefix at line 3:507589 new s.CanvasRenderer at line 3:192693 i.Game.setUpRenderer at line 3:289390 i.Game.boot at line 3:286307 i.Device._readyCheck at line 3:497824 It looks like CanvasRenderingContext2D is null in some cases. What could be the reason?
  9. user471

    Layout engine

    Is there any library which could do something like this. I have three sprites and I want to place them horizontally with some margin. So, instead of calculating their positions manually, I want to do something like this. var stack = new HorizontalStack();stack.margin = 10;stack.addChild(sprite1);stack.addChild(sprite2);stack.addChild(sprite3);If such thing doesn't exist, what would be the best way to implement this? I guess I can inherit HorizontalStack from Container. What would be the best place to recalculate children positions?
  10. >Because creating, modifying, or in any way changing DOM is expensive. I think I understood what was wrong with this conversation. No, I am not talking about this aspect of virtual dom. If you use FRP approach, it is much easier to recreate the whole UI every change of the state instead of modifying UI directly. So, I need to recreate the whole UI object model. For example if I have timer, then render function always return new text object. render time = h("text", {text: time})and it is completely different from the common approach var timeText = new PIXI.Text();changeUI time = timeText.text = time;That is why there are two options 1) I can recreate the whole Pixi object model 2) I can recreate the whole virtual dom object model. Virtual dom model is much lighter than Pixi model. So it is preferable to work with virtual dom, compare two states of it, and apply diff to the real Pixi dom. It isn't because I think changing the Pixi dom is expensive. It's because I need to recreate the whole object tree after every change. Is it clear now?
  11. I think you don't understand how virtual dom works. You create virtual dom var vNode = h('container', h('text', {text="123"}))then you create dom from it var stage = createElement(vNode)renderer.render(stage)then you create completely new virtual dom var vNodeNew = h('container', h('text', {text="456"}))then you create a diff between two virtual doms diff = diff(vNode, vNodeNew);and you apply this diff to the dom How does it suppose to work with pixi "virtual tree"?
  12. >Yes, the DOM has treelike structures too, but just because PixiJS and the DOM share a common abstraction does not make them the same thing. It doesn't really matter. The question is what will be faster - changing Pixi object or create new one. xerver said the changing is faster, so then virtual dom is needed.
  13. >The second is way more work. Then why everyone is saying than virtual dom would be useless? With virtual dom you can change objects, but without it you can only recreate them.
  14. Is Pixi not have any cache? Also, for example I want to change text, so I can 1) Change property in existent text object text.text = "new text" 2) Destroy previous one and create new text.destroy(); text = new PIXI.Text("new text") Would it be the same operations, performance-wise?