TomC

Members
  • Content count

    13
  • Joined

  • Last visited

About TomC

Contact Methods

  • Twitter
    crysoftware
  1. Procedural Game Art Generator

    Just an update: Have powered on with development due to some time between jobs. On track to get both Mac and Windows released on itch this weekend. Some up-to date screenshots of how the software is looking, including the new 1-bit mode!
  2. #canvas:focus { outline: none; } replace #canvas with your canvas id.
  3. Accommodating different pixel densities

    How are you getting the screen width/height? As far as the browser is concerned it already takes into account the pixel density. i.e. 2560px retina screen will act as if it was 1280px. If you want your game to support retina the easiest way is: set the phaser game size to double the required size and then use canvas.width and canvas.height to set it back to the original size.
  4. Procedural Game Art Generator

    ^ Cheers!
  5. Procedural Game Art Generator

    Of course, just happens that a ship/sword with mirrored x axis our good examples. Sea monster (sorta monster/dragon thing, i'm not an artist!) attached below with the grid used to generate it.
  6. You could try: https://loonride.com/physics Haven't personally used it, but currently free and has specific phaser support.
  7. Do you build your UI's in MelonJS or DOM?

    Yes @Ian_ that would be the general way to go about it. There is always going to be some DOM manipulation required, and obviously you need to change the text, images etc. Just leave as much of it already rendered as possible and hide/show it as required.
  8. Procedural Game Art Generator

    Hi Guys, I'm pretty new here so quick bio, i'm a full-time developer from the UK and currently working on some game software projects in my spare time. Im currently building a software package for procedurally generating pixel sprites. Just wanted to see what people think and how many would be interested in the end product. Might look into the idea of crowdfunding so I could work on it one/two days a week and get it finished and packaged on mac/windows and linux. I have attached some outputted sprites so you can see the results. There's tons of configuration options so I have just gone with what I think looks good as an example. TomC
  9. Do you build your UI's in MelonJS or DOM?

    Nearly all html5 mobile wrappers support the DOM fine, even CocoonJS has WebView+ if you need to use the dom. It won't be too long until wrappers aren't needed and you can just use native web-views in ios/andorid anyway, and again the DOM is perfectly supported. As @Parasyte was saying, you just need to choose the right tool for the right job, and DOM UI's do not like to be moved around the screen performance wise. Also make sure you don't modify the DOM mid cycle, just pre create any DOM UI that isn't always in view and display: none; it with css until needed.
  10. Animation working when he want

    this.car.animations.add('mover',[0,1,2,3],1000, true); Looks like your setting the speed of animation to 1000 frames per second. Could you try setting it to something lower like 10 or 30?
  11. Just whipped up a jsperf. https://jsperf.com/declare-object-in-game-loop On firefox declaring the object inside the loop is up-to 100% slower! However on chrome/safari declaring inside is actually quicker by a very small margin. If your going to be dealing with older browsers and mobile's I would stick to declaring outside and re-using, If not then I wouldn't worry either way.
  12. For declaring a primitive value such as (bool , string, number) then the performance difference would be negligible. As the above posters have said, one way has a quicker lookup scope, the other doesn't have to re-declare and initialise the variable. However if the above example was any kind of object, i.e. var speed = [player.xSpeed, player.ySpeed] Then you would definitely declare this outside the update loop and reuse the object for performance.
  13. Adobe Animate Example Game

    Had a friend who was using Animate for a WebGl project and found quite a few nasty bugs. Problem is although an improvement over past attempts, the javascript output is still pretty messy. So if you get a browser bug you'll need to know you native JS/WebGL anyway, plus it will be messy and inconsistent to read. And if you know those languages anyway you might as well just use a decent WebGL library like Babylon/Three.js in the first place. Looks like any other code/scene builder, will save you time initially, will cost you time trying to get something release ready. Just my two cents.