Jump to content

Search the Community

Showing results for tags 'garbagecollector'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • HTML5 Game Coding
    • News
    • Game Showcase
    • Facebook Instant Games
    • Web Gaming Standards
    • Coding and Game Design
    • Paid Promotion (Buy Banner)
  • Frameworks
    • Pixi.js
    • Phaser 3
    • Phaser 2
    • Babylon.js
    • Panda 2
    • melonJS
    • Haxe JS
    • Kiwi.js
  • General
    • General Talk
    • GameMonetize
  • Business
    • Collaborations (un-paid)
    • Jobs (Hiring and Freelance)
    • Services Offered
    • Marketplace (Sell Apps, Websites, Games)

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Twitter


Skype


Location


Interests

Found 2 results

  1. I'm just curious what are regarded as best practices to avoid the dreaded GC pauses that can mess with the framerate of your game. I've only made some really simple games so I don't really have that much experience with this. Generally the way I've made objects when outside gamedev type situations is pretty close the Crockford-style way of making objects by have a factory function that returns an object literal with functions that closures that refers to variables inside functioning as private variables. (Technically I use TypeScript, but I don't really need to get into the types for this discussion.) const createObject = (someArg) => { let variable = someArg; return { changeVariable: (change) => { variable += change; }, getVariable: () => variable, }; }; const o = createObject(42); o.getVariable(); // 42 o.changeVariable(3); o.getVariable(); // 45 From a purely programming ergonomics perspective this is the way of writing objects I find the most comfortable (not trying to convince anyone else here, this is just my preference). However, I've read many places that aspects of this can be bad for performance (even Crockford admits this about his own pattern). in typical JavaScript programming this seems fine to me, but for games I worry that I'm limiting myself in performance which can lead to slowness or limits to for exampe how many objects I can have running in my game. This has made me think that I maybe ought to be using ES6 classes (or something else that uses prototypes) instead of my closure based approach. Also, maybe I should use object pools? Or hell, maybe even entity-component-systems? Suddenly this stuff seems really complicated (I'm _almost_ wishing I could just use malloc and free, haha). How do you people deal with this? How do you balance ease of testing out ideas while having an reasonable path towards optimization if needed be? I'm generally thinking of using Pixi.js for graphics (hence why I posted in this forum), and Matter.js for the times I want a dedicated physics engine. Sorry for the long post! I'll be very grateful for any thoughts on this!
  2. I have Class constructor that require options parameter, that parameter is plainobject {}, also it has 0 or more arrays inside and another plainobjects. I create a lot of instances of this Class and these are succesfully pooled already. But I am wondering what to do with this options param like this one: { type: "type", ..., bodies: [ { type: "type" ..., }, ... ], ... } Sometimes options param is hardcoded, sometimes algorithm gets it by net connection in arraybuffer to recreate {} & []; What is worth pooling mechanism in javascript? For sure complex objects with a lot of properties and inner objects. What about these little guys then? {} & [] Is it worth to pool empty plain objects and arrays? With releasing it to pool you would remove all properties in {} and setting length to 0 in array.
×
×
  • Create New...