• Content Count

  • Joined

  • Last visited

About kaan

  • Rank

Contact Methods

  • Twitter

Recent Profile Visitors

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

  1. Below 4096x4096 I haven't had any issues so far either, I'm too lazy to divide things into 2048x2048 Initially, without perfect .destroy's, some people experienced weird glitches, but now, with everything .destroy'ed perfectly, I'm hoping those issues will be a thing of the past I also got the distant impression that old drivers don't favor large texture's, so I added the high performance RenderTexture routine as an optional feature
  2. Very very interesting, thanks for that insight, I'm guessing MAX_TEXTURE_SIZE is the metric there Would dividing a large texture into 2 or 4 solve the issue?
  3. After my initial tests, I haven't come across any performance issues yet, however, I've stumbled onto a scale/resolution issue when Canvas is used, I'm guessing/hoping it's not a major issue, a bit digging might manifest a solution
  4. Hi I'm wondering whether a RenderTexture could be used for a 2d map that is roughly 2000x3000 at most On theory, a RenderTexture is a dream come true, it's like the ultimate cache, I'm just wondering whether it has any downsides, maybe WebGL or Canvas issues, maybe limitations I'm going to invest a considerable amount of effort into converting my complicated (not in a good way : ) and custom 2d map tiling routine, it would be nice to know potential issues beforehand
  5. After posting this, decided to calibrate my usage, found a sweet spot that pushed the fps from 55 to 60 TL;DR: Don't use TilingSprite for small areas, but for large areas, it makes a difference that matters, and matters a lot Interestingly, I expected the performance to be on-par with Sprite's on Canvas, but on canvas, with a calibrated TilingSprite, the fps was 18, while with regular Sprite's, it was 14, so I personally marked it safe to use for Canvas mode too
  6. Since Ivan pushed TilingSprite to visual perfection, I rushed to integrate it to my map_editor, it basically renders the entire map directly into the scene (questionable method, works wonders for me with a GT750M OSX, almost always 60fps, but we had a lot of issues when I onboarded a map creator with a GTX960M on Windows) Anyway, I had a test map filled with excessive amounts of area tiles, when I turned on my new TilingSprite routine for that map, the fps jumped from 4-5's to 60fps, at that point I thought, no matter how it's used, TilingSprite would be a life-saver in terms of performance But as it turns out, in another map, in a normal map, it dropped the map_editor fps from ~55 to sub-20's (Area's aren't that big) I added a condition to only use TilingSprite if the area is subjectively large, in that case, the fps remained around 55 My unprofessional and un-backed conclusion is to use TilingSprite mainly for ~full page Sprite's - or really large area's Just wanted to share my limited experience and check whether anyone else run any performance experiments
  7. They are switching to a V6 or a V8 engine
  8. This might also be to blame: https://en.wikipedia.org/wiki/Screen_tearing - However, I could only make people with P2415Q reproduce the issue, everyone else says the animation is smooth on their systems
  9. I had a chance to debug this issue a lot further It seems a chronic Dell P2415Q issue, the replacement monitor I got also has this, I even started seeing these sections sometimes while watching stuff (This version replicates it across various browsers and os'es: kaansoral.com/images/pixel2/index.html ) Sadly, only pixel-perfect games trigger and make the issue noticeable significantly, and the existing owners of the monitor doesn't seem to notice or mind the issue, which is pretty interesting on it's own, as these people are buying the monitor for it's color reproduction etc. too I guess I will try and make Dell recognise the issue, and hope I can find a replacement monitor myself, sadly only Dell makes affordable/decent anti-glare IPS monitors, I hope Apple's new monitor will be a worthy replacement Once again, thanks for helping me debug this issue, I really appreciate it
  10. Thanks a lot, just saw your reply I got the monitor replaced, yet still, I see the issue, I guess it might be a chronic issue with this specific monitor Or maybe there is an issue with the animation and it's only visible with this monitor's color dynamics etc. Anyway the issue still baffles me
  11. I think it's both the Chrome lag, as I see the occasional spikes on http://www.duckware.com/test/chrome/jerky3.html - and probably an additional delay too, might be from GC as you pointed out Currently my map is very basic, it's basically a small land piece on an infinite default tiles, so testing is a bit futile - the thing is, I'm unsure whether a pre-calculation in terms of map data/placement is necessary (most probably not) If the map placements is safe to re-calculate every frame, then the bottleneck becomes the drawing So basically, I'm going to extend my map format and map data right now, move towards an actual production map a bit, with no default tiles, with tiles that fill a rectangle that they are defined to, so the map data will be compact, yet the actual map will be not - there are repeating tiles, there are repeating edge tiles, there are repeating animating tiles, and there are cosmetic tiles - so until an actual map is ready, it's hard to speculate where the actual bottleneck is going to be You help everyone as much as you can, so I want to help your as much as I can, so I will try to test https://github.com/pixijs/pixi-tilemap/tree/dev-multitexture when I can, probably after the map data is ready As a very small humble suggestion, the documentation of pixi-tilemap is a bit lacking, so for an outsider, it's unclear what exactly the library does best and how exactly it's going to be used
  12. The animation: kaansoral.com/images/pixel/index.html This issue drove me crazy, basically, image-rendering: pixellated in Chrome caused columns to appear in my screen, they are differentiated by maybe 2-5% of a Contrast difference, maybe less, I thought it was my game, but I noticed the columns extend outside the browser window, so I moved my suspicions to the monitor, which is a Dell P2415Q My trials are more in detail here: http://forums.macrumors.com/threads/dell-p2715q-and-p2415q-4k-ips-displays.1816805/page-60#post-23077379 http://forums.macrumors.com/threads/dell-p2715q-and-p2415q-4k-ips-displays.1816805/page-61#post-23082108 Yet couldn't find anyone to test the issue I tested it myself in various systems and monitors, only the P2415Q consistently renders those columns, it might be a monitor defect/bug, or it might be that the color reproduction is better, I would be glad if someone else can test and detect the columns
  13. What do you mean by "its just all the sprites are stored in the buffer." - If I create but not render Sprite's, will they still slow down things? I currently have 12 map tilesets, all of them are smaller than 1024x1024 I intend to make the map smaller than 10.000x10.000, there will be areas which are just a rectangle, filled with a single tile, and the data for the map has to be <1MB, yet the actual number of tiles can be high, so my 128x128 pre-prepared map-piece-sprite idea might be a bust too, there might be 100K un-drawn individual child sprites in total (~16x16 tiles that are the children of the un-drawn 128x128's), not sure how much of a memory impact they will make I was also going to specially declare some tiles and integrate pixi-display to them, for example a tree, or a castle arc where you walk inside, yet I decided that it's an extreme amount of complication for something so simple, so decided to skip it for now - so now you can't walk into a tree, and the castle doesn't have an arc, walls are unconnected - Even if you solve the technical challenge, modifying my custom map editor for such an extra layer/section would be challenging
  14. No it was more basic, I attempted to remove things that went outside the viewport, and add the new things every frame, yet since order is important with rpg tiling, it didn't work out, the logic has to be bulletproof, mine wasn't (sometimes a 16x16 tile that is under an 8x8 overrides the 8x8, my conditioning was simple, didn't include a solution to this problem) They are from multiple .png images currently, otherwise I was going to test pixi-tilemap It was nice seeing Fatalist's example, the same slowness happens there too, so I guess it might be system related, every now and then, the 60fps becomes ~57, but since there is a pause that causes the dip, it is perceived as sluggishness (osx, gt750m, chrome, so anything is possible) I do want to inspect Fatalist's code in more detail when I can, the stats are impressive My next idea is to draw the map into 128x128 Sprite's, and add/remove these Sprite's to the map when the viewport shifts -- It's another lazy and easy to apply solution, it eliminates the need to analyze the map data at each update, solves the issue of order -- on theory, the only downside (to me) seems to be the extra memory usage (and some things are drawn multiple times, but shouldn't be significant)
  15. When I started building a game, I didn't think map drawing/re-drawing would be an early issue, but when I placed 30-40K 16x16 test tiles on the map, it became an issue, the fps quickly dropped to 10-20's I initially intended to draw the entire map at start, and hoped PIXI would ignore the parts which are outside the viewpoint, I'm assuming this is not the case? (It obviously isn't, let's move on) My current solution is to redraw the map at each 100px movements, I was initially only drawing the additional 100px's, however at the edge's things got complicated, things that should be behind things got above them, so I started redrawing everything, which is simple, yet ~3K sprites are destroyed and re-created at each update, which happens regularly if the character is moving I tried using pixi-display and setting an explicit zOrder for each tile - and - more easily updating tiles, deleting/adding ~100 sprites at each update, yet the performance doesn't change much So, currently, with the "redraw the entire viewpoint" method, the fps is 60, yet I feel some minor sluggishness, some frames are 50ms, the retiling takes 10-20ms, and considering there is few actual map data, I'm not sure whether re-visiting a hefty map data would be an overhead too (I'm unsure whether 2D range trees etc. are needed or not) I'm just wondering whether I'm re-inventing the wheel, whether there is an intended solution that will solve the problem without any significant overhead etc. I'm yet to inspect the existing solutions, pixi-tilemap to start with, I had to find an immediate solution and redraw-all was it