Jump to content

b10b

Members
  • Content Count

    691
  • Joined

  • Last visited

  • Days Won

    24

Everything posted by b10b

  1. Why scale the stage rather than the fontSize? A rescale like that won't necessarily resample, so pixels appear to have been removed in this case (creating the jaggies). Pixi Text is very smart with what it does. However it can't reliably know the final onscreen size at time of creation, so assumes that the fontSize requested equates to the onscreen size desired and samples accordingly. Alternatively bitmap font assets can be intentionally oversized to reduce some of that issue, but come with their own burdens. In summary, use Pixi Text as intended and it's great, being optimally s
  2. b10b

    PIXI Sound Filters

    Sorry that was my bad on the typo, too much haste on my part! Yes, package name is PIXI.sound.filters. I have corrected in original post to avoid errors propagating to others. Sound.from returns Sound. Sound has member "filters" which is a passthru to this.media.filters. I can see nothing specifically wrong with that code, so some debugging is needed - check whether WebAudio is being used perhaps?
  3. b10b

    PIXI Sound Filters

    Option 1. What's the error? (F12, console message). Try the full package reference ... const sound = new PIXI.sound.Sound.from('data:audio/mp3;base64,' + audiodata); sound.filters = [new PIXI.sound.filters.TelephoneFilter()];
  4. b10b

    PIXI Sound Filters

    I understand the goal but I do not understand the problem. Have you created a SoundInstance? Have you created a Filter? Are you aware of the "filters" (array) member of the SoundInstance? If so push the created Filter instance into that array (or create the array). Done. Think of it like adding a Filter to a DisplayObject.
  5. b10b

    PIXI Sound Filters

    Is your question about how to create a new Filter Class, or how to bind an existing Filter Instance to an existing SoundInstance? Are you wanting to run filters on mobile devices during intensive gameplay?
  6. Nice tut. I find it noteworthy that what we as developers call "without coding" is what schools call "coding" these days. I suspect it is us that need to change our language to theirs' - with coding being the arrangement of logic to develop a system. In turn the term "hacking" appears to be increasingly applied to the activity formerly known as coding. I don't really agree with that one (imo Hacking is about unauthorised access) but it'll probably stick increasingly as modern systems lay down proprietary rules by which contributions can be made (Apple etc). So in a way the mainstream "cod
  7. @Dr Popet good stuff, thanks for sharing your game
  8. Thank you. Webpage front door not currently working. Docs at https://docs.kheljs.com/ I couldn't find a repo link? NPM states license as MIT (but no mention of licensing in docs from what I could see, and no access to source before installing - via NPM only). Some easy wins to help adoption there
  9. Oof. I guess they have to spend the money gamedevs and investors have freely handed them (and reduce competition simultaneously)?
  10. You got me thinking about this Color Map some more. I think it'd be viable to include an index directly in the original texture and avoid the need to render twice to create a Color Map. Let's say any given color value is RGB 255,255,255. Let's sacrifice the last 3 bits of each channel. Max is now RGB 248,248,248. That gives us 111111111 as combined "spare" bits = 512 indices. Add the index back to the RGB channels. The eye will unlikely notice the loss of data. Now any pixel value can reveal an index between 0...512 to identify its respective Texture. This assumes no mipmapping, no in
  11. Nice - yes reducing the hitmap size is sensible, 8x is usually ok for "fast moving mouse". A very different approach to a boolean hitmap is to render the entire scene twice per update. The first render is what you currently want to see. The second render as a "Color Map" to an offscreen renderTexture using substituted textures (or a Shader) assigning a unique RGB value to each Texture which can be "looked up". A ray scan of sorts. Advantages of this approach are lower memory footprint and reduced pre-processing (no hitmaps needed), minimal overhead to do multiple hit tests, pixel perf
  12. I am wondering about your audience, who they are, where, what they spend money on, and how? At such low eCPM and no uptake on the IAP the answers might not be good news and hitting reset may be appropriate. Then pivot the positioning of the game towards a higher value audience and build the audience back up? But for sure, removing non-performing ads in the meanwhile is a very good thing.
  13. All ads are annoying, the value to obstruction ratio is negative whether someone is aware of it or not. Your players hate the ads; they don't click on them; no value is earned for the advertiser; eCPM plunges. Mathematical proof: at $0.05 eCPM you are needing to present 20,000 ads to earn a single dollar. Those ads have consumed hours and hours of players' time to display (even if dismissed immediately) to create the equivalent game content that can be developed for $1 of your creative time. This isn't just annoying, it is an irritation inflicted on others of such magnitude that it is easi
  14. Oof ... yet $2 eCPM is relatively "good". So my suggestion is to accept how it is and stop using ads - they are annoying to players and create negligible value to advertisers. Or, the benefit does not warrant the cost. By totally rejecting eCPM it may lead to discovering something new?
  15. Have you considered doing your collisions on a dataset that isn't the isometric view? For example, the isometric world is likely created with tiles (2D) from a dataset (2D map)? Why not generate a "hit map" (2D top down) at the same time the isometric tiles are parsed? Then use that exclusively for collision detection and Y displacement (for raised areas). I have a vague recollection that the original "Marble Madness" (or another old school game) used a chromakey of the isometric view for collisions and physics properties. A chromakey (where each item has a unique color, thereby r
  16. My advice would be don't worry too much about "spinning" reels or "graphics" to start off with (first project afterall). First think of columns of data ... each "reel" (x5) is an array of 64 "symbol"s. Then increment the "index" of that array per reel. The 3 symbols visible on each reel are: reel[index-1], reel[index], reel[index+1]. Next consider that -1 or +1 might take the array out of range, fix that with modulo: reel[(index-1)%reel.length], reel[index], reel[(index+1)%reel.length]. Starting a spin, stopping a spin, shuffling a spin, even animating the spin are now modifiers
  17. Yep ... think of it as "reading a page" rather than "flying a plane" then it'll make a bit more sense until it becomes automatic. Why is Y down? iirc it's to do with gravity, and how on early raster displays there are no lines, just a gradual droop of the ray with a period return of the X, and a period return of the Y as a multiple of the X period.
  18. Edit ... found it, three links in: https://www.facebook.com/fbgaminghome/developers/instant-games/approved-partner-program Btw I'm pleased to see this approach, I doubt I'd ever put "my" indie games on Facebook but it's good to see that copycats won't be able to clone my games as easily in future. It should lift quality and player experience.
  19. @serhiic is that your tool? If so thanks. One issue I found was (within styles) the drop shadow was on top of the stroke. Seems wrong to me, the drop shadow should be lowest element, underneath the stroke.
  20. https://pixijs.download/dev/docs/PIXI.Texture.html#from For the blob scenario it's a helper function to ImageResource which uses the same async methods you describe (image.src + image.onload). https://pixijs.download/v5.1.2/docs/packages_core_src_textures_resources_ImageResource.js.html So what's the alternative? Custom write a blob to pixel data parser in Javascript (to replicate the inbuilt image.src + image.onload methods). Then you have the option to run it synchronous and wait for completion by blocking the main thread. However ... Such a parser will likely
  21. I doubt there will be a holy war - neither are bad choices for making web games, but one is not a game engine so a direct comparison might be on shaky ground? From my understanding: Pixi is proven for putting things on screen in a mostly unopinionated way (library). Phaser is proven for making Phasery style games in a Phasery style way (framework). Pixi is first in class (not many alternatives for rendering 2D graphics fast to browser). Phaser has stiff competition (many alternatives for HTML5 game engines). Pixi will need developer expertise to make a technically goo
  22. Generally this. Or at least that's the starting point. There are finer points to consider: how large a buffer / margin to operate, how frequently to reconfigure the tiles, whether the larger tilemap should be chunked, whether tiles can be cached / cloned, ..., ..., ...., no end to it? Tiling is about juggling multiple subsystems at once, each having their own level of precision vs performance. Rendering on screen needs highest precision and will likely represent the largest impact on performance - so don't worry about abstract calculations that will reduce that burden. And remembe
  23. If I understand correctly the player is effectively being viewed in a predicted future - so when an unexpected interaction from the past catches up with them it is jarring because it proves the recent predictions wrong. The goal is to smooth this out to the extent it is no longer distractingly observable. This article explains some approaches better than I would manage here: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking The takeaway is to embrace a default 100ms lag. Compensate the Players' inputs (rewind time to when the input was most likely made) rat
×
×
  • Create New...