Minecrift Discussion Thread

[Jademalo]

Also, I'm putting together a test build of Minecrift 1.6.4 that will use the Oculus SDK 0.3.1. It'll be windows only. Give me a few days...

Oooh, is there anything interesting that you're going to add? Option to let the SDK do the distortion?
Is there anything else interesting buried in there?

[AforA]

Hey somebuddy!

Glad you got Forge up and working. Sadly, it looks like one of the mods in the FDB modpack is trying to load a coremod that modifies the EntityRenderer class. We heavily modify that to provide the VR rendering, so it is unlikely to work without us writing explicit support for their mod (or vice-versa). Sorry about that!

@Stella: Since you're doing another 1.6.4 build anyway, could you rebase your code against OptiFine 1.6.4 HD U D1? Feed the Beast Monster and Forge 965 have known and severe incompatibility issues with OptiFine 1.6.4 HD U C6 which you are using, exactly due to a core mod.

[StellaArtois]

@Stella: Since you're doing another 1.6.4 build anyway, could you rebase your code against OptiFine 1.6.4 HD U D1? Feed the Beast Monster and Forge 965 have known and severe incompatibility issues with OptiFine 1.6.4 HD U C6 which you are using, exactly due to a core mod.

Sounds a plan.

Oooh, is there anything interesting that you're going to add? Option to let the SDK do the distortion?
Is there anything else interesting buried in there?

Well, I'm working my way through it... slowly. Did I say days? I meant weeks... cough

I'm working on the assumption that we want to let the SDK do the rendering, meaning we will support any overlays / latency testing / updates to timewarp / distortion etc. automatically with each new Oculus SDK. We'll also support DK2 and it's pos track straight away as well (albeit with nothing to stop a disembodied head floating around animation wise to start with). The frame timing stuff will be handled by the SDK as well - I'm hoping this will make a night and day difference to Minecrift's achilles heel - too much head track latency.

Progress report so far - JRift has been updated to support the new SDK (obviously Win builds only at the moment). Now I'm just about to start plugging it in to the main Minecrift source. I need to get some low level windows OpenGL pointers from LWJGL somehow for the SDK rendering - I'm hoping reflection will allow me to do this. I don't want to have to build a custom LWJGL jar otherwise, to be honest!

[Jademalo]

The frame timing stuff will be handled by the SDK as well - I'm hoping this will make a night and day difference to Minecrift's achilles heel - too much head track latency.

*Squee!*

Looking forward to seeing the eventual product, good luck with it! =p

[somebuddy]

Hey somebuddy!

Glad you got Forge up and working. Sadly, it looks like one of the mods in the FDB modpack is trying to load a coremod that modifies the EntityRenderer class. We heavily modify that to provide the VR rendering, so it is unlikely to work without us writing explicit support for their mod (or vice-versa). Sorry about that!

@Stella: Since you're doing another 1.6.4 build anyway, could you rebase your code against OptiFine 1.6.4 HD U D1? Feed the Beast Monster and Forge 965 have known and severe incompatibility issues with OptiFine 1.6.4 HD U C6 which you are using, exactly due to a core mod.

I think this could be the solution.
FTB Monster works "fine" with OptiFine HD U D1. With C6 there is no function.

Thank you !

[CaptnYesterday]

FYI Minecrifters: 1.6.4 is up to build 22! Thanks Stella.

5 builds in 2 days.
Someone's been awfully busy.

[Jademalo]

Oooh! I'll have to check it out when I get a spare minute!

[StellaArtois]

These builds are just trying to create a clean base for plugging in the new SDK. Hope I haven't broken anything in the process. Last cleanup job todo - port to the latest 1.6.4 Optifine.

Further SDK 0.3 progress: I have some test code now running with the new SDK on an updated JRift. That is displaying all black at the moment Will be trying all the related suggestions on the Oculus dev forums...

[CaptnYesterday]

Good luck with integrating the new SDK. Be sure to let us know if there's anything that we can help you test.

