• Content Count

  • Joined

  • Last visited

About stormwarestudios

  • Rank
    Advanced Member
  • Birthday 06/19/1978

Contact Methods

  • Website URL
  • Twitter
  • Skype

Profile Information

  • Gender
  • Location
    Cambridge, Ontario, Canada

Recent Profile Visitors

1057 profile views
  1. Hello, I'm (slowly!) building the GUI for my game, and I believe I have a use-case which the current API does not cover. I have a workaround, but I thought I would discuss it here. The game itself is a client/server model (websockets for transport), where various states of the GUI are loaded from the server once the user has jumped through the usual hoops (auth, chosen context, etc). For example, the current feature I am developing involves Slider controls. What I want to do with the sliders is three things: Once the hoop-jumping is done, Slider state is loaded from the server, and the Slider value is set. A player may be an initiator of a Slider value-change, whereby I use the onValueChangedObservable event to send the change to the server. Such changes are broadcast to all players sharing a similar context. A different player who shares context as #2 may be a receiver of a Slider value-change (e.g. as done by a player in #2), whereby I must update the Slider value without triggering onValueChangedObservable and just cause the slider appearance to be modified. In the case of #1, when I load the Slider value from the server and set Slider.value = newValue, this triggers a onValueChangedObservable, which pushes the change to the server, which would broadcast the value change to all clients in the same context, which would cause their Sliders to update, which would trigger onValueChangedObservable, and so on, until a rift in the spacetime continuum appears. In the case of #2, the same sort of thing may occur, except initiated by a player. What I have done to avoid the onValueChangedObservable trigger, is to call: Slider._value = newValue; Slider._markAsDirty(); This works perfectly, and does not trigger onValueChangedObservable. However, it feels ... dirty. Is there a better way to handle this? I suspect I'll get deep into this pattern once I get to the rest of the types of controls I have planned.
  2. For anyone coming across this in 2018, the problem is solved in Babylon v3.2.0-alpha0; however, you may need to lower skybox texture sizes to 1024x1024 if they are higher. I've been able to get this to work without the engine._badOS = true and without noMipMap set to true, using 1024x1024 skybox textures. When using something higher (all 2048x2048, for example), only one side appears.
  3. Any indication when Babylon 3.2 will make its way to Github? Thanks for the feedback to my questions!
  4. Hello! I've been diligently working on my game, and recently came upon the recently released BabylonJS v3.1 ... and I am super excited about NullEngine! My game is multiplayer client/server; the server component is Node.js running ActionHero v18 (and of course the client is running BabylonJS!). Taking a look at the documentation and accompanying example for NullEngine, it seems it does not run 100% out of the box. However... I've been able to get everything up and running under Node 8.9.3 with a combination of mock-browser, EventEmitter, xhr2 and sheer luck // assume this file is saved as mock-browser.js 'use strict'; const EventEmitter = require('events'); class ProgressEvent extends EventEmitter {} module.exports = { setupMockBrowser: () => { const MockBrowser = require('mock-browser').mocks.MockBrowser; const AbstractBrowser = require('mock-browser').delegates.AbstractBrowser; let window = MockBrowser.createWindow(); let opts = { window }; let browser = new AbstractBrowser( opts ); global.window = window; global.navigator = browser.getNavigator(); global.document = browser.getDocument(); global.XMLHttpRequest = require('xhr2').XMLHttpRequest; global.ProgressEvent = ProgressEvent; } }; To use this, it is as simple as: require('./mock-browser').setupMockBrowser(); I'm curious to know a few things: 1) Since the game supports multiple users interacting in different areas (e.g. multiple "rooms", multiple users per room, users can only interact with others in the same room) it makes sense to me to manage these "virtual player namespaces" separately, as one BabylonJS Scene per "room". Does this sound like a good way to divide up the game? Are there software limitations of managing multiple scenes simultaneously? 2) Since the game-server has many other responsibilities (database saves, websocket clients, periodic tasks via a task-runner) it seems wisest to manage the client-side-equivalent of the "render loop" in a periodic task, which would be responsible for updating objects' positions based on velocity, testing collision, and issuing events (via websockets) to game clients based on movement updates/positioning rather than the typical engine.renderLoop(). I don't need the updates to be real-time, but do need them to occur 'quickly enough' (e.g. every 100ms) that my game-server can keep up with the number of objects per-scene. Does managing my own engine.render() seem sane? (Now that I write this out I feel that updates and rendering are unrelated. I guess we'll see...) 3) For geometry collision, I'd like to have "proximity" and "actual" collision-testing; perhaps BoundingSphere for quickest/optimal proximity-testing, and BoundingBox derived from a mesh for actual collision. Good idea? Terrible? I'd love to hear the community's thoughts, and thanks for the amazing NullEngine update!
  5. Hi Nockawa, This looks great, I'm anxious to apply this to my own game! :-) I am deep in back-end country, so I will try to check these out as soon as I get past my current task! All the best, - Peter
  6. Disagree here; pixel art is created with pixel-integer resolution, then converted to real numbers on rendering in GL. It seems unorthodox to have to convert from pixel to real numbers for artwork, but accuracy should be more desirable.
  7. 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!
  8. Tinkering with the PG tonight to learn about Canvas2D, and a thought occurred to me: "Has any crazy BJS dev put a full playable game into the playground?" Could be Pac-Man, could be Doom, could be anything really, I am just curious! :-) Cheers and happy Sunday evening (or Monday morning for those of you east of me!)
  9. Just wanted to update that there has been no update yet... :-\
  10. I happened to Google for "Babylon.js Shirt" and came to this thread, but David's Zazzle link is dead. Is this still a thing? Thanks! </thread necromancy>
  11. Hello, I am experiencing this as well... thought I was going crazy until I did a bit of searching and came across this thread. I'm on macOS Sierra 10.12 (16A323), noticed this bug after I'd updated. Confirmed my code (similar in function to OP's code) still behaves as expected in Safari (Version 10.0 (12602., however, Chrome (Version 54.0.2840.71 (64-bit)) exhibits the one-side-per-skybox bug. Related to this, I've tried engine.enableOfflineSupport = false but no change in behaviour. I've reported this through Chrome's help tools, if there's a better medium please let me know...
  12. Well... it turns out that one of the parents of the missing object had its rotation.y initialized to NaN, which trickled down after the first render to result in the NaN position, too.
  13. Hello! Your first question may very well be, "Peter, what in the nine hells did you do?" and so for this I will try to explain! While building up my scene, I happened upon a situation where a mesh that I expected to be present, was absent in the rendered viewport. After visual inspection with the debugLayer, the object was truly in the scene, but simply not visible. Upon calling mesh.getAbsolutePosition(), I was shocked to see the return value of { x: NaN, y: NaN, z: NaN } What is odd about this particular situation is that the mesh is one of 10 that are generated in a loop; the others are fine and appear as expected, but my missing mesh (#3 in the list) is visually not appearing. I broke down my code to determine where this might be occurring, and it seems that, until the following call, the absolute position of the entity resolves to { x: 0, y: 0, z: 0 } (as expected)... once the call is made, the absolute position of the mesh appears as { x: NaN, y: NaN, z: NaN } ! engine.runRenderLoop(this._runRenderLoop.bind(this)); It would be difficult for me to explain in code how things are set up, so I'm hoping that someone might have encountered such a situation and be able to say, "hey, I know what in the nine hells *I* did, so here are my experiences and how I fixed it!" Regardless of the outcome, I will try to explain my solution when I come across it. Thanks for reading! - Peter
  14. Hello! Thanks, Deltakosh. That makes sense to me. I will look in to your suggestion. Thanks again! - Peter