lTyl

Members
  • Content count

    9
  • Joined

  • Last visited

About lTyl

  • Rank
    Newbie

Contact Methods

  • Twitter
    TylerDeren
  1. I received an email reply asking for a fiddle. Here is one showing the flickering issue. Simply use the mouse wheel and zoom out; flickering should start happening (I'm on latest Chrome) https://jsfiddle.net/744o680r/4/ I am drawing the graphics once and then scaling. I am using PIXI.Application and handling my zoom in a function, which is then added to PIXI.ticker with a HIGH update priority. In my application, I re-draw the graphics when one of the following is true: the widget window is resized or the browser window is resized. When a tracked data model is updated, then I re-draw only the changed graphic represented by that data model. @OSUblake: Thank you for the link! It is definitely relevant to my needs and I shall peruse. EDIT: Argh. @ivan.popelyshev had it right. graphics = new PIXI.Graphics(true); Enabling native lines made the annoying flickering go away. I could've sworn I tried his suggestion earlier...my bad <_<. Thanks for the assistance everyone!
  2. If you are referring to the resolution property, using a value of 1 or a value >1 still has the same unwanted flickering. EDIT: I had a thought where maybe my use of requestAnimationFrame instead of the Application ticker is why I was experiencing the flickering on scale change. I re-wrote the zoom to use the ticker: this.ticker.add(this.renderSmoothZoom, this, PIXI.UPDATE_PRIORITY.HIGH); After the edit, I am still experiencing the flickering. I suspect it is a relatively minor issue that I am overlooking...
  3. Does anyone else have tricks or ideas I could try to remove/reduce the amount of flickering as shown in the OP? Or any ideas on why the positions are off when re-drawing and using toLocal to calculate the relative draw position? Much appreciated~
  4. Thanks for the reply! I am currently using version 4.5.1. Updating to 4.5.2 has no change for my two issues above. I am doing this to initialize PIXI: this.app = new PIXI.Application(renderOptions.width || 100, renderOptions.height || 100, renderOptions); this.renderer = this.app.renderer; this.stage = this.app.stage; this.view = this.app.view; renderOptions has an 'antialias' property and the value is true. Using new PIXI.WebGLRenderer causes all of my interaction functionality to break, because the renderer isn't linked up to the PIXI Ticker (I'm assuming...). var line = new PIXI.Graphics(true); ^ Has provided no improvement to the flickering I am experiencing. It has actually made the flickering worse and more prevalent.
  5. Hey there, I am building a Gantt chart using PIXI.JS, and have some miscellaneous questions regarding some unexpected behavior I am seeing with the outputted render. 1.) I experience flickering when applying a linear zoom (Changing the scale property with the mouse wheel). The GIF below shows the issue. Here is the zoom code: function zoom(factor) { var newScale = self.zoom.scale * factor; // Clamp the scaling if (newScale > self.zoom.max) { self.zoom.scale = self.zoom.max; return;} else if (newScale < self.zoom.min) { self.zoom.scale = self.zoom.min; return; } // Stops an error when you change state inbetween frame draws if (!self.renderer || !self.renderer.plugins){return} var mouse = self.renderer.plugins.interaction.eventData.data.global; self.zoomLayers.forEach(function(layer, idx){ layer.scale.x *= factor; layer.scale.y *= factor; self.zoom.scale = layer.scale.x; layer.x -= (mouse.x - layer.x) * (factor - 1); layer.y -= (mouse.y - layer.y) * (factor - 1); }); self.emitter.emit('zoom', {pointer: mouse, event: e, factor: factor}); } var remaining, lastTime; function calcZoom() { var time = Date.now(); var delta = time - lastTime; lastTime = time; var step = Math.pow(remaining, delta/100); remaining /= step; zoom(step); if (Math.abs(remaining - 1) < change) { zoom(remaining); remaining = 1; zooming = false; } else { requestAnimationFrame(calcZoom); } } If it helps, my stage is set-up like this. LayerManager is simply a thin wrapper which creates a new PIXI.Container(), and tracks them by name: this.layerManager.getLayerByName('underlay').addChild(this.lineContainer); this.layerManager.getLayerByName('main').addChild(this.layerManager.getLayerByName('surface')); // Add the renderer layer to stage this.stage.addChild(this.layerManager.getLayerByName('underlay')); this.stage.addChild(this.layerManager.getLayerByName('details')); this.stage.addChild(this.layerManager.getLayerByName('main')); The layer which has ‘zoom’ applied is the ‘main’ layer. The lines that are flickering are being drawn with PIXI.Graphics. The line is being added to the ‘details’ layer: var line = new PIXI.Graphics(); this.draw = function(sx, sy, dx, dy){ line.moveTo(sx, sy); line.lineTo(dx, dy); return line; }; Any idea why I am seeing this flickering with these simple lines, and steps on how to mitigate the problem? Ideally, I would like the horizontal lines to remain relatively static. 2.) When refreshing the render (Such as when the data model changes and an event is dispatched), I clear the individual bar and then re-draw with the new data. This works fine UNLESS the view window has been zoomed or panned; in which case the new bars are drawn with an offset that correlates to the amount I have zoomed in/out on the plan. I am calculating the X and Y like so: var shape = new PIXI.Graphics(); var completePoint = shape.toLocal(new PIXI.Point(data.completeX, displayNode.y)); var incompletePoint = shape.toLocal(new PIXI.Point(data.incompleteX, displayNode.y)); shape.drawRect(completePoint.x, completePoint.y, width, height); shape.drawRect(incompletePoint.x, incompletePoint.y, width, height); displayNode is the parent DisplayObject. data.completeX/data.incompleteX is the GLOBAL X draw position. The shape is added as a child to the displayNode. The displayNode is added to the ‘surface’ layer. The gist of it is it appears toLocal is not recursively factoring in the position of all of the parents. My display node graph should look like this: Stage -> Main (PIXI.Container) -> Surface (PIXI.Container) -> displayNode (PIXI.Graphics) -> shape (PIXI.Graphics) ^ Everything is drawing with correct positioning. ^ ‘Floor 1’ updated; expect to see it drawn similar to the former image, but with a higher width. Notice how the greenbar is drawn with a small Y offset and a very large X offset? Why is that? Do any PIXI experts here have any insights they could provide to help me solve these two problems? Thanks!
  6. Heya. I am using PixiJS to build a visualizing tool as part of a larger application. Currently, I am building a minimap component which draws linked ancestors from a selected chain in the main web application. Each link is drawn from the center of one shape to the center of another. The minimap has panning and zooming. When the minimap is updated, and new links are drawn, the lines linking two shapes are not drawn to the center of those shapes. This draw bug only happens if the main draw layer scale and position was changed from a pan or zoom action. Panning works by changing the X and Y position of the relevant Pixi Container on drag. Zooming works by changing the scale property for X and Y. Obviously, my center point calculation is failing to factor in the position/scale of the container. I am calculating the center via: var center = { x: shape.x + (shape.width / 2), y: shape.y + (shape.height / 2) }; Thus, how can I get the center point of a Container (shape) to always represent the center point of that container, regardless of how I manipulate the scale and positioning of the parent? This will be the world coordinate representing the center point of a container. Is there an easy way of getting that point?
  7. Thanks for the comments! We have a Web demo over on shadowsofadam.com. I'm not actively sharing the link because that demo is 11-months old at this point, and quite a bit has changed since. Updating the Web demo is on the to do list. I also am planning on getting a demo live on Steam as well. Regarding the difference in art styles from the game versus promotional art, this was done mainly as a throwback when game box art would have outrageous cover art compared to the art style of the game. @lemmo Thank you!
  8. Thanks! We definitely spent a lot of time on the art to get it "just right." Here is what it looked like before: All of our artists did a phenomenal job getting us from there to the art you see today.
  9. Heya! I've been a long-time lurker on these fine forums, and I hope to change that by becoming an active and valuable member here. There are a lot of great like-minded developers to communicate with and share in our common interest; game dev with HTML5 technologies. The entire team on this title is very humble and open. If you need a re-tweet or just want to chat, feel free to give get in touch! We love helping out other devs. Finally, for my first post, I want to share a Kickstarter funded project I have been working on with 4-other talented developers: Game Website: http://www.shadowsofadam.com/ Developer: Something Classic Games LLC. Developer Website: http://www.somethingclassic.net/ Developer Blog: http://blog.somethingclassic.net/ Press Kit: Press Kit Buy: Direct | Humble Store | Steam All pre-orders receive instant access to the beta. Shadows of Adam is the self-proclaimed modern day successor to the oft-heralded classic JRPGs of the ‘90s. A shining example of sensibility through contemporary design. Its incredible story is backed by world-class pixel art and nostalgia-inducing music that you’ll be humming for decades to come. Random encounters, mindless dungeons, and empty dialogue are all tossed aside, favoring instead, substance through simplicity: only the choicest cuts of story make the game; every battle provides a meaningful challenge; each map is its own expression of exploration and beauty.The story follows an outcast with a fearful power who ventures out into the unknown world to save her father and herself. Along the journey, dangerous foes present an ever-growing challenge, and players will have to level up, find equipment, and learn new skills to overcome them. Combat takes place in a traditional turn-based battle system, albeit an upended one. Notable mainstays like ability points have been redesigned from the ground up to support faster paced battles where using powerful skills is an every round affair, and the only way to succeed is through careful planning. Dungeon exploration takes a similar turn where intent and purpose help drive the player’s decisions. Whether riding hot air vents in a smoldering volcano, battling Cthulhu-like plant monsters in a murky swamp, or solving puzzles crafted by ancient practitioners of magic, every step and turn in Shadows of Adam promises to offer some novel experience, guaranteeing thrills and twists that will keep players guessing until the very end. More Screenshots: http://www.shadowsofadam.com/ 16-bit JRPG glory with a modern design 10-12 hours of gameplay (12-14 if you never figure out how to run) Delicious graphics (consume raw at your own risk) A deep, character-driven story with lots of humor Blazing fast battles that will set your pants on fire No random battles. Monsters are on screen, waiting for you to thrash them! Four playable heroes with unique skills Save anywhere! Inspired music you will find yourself humming twenty years from now Suplex dragons Revel with clean freak pirates Sneak past gambling addicted guards Learn novel new swear words Sample strawberry flavored potions Evade taxes at a booming black market Deface ancient graves Run from the cabbage lady Eat the mushroom sauce of a lunatic witch (with a fork) Stomp through an old man's house in the middle of the godforsaken night Why are you still reading this? Get the game! Developed by: Connect: Twitter: @SomethingClassc Facebook: Something Classic Games Kickstarter: Kickstarter Technical: IDE: Webstorm 10 Development Server: WAMP Version Control: GIT via GitHub Game Engine: ImpactJS Programming Language: JavaScript, PHP Level Editor: Weltmeister Code Debugging: TraceGL / Webstorm Bug Tracking: Trello Binary Distribution: Electron File Sharing: Dropbox / FTP / Google Drive Game Script / Design Document: Google Docs Team Communication: Slack / Email more Info:Tools of the Trade Choice Development Articles from our blog other developers may enjoy: The role of the Composer Budgeting the Art Costs of an RPG: Part 1 Budgeting the Art costs of an RPG: Part 2 Budgeting the Art Costs of an RPG: Part 3 Jump Inside My Head and Let's Map!