I cannot wait for my DK 2 as much for the latency tester as for anything else. Outside of just enjoying the game I enjoyed many hours of testing for the balance between Fidelity and Function. With all the settings that Minecrift brings to the table, there are just so many things you can learn about settings optimization.
Here is hoping that we can use that latency tester in DK 2 to compare the plethora of settings in Minecrift (not really sure how the latency test works in practice). I can see this as great info to share and something that may be applied, in theory, to other games/applications.


Is this thread still the best place to discuss Minecrift and interface with yourself and Matt? I see a couple more out there on OVR and the other development release thread here on MTBS.

[StellaArtois]

Good luck with integrating the new SDK. Be sure to let us know if there's anything that we can help you test.

I cannot wait for my DK 2 as much for the latency tester as for anything else. Outside of just enjoying the game I enjoyed many hours of testing for the balance between Fidelity and Function. With all the settings that Minecrift brings to the table, there are just so many things you can learn about settings optimization.
Here is hoping that we can use that latency tester in DK 2 to compare the plethora of settings in Minecrift (not really sure how the latency test works in practice). I can see this as great info to share and something that may be applied, in theory, to other games/applications.


Is this thread still the best place to discuss Minecrift and interface with yourself and Matt? I see a couple more out there on OVR and the other development release thread here on MTBS.

Thanks Captn, will do.

Once the new SDK is integrated we should have automatic support for the lattency tester. We already have DK1 latency tester support in Minecrift.

This is the best thread for me, yes. As for Mark, I don't know.

[StellaArtois]

As an aside, can I just note that the Quaternion support is definitely as described - experimental. It should work correctly with just yaw offset, but any pitch offsets currently screw things up. With head tracking off, is also broken. And, I haven't been able to get the head sensitivity setting working either. So yes, experimental!

It's a low priority fix at the moment, concentrating on the SDK currently.

[Jademalo]

I like this thread for discussion and the release thread for installation/configuration help etc, personally.

[StellaArtois]

Port to Optifine 1.6.4_HD_U_D1 now up.

[Jademalo]

ヽ༼ຈل͜ຈ༽ﾉ Port Hype! ヽ༼ຈل͜ຈ༽ﾉ

[StellaArtois]

Further progress report. JRift library on 0.3.1 is working in the test app, I'm able to get a full Oculus SDK rendered distortion view all OK. All thanks to a great thread on the Oculus Dev forums HERE

Now to the port into Minecrift 1.6.4...

[CaptnYesterday]

Nice! That's a large step forward.

I have read the release notes for 0.3.1 and very curious to see what the differences will be when it is actually put into practice.

I looked at the comparison between 0.3.1 & 0.2.5, but as I am no more than a unity 3d hobbiest... I can't understand how the experience would be enhanced/changed. Can you expound on this? I would love to know.

[Jademalo]

Second on that!

[StellaArtois]

As I understand it, the main goal of the new SDK is to provide consistency of framerate, accuracy of motion prediction and precision in the timing of displaying the image to each eye. All while reducing latency to an absolute minimum, by:
- waiting until the last possible moment to take a sensor reading and then start to render a frame, and
- taking a final sensor reading during the final distortion phase, and applying a 'timewarp' image rotation to adjust for any changes in predicted orientation

A great vid on this: http://www.youtube.com/watch?v=WvtEXMlQQtI

Basically, what this boils down to should be spot-on tracking, and minimal latency. Quite how much of this is possible with the current Minecraft engine I'm not so sure; there seem to be a lot of stalls and hiccups during rendering which even Optifine doesn't seem to clear up completely. But hopefully, head tracking latency should be improved.

And then, with using the new SDK, you also get DK2 support 'for free', latency tester support, any overlays that oculus decide to supply in the future.

Worth the effort to port to basically, in my view.

[CaptnYesterday]

