Pos 1–9 dari 9
1
oleh
Firefly5 tahun lalu
I debugged and fixed a rendering issue causing tiny pixel holes in the village pavement and village walls. This happened only when using the 'normal' texture detail level (mostly used on Android, Windows and iOS), but it was rather annoying. So if you ever had rendering problems or artifacts, this'll be fixed in the next update. It looks way better and 'solid' now.
oleh
Hummm5 tahun lalu
it's REALLY hard to capture... only lasts for a split second https://imgur.com/VsVo3vU this image only has it in the distance, (village wall) but it's usually a split that runs the length of the brown walkway looking at this SS, it looks as if the the frame is rendered at 2 different vertical heights on the initial drop into the game. interesting side note, it only happens on first login/account (ie if I sign out, but don't exit the game, a sign in on the same account will not have the "rip", I have to change accounts to see the rip again)
oleh
Firefly5 tahun lalu
I see stuff, but I'm not sure what the 'rip/tear' is. I'm going to spam a few things in the hope that one matches it (a 'chunk' is a 32x32x32 piece of the world): – chunks fade in from bottom to top with a 'vertical fade' effect – if one chunk is faded in and the other isn't, blocks won't connect visually until fading is complete – chunks are lazily rendered, ignoring neighbors at first; this can lead to gaps in geometry until all surrounding chunks are visible and rendered again (<-- I think this is it) – after rendering all chunks once, Angeldust will re-render any chunks for which the neighbors are now known, patching all gaps left by the previous step – lightning is propagated between re-renderings of a chunk and it might not connect fully until your computer is all caught up rendering
oleh
5 tahun lalu
As of the lazy rendering of player modified chunks, it might work better if it put more priority on this and start rendering out further. It might be nice to multi-thread this across multiple processors to accelerate the process. I would propose starting downloading and caching the chunks at 24 claims distance (or a value based on the maximum the client's memory can hold if it is less), start rendering them at 8 claims distance (or view distance if lower), or when available if it is delayed. Prefetching, and rendering should be separate threads, and run a large number of asynchronous parallel threads each, based on number of processors, so they can run while the other one is in wait-stat. The only thread that should run synchronously is the final lighting cleanup pass. Chunks should be rendered in parallel horizontally across each claim, once a claim is rendered the client should move the next closest one in view. It should follow out of sight out of mind for all claims further than the adjacent claim point for rendering, but not for pre0fetching.
Pos 1–9 dari 9
1
Spectrum
