• Content Count

  • Joined

  • Last visited

  • Days Won


Reputation Activity

  1. Like
    mobileben reacted to themoonrat in Inconsistent availability of font for PIXI.Text   
    I use to load custom fonts, which handles the required hackery for you!
  2. Like
    mobileben reacted to jonforum in Inconsistent availability of font for PIXI.Text   
    yes in dev we learn all day
    i never test this on Cordova  for publish Android or Ios , so i can say  nothing about this kind of approach for mobile sorry.
  3. Like
    mobileben reacted to jonforum in Inconsistent availability of font for PIXI.Text   
    you need load font after,inside a div and delete after.
    Or more easy way if you understand promise  and documents .fonts
    this is how i load my font for my game
    const loadFonts = () => { return new Promise((resolve, rej) => { const fontsList = [ new FontFace('ArchitectsDaughter', 'url(fonts/ArchitectsDaughter.ttf)', { style: 'normal', weight: 700 } ), new FontFace('zBirdyGame', 'url(fonts/zBirdyGame.ttf)') ]; fontsList.forEach(fonts => { fonts.load().then(function(loadedFontFace) { document.fonts.add(loadedFontFace); // = '"Junction Regular", Arial'; }); }); document.fonts.ready.then(()=>{ resolve() }); }) };
  4. Like
    mobileben got a reaction from ivan.popelyshev in Proper freeing of textures and cleaning up the loader   
    Just wanted to add something else. I tried to explicitly purge the Loader resources via something like
    delete this._game.loader.resources[name];
    I have found that after this is done, on the next load, the spritesheet property is undefined. I load this asset using this code
    if (!this._game.loader.resources[bname]) { const tname = Layout.LayoutManager.shared.decoratedAssetName('assets/' + bname + '.json'); this._game.loader.add(bname, tname); this._game.loader.load((loader: PIXI.Loader, resources: Partial<Record<string, PIXI.LoaderResource>>) => { postLoadHandler(); }); }  postLoadHandler tries to access the spritesheet via this code (note that resource is split out as a const right now to make it easier to inspect in the debugger).
    const resource = this._game.loader.resources[bname]; let spritesheet = resource.spritesheet; spritesheet is undefined when I try to reload a spritesheet which was forcibly removed using delete as described above.
  5. Like
    mobileben reacted to d13 in Inconsistent availability of font for PIXI.Text   
    I don't know if Pixi's loader deals with this problem, but browsers will never actually load a font until they're requested to display it. In the past I've had to solve this problem by creating a hidden HTML element that uses the font, just so that the browser is prodded to load it. Here's code I've used in the past to fix this problem:
    I've done tons of research on this problem in the past and this was the best solution I could find ... but this was a few years ago - hopefully there's a better solution out there.. ?
  6. Like
    mobileben reacted to jonforum in mouseover works but mouseout don't? can't retrieve   
    i was made this demo, maybe it will be more revelen
    with class
  7. Thanks
    mobileben reacted to ivan.popelyshev in Window resizing and texture updating   
    Its strange that at the scale of problems you're trying to solve you're only now getting rid of Application class. I write it to every person here who encounters application-related problems, maybe it wrote it to you too: read and make your own. Otherwise you'll have to wait when someone from pixi team fixes particular problem or adds particular feature in an area that's very game-specific and has no critical WebGL stuff that we have expertise of.
  8. Like
    mobileben reacted to ivan.popelyshev in Window resizing and texture updating   
    You can make something like proxy textures, i had that before:
    That way you wont need to change "sprite.texture", just adjust baseTexture and frame. Actually you dont even need a class there because setting "texture.baseTexture" works in latest pixijs dev
    I also use the same principle in new plugin that'll appear soon.
    You are still on a front of the problem, there's no progress from our side.
    If you solve it even partially, I suggest to publish your engine on github.
  9. Like
    mobileben got a reaction from ivan.popelyshev in Window resizing and texture updating   
    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.
  10. Like
    mobileben reacted to ivan.popelyshev in Rotation values   
    Those frameworks/libs have their own math. Pixi math module is tiny and we dont focus on it, we leave it to people to make whatever they want. No Vec2/Vec3 math. No add() sub() and other small functions because pixijs doesnt need that. 
    For example, I was pro-degrees that we convert everything to degrees - that failed, we added `angle` prop instead, and inside its still backed by radians which can trigger some strange behaviours when you try to serialize elements.
    You can set `Object.defineProperties(DisplayObject.prototype, 'rotation', {your getter/setter});` , its fine to hack pixi. 
  11. Thanks
    mobileben got a reaction from b10b in MTB Hero   
    Maybe one way of handling jumps is letting the player do a little bit of a trick move when they have air time? Perhaps giving some extra "bonus" for doing so. Bonus to provide some incentive (note since you are time based, that would need some further thought on what the bonus does or if an extra point system is added ... or perhaps it adds some "speed up"). But also, if timing isn't right on the jump, there is a "wipeout".
    I double quote that because a wipeout could be treated much like running into a barrier.
    I agree with totor though. I thought there would be jumping.
  12. Thanks
    mobileben reacted to mattstyles in HTML5 game build environment and Cordova   
    I typically use Parcel as my bundler, which also handles an index.html out of the box (requires it actually), so when that 'watch' task runs it performs an incremental build based on what has changed and the output folder will typically contain html, JS, CSS (if generated) and images (if using directly) etc. The output folder becomes the stuff Cordova wants. I haven't fired up Cordova in a long time so don't know if that auto reloads things in Cordova, I never got to the stage of using it much so only ever fired up Cordova for a 'static' build for smoke-testing.
    The stuff such as IAP and other Cordova plugins: the Cordova bridge are just exposed global variables which it tacks on to 'window' at init time so they are available (typically) _before_ your code wants to use them. For in-browser use, you need to shim or mock those exposed globals. I.e. for IAP, it probably does something like expose a function with a callback or a promise, which you can then use to determine what has happened, for in-browser you just need to shim that function/promise with an expected result. I think that many Cordova plugins (such as the persistent storage stuff) will typically expose browser-based versions (where it makes sense) so you _could_ use those instead. Otherwise a custom HTML file with the shims attached in the head (for a dev build) would suffice I expect, although, shimming the entire API you are using (depending on the complexity of the plugin) could be tricky. Your workflow of devving in the browser isn't unusual though so hopefully the plugins you use will expose browser-based shims/mocks/functionality that you can use whilst developing your product.
  13. Thanks
    mobileben reacted to mattstyles in HTML5 game build environment and Cordova   
    I agree with Bruno and generally take a two-step approach (not that I've done it much, and only to proof-of-concept stage).
    Use your webpack build during development (using mocks as much as possible, quite a few Cordova plugins I've used actually provide these mocks for browser-based use, or even feature-complete ones browser versions), then use webpack to package it up and then use Cordova to take your built files and turn them in to a whatever cordova needs to run on a device. If you don't use any newer language features you can omit the webpack build step, but, you're using TS and no runtime understands it (yet) so you'll need to transpile it anyways.
    On the dev in browser thing, yes, this is great, but, make sure you do regularly check on a device. If you're on a Mac then the simulator is generally good enough (always always do smoke-testing on real devices though, at least, more is better but more is time-consuming so find a balance), I can't remember what tooling I used to simulate Android devices on my dev machine, I remember there were a couple of options and all worked without too much hassle. Again though, test on real devices. The more frequently you do this the better, but you need a balance because it is potentially time-consuming.
    I'm pretty sure you can set up Cordova in some sort of watch mode, again, you can do a two-step approach here where Webpack builds built files for Cordova, which is watching them and rebuilds itself when they change. I don't think there is any way to get hot reloading or even incremental builds like this though. Generally speaking, devving in the browser (where things like debugging are also easier and tooling is better for hot reloading, incremental builds, shims, mocks etc etc) will be good enough. Just don't forget the real devices, lest you risk something 'funky' slipping through (iOS Safari is the new IE6, there are some oddities you might run foul of).
  14. Thanks
    mobileben reacted to bruno_ in HTML5 game build environment and Cordova   
    I usually make my game ouside of cordova.
    When using cordova, you will need to use some plugins (for ads, read or write files, whatever you need).
    When I am developing I use dummy files with those apis, so I can develop from the start with that in mind.
    When the game is complete, I create a cordova project with all the configuration and plugins I need.
    Then, I create a batch file, that copys the bundled files and replaces the dummy apis with the real ones.
    Then I can publish and test it on mobile.
    When I want to add new features, is the same.
    Develop outside of cordova, use the batch to replace only the game files, and build and deploy again in cordova.
    My games work on the browser without cordova (although they are limited, because I don't use replacements for the cordova plugins, as I build only for android).
    Although my games should be able to run on ios, I don't have a mac to build the game neither devices to test.
  15. Thanks
    mobileben got a reaction from jonforum in PIXI, Suggest optimizations to minimize CPU/GPU   
    I assume when you ask "render it as canvas" you are referring to rendering the `PIXI.Graphics` as is? So in other words something like:
    const gfx = new PIXI.Graphics(); // Do stuff to make a graphic gfx.endFill(); app.stage.addChild(gfx); Yes, you are better off converting to a texture and the creating a sprite. The actual `_render` for a graphic does a bunch of work to display the parts of the graphic. Simplified graphic shapes like rectangles should be faster to draw. Just how much work is related to complexity and whether or not the graphic is batchable.
    Sprites on the other hand just update vertices (presumably only if needed, although looking at the code it doesn't look like it has any dirty bits) and then renders.
    Hmm, wondering. I'm not really a JS guy. But I've done some reading that seems like you can get some async stuff running. Has anyone dabbled with that? It would be super helpful if it is real async. Since then things like texture creation could be done off the main thread. The only caveat though ... which I don't know if pixi can handle is the need for some locks.
    I'm more used to multi-threaded game engines where one has those features to help better hide latency.
  16. Thanks
    mobileben got a reaction from jonforum in PIXI, Suggest optimizations to minimize CPU/GPU   
    I think for generating a texture from the line graphic you would do something like this, however I will be quick to add is in my test, it comes out a bit jaggy. The actual sine wave as a graphic is slightly jaggy as well, just not as bad. I also notice clipping.
    You should be able to draw the two and compare to see what I mean.
    const graphic = new PIXI.Graphics(); graphic.lineStyle(2, 0xff0000, 1); const startX = 0, startY = 0; const increment = 0.1; graphic.moveTo(startX, startY); for (let x=increment;x < 100;x += increment) { const y = Math.sin(x) * 20; graphic.lineTo(startX + x * 10, startY + y); } graphic.endFill(); let sineTex = app.renderer.generateTexture(graphic, PIXI.SCALE_MODES.LINEAR, window.devicePixelRatio); let lineSprite = new PIXI.Sprite(sineTex);  
  17. Like
    mobileben got a reaction from Karthik in PIXI, Suggest optimizations to minimize CPU/GPU   
    Why don't you send a few examples of what a graph looks like at different scale so we can see the spectrum of visuals you are trying to achieve and how they interrelate?
  18. Like
    mobileben got a reaction from Karthik in PIXI, Suggest optimizations to minimize CPU/GPU   
    Ahh, okay, I saw that. I misunderstood. You talked about zooming/scaling so wanted to see how it would differ. Essentially the rough views are the same (rectangles and lines)?
  19. Thanks
    mobileben got a reaction from quannm in how to set height for PIXI.Texture.fromImage   
    When scaling anything up, you will potentially artifacts. The severity of which depend on the direction (up or down) as well as how much and what you are scaling by. As you are doing an affine scale, you won't suffer any effects due to change in aspect ratio.
    Are all those images the same size BTW?
  20. Like
    mobileben reacted to ivan.popelyshev in Best way to test fork of Pixi.js   
    I've tried to run `npm link` inside "bundles/pixi.js" and i dont remember if it worked, you can try. 
    both bundles of pixijs (pixijs, pixi-legacy) have two versions: one for vanilla (just es5 js file)  and es6 lib. When you open "bundles/pixi.js/lib" you see that es6 version that is taken by webpack.
    > I'm new to the whole Typescript/webpack game 
    Welcome! It sucks. Personally, I use namespaces , no imports at all, no webpack/rollup. I'll get people who know that stuff in this thread
  21. Like
    mobileben reacted to ivan.popelyshev in physics library   
    > I already have a working code base with Box2d and there doesn't seem to be any issues ... so just double checking if I was missing something.
    OK, thought about that while i was sleeping. Finally got an answer:  its very good topic for book. As a result, we have books for 40$ and no open tutorials on physics integration
    I had something with box2d+liquidfun but now i dont remember where is it. 
    Here's the example of what can happen when you do integration with p2, with very helpful comments:
    import { BodyOptions, Body, Box, Shape } from "p2"; import { PIXEL_TO_METR, METR_TO_PIXEL } from './constants'; export class PixiBody extends Body { display: PIXI.DisplayObject; _lastTransform: number; constructor(options: PixiBodyOptions | undefined, display: PIXI.DisplayObject) { if (!display) throw Error("Display object can't be null"); options = options || {}; options.boundsToShape = options.boundsToShape == undefined ? true : options.boundsToShape; const pos = display.position; const force = options.force ? options.force : { x: 0, y: 0 }; const vel = options.velocity ? options.velocity : { x: 0, y: 0 }; const opts: BodyOptions = { ...(options as any), //because PixiBodyOptions have some other definitions ...{ position: [ -pos.x * PIXEL_TO_METR, - pos.y * PIXEL_TO_METR ], velocity: [vel.x, vel.y], force: [force.x, force.y] } }; super(opts); this.angle = display.rotation; this.display = display; if(options.shape instanceof Shape) { this.addShape(options.shape) } else if (options.boundsToShape) { const bounds = display.getLocalBounds(); const box = new Box({ width: Math.abs(bounds.width * PIXEL_TO_METR * display.scale.x), height: Math.abs(bounds.height * PIXEL_TO_METR * display.scale.y) }); box.material = options.material; //todo fixme, pass valid offset; //FIXME //FIIIIIIXXXXXMMMMMEEEEE this.addShape(box); } this._lastTransform = (this.display.transform as any)._localID; } update() { if (this._lastTransform !== (this.display.transform as any)._localID) { this.position[0] = -this.display.x * PIXEL_TO_METR; this.position[1] = -this.display.y * PIXEL_TO_METR; this.angle = this.display.rotation; } else { if (this.sleepState != Body.AWAKE) return; this.display.position.set( -this.position[0] * METR_TO_PIXEL, -this.position[1] * METR_TO_PIXEL); this.display.rotation = this.angle; } this._lastTransform = (this.display.transform as any)._localID; } destroy() { //??? this.display = undefined; } }  
  22. Like
    mobileben reacted to Exca in physics library   
    Using physics libraries is ok in my opinion. People just need to know that there's no pre-existing integration, so you have to basically do one of these:
    - Integrate physics library to pixi directly (I wouldn't recommend, that would break updates etc.)
    - Run the physics and rendering separately and have some kind of synchronization between the two. This is the method I have used succesfully with matterjs.
    - Build a plugin for physics syncing to pixi.
    The second method I basically had all physically interacting game objects paired with a physics body and on each renderloop the transforms for those objects would be synced with physics bodies.
  23. Like
    mobileben got a reaction from ivan.popelyshev in physics library   
    Heh. I was just wondering you were noting some other issues.
    I already have a working code base with Box2d and there doesn't seem to be any issues ... so just double checking if I was missing something.
  24. Like
    mobileben got a reaction from ivan.popelyshev in drawRoundedRect and expected dimensions with strokes   
    Okay, I think I found an answer to my own question. The trick seems to change the alignment if the lineStyle. Doing the following gives me the expected results.
    this.panel.lineStyle(this.menuDef.panel.stroke.thickness, this.menuDef.panel.stroke.color.color, this.menuDef.panel.stroke.color.alpha, 0);  
  25. Like
    mobileben got a reaction from ivan.popelyshev in drawRoundedRect and expected dimensions with strokes   
    I'm prototyping code to draw menus. Essentially the menu is a rounded rect with stroke lines. The interior rows are the individual menu items. Menu items are based on a colored rectangle backing with icon and/or text. Each menu item as well as the menu panel can have their own colors.
    This menu is generated "programmatically" based on metadata. As part fo the process, the max required width for each menu item is computed. The overall size of the menu panel is based on this.
    In my tests, the menu panel and the menu items use different colors. Thus it's easy for me to see gaps.
    I have noticed that my expectations of what the panel size should be doesn't match. What I'm seeing is the menu items width are "smaller" than the interior of the fill of the panel. I see this by seeing a leading and trailing gap between the menu item and the stroke lines of the rounded rect.
    Code to create the panel looks like the following:
    this.panel = new PIXI.Graphics(); this.panel.lineStyle(this.menuDef.panel.stroke.thickness, this.menuDef.panel.stroke.color.color, this.menuDef.panel.stroke.color.alpha); this.panel.beginFill(this.menuDef.panel.backgroundColor.color, this.menuDef.panel.backgroundColor.alpha); this.panel.drawRoundedRect(0, 0, details.width + this.extendedWidthCorr + this.menuDef.panel.stroke.thickness * 2, details.height + this.extendedHeightCorr, details.radius); this.panel.endFill(); this.root.addChild(this.panel); Current thickness is 4 and details.width is 190.
    You can ignore the "extended*Corr" items. They are effectively 0 right now and will be used later since I plan on allowing the panel to be anchored to an edge, and in that case, I don't want to see the rounded corners along the edge. Also, ignore the inconsistency of width and height. I'm currently focusing on why the width is not proper.
    Note that when I create the application I have been using a resolution of 1. I'm on a Mac, so the devicePixelRatio is actually 2. I've also as a test set this to window.devicePixelRatio and have the same results.
    When I define stroke thickness, is that "pixel accurate" or or rather pixel close enough? It does not appear that is the case. The scale ratio of fill to stroke lines are different by roughly a factor of 2.
    Observationally I have found that if I have the menu item width and the width used to create the panel be the same:
    - If there is no lineStyle, then the width of both the panel and menu item is the same (they properly overlap which in this case means the widths are identical and overlap)
    - If I use lifeStyle, the menu panel is slightly larger than the menu item. It looks like it is close to one lineStyle width (which also then seems to confirm my "roughly a factor of 2" from above). I also noticed that even though the menu items are drawn at x = 0 (anchor is upper left), when line styles are drawn, and even though the panel is also at 0, 0 ... The starting draw positions are not the same. They should be aligned properly. What I see in this case is that the menu item background is slightly smaller than the menu panel and the menu panel appears to be offset slightly in the draw, even though the x/y of the panel is 0, 0 just like the menu items (they are all children of the same container).
    I was going to attach an example, but I get an error indicating can't create some directory for uploads and to contact for assistance.