Tiggs

Members
  • Content Count

    10
  • Joined

  • Last visited

About Tiggs

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ah -- good to know. I'm running it on a desktop with a GTX 980Ti, and haven't tested it on anything else yet. Will have to work out how to detect relative GPU speed, I guess, and then request different frag shaders based on that. I'm also running a lot of javascript on the main thread, while the shader's up. Will probably need to move some of that out, too. I'm still working my way up to the 3d layer. That looks wonderful from here -- well done
  2. I hear you. In that case you should be fine I started using TS for the day job a few months ago -- and there, my code gets used in various legacy JS projects, so I have to be more careful. But, by night, I write TS just for myself, too. The free version of Heroku is pretty great, for no-cost playgrounds. I'm currently giving Cloudflare workers a spin for $5 a month, as I don't need a server for my game, and it's "Always on". So far, I've only got a basic proof-of-concept loader screen up, but there's a lot of other stuff going on, under the hood. Quick peek here, if you're interested: https://cthulhu1872.indie.workers.dev/
  3. In Typescript -- sure. If you're developing code just for yourself, purely in Typescript -- then it should be fine. The issue only kicks in when you transpile it down into a javascript module for other people to use. Let's say you create a library containing the Output class with no TSC compile errors, that you then transpile and release as a javascript module. If someone then loads that module using javascript, & they write `let output = new Output` in their code -- then they're not going to see that error in their console when they try and construct it. It'll manifest itself later, maybe, if they run some code on that object that needs the initialization to have run first.
  4. So you're now seeing this kind of behaviour? const myOutput = new Output() const myOutput2 = new Output() const myOutput3 = new Output() myOutput.Print("This will implode, as it hasn't initialized") I believe that's because even though Typescript knows it's private, javascript doesn't care, and will let you merrily construct new ones, regardless. IMO, best way to handle that is to throw an error in the constructor, so creating a new instance will fail. That'll stop 'em. Something like this: private static _instance: Output; private static _locked: boolean = true; // This is only ever unlocked when we're creating the _instance, above. private constructor() { if (Output._locked) throw new Error('Output is a Singleton. Please use `Output.Instance` directly.'); } public static get Instance(): Output { if (this._instance === undefined || this._instance === null) { this._locked = false; this._instance = new Output(); this._locked = true; this._instance.Initialize(); } return this._instance; } Note you'll need a lock, so you don't throw an error when you try and create a new instance of the class internally. Don't believe you can do async work in a constructor, so a simple binary lock should be okay (as it should all run on the same code stack) -- but I've been horribly wrong before, so you should probably test that. A lot. A more dangerous alternative to making the constructor implode is to make it return the static instance, instead. Wouldn't advise it, though, because it subverts the general expectation that `new Output()` returns a non-shared version of the class.
  5. Ah, wonderful That will definitely be helpful, for the future. I expect the "Y was too big" thing happens a lot, tbh. The good news is that you're winning on that front -- at least for me. I'm developing a UI-heavy game, and one of the big reasons that I chose Pixi for my UI layer was its size. As you said, it's delivered gzipped, so even the full version comes down the wire at only ~70kb. For my use case, that's small enough. That said -- I'm kind of cheating. I've currently bootstrapped the whole thing with a small-ish (12kb) shader, which spins up a pretty background during the first half-second or so of page load, to distract the player while Pixi loads. That gives me enough time to then load Pixi, and gently fade some Pixi text in -- and it seems to work surprisingly well. My plan is to then use Pixi to distract them further while the 3d layer is loading -- and (hopefully) progressively bootstrap my way to 3d without the player particularly noticing. Truth is — it's the size of the 3d layer which is making me come back and look at deferring as much early bandwidth as I can.
  6. I have 'esnext' pretty much welded to on, so unfortunately not, but I'm sure it will help someone. Many thanks, anyway (Your 'constructor' in the Output class is missing an 's', btw.)
  7. Ah, okay -- that makes perfect sense. Previously, I thought @core was gluing it all together. I hear you. I expect I'm probably going to need to load most of the full bundle whatever I do -- was just hoping I could defer some of it to reduce the bandwidth during the initial download sprint. Since there are those not-obvious links, though -- I'll just use the full bundle for prototyping, and cut a custom one at the end. Just didn't want to head off in the 'wrong direction' with imports, and then regret it, later. Anyway -- many thanks for taking the time to explain that. That's helped clear up a lot. Much appreciated
  8. Hi all, I'm currently building a game with Pixi in Typescript. I'd like to use the ES6 modules, as I'm under the impression that by doing so, I should be able to treeshake any unused PIXI code out of the final build / load it in chunks on demand. So -- do we have a set of Typescript definitions for each Pixi ES6 module, something like: declare module '@pixi/app' { class Application ... } -- or am I just doing it wrong, and treeshaking already works with import * as PIXI from 'pixi.js'? Quick caveat: I'm new to both Pixi and Typescript, but wildly experienced at misunderstanding and breaking stuff.
  9. Tiggs

    SDF Text

    Many thanks for that summary. That's a wonderful list Will take a deeper look at pixi-ui and gown. May well work on a fork of one of those, rather than rewriting the entire wheel. Was secretly hoping someone had snuck SDF text into Pixi 5, without me noticing.
  10. Tiggs

    SDF Text

    Hi, all -- I'm new to Pixi development. I'm building a GUI-heavy game (think sports team management), so looking at using signed distance field text, if I can. What's the latest news on SDF text in Pixi? Is pixi-sdf-text the current state of the art? Thanks in advance