Thanks for laying that out, Stella. Can't wait to try any of this out in Minecrift. With my preferred settings, Minecrift is already more comfortable on my eyes and senses than most, if not all, other OVR demos/apps. Been like that since your 1.6.2 builds. MCrift just feels snappier.

Not sure how much of the new sdk will work in the MC engine? It's going to be awesome regardless of what gets utilized! Even if the time-warp piece does not work, I can't wait to get my greedy little world-building fingers on it. To be honest, because Minecraft is not a natively supported platform (unity 4/UDK), I never understood how you added support into Java in the first place. Then updated your builds to incorporate subsequent sdk versions(Your sdk updates are fast and furious). How? Was that hard?

:roll: yeah, I know. Probably sounds like a derp, but in unity I just drop in pre-made assets. It has been nearly effortless to get a basic scene up and going... Not to keep distracting you, but always fun getting answers to stupid questions.


Edit: almost forgot to mention how awesome it is that DK2 will work with MCrift simply do to your integration of the new SDK!!! Yo, Jademalo, up top! (I swear I'm going to bring back the 'High-Five' back...even if it is figuratively) :mrgreen:

[StellaArtois]

I'm just standing on the shoulders of giants.

Oculus themselves provide the SDK obviously. This is a C/C++ interface to the rift. Unity / UE4 etc will have integrated this into their engines.

We've done exactly the same. And there are two main reasons we've been able to do this relatively easily:

- The Minecraft coders pack (MCP). This is a framework that allows you to easily decompile, and critically deobfuscate the Minecraft source code. Once you have the source code, you can then work out how to plug in the Oculus SDK.
- Java JNI (or JNA, but we don't use that). These are technologies that allow Java to interface with C/C++ libraries such as the Oculus SDK.

So what we first have to do is implement a JNI 'wrapper' around the SDK. In this case, that is JRift. This has to be built under Windows, Linux and OSX. And then integrate this wrapper into the Minecraft source.

If you build the wrapper correctly, and not an amazing amount has changed in the SDK, then it is relatively easy to integrate and build the wrapper against a new SDK. However, with 0.3.1, nearly everything has changed, so the wrapper has been a total rewrite. Also, how you use the SDK has also changed - so that requires a rewrite of our stereo rendering code.

Minecraft uses OpenGL via a Java library called Lightweight Java Game Library (LWJGL). (Incidentally, LWJGL itself will have a JNI wrapper calling the c opengl interface dlls). With the new SDK, Oculus have provided support for OpenGL - so JRift (and hence Minecrift) will have no excuse to not support everything the new SDK does, including time warp. In fact the new SDK should (in the long run, not now!) make our lives easier to support new features in the future. The new SDK already means we don't have to handle the distortion shader side of things anymore.

On top of this (and to be frank, this is the bit I find a PITA) you have a shifting code base with Minecraft updates, Forge updates, Optifine updates. All these (and Minecrift) are 'core mods' which mess with the fundamental infrastructure of the Minecraft source. Porting to new versions (such as 1.7) is a major headache!

[Jademalo]

Edit: almost forgot to mention how awesome it is that DK2 will work with MCrift simply do to your integration of the new SDK!!! Yo, Jademalo, up top! (I swear I'm going to bring back the 'High-Five' back...even if it is figuratively)

o/\o

[CaptnYesterday]

...all thanks to a great thread on the Oculus Dev forums HERE

More (but rather dated) info on SDK 0.3.1 & OpenGL. Jherico in this one too. Looks like he knows his business!
Bet you have already seen this, but I gather that the next SDK release will be polishing up some of the OpenGL code.


Jademalo, when do you hop into Metacraft? I haven't seen Mumbleton since the early days and was going to hop in sometime this week for drinks and general tomfoolery. Not sure on the 'what time' but if you have a general time that I might see you, Stella, or Mabrowning... I'd like to plan my time around that.

[Jademalo]

Not sure if I'll be able to get on in the next couple of weeks, I'm really busy with a project of mine involving old broadcasting equipment. In addition to that I have an ear infection, so the rift is a total no-go atm. Come DK2 I'll definitely be on a decent amount though I think.
I'll let you know if I can get on at some point this week though, I haven't been on for a decent while so I'm in the mood to give it a whirl.

[StellaArtois]

So Captn, Jade - if you fancy doing some testing, try out the new parameters in the latest build 28. This isn't the 0.3.1 SDK, but I have made some changes to attempt to help head-track latency. It feels better to me on my rig anyway.

So the settings to play around with are combinations of:

Options->Head Tracking->Prediction On, Prediction Timing set to AUTO (which is zero)
Options->Optifine->VSync ON (this may need a restart of Minecrift to pick up the changes for some reason).
And with Vsync on,
Options->Render->Delayed render mode

There's also some settings in optionsvr.txt (beginning with 'frametimings') if you're really adventurous!

With the default config file and the above settings I'm getting some very nice results, even at 1280X800 with 3X FSAA, on a GTX580 3Gb.

[Jademalo]

Alright, I'll give it a shot in a couple of hours after my tea. Will probably only be able to manage 10 minutes, but that should be enough to gauge it.

What exactly have you changed with the head track compensation thing? I thought it was better to have that higher than 0


I will admit I'm extremely interested in Oculus's distortion in the new SDK, since most of the tracking issues I've ever had have been with the multiple shaders on top of the renderer rather than the tracker itsself. HL2 suffers from this terribly, but as I've told you before, with the distortion disabled Minecrift is extremely snappy.
I suppose that's the benefit of prediction and why it feels tighter to me.

[StellaArtois]

Alright, I'll give it a shot in a couple of hours after my tea. Will probably only be able to manage 10 minutes, but that should be enough to gauge it.

What exactly have you changed with the head track compensation thing? I thought it was better to have that higher than 0


I will admit I'm extremely interested in Oculus's distortion in the new SDK, since most of the tracking issues I've ever had have been with the multiple shaders on top of the renderer rather than the tracker itsself. HL2 suffers from this terribly, but as I've told you before, with the distortion disabled Minecrift is extremely snappy.
I suppose that's the benefit of prediction and why it feels tighter to me.

Setting it to zero now sets 'auto'. This is a dynamic setting whereby Minecrift records how long it took to render the past few frames, and then uses the median value of those times as the new prediction time value. This value is re-accessed constantly.

[Jademalo]

Right, I managed to have a decent session and should have some interesting test results back for you!

First off, Auto prediction timing is horrific. =[
Thankfully I tried that last, because it tipped me over the edge of having to stop. It severely increased the floatiness of the tracking. 30ms is substantially better, and that's not a subtle difference like most of the other tweaks. It's a very, very obvious detriment. It sounds like a good idea in theory though, but it really didn't work in practice. Ah well, can't all be winners!

Next, the combination of Vsync and Delayed Render mode is... Interesting. It's a very minimal difference, a lot like texture lookup and brute force distortion modes. I imagine if I had a rig that could vsync at 120fps then it would be an improvement, but at 60fps it was a bit strange. To start with, Optifine is terrible at Vsyncing it turns out. There was a lot of slow tearing which looked extremely strange. Because it was dipping under 60 every so often, the benefit, if any, of the delayed render was lost. Simply setting it to 100fps or something was a much more plesant experience, I assume purely because the higher amount of drawn frames combined with it not dipping below 60 provided a bigger benefit than what was gained from delayed render.

I still have a feeling the biggest losses are during the image processing stages, such as distortion and AA. The test with distortion turned off is still fascinating... Another similar test is high levels of AA in HL2 while still keeping above 60fps, it adds to the lag even though it shouldn't. In addition, the more prediction, the better it seems to feel for me. I have a feeling that's due to the same thing, except it's drawing the frame where I'm going to be, rather than where I am.
I am extremely excited to see Oculus's implementation in the new SDK, I'll give it a whirl almost as soon as you get that finished =p

Oh also, the new tilt mode thing you added flat out doesn't work. Crash on attempting to enable.
I also have one last question - What exactly is the difference now between reset origin and recalibrate? They seemingly do the same thing, all I can see is that one turns your character while the other doesn't. Tank mode renders reset origin useless though, I'm wondering if it's really neccesary having both still.

[CaptnYesterday]

Gave it a quick whirl

-Auto prediction felt pretty discomforting. I love the idea of it though. Where did you come up with this?

-VSYNC+Delayed render mode was a minimal difference to me as well. Although there was no tearing either way for me, "immediate" felt smoother. Maybe I can try this again in combination with other settings.(I learned something though. Vsync felt much smoother than I remember it.)

Ok, all that said, Stella you had a pretty fair experience with both enabled using this spec (default config file, 1280X800, 3X FSAA, GTX580 3Gb).
Beyond that is there anyway to just get a dump of all your in-game settings? Maybe different combinations change performance and I tend to test 1 parameter at a time for a controlled comparison.


All in all it was fun testing and I accidentally looked at an Enderman from a sky bridge... that sound!!!!!

[StellaArtois]

Many thanks for having a look at these options! But ack. Ok, not the response I was hoping for though! Very interesting.

I'm very surprised about the 'auto' setting (idea ripped from the 0.3.1 SDK) - it feels night-and-day better for me. Minecraft is very system and configuration dependent. Would you mind attaching your options.txt, optionsof.txt and optionsvr.txt files? What maps / servers were you on? Metacraft? Are you letting the chunks update before testing (I'm assuming that's a 'Yes')?

Have you guys set your video driver 'render ahead frames' to as low a setting as possible; 'OpenGL multithreading to OFF', etc? Are you using extended desktop mode with the Rift as the primary, or running in duplicate mode? Rift native res?

There was a lot of slow tearing which looked extremely strange.

I see that if I run in duplicate mode, or with the Rift in extended and not the primary monitor.

The test with distortion turned off is still fascinating

Minecrift renders at about 1.7 X resolution as soon as you turn on distortion, so there' a lot of extra rendering effort going on, not just the distortion shader. If you run 2X FSAA with distortion off, how does that feel?

In addition, the more prediction, the better it seems to feel for me.

That must surely imply you have a lot of latency from when the sensor is polled, to when it actually ends up on the screen on your rift.

Oh also, the new tilt mode thing you added flat out doesn't work. Crash on attempting to enable.

Euler versus Quaternion? Or something else? Could you post up a pastebin of the crash?

What exactly is the difference now between reset origin and recalibrate? They seemingly do the same thing, all I can see is that one turns your character while the other doesn't. Tank mode renders reset origin useless though, I'm wondering if it's really neccesary having both still.

Nothing. I need to remove that now, thanks for the reminder!

VSYNC+Delayed render mode was a minimal difference to me as well. Although there was no tearing either way for me, "immediate" felt smoother. Maybe I can try this again in combination with other settings.(I learned something though. Vsync felt much smoother than I remember it.)

Again this seems to smooth out frame delivery for me somewhat. Hmmm. I agree that VSync feels good though.

Beyond that is there anyway to just get a dump of all your in-game settings?

EDIT: Settings

Ok, this was all a stop-gap test to see if doing 'SDK 0.3.1' type stuff would improve things. It seems to have helped on my system, but not on others. My strategy now is to just get the new SDK plumbed into a preview build (Windows only for now) - the Oculus guys have no doubt done a somewhat more through job with the frame timing stuff than I can ever hope to achieve with a quick experiment!

We shall see!

[Jademalo]

http://pastebin.com/mEYV5tJR - Theres all my settings as well as the crash log.

Right, to start with my bad - I was in duplicate mode for that test. I set it to extended with rift primary, and it was still negligible, and the other results are all still valid.

Regarding the aa with no distortion, it's still very responsive. It's only once distortion is enabled that it gets sluggish, regardless of framerate. Out of curiosity, what is done first? the downsampling of the FSAA or the Distortion?

With the 30ms latency, it actually makes it worse if I turn off distortion. I'm fairly sure the issue isn't the polling speed of the sensor per-se, but the time from the sensor being polled to the frame being drawn.

Quaternation, and I've posted the log.

I'll do another test now with 1 pre rendered frame rather than Auto, see what that changes. Also, where is the option for OpelGL multithreaded?
I'm also curious to see what effect SLI has on all of this, I've been disabling one card delibrately but I'm curious.

[StellaArtois]

Currently, the distortion is done first, then the downsample. That will have to change with SDK 0.3.1, which will help latency, but possibly worsen image quality.

>but the time from the sensor being polled to the frame being drawn

That's exactly it.

>I'll do another test now with 1 pre rendered frame rather than Auto, see what that changes. Also, where is the option for OpelGL multithreaded?

Hmmm, it may have moved. I think it is just 'Multi-threaded optimisation' currently - nVidia console->Manage 3D settings->Global Settings (or Program Settings). Hmmm, need to look that one up.

>I'm also curious to see what effect SLI has on all of this, I've been disabling one card delibrately but I'm curious.

Using SLi disabled here.

>Quaternation, and I've posted the log.

Thanks! What version of minecrift are you using (forge, no forge hydra etc)?

[Jademalo]

>Currently, the distortion is done first, then the downsample. That will have to change with SDK 0.3.1, which will help latency, but possibly worsen image quality.

I wonder then - Is the fact that the distortion is being done on such a massive image the reason for the increased lag when multisampling? If the image was downsampled then distorted, since a much smaller resolution is being distorted, may that potentially increase performance of a multisampled frame? I'd be very, very interested to try that out, especially considering how quick it feels with distortion turned off, and considering that when I up AA, even if the framerate isn't affected it still gets more sluggish.

>Thanks! What version of minecrift are you using (forge, no forge hydra etc)?

I make my own custom profile because the defaults drive me nuts in terms of organisation.
I have a few extra things in there, such as special OpenAL dlls. I also have all of my mods contained in a mods folder that then has the correct subfolder format (/mods/mtbs3d/minecrift/1.6.4_b28/minecrift-1.6.4_b28.jar as an example.) The reason for doing that is it means I can easily see modded files without screwing up any of the other required things, and it also allows me to make different coremod profiles with ease to include say forge, optifine, minecrift etc.
I always compare my profile to the newly released one though so that I'm not missing anything out. It's essentially nothing more than a default with hydra and no forge. I'll check it again incase I've made a mistake, if I have then my bad.


EDIT: Right, another test session, some on a fresh world and some on FyreUK. Very little difference in framerate amazingly. 1 frame made very little noticible difference, but one thing was very strange - Vsync made it unplayable for me. It must have not enabled properly last night, but I had to set it to Max FPS pretty quickly. I have absolutely no idea why.

[StellaArtois]

>Currently, the distortion is done first, then the downsample. That will have to change with SDK 0.3.1, which will help latency, but possibly worsen image quality.

I wonder then - Is the fact that the distortion is being done on such a massive image the reason for the increased lag when multisampling? If the image was downsampled then distorted, since a much smaller resolution is being distorted, may that potentially increase performance of a multisampled frame? I'd be very, very interested to try that out, especially considering how quick it feels with distortion turned off, and considering that when I up AA, even if the framerate isn't affected it still gets more sluggish.

>Thanks! What version of minecrift are you using (forge, no forge hydra etc)?

I make my own custom profile because the defaults drive me nuts in terms of organisation.
I have a few extra things in there, such as special OpenAL dlls. I also have all of my mods contained in a mods folder that then has the correct subfolder format (/mods/mtbs3d/minecrift/1.6.4_b28/minecrift-1.6.4_b28.jar as an example.) The reason for doing that is it means I can easily see modded files without screwing up any of the other required things, and it also allows me to make different coremod profiles with ease to include say forge, optifine, minecrift etc.
I always compare my profile to the newly released one though so that I'm not missing anything out. It's essentially nothing more than a default with hydra and no forge. I'll check it again incase I've made a mistake, if I have then my bad.


EDIT: Right, another test session, some on a fresh world and some on FyreUK. Very little difference in framerate amazingly. 1 frame made very little noticible difference, but one thing was very strange - Vsync made it unplayable for me. It must have not enabled properly last night, but I had to set it to Max FPS pretty quickly. I have absolutely no idea why.

VSync definitely does not always 'stick' for some reason. Seems to be an Optifine weirdness.

It sounds to me as though you are not using JRift 0.2.5.4, JRiftLibrary 0.2.5.3. That's what the installer for Build28 sets up.

Going to give your config a go tonight. A 580 should not be much faster than a 570. I know you've mentioned this before - but what CPU are you using?

[Jademalo]

I should be using jrift .4, it was one of the things I edited.

My CPU is an i5-2500k. It's stock at the minute, but back a while ago when we were testing it was @4.6ghz

[StellaArtois]

My CPU is an i5-2500k. It's stock at the minute, but back a while ago when we were testing it was @4.6ghz

Ok, plenty quick enough... Quicker than my stock i7-920!

I should be using jrift .4, it was one of the things I edited.

Ok, now I'm stumped. So you're basing this on 1.6.4_b28_noforge_hydra? I'll test that again. 1.6.4_b28_noforge_nohydra works for sure on my rig, even with a clean install.

[Jademalo]

My CPU is an i5-2500k. It's stock at the minute, but back a while ago when we were testing it was @4.6ghz

Ok, plenty quick enough... Quicker than my stock i7-920!

I should be using jrift .4, it was one of the things I edited.

Ok, now I'm stumped. So you're basing this on 1.6.4_b28_noforge_hydra? I'll test that again. 1.6.4_b28_noforge_nohydra works for sure on my rig, even with a clean install.

Basically, yes. I'll try a reinstall of java.

[StellaArtois]

My CPU is an i5-2500k. It's stock at the minute, but back a while ago when we were testing it was @4.6ghz

Ok, plenty quick enough... Quicker than my stock i7-920!

I should be using jrift .4, it was one of the things I edited.

Ok, now I'm stumped. So you're basing this on 1.6.4_b28_noforge_hydra? I'll test that again. 1.6.4_b28_noforge_nohydra works for sure on my rig, even with a clean install.

Basically, yes. I'll try a reinstall of java.

Let me do a test run again first when I get home. Shouldn't need a Java reinstall (I hope).

[Jademalo]

Oh man, I'm absolutely livid. Mojang just pushed a new update for Minecraft that clears out every library unless it's in an active profile on launch. I've lost a massive archive of Minecrift builds, and a ton of mods since I keep my json profiles in a different folder to speed up load times.

God loving damnit.

EDIT: Found a backup from April. That's most of it.

I'm still extremely annoyed. Setting the mods to Read Only doesn't work, the launcher doesn't load the game.

[StellaArtois]

Oh man, I'm absolutely livid. Mojang just pushed a new update for Minecraft that clears out every library unless it's in an active profile on launch. I've lost a massive archive of Minecrift builds, and a ton of mods since I keep my json profiles in a different folder to speed up load times.

God loving damnit.

EDIT: Found a backup from April. That's most of it.

I'm still extremely annoyed. Setting the mods to Read Only doesn't work, the launcher doesn't load the game.

Why on earth did they change that?

[StellaArtois]

Progress update. We now have Minecrift up and rendering with the 0.3.1 SDK

Head tracking is broken currently, so I can't really test latency. But of note - the chromatic aberration correction seems better to me. Next up - fix head track, get our pos track implementation changed up a bit!

2014-05-17_19.30.24.jpg