Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by dmko

  1. hehe - seems I had a few tabs open and got a bit confused about which thread I was responding to It's totally relevant here though! I'd like to get the scene shown at http://editor.babylonjs.com/ as a glTF file w/ assets, would be great if someone had that available
  2. I'm playing around with glTF and the babylon demo scene in that editor looks great (plastic, metal, spheres, fast load time...) Has anyone got a glTF version of it available for testing outside of babylon? I'll look into converting it myself, just thought someone might have already done it
  3. In this sense nothing changes. You're not adding/removing elements from the page, you're wrapping all the imperative canvas calls up in a declarative framework. The same way React-DOM deals with all the element.innerHTML stuff, your react renderer (or components) deal with all the canvas.draw (or rather, PIXI.*) type calls - but on the app level you don't touch any of that, you just write the changes declaratively.
  4. @caymanbruce Thanks for bringing this thread up - I should note that my experiments here were superseded at this other thread: I don't know anything about Angular. With React, essentially, there's two approaches 1. Using React as-is with the built-in React-Dom renderer. With this approach, there's nothing really special going on, you just handle all your imperative PIXI updates in render() or one of the other lifecycle methods. To make it worthwhile, you'd probably want to create some boilerplate components that do this for you and expect certain props to exist. E.g. a Sprite
  5. dmko

    Vue js hot reload

    Also just to add if you call app.render() directly, you should setup the PIXI.Application with `autoStart: false` I'm not sure if it makes a difference practically (e.g. double-render somehow), but it can only help
  6. I created a very early, very alpha React renderer for PIXI. There's some other projects out there but I wanted to start from scratch. You can get it at https://github.com/dakom/react-pixi-renderer However, be warned, performance kindof sucks if you use it for lots of nodes. See this test/demo I wrote that tries to figure out where the bottleneck is: https://dakom.github.io/react-renderer-test/ Turns out that the bottleneck is basically React itself and the size of the tree. The React-pixi-renderer could be really useful for declaratively describing a few of a small number of ite
  7. Okay I added a clean baseline version: https://github.com/dakom/baseline-pixi-bunnymark No comparison (it takes me like 100,000 bunnies to get to where react crawls at 8,000 and it’s still more responsive) :\
  8. Yeah, for this context I'm focused really on using it with react (or as I'm now looking into, maybe Inferno) Cool stuff though and reminds me that I'm missing a baseline comparison hehe... will write that now Right on, that's what I meant by like "built-in ability to "removeChild" when the JSX changes" but you nailed the overall idea in that sentence. It would be super awesome if that were possible imho, I don't think it would be rubbish unless it introduced a bunch of restrictions like specific props you have to pass in etc (kindof like in my implementation, where you have
  9. Yeah - everything you're saying is spot-on @mattstyles The performance killer here is definitely React as far as I can tell. This attempt to use React as-is and simply render `null` does rely on lifecycle methods so stopping propagation via shouldComponentUpdate isn't going to work completely. I did change everything except `withPixi` to be PureComponents just now though - negligible gains. I'm not aware of how to bypass all that evaluation stuff... I looked at react-pixi and couldn't make heads or tails of what's going on there and I'm not immediately convinced without seeing
  10. FYI here's a screenshot of some random-ish stats from a long frame in development mode:
  11. Just pushed an update - might take a little bit for Travis/github, but testing locally - it didn't seem to fix it, I think it's probably something with React itself :\ Btw I suck with profiling, when you have a minute can you take a couple screenshots to show me where you see that 19% GC stat? Shutting down for the night, thanks for taking a look
  12. Sorry - yeah Fuse-Box doesn't have source maps working with minification yet :\ Hmmm that's interesting about the GC - just for fun I'll see what happens if the update objects are made mutable
  13. OK here is my attempt at it: https://github.com/dakom/react-pixi-bunnymark Performance is awful. Very happy to know if there's some key thing I missed to optimize (though maybe prove it with a fork or something... of course there's lots of things that can be made better but might not add real big numbers)
  14. Ah - so I'm looking at more for describing the PIXI scene itself, not for additional UI. I'll try to mock up the bunny-mark test and put it on github for all to fork and tinker with. I actually may need to use this approach for an upcoming project so I'm very interested in any gotchas
  15. I haven't done a ton of React stuff but I am tinkering a lot more lately Here's a little JSFiddle to benchmark - it doesn't include PIXI stuff but just to see how long it takes to get from a render on a parent to an update on a child, and I think this is roughly the way I'd structure a React+PIXI app (the pixi updates happen in the child's componentWillReceiveProps() - and the render() from child would just always return null) https://jsfiddle.net/dakom/e65tbxsy/ I'm getting less than .1ms between the parent's render() and the child's componentWillReceiveProps(). Assuming I benchm
  16. Oh my problem was on my side... was pointing to the wrong target
  17. It's a debatable topic, that's for sure. On the one hand - you're of course right, GC sucks for games and creating a bunch of objects is a no-no. On the other hand - code that's easy to reason about is a huge win for lots of reasons. I'm working on something which I'll hopefully share in the next week or two, it's really just pong but using some functional programming and object-copying stuff. The neat thing is I'm pushing all of the game logic off to a web-worker. Theoretically, browsers are allowed to compartmentalize GC per thread, and those that do (if they do) would get the
  18. I guess you can get the pixel data via something like http://pixijs.download/dev/docs/PIXI.extract.WebGLExtract.html#pixels Though once you have that, for a space shooter you're in real trouble because you really need to test against the in-between frames too For example let's say frame 1 your scene is like this ----- BULLET ------- TARGET ------ And then in frame 2 it's like: ----- TARGET ------ BULLET ----- So we know the bullet passed _through_ the target between renders - and when you're just calculating against simple shapes like via `distance` it's no big de
  19. Yeah that's basically the idea, trying to get more into functional stuff and keep things pure... in this case we're mutating the "this.children" anyway so there's no point really, but still - trying to force myself into new habits Not sure why the action isn't working for me yet, maybe I'll add a fiddle here tomm...
  20. I'm still having some weird stuff happening where the same code run over two different objects is having the opposite effect. In other words, for the more recent object (starting at top layer) things work correctly. For the first object (starting at bottom layer) the action is refersed ("send to back == send to front and vice-versa") It's almost like the ordering is affected by setting children(), but it's somehow affected by the original placement too? Not sure... will revisit on Monday probably. Have a good weekend!
  21. So it's more on the js side? e.g. the WebGL side sees an array of values and uploads it to the buffer when there's a change, regardless of how much of it changed, but the JS side populates those values through lots of processing?
  22. When you have time, can you explain a bit more about the reason behind that? Is it on the JS side or WebGL side? I'm only starting very very slowly to get into webgl stuff... really don't know what I'm talking about yet (waiting for first book to arrive!) - but I'd think that filling a buffer with different data is relatively cheap?
  23. This is surprising to me! I would have thought that a graphics item doesn't really care much about what's in it, more like the size of it. Interesting
  24. Hehe cool! Yeah the partial application thing is a habit I'm getting into from more and more functional programming type stuff. It's soon to be the default way things are done in the Sanctuary library - https://github.com/sanctuary-js/sanctuary/issues/438
  25. I'm trying to implement a simple "move to back" / "move to front" without relying on the heavy lifting of something like https://github.com/pixijs/pixi-display Here's my ordering code, but it doesn't seem to always work... though it does work some of the time... I think it looks like for some of the items it works but in reverse? What am I missing? //moves an item in an array to either the front or back export const PopTo = (isFront:boolean) => items => item => { const copy = items.concat(); const ret = copy.splice(copy.indexOf(item), 1); return (isFront) ? ret.c
  • Create New...