Jump to content

timetocode

Members
  • Content Count

    124
  • Joined

  • Last visited

  • Days Won

    2

timetocode last won the day on November 11 2019

timetocode had the most liked content!

About timetocode

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    http://timetocode.tumblr.com/
  • Twitter
    bennettor

Profile Information

  • Gender
    Not Telling
  • Location
    Seattle, WA
  • Interests
    game development, pixel art, procedural content generation, game music

Recent Profile Visitors

2382 profile views
  1. I've found the specific piece of state that is "shared" between multiple spine instances and thus is resistant to having its texture changed directly. You will probably not be surprised to hear that this shared state is the "Skin" because that's pretty much how it is supposed to work. Interestingly `hackTextureBySlotName` is immune to this problem because it never messed with the skin itself, it just changed the texture of one active slot of a spine instance. Skins are only involved when a spine entity is first created, when it has its skin programmatically changed, or when an animation change
  2. I have a bug where I can create two different spine instances and hacking their attachments is linked. In other words if I change the attachment in spineA the attachment in spineB may change as well. I say "may" because it doesn't always happen. I think it follows the same rules discussed above where during an animation with multiple attachments some methods affect only the active slot whereas others affect the textures associated with a skeleton. My guess is the bug is one of two things: my code above that changes the attachment texture of the skeleton is using the wrong approach
  3. I rewrote it in typescript and put it into a PR: https://github.com/pixijs/pixi-spine/pull/347 I'm sorry that I don't actually know how to build pixi, so I was unable to test the final version, you may want to make sure it works. The version of it right before I pasted it back into Spine.ts was correctly able to change attachments in my own game. For reference for anyone reading this thread for attachment-hacking related purposes, here's the added code which contains the logic from earlier but refactored to more closely follow the style of Spine.ts' hackTextureBySlotName/index
  4. As it stands currently the issue is two parts: 1) `hackTextureBySlotIndex` will modify the *current* texture of an attachment in a slot, however if a slot has multiple attachments the attachment whose texture gets changed is whichever one is currently active. So this method gives an instant result, but won't change the hidden attachments. If called during an animation that changes attachments (esp if multiple frames), the results can be a bit random as it'll simply replace the texture in one frame of the animation. 2) using `getAttachmentByName` + `attachment.region.texture = newText
  5. I've got a spine animation where the sprite of a certain slot changes. This is essentially the same thing as in the spine demo where they make a character blink by having two different images for the eye and having an animation that swaps between them. Currently, due to spritesheets + pixi being superior imo to how spine wants to work, I use `hackTextureBySlotName` for everything. Now my question is how I handle the situation where a slot has multiple images that are changed during an animation? For example I have code like this: model.hackTextureBySlotName('head', Texture.f
  6. If the tilemap isn't mutatable (or if only a few layers are mutable) one can also get away with: keeping the map data in some simple form, like an array per layer containing ints for tiletype generating megatiles by drawing sections of the map (e.g. 16x16 tiles) onto a rendertexture add the megatiles to the game instead of individual tiles (maybe) hide megatiles that are offscreen (if your player only sees a small subsection of a much larger world) Baking a large number of tiles into a megatile takes a little bit of time (milliseconds, usually) but baking an entire
  7. Nevermind! The bug was that indices are an Int32Array and I had turned them into Float32s.
  8. Thanks @bubamara and @ivan.popelyshev I've been able to mutate my mesh a bit now. I'm stuck trying to change the indices, any idea what I'm doing wrong? const vertBuffer = geometry.getBuffer('aVertexPosition') vertBuffer.update(new Float32Array(vertices)) // works const colorBuffer = geometry.getBuffer('aVertexColor') colorBuffer.update(new Float32Array(colors)) // works const indexBuffer = geometry.getIndex() indexBuffer.update(new Float32Array(indices)) // makes my mesh disappear All of this except changing the indices seems to work. If I change the indices my object vanishe
  9. I'm trying to create a mesh that consists of a few dozen triangles that are going to change every frame (hopefully performs okay....) How do I actually do that though? Create mesh: const shader = Shader.from(vertexSrc, fragSrc) const geometry = new Geometry() .addAttribute('aVertexPosition', [initialVerts]) .addAttribute('aVertexColor', [initialColors]) const mesh = new Mesh(geometry, shader, null, DRAW_MODES.TRIANGLES) Attempt at changing aVertexPosition and aVertexColor each frame: mesh.geometry.addAttribute('aVertexPosition', newVertices) mesh.geometry.addAttr
  10. Okay so I only ended up making two fully functioning implementations, though I did go down a few paths just to benchmark varying techniques. I have not yet done any techniques with instancing (I've only been doing webgl for a few days and need to study some more). Hopefully someone finds this useful. So a few details about the underlying map data before getting into the specific techniques. The game is networked (nengi.js) and sends chunks to the game client as the player nears them (like minecraft more or less, but just 2D). Each chunk is an array of tiles, it happens to be a 1D arr
  11. I think I'll try making one of each of those for the webgl practice. Thanks Ivan!
  12. I was testing a little more, and while creating a new shader every time is a bit expensive, creating new geometry from the save vertices + uvs is cheap, and then I can put the data in an attribute on that geometry instead of as a uniform. I'm new to webgl so not sure if that is the right way, but seems promising.
  13. Hello! Loving v5 it's great! I've been trying to render an extremely large map of tiles in smaller chunks that load in as the player moves around. I've done this with sprites and a render texture per chunk and it works fine, but now to learn some webgl I'm porting the project to use pixi Mesh + Shader. I've gotten to the point where I have the vertices and uv coords for a 16x16 chunk of tiles (skipping the code, nothing special). I then create a mesh per chunk of tiles and position them around. Code looks like this: const shader = PIXI.Shader.from(vertexSrc, fragmentSrc, uniforms
  14. GC in javascript is frequently undergoing changes, but for the last few years (if this hasn't just changed...) one of the main problems is that it isn't occurring "in the background when the program is idle" like most people assume. In truth the biggest GC hit occurs while creating a new object -- i know that sounds unbelievably bad but unless it has recently changed that's what is happening. The reason GC is invoked while creating a new object is that the trigger for GC is based off of trying to allocate new memory but discovering too much memory is already used. So right in the middle o
×
×
  • Create New...