Dan K

Members
  • Content Count

    8
  • Joined

  • Last visited

Everything posted by Dan K

  1. In the examples/graphics the following call is made on line 45 me.video.renderer.setColor(r); But where does the setColor function come from? the renderer is a me.Object and there is no setColor Funciton in the renderer class. The function does seem to refer to the declaration in me.Color.setColor but this function just returns a color, so to me its unclear how the canvas context knows that the color is set. Even if the setColor is a prototype function, I still don't see where it become part of the renderer object. --- To supplement this thought. I would suggest moving color related functions (the active setting / changing not the Color manipulation functions) inside of the me.Renderer even if it just referencs the function in the me.Color class. It is logical that the programmer will be using the 'renderer' class for custom drawing functions and it would be natural to expect to find references on how to set the color here.
  2. As with the nature of all things... Pluging at this for a few more hours finally yields an answer myself... This is an interesting trick... The problem was that the timer object gets called from the 'window' object where the application instance was difficult to find. So instead, I pass the 'this' instance as the context variable, thus ensuring that I had the 'deployUnit' property availble to call when the setTimeout executed the toBeCalled() function. var makeTimer = function(unitType,delay,context) { var localUnit = unitType; var toBeCalled = function () { console.log("Deploying Unit: " + localUnit); // this.deployUnit(unitType); // context.deployUnit(localUnit,context); // 'this' here is the 'window' object because the timer comes from the window. // on top of that problem, I couldn't seem to access the AppJS.GameController object, so I just // passing int along in the parameter context. };//.bind(this); // eventually just removed the bind, because I was able to pass in the class pointer in the parameter 'context' me.timer.setTimeout(toBeCalled, delay * 1000, true); }; for (let i = 0; i < this.unitList.length; i++) { var unitType = this.unitList[i].type; var delay = this.unitList[i].delay; makeTimer(unitType,delay,this); //https://www.youtube.com/watch?v=-jysK0nlz7A 9.6: JavaScript Closure - p5.js Tutorial by the Coding Train }
  3. I am having a difficult time passing a variable to a me.timer.setTimeout... can it accept variables? Specifically its a bit of a closure problem as well. I am trying to deploy units over set intervals of time. I have the units in an array with time offsets. I thought I'd cycle through the array of units setting the timer event to the offset. But when the timer event fires, it accesses the last known value on the closure variable. for (let i = 0; i < this.unitList.length; i++) { var unitType = this.unitList[i].type; var delay = this.unitList[i].delay; var toBeCalled = function () { console.log("Deploying Unit: " + unitType); // this.deployUnit(unitType); this.deployUnit(unitType); // 'this' here is the 'window' object because the timer comes from the window }.bind(this); // if you don't bind it to this. then the unitType won't be declared me.timer.setTimeout(toBeCalled, delay * 1000, true); // window.setTimeout(toBeCalled,delay*1000,[unitType]); // but this is not pausable and it can't access the deployUnit function because it is part of a class } Any ideas of improving the closure? or passing arguments to the function? the window version allows arguments but I can't seem to reach my class instances... (in theory they have to be there somewhere)
  4. If it was limited to those physic interactions then I agree... The name seems appropriate... But the fact that it blocked the events surprised me. However, it was in the documentation so that is on me of course (like there's anyone else to blame...🤣)
  5. I think you should change the property isKinematic to "blockEvents" to embody the scope and purpose of this variable. I know its linked collisions and I suspect that's why it was chosen. But even if the programmer is looking at the collisions aspect of the Renderable, I think the blockEvents will catch their eye and their mind will consider 'collisionEvents' blocked by the changing of this term.
  6. Oliver, Look at my branch push... I think that might fix this...
  7. Dan K

    melonJS 6.4.0

    Yes I agree, I found scaling the individual sprites difficult when I wanted manual control over the scaling. I created my own Image Renderable class to solve the problem. For me It may have been an issue with not fully understanding the scaling implementation. here's an example of my scaling function that probably describes what sistem wants... However, I have the me.video autoscale to false when I use it. (this object is a me.Renderable not a me.Sprite FYI) scale: function(scaleFactor /* <1 width is scaled, otherwise > 0 width is set*/) { if (scaleFactor > 0 && scaleFactor < 1) { this.width = this.image.naturalWidth * scaleFactor; this.height = this.image.naturalHeight * this.width / this.image.naturalWidth; // preserves aspect ratio } else if (scaleFactor > 1) { this.width = scaleFactor; this.height = this.image.naturalHeight * this.width / this.image.naturalWidth; // preserves aspect ratio } else if (scaleFactor === 1) { // unscale this.width = this.image.naturalWidth; this.height = this.image.naturalHeight; } this.updated = true; }