Posts by Cadde

    I wasn't blaming you greg. It happens to everything in MC.


    But at the same time, yes, i was pointing out that updating something on every tick is madness as far as MC is concerned.


    Last time i played RotaryCraft though, animations themselves were not an issue. But machines that updated every tick definitely were.

    Caching is of great importance.


    As for FPS limiters, i am yet to see one done properly. In a perfect world, FPS limiters would operate in such a way that it would cut out all other processing IF a frame is going to take more than 16.666 ms. (or whatever timestep one chooses) That is, render and input would be done first and foremost, then as time permits do everything else after that.

    This would mean that when someone like me has enough power to run at 300 FPS most of the time, i would have about 5 times as much processing time for other things. But when something HEAVY happens, it would be distributed over several frames rather than handled in one single frame.


    And of course, multithreading where it's needed as well as using the GPU as much as possible aside from just rendering stuff.


    But most every games i've played... Most every applications i've used... They all tend to do things "NAOW" when they really don't have to. It's like old Windows doing defragmentation of harddrives in the middle of a gaming session, whereas these days it's set up to defragment when i am not using the PC and as soon as i start using the PC in the middle of a defrag (which doesn't happen anymore because i have SSD's now) it would pause the defrag.

    That's what i want from other games... Sharing the load. And if for some reason there's still not enough time to run the game, then it would slow the game down rather than the renderer. And if that's not something i want, i would have to reduce the renderers priority myself or increase my processing power.

    Except that Greg is also planning "GregoriusT: Modder Unleashed - The Game"

    ...

    I meant discussing perception of FPS further was pointless. Not actual performance stuff.


    And i agree that modern games have focused too much on "see my game" rather than "play my game".

    But i don't agree with the maintainability aspect. You can write maintainable code and still have it run great. It's just that developers easily forget about putting heavy processes where they don't belong. Such as updating a whole chunk when only one block changes state.


    It's like telling every application to update their video buffers just because one application changed it's contents. There's dirty regions for that, the same way a single block should be marked dirty and only as often as necessary and that dirty region should be all that's affected.


    Minecraft has always had trouble with it's chunk handling.

    As for GC, a properly used GC is just as efficient as a manual one. It's the same amount of processing time except one does it on the spot and the other does it in batches. You can still do "on the spot" GC with managed languages. But better still is if you never have to do GC in the first place when something is to be used again unless you absolutely have to. And that's where an unmanaged language forces developers into thinking twice about their own GC. It's simply too easy to forget that leaving something out of scope (which would be a fatal memory leak in unmanaged code) will cause it to be GC'ed only for a new, pretty much identical instance to be created elsewhere.


    A constantly growing and shrinking memory pool is indicative of poor GC usage.

    It's random as well. If you find a 12x12 vein of tetra, another will find a 96x96 vein of tetra and say it's too easy still.

    Not every vein is the same size. And not every vein will spawn where you want them to. ;)


    I'd still say, it's working as intended and the rocks you find on the surface and/or in caves are pretty good precursors to what vein is in the chunk. (EDIT: cluster)

    Since i know for a fact that copper veins as well as tin bearing veins have spawned in the last GT. I will simply say, working as intended.

    With IC oregen on, GT becomes too easy.


    Besides, i played a game of GT in the past where i found neither and had to get by on small random rocks of both kinds as i was unlucky in finding any relevant veins. It was tedious but i pushed through.


    ...


    As for the FPS and game engine discussion... If i told you that you are only imagining things while gasping for breath on top of mount everest... Would you take me seriously?

    I mean, there are some climbers that can go to the top of everest without an oxygen supply so that applies to every human. Right?

    Discussing that further is pointless.

    Yeah, when i go near a fluorescent light it noticeably flickers. Being in Europe that is 50 Hz, not 60 Hz like the us. It doesn't matter if i've been playing or not.

    And on a 144 hz monitor, i can see a single frame drop. Most people around me are like "no, it's running purrfect" but when they run a fraps benchmark it's as clear as day that one out of those 144 frames did indeed miss it's mark.


    It's not something to be proud of to be honest. It's like being tall and therefore not being able to fit in a doorway without bending over like the hunchback from notre dame. It's painful most of the time. And imagine what life was like back when we all used CRT screens... I ran mine on 120 Hz and a lower resolution than everyone else because otherwise i would have to stop using the computer after about 10 minutes.

    I've had this discussion many times before. I won't bother explaining it to those that lack the same perceptions that i have.


    Essentially though, a 60 hz monitor is SLOW for my eyes. And even then, before i used higher frequency monitors, i could (without VSYNC on) tell the difference between 60 FPS and 70 FPS even though the whole screen only refreshed 60 times per second.

    It's because a screen doesn't paint the whole image in one go. There's a scanline. And i prefer VSYNC off as everything is PERCEIVED as smoother TO ME.


    And beyond that, there's other constructs that are quite common in gaming that definitely depends on FPS no matter what monitor you have.

    The game loop is traditionally bundled with the input, simulation and remote communications loop. Higher FPS means EVERYTHING runs smoother unless the developer has taken those things into special consideration and utilizes multithreading... PROPERLY.


    If you don't believe me, then google for the 333 FPS jumping boost in the GoldSrc engine. Basically, if you had 333 FPS or higher in any GoldSrc game that used the built in jumping code... You jumped HIGHER than everyone else. Not by much, but enough to be able to bridge gaps no-one else could.


    Don't lump me in with you just because you are fpsblind. (Essentially colorblindness but for FPS)

    On another completely unrelated note... Are the stats on Chromium and titanium burning boxes swapped on purpose or by accident?


    For example...

    Chromium boiler: 96 HU/t input

    Titanium boiler: 112 HU/t input

    Chromium burning box: 112 HU/t output

    Titanium burning box: 96 HU/t output


    So as you can see, their roles are reversed. The same applies for the dense/strong variants.


    And one more thing. Boilers are the only ones that will display their HU/t requirement as a decimal where all other machines use integers. It makes it confusing when using the NEI filter to see which machines are needed.

    Alright then, i will make a video in a few unless something gets in the way.

    But i can tell you in advance that the stem output of every boiler i've used has been irregular. IIRC, once every 2 ticks. I've had to set averaging mode on every fluid-o-meter. But i believed it was meant to do that as a performance saving thing. And that all your machines had buffers for that.

    Thanks Greg.

    But in response to the "rage inducing frame drops", we all have different levels of tolerance. Which is why i've spent my hard earned cash on a decent rig.


    For you it might be good to have 20 FPS. For me, that would mean i physically couldn't play the game as it would give me a throbbing headache. And frame drops does the same.


    But hey, while we are at the subject of rage... Imagine if you couldn't change stuff with either the core game or other mods to make your mod work proper? How fun would that be for you? Not rage inducing at all, right?


    EDIT: Oh, and if you don't mind telling me... How should i set that up in a non flickering way then? Ignore all the tooltips and use boilers that outputs the wrong amount of steam/t so the pressure valve is constantly wasting steam?

    The only reason i've used that particular setup is because that's the one that lands me smack in the middle of the power requirements so there's no unnecessary losses and it's not underpowered.

    The aim after all is to output 32 KU/t or above and from all i can tell reading the tooltips, that's exactly how one should set it up. No?

    On a completely unrelated note, connecting a red power framed red alloy wire (and enderio conduits as well) to a red alloy cable from gregtech causes a feedback loop that causes strange things to happen.


    See video:


    Essentially, if one uses gregtech red alloy cables, it's going to do different things on every other tile.

    Uneven number of tiles will cause a lock of the circuit when interacting with other redstone mods.

    Even number of tiles will cause a flicker to happen that kills FPS.


    If i just use gregtech cables then all is good so far. But the plan was to use the best of both worlds, as in i like how gregtech cables look and route. But i would still have to use other mods for their specific features. But gregtech and other mods doesn't play nice.


    So let's play the "blame the other mods" game... Oh wait, EnderIO and RedPower plays nice with each other. ;)

    I've tried really hard to break interoperability between EnderIO and RedPower and so far they do what they are supposed to do, except there's some delays that shouldn't be there. But that's fine, it's not like one would mix between EnderIO and RedPower when time is of the essence. For that i would use OpenComputers.

    Sounds play before the stutters appear. The stutters appear ONLY when the engine is constantly changing state from one color to the next.

    The FPS number is kinda irrelevant BTW. It's an average over one second. It doesn't show which of those frames rendered in 30 milliseconds and which did so i 1 millisecond. For that one needs to run a fraps benchmark. I could do that too, no problem. But so far it's pretty evident that the steam engine switching state from one to the other IS the source of the stuttering for whatever reason. And to be honest, it's not really the chunk updates either because i can run light shows in MC over several chunks without much stuttering. Stuttering ONLY happens when something takes too long in a single frame and i can have 200 chunk updates and still not notice any stutters.


    EDIT: Oh and i am on SP as i were when i made the missing recipe report.


    Either way, i'll just use electric engines then. No problem.


    EDIT #2: Btw, the steam engine doesn't happen to play the sound when it chances speeds does it? Because that could make sense if it's replaying the sound every tick and never gets to finish it. But at the same time, i haven't heard the engine play doubles nor have i heard it cut one in half. So maybe not.

    Nope, still stutters without any EnderIO stuff. In my opinion, just as badly as before i removed all the EnderIO stuff.


    I also made a test on a clean world with just a tank of distilled water and the same setup.

    And the stuttering is there, just not as heavy as it was in the "base" which is explainable.


    So i took it to some extremes and put ten of them in a row. It's all fine until the first one (because it had stored steam) starts to flicker. Then it's somewhat stuttery. Once all ten are up and running, it's like being eaten by a shark... If i ever knew what that was like.

    If you wanna know, the row is occupying two separate chunks.


    And no, sound playback is not the cause of the stutters. I notice you put that into the changelog. Sure, MC sound engine is bad but it's not to blame this time round.


    EDIT: whoops, i named two images incorrectly. Fixed that.

    EDIT #2: I'll add the shots without EnderIO as well. They are named "nope" as in nope.avi, it's not EnderIO's fault this time.

    I have a few Questions about this:

    ...

    1. Sometimes it's every tick, other times it varies between twice per second. The rate of flickering is consistent with the frame drops i am getting. As in, it varies a lot. And when both steam engines are running, it's twice as horrible. I haven't actually tried more than two engines at the same time.


    2. I thought so too. So i replaced all Railcraft tanks with yours. Didn't even know your's were that great. But then i thought it might be the sounds that causes the drops. But after turning sounds off it made no difference. So i enabled sound multi threading in your config and the issue was gone for a while, but then it came back (i will get to that) and eventually the game crashed with a concurrentmodificationexception. As i expected it to.

    I intended to replace all EnderIO conduits with your pipes as well but that's when i once again noticed the stutter was gone, just until the engines were up to speed and the flickering was back.

    I started googling for the problem and came across a post in this very thread about steam engine flicker and the fps issues they caused. So that's when i became certain that the FPS drops happen because of the flickering steam engine.


    Mind you, the world is a test world. I haven't actually started playing for real. Good thing too because issues like these always makes me ragedelete Minecraft. ;)


    3. I would very much think so yes as the bronze sifter and bronze crusher takes 32 KU/t and the invar steam engines produces 32 KU/t at 100 steam/t. Though they are the only machines that show up as ~100 steam/t -> ~32 KU/t rather than say 64-256 steam/t -> 16-64 KU/t as i would have expected?

    Am i getting this part wrong perhaps?


    Either way, as the strong invar boiler (i am using distilled water btw) should push 128 steam/t out of the ~100 steam/t necessary i would assume the engine gets enough steam to push the necessary 32 KU/t for the sifter/crusher.


    The animation changes, obviously, as the machine is running. I don't see any hints towards the machine not working correctly though.

    Also, i did try the electric setup prior to building this "base" and there was no stuttering then.


    ------------


    So yes, i think it would be a great idea to limit the color changes of the steam engine to once every second or so as it seems to (as far as i can tell at least) be the source of the stutters.

    That, or somehow make it so they don't cause a chunk update as evident from the screenshots.


    EDIT: I can test it without anything other than a distilled tank, some hax fuel and the machine setup if you want. But i think it would be better if you did it locally so you could debug? At least that's what i would do if i had a debug environment set up to begin with.


    Also, thanks for your time!