• Content Count

  • Joined

  • Last visited

  • Days Won


mobileben last won the day on September 11

mobileben had the most liked content!

About mobileben

  • Rank
    Advanced Member
  1. @RomainMazB got it, I perused the code. Some unsolicited suggestions (feel free to ignore) which may make your life easier, especially given the actual behavior is to make `onClick` part of the CardSprite class and avoid using `event` to derive the target to use. I would also recommend you wrap setting the card to be interactive and listening to events into another `CardSprite` method. You can control enabling and disabling a card from being interactive as well as listening to the mouse over. This will be helpful if you have several cards where some are interactable but others are not ... and the state can change depending on user actions.
  2. @ivan.popelyshev I created a issue here:
  3. Nice code sample! Obviously doesn't use ``, but I think this type of approach works well.
  4. I think the problem is the implementation and the definition of how `target` gets assigned. Keep in mind that how the browser handles the mouse events is different than how pixi does. Pixi essentially transforms it into "pixi space" or rather the node hierarchy. Mozilla documentation indicates that mouseout would have an assigned target. Based on the code base, `processInteractive` is responsible for `target` assignment and that is assigned based on hit, where hit has several criteria much of which is dependent upon the point being within the DisplayObject. Since, when there is a mouseout, the point is no longer in the affected DisplayObject, target will be null. So what ends up happening (at least in my test cases) is that target == null and currentTarget = parent. @RomainMazB you may want to think about creating a class for your cards. This would make it easier to manage your cards.
  5. Bizarre. I'm nascent with Javascript/Typescript. Try this variant. card.on('pointerout', event => { card.position3d.y -= 10; }); It is probably grabbing the `this` context from the current scope that card is in.
  6. Fair point about the new function objects 😁! I think the reason there is not target is that it fails the hit test. The actual DisplayObject in question no longer has the point within the object. Hence target cannot be set to it (I looked at the code in a debugger). I believe in this case, if currentTarget is set, it is the parent. This is the normal code that should set the appropriate target (Pixi.js code). if (displayObject.interactive) { if (hit && ! { = displayObject; } if (func) { func(interactionEvent, displayObject, !!hit); } }
  7. Have you tried to use pointerout? The currentTarget is set for that. I use pointerover/pointerout for my hover code. Are you just trying to animate an object on hover? I don't care about target. If card has the position3d property, then just use an arrow function to get the proper this context. This would change your code. to look like. card.interactive = true; card.on('mouseover', event => { this.position3d.y += 10; }); card.on('mouseout', event => { this.position3d.y -= 10; });
  8. I figured it out. It's assigned in bundles/pixi.js/src/index.js. I believe it's assembled through lerna/rollup. The rollup config I believe references that index file.
  9. I took a better look at the custom game loop and it makes sense. Not sure if I'll go that route just quite yet. A question I have when looking at the code. I can't seem to see where Application actual assigns properties such as Ticker. I've run a grep on the code base and it isn't obvious to me how this is done. For the most part, Application.js (in packages/app/src) look pretty "empty". I also don't see assignment to other things such as view, etc. Where is this all done?
  10. BTW, as a heads up doesn't load/do anything. I've tried on Chrome and Safari.
  11. I very may well have to go this route. I generally try and deviate as little as possible when using 3rd party. I've been burned too many times doing my own things and then running into incompatibilities. Plus my relative lack of JS/TS experience has me focusing a bit more on getting up and running versus getting things cleaner. Up to now, I think my scaling handling has been smattered across different places. This one is more application based. I'll dabble with the game loop a bit today. I'm still tying some pieces together and then will see if I can handle the resizing of assets dynamically. I don't expect the handling to be real time, since that is dependent on assets. I also expect the ease of doing this to be dependent upon the actual number of assets involved. My initial stuff here is "toy" in size, so manageable.
  12. It is indeedy an Application thing. It takes the HTML Element or window. It works, I tried it. I also tried using renderer.resize(w, h), which seems to work. For now I'll assume it correctly resizes the frame buffer versus scaling. Once I get further along I can verify if this hypothesis is correct or not.
  13. Thanks. I'll need to experiment. BTW, is the best way to resize the renderer to use `renderer.resize()`? This is why `resizeTo` eventually uses and I assume then this actually modifies the framebuffer size in use. I'm not quite used to following JS code that use "runners" yet.
  14. When a user resizes the window, the render area can become bigger or smaller. This potentially has a visual effect in that if the window started off small and then was increased, the textures could look bad if the render area is simply scaled to fit the canvas bounds. Going from larger to smaller is less of an issue, though one could make the argument that it's doing more work than is needed. How are most people handling this? For example, if you get a resize event and the canvas say doubles in size, do you simple increase the canvas size but leave the renderer area the same? Or do both? If it is the latter then this would possible require newer textures. For my setup, I have a defined game area which is currently defined as 480x640. I then support different multiples of this. The plan is to do layout at 480x640 right now (though I may use a higher res multiple later). When the game starts, it will best match which multiple fits the canvas and it will use that. I'm trying to determine if I should just choose the size of everything at start only and if the user changes the window size, they are stuck with that or if I should add support to find the best matching supported dimensions and then use that. If I decide to support better fitting which multiple works, it also implies I would need to have a method to change textures on the fly. I would imagine something like this would use a multi-pass system where I destroy/dispose of the active textures, load the newer ones, and then apply those new textures to the existing PIXI.Sprites. Obviously any other draw element would need to be updated as well. This seems like a lot of work, so seeing what people's experience is regarding this and if it's worth the effort.
  15. Okay, sure you provided some code, but the reason I asked about more code was to better understand how you set it up primarily since you indicated you were getting invalid values. I think that's pretty much standard practice and if you posted to say SO, I would guess someone would invariably ask you the same thing. Regardless of if you use degrees or radians, you would be faced with "out of bounds" numbers. At least for my code, I always 1. work in radians within the engine and 2. adjust for when the value falls out of bounds. Note there are times I actually do use degrees. That could be when coming from a tool that exports the data, but where we find that occasionally we manually tweak values during experiments. However, it will be corrected once it goes into "runtime". Also keep in mind, you can use "angle" instead of rotation. If you look at the code, it just does the math for you to cover to radians. FWIW, I'm a C++ guy. But I also have used Flash and Actionscript as part of my tool chain. I always have method for dealing with degrees or radians (explicitly named as such) but as mentioned, game engine itself uses radians. I'd say more often than not, most stuff I've encountered uses radians.