Posts by Player
-
-
A new preview build is available at (outdated, see newer posts for the most recent build)
It's supposed to fix various issues including the culling bugs. Additionally I've been trying to improve world renderer update scheduling to handle pathological cases better and tweaked the font renderer performance. Please test and give feedback
-
Muramasa: Something seems to have caused the pre- and post-decoration events to be fired in unmatching numbers, which indicates a bug elsewhere. Disable monitorBiomeDecorators in the fastcraft config to avoid the issue.
ate0ate: This may be fixed in the next build.
ZillaGames: I'm considering it, time's a bit limited and Forge still isn't on the last release though.
-
Quite some responses after being busy with Minecon and bug fixes..
lil_kreen: Constant heap usage fluctuations are normal for Java, 300 MB doesn't sound too bad and the way it's being handled internally is quite efficient. The usual cause for slow/stalled chunk updating is that a nearby chunk gets updated frequently mostly through broken mod code. Said nearby updating chunk "steals" the update time slow for the distant ones. Chunks not in view range also receive rather low priority. You can control the amount of time available for chunk updates through the max fps setting, lower fps limit = more time for updates. The metrics you posted look quite normal, although I'd expect the terrain part to be lower with FC 1.22. You may want to try the async culling option in the FC 1.22 config for slightly better performance.
MaouKami: That's quite well reprducable indeed, I'll see about adding said debugging functionality.
SpwnX: I believe I fixed a very related problem, so that's to be tested in the next build.
nicholasiv: That's fine.
Bogdan-G: Hmm the stall reports aren't overly conclusive, I'll investigate later.
Questwizard: 1.8 runs chunks updates in different threads, which works around most of the problem, but also most updates are from broken mod code, which just doesn't exist in 1.8 yet. In 1.7 all nearby block updates get processed instantly at the start of a frame, covering all block changes during the previous frame. I'll add some more logic to optionally reduce its impact at the cost of not updating right away. If 1.8 doesn't normally render nearby updates right away I'd consider that a bug... Distant updates are throttled in both versions.
Xyain_Jyrain: Sponge mixin support is broken right now, but it should be fixed for the next build.
jochuan: This crash is LWJGL's fault, I'll look into fixing what triggers it though.
-
It should work, you'll however need to prefix almost every translation key with ic2 if it isn't loaded from the ic2 jar. The exceptions are entries starting with achievement, itemGroup and death.
-
Xee1: That's not related to FC, with 1.22-ctest10 it'll just show up in a lot of stack traces just like minecraft itself, but doesn't have much of an effect on the crashes themselves. Likely causes for the crash I can think of are:
- a potential race condition between placing a block and using an inventory which doesn't contain the hotbar slots, i.e. doing those at a very similar time
- broken mod code in a gui that allows placing blocks while it's open
- a mechanism that places blocks as if the player placed them
- a faulty mod edit to the ingame gui (the one showing just the hotbar as in no "machine type gui")MaouKami: That's possible to debug with somewhat elaborate monitoring code, but that's only worth the effort if it happens frequently enough or can be reproduced easily. If it does we should get in touch to deploy that.
lil_kreen: What do you mean by "game menu"? The main menu or the one that shows when pressing esc while ingame? The latter stops the integrated server thread/processing while being shown and thus pauses the game.
As far as I'm aware such a large difference between ingame and paused may come primarily from lack of heap memory, saturation of all cpu cores or overly frequent chunk updates.
The debug screen can show some profiling information (http://minecraft.gamepedia.com/Debug_screen#Profiler_graph), yielding some more insight how much time is spent for entities/tile entities (root.gameRenderer.level.entities), chunk updates (root.gameRenderer.level.updatechunks), the actual world rendering (root.gameRenderer.level.terrain) or client-side simulation (root.tick). You have to re-open the debug screen to reset the values, otherwise they just accumulate+average infinitely.
-
Bogdan-G: The most stalls are server side when you do world edits. The client part looks fairly healty, there's only those suspicious glFinish calls, but I have no idea what's going on there. Maybe a mod renders too much geometry or forces lots of state changes in its block rendering code. The GC problems I've seen earlier are fixed. Unfortunately the sampling mechanism isn't very good for investigating spikes atm, so I can't really do anything more.
Entoarox: Thanks, I think I've just fixed this, did you increase the view distance by any chance? The issue is in FastCraft.
MaouKami: Tentatively that's not caused by Fastcraft. Apparently something adds/removes entities from a thread or an entity's writeToNBTOptional implementation does likewise.
-
-
-
-
Bogdan-G: The Mystcraft profiling was running while you acquired the data, reducing its expressiveness. This may be also the cause for the unusually high memory pressure and lots of client side simulation (mostly entities), which doesn't leave that much time for the actual rendering.
Optifine's smooth world renderer updater wastes some time with reflection, BetterFoliage slows wr updating down, weather2 does nasty edits, the threaded lighting mod is inherently broken and should be removed.
I've fixed the sampler issue for the next (upcoming) version, thanks for reporting it. The issue is sporadic, so it should usually work. The report (srp) format is the most useful for me.
-
-
-
Bogdan-G: With Optifine installed the fastcraft.distantWrsPerPass option has no effect since I currently have to disable the whole module including most of the more recent client changes. A sampler report with growthcraft may be interesting ("/csampler report <filename>") while it's running slow. The results are quite interesting, I'll look into further improvements and better debugging support to investigate the frame rate drops more.
Euphoria: Missing chunks are different, are they actually loaded on the server? The output of "/csampler chunkInfo" while hovering over one and looking at yields specific information about the potential cause. I could use some screen shots or a video to see what's happening, I don't think having seen something likewise myself. I'm assuming the asyncCulling config option is off?
Chocohead: Not directly, I'd be mostly responsible if animations don't play at all, but this looks different. If the animations on items in other inventories work I'd blame xu.
-
-
-
-
Thanks, this is some very interesting data. I wonder why Fastcraft reduces the framerate (compared to vanilla I think?), which would be something to fix. You may also want to try the asyncCulling option in the FC config to lower the calculation overhead, although that's quite experimental.
A sampler report (sampler download -> opening post) generated by "/csampler report <filename>" from your typical benchmark situation in the FC 1.22 case could be interesting as well.
-
-
Euphoria depending on your GPU you may need version 1.22 to see a difference in steady state, if at all. This area is way too volatile on Mojang's side and usually not the bottleneck, so Fastcraft targets mostly aspects that come increasingly into play when having a well developed base, moving around, lag spikes and the likes.
You can see FC running properly by looking at the F3 screen. Having mods like Optifine or Shadersmod installed disables some optimizations for compatibility.