• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    jinzo7 reacted to b10b in Everything to create fb instant game   
    I'll have a stab at these as I like to snapshot my view on things periodically ...
    Yes and yes.  Pixi has a very decent power to size ratio and solid compatibility (v4.8 may be wisest in 2019?).  For a competent developer capable of spinning their own game structure Pixi is ideal for a lightweight browser game.  Coming in at less than 5MB total for your IG is wisest.
    Red tape aside, it's possible but improbable to make money releasing a single game.  Primary monetisation choice with FB IG is in-game ads (which are a low value transaction for a developer and an intrusion to the player).  In-game purchases have more value but will require significant retention first.  Or consider indirect value generation such as consultancy services, brand building, learning for the next game?
    FB IG is inherently multiplayer (async).  Within the SDK are context (group) leaderboards, notifications, packet sharing (challenges).  That being said the vast majority of initial plays will be in solo mode, so a compelling single player experience is necessary for retention.  Get creative for the crossover!  For more advanced multiplayer use a custom backend.  Having some separation / abstraction from the Facebook SDK might be wise in case other markets are a better fit for your game?
    For Multiplayer specifically?  Yes there's a TicTacToe example that covers the basics of a client-server model.
    My advice is play some of the popular titles, understand what the FB IG audience seem to be attracted to and how other developers are leveraging the SDK to create retention and monetisation - warning, some of it can be ugly.  Iterative development is going to be crucial, however you'll likely only be promoted once - so use it wisely, and use each territory to run a split test.  Or build several games and apply the learning from one to the next etc.
    If you haven't built dozens of games already, FB IG probably isn't for you yet?  Imo there are better platforms that can help evolve game development skills and player retention mechanics.  Instead see FB IG as a specific audience with a specific style of game - developing a game precisely for that might work out very well (FB has a HUGE potential audience after all).
    Imo Messenger games should be about decorating a conversation, in the same way filters decorate a photo.  So quick, contextual, personalised, fun, indisposable.  That's not necessarily a standard casual game, so changing some assumptions and expectations may be wise.  Just my advice, your mileage might vary!
  2. Like
    jinzo7 reacted to ivan.popelyshev in Resize Sprite/Container with children - the proper way?!   
    Yeah, we know of that problem. We even want to make example like that soon, because v5 is ready and its time to cover it with tutorials.
    Its difficult to make if you dont understand how exactly PixiJS Transform works (almost the same as Flash transform). `width` and `height` are secondary calculated properties, be vary cautious if you use them! If you dont know how exactly PixiJS reflects "I want this element to have 100px width" - dont use it.
    There's no layout engine inside PixiJS.
    There are hundreds of ways to make a mistake in your case. My telepathy doesnt give any answers except "he uses "width" somewhere wrongly", maybe you should post the full demo. Again, the time of response depends on how clear you make it. Big demo = wait for a month before someone gets it. Small obfuscated demo = week. Small demo = day or two.
  3. Like
    jinzo7 got a reaction from ivan.popelyshev in Resize Sprite/Container with children - the proper way?!   
    Hello, nerds ! Happy v.5 release also !
    So I`m making pinch to resize(zoom like), stretch and shrink(which is basicly resizing to constant values) over class that extends Sprite or Container. I`m not defently sure what I should extend. 
    My class has methods resize(newWidth, newHeight), stretch() and shrink() . For ease I will call the class Player which extends Sprite or Container with the 3 additional methods. 

    Everything was okay when the parent was Sprite with texture. Then I had to add as child different sprites. So the composition went complex and the algorithm went to the trash.
    The composition is:
    Player - extends Sprite or Container, methods resize(newW, newH), reposition(newX, newY), stretch(), shrink();  Background1 -  extends Sprite, has texture; visible only when stretch() is called; size - 50x50 Background2 - extends Sprite, has texture; visible only when shrink() is called; size - 100x100 Video - extends Sprite, has texture; always visible; initial size - 500x500 Label - extends Sprite, has texture; visible some times only; size - 70x70  Text  1. At the begining the Player instance has to be shrinked. So the size has to be 50x50. If user tab it, it has to stretch with size 100x100.
    2. If user use pinch when it is stretched it has to resize.
    The question is: 
    In my methods resize(newWidth, newHeight), stretch() and shrink() which children I have to scale, change width and height and so on. 
    Where the factors are -  the Background sprites are with different sizes and changing its visibility and the Video sprite is with bigger size than the need.
    I tried a lot of things but there is no success. And maybe I`m wrong with something small. If the problem is not clearly defined I`ll make changes! Thank you very much !

  4. Like
    jinzo7 reacted to Exca in "Operation is insecure" error in Firefox - Texture.fromVideo(videoElement)   
    You could create a simple test case where you have a canvas, you draw the video there and then read a single pixel from it. If it gives the same error, then the video causes tainting. If not, then it's something else.
  5. Like
    jinzo7 got a reaction from ivan.popelyshev in "Operation is insecure" error in Firefox - Texture.fromVideo(videoElement)   
    Said in that way sounds very trustworthy.

    Okay I will make more research around. Think the Firefox forum will be affected too.

    Thank you very much! I will write when something new emerges on the horizon !
  6. Like
    jinzo7 reacted to Exca in "Operation is insecure" error in Firefox - Texture.fromVideo(videoElement)   
    Do you draw something else than the video to canvas? If something taints a canvas then it stays tainted no matter what is rendered in the future. Or it might be due to stream becoming unavailable at some point for short duration and that could cause tainting (though the bug report I found on this should be already resolved, it was 5 years ago).

    Pretty sure it's some kind of edge case in security constraints which causes canvas to become tainted (by something), which causes security error when pixels are read from it.
  7. Like
    jinzo7 reacted to Exca in "Operation is insecure" error in Firefox - Texture.fromVideo(videoElement)   
    That looks like a CORS problem. Can you check what network headers the video (and possibly related preflight request) have in relation to access control?
  8. Like
    jinzo7 reacted to ivan.popelyshev in "Operation is insecure" error in Firefox - Texture.fromVideo(videoElement)   
    > I know it's not directly linked by PIXI but still I need help.
    You're very humble, I pinged people who have experience with videos in pixijs to help you  
  9. Like
    jinzo7 got a reaction from ivan.popelyshev in "Operation is insecure" error in Firefox - Texture.fromVideo(videoElement)   
    The project is old so PIXI v.3.0.11 is used.
    For streaming - Flashphoner via WebRTC
    Steps to reproduce

    1. Start video stream in html video element - stream.start(myDiv) which creates streamVideoElement in myDiv
    2. When stream fires STREAM_PLAYING event the method PIXI.Texture.fromVideo(streamHtmlVideoElement) is called and the returned texture is set to the specific PIXI.Sprite instance.
    3. Somewhere after this the Firefox browser receives error thrown by WebGl:
    Additional information
    The problem is happened very rerely Only Firefox Stream(video element) is not failed after the error   In the PIXI source code that means:
    gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, texture.source); What we tried
    tried to set  video.crossOrigin = "anonymos" to the video element but no success. tried to dispose video like video.src = "" and etc according some advices related to the localStorage caching I know it's not directly linked by PIXI but still I need help.
    And the image of the current block when exception was thrown.

  10. Like
    jinzo7 reacted to sbat in Typescript + pixi + other libraries[BEST WAY]   
    Quick copy-paste from our Tech Stack document.  Hope this helps, and feel free to ask any questions in the areas, which are of interest. 
    JS Libraries
    Tool URL Usage howlerjs https://howlerjs.com/ Sound support (web audio, html audio tag fallback) pixi http://www.pixijs.com/ Rendering tweenjs http://www.createjs.com/tweenjs Tweens (we do not use Greensock/GSAP due to license restrictions) Dev Tools
    Tool URL Usage VSCode https://code.visualstudio.com/ Our IDE of choice Great typescript support, autocomplete Reasonably good refactoring Free TexturePacker https://www.codeandweb.com/texturepacker Build texture atlases (spritesheets) from individual sprite PNGs, provided by artist ffmpeg https://www.ffmpeg.org/ Convert WAV from sound engineer to MP3 sound files (we use MP3 as patents seem to expire around the world, and it is the easiest/widely supported format) Build Tools
    Tool URL Usage typescript https://www.typescriptlang.org/ Code for our games nodejs  https://nodejs.org/en/ Our build is based on nodejs npm (included with nodejs) Handle dependencies to third-party modules (PIXI, Howler, etc) shelljs https://github.com/shelljs/shelljs We develop custom build tools as “npm run” scripts (javascript files, located in tools/build project folder) shelljs provides crossplaform cd, rm, mkdir, etc webpack 2.0 https://webpack.github.io/ Support ES6 modules Build single minified javascript file from typescript sources and non-JS modules (JSON, images, spritesheets, sounds) However, we DO NOT use webpack for everything. We package static assets, upload to server with shelljs-based build tools.  Bitbucket/Mercurial https://bitbucket.org Our private projects/modules are Mercurial repositories at bitbucket.com [this is for historical reasons, I am not sure 
    there are good reasons not to use git in 2018] tslint https://palantir.github.io/tslint/ Enforce coding style of our choice putty/pagent (windows) http://www.putty.org/ Our upload scripts expect on Windows that SSH keys to our webserver are stored with pagent (in memory)
  11. Like
    jinzo7 reacted to AndyTyurin in The event-based games/apps today ?   
    Hi man!

    Pixi.js I think best player here. Phaser is a little bit overhead in my opinion.

    From my experience, I started to work with Pixi, but after some time, I realized that is quite old (I want to use ES7 babel by clear way, also there are a lot of stuff which is not needed to me and a lot of stuff that is needed but hard to implement with current engine), I wrote my own rendering engine from scratch, only for my purposes for one month.
    I can easily scale my rendering engine and I didn't have something that is not needed.
    Of course, this rendering engine only for my game, I didn't make it to be absolute.
    1) Write by yourself or just use Pixi, it's not big overhead.
    2) I have a twitch stream where I'm discussing my game development, maybe you can watch and ask appropriate questions and I will help you.
    3) Depends on what do you want to use, webgl or canvas. Right now I'm working with webgl only and have good practices how to make the game by using famous libraries such as React along with server-side rendering. And also I know how to write minimal rendering engine which will work fine.
    I apologise that didn't answer your questions by clear way, but you need to describe your problems, otherwise answers will be abstract.
    Because you can use any frameworks you want, you can use OOP, functional programming, MVC or event-based model, server-side or just client-side – you know.
  12. Like
    jinzo7 got a reaction from Jacky Tea in PIXI current versions in the future ?   
    Hello, developers! 

    I am wondering about PIXI v.3 or v.4, how much they can live and work on the internet.
    Imagine now I start big project on v.3 or v.4. This project should be licensed with little exceptions.
    Should I extract the whole code related to PIXI(my view) to be specially maintained over the time?
    What is the experience on similar cases?
    What is the risk? 

  13. Like
    jinzo7 reacted to botmaster in PIXI current versions in the future ?   
    Risk is big in my experience, I built an entire framework around PIXI 4.1.something and when later tried to update to PIXI 4.5.something (I think it was 5) all hell broke loose. This was a huge disappointment to me, I was expecting PIXI 5 to do that eventually but not while still in version 4. I did evaluate the changes and found they were deep and numerous to the point that my framework would have to be completely rewritten. problem is I already have a bunch of apps in production and I can't throw so much testing time down the toilet and start over. So I'll stick to 4.1 for now and make the updates myself and as for PIXI 5 I might have later to adapt it to my framework and not the other way around. It's really a trend that I think Apple started with all frameworks nowadays, why being backward compatible when you can simply just not care about it at all. 
  14. Like
    jinzo7 reacted to b10b in PIXI current versions in the future ?   
    Risk is minimal.  Minor updates are usually for specific reasons - a particular feature or bug fix.  So there is often only need to update if such feature or fix directly affects our project, sub-library, or user base.  Generally this is rare for a library as mature and well tested as Pixi.
    Major versions (and resulting deprecation) can be very exciting for early adopters but should be considered a "new book" - before opening we should check if we've finished the previous book and pre-identify why the new book is better.
  15. Like
    jinzo7 reacted to Exca in PIXI current versions in the future ?   
    Currently I would go with pixi v4. It is pretty mature library at current point.
    Depending on your project the same code will work on v3, v4 and v5 with small modifications. Though if you do something like custom renderers, filters, meshes and so on then you most likely need to do a lot more migration work if you want to change the major version.

    Inside a major version I have had no troubles updating.

    I have about 5 projects still working nice with pixi v3 and have had no problems from clients and havent done any updates related to graphics to those after they have been released (2-4 years ago). Same story with pixi v4 projects, the graphics part rarely needs updates.
  16. Like
    jinzo7 reacted to jonforum in PIXI current versions in the future ?   
    my personal opinion is that pixiGuys make a lot of effort to alert retroCompatibility.
    When a code becomes obsolete, your program works but you get alerted that changes are being made.
    so the risks are minor, if you work neatly.
    However I think that v.5 will be very different from v.4
    these confirmed, but I have read some discussion, and this should not be too difficult to update.
    Ideally, it is necessary to work by module, thus during a critical update, only the modules updated need to be modified.
    Rarely the integral logic of your application.

  17. Like
    jinzo7 reacted to ivan.popelyshev in When do I need to call renderer.render(stage)?   
    @jinzo7 I'll point other users to your post in the future
  18. Like
    jinzo7 got a reaction from ivan.popelyshev in When do I need to call renderer.render(stage)?   
    I appreciate it. I will make topic with example of PIXI and mvc soon(the weekend maybe). This is good tech and we can share it by simplicity.
  19. Like
    jinzo7 got a reaction from ivan.popelyshev in When do I need to call renderer.render(stage)?   
    Hello !
    In PIXI v4, you dont need to call requestAnimationFrame().It is called internally and the renderer renders app.stage (PIXI.Container) instance.
    1. Create PIXI.Application instance :
    var app = new PIXI.Application(800, 600, {backgroundColor : 0x1099bb});
    2. Append the  view of PIXI... app.view is your HTMLCanvas (canvas2d or webgl renderer). So you need it in your DOM.
    3. Use the stage(app.stage). Its PIXI.Container type. And Its your root container to add other containers(PIXI.Container) or sprites(PIXI.Sprite) and etc.
    var bigRect = new PIXI.Graphics();
    bigRect.drawRect(0,0,500, 500);
    Or follow the first example: http://pixijs.io/examples/#/basics/basic.js .
    And after this create other containers,graphics,sprites and add them to the stage or make composition.
    In PIXI v3, you have to call manually requestAnimationFrame()  and tell PIXI.renderer to render some container. And no random but your root container(PIXI.Container). The renderer renders the root container and all its children in order.
    The same is in flash,pixi and every child-based rendering.
    If you are new to PIXI - use v4. Anyway v4 is good to be used for learning or commercial products.
  20. Like
    jinzo7 reacted to Asisvenia in Do frameworks provide better performance than pure JS coding or not?   
    I understand you, as a newbie programmer I can tell you making platform/shooter games with pure JS is not easy. I'm not saying it is impossible because I don't want to discourage anyone. In my opinion, anyone can try and succeed it but you have to learn and implement concepts such as: physics, collision, shooting, sprite animations, loading etc.. that's why I spent so much time. I don't even know that game is good enough to attract players but at least I learnt many new things in this journey so I'm happy with that. You guys will decide whether this game good or not 
    Thank you for sharing your opinions with me again.