Oculus PC SDK 1.3 (Oculus Rift CV1) + GLFW3

Here you go:  https://github.com/jherico/OculusMinimalExample

Many thanks for the sample jherico! I'll try it asap! :smiley: 

Hi jherico! It works! Thank you very much! 

It took me a while to port the sample to C but here it is a screenshot of the result (I use Notepad++ for development):



Now I'm working in a simple 3D scene (a cube and a grid); I'm dealing with math to track head position and orientation (I use my own math library, raymath).

Next step, adding support for Oculus to raylib, that way my students would be able to easily code in C for Oculus Rift CV1 backend. :smile: 

I feel sad for your students to be forced to use C as a learning language in 2016 ! This is probably the worst language choice to teach programming right now, and far from most development reality.

And it is a low level graphic engineer saying so…

Great example file.

Here it is a C sample of GLFW3 + Oculus Rift 1.4. Still working on it but already functional.

galopin said:

I feel sad for your students to be forced to use C as a learning language in 2016 ! This is probably the worst language choice to teach programming right now, and far from most development reality.



And it is a low level graphic engineer saying so…

No. It's close to the metal and the only proper language to make people understand pointers. Or what a type exactly is. How memory works. Once you know how to cleanly code in C, adding POO is a "detail". After that the next step is to write your own small compiler. Add some VHDL with a project to recreate a very basic processor. And only then you have a student that truly understand the full stack of a computer. Anything short of this and you have a code monkey dealing with magic he don't understand.  

Ofc if you want just code monkeys to make python and front end stuff, yeah, C is a bit overkill...

This is were you are wrong, you do not need a language to teach how memory works in a program. And mostly no one understand memory on modern architecture, too many cache level, multi core synchronisation and fuzzy prefetch logic, virtual memory, every assembly instruction is a fucking full program unrolling deep in your cpu.

And c++ is not POO, it is multi paradygm. C is for runner, and before running you need to learn how to walk properly. Yes, it is easy to write bad c++, even easier to write bad C, and it is not because you use high level concept that you do not have to understand them.


And C close to the metal is also a myth, it is high level language, or you would not need the compiler to perform optimisation. C++ is also more strongly typed than C, the malloc you want to teach them is the perfect example, returning a very weak void*, learning that first thing to do is to change the type to whatever is convenient to you is a dangerous lesson.u

galopin said:

This is were you are wrong, you do not need a language to teach how memory works in a program.

You actually do need exercise. if not it's forgotten.

mostly no one understand memory on modern architecture, too many cache level, multi core synchronisation and fuzzy prefetch logic, virtual memory, every assembly instruction is a fucking full program unrolling deep in your cpu.ou actually do need exercise.

Because you are assuming everyone code for X86 computers. Coding for robotics/older gen console (GBA is a very good cheap platform to start with embedded devs), you pretty much understand the whole stack. Most of the "magic" you are describing is also done in a sub-assembly level and will change from processor to processor and from generation to generation.  

And c++ is not POO, it is multi paradygm. C is for runner, and before running you need to learn how to walk properly. Yes, it is easy to write bad c++, even easier to write bad C, and it is not because you use high level concept that you do not have to understand them.

I started with C at 10 years old, using early programming tutorials websites and my local library... I hence believe any one with half a brain can learn C at university level...

And C close to the metal is also a myth, it is high level language, or you would not need the compiler to perform optimisation.

It's totally not a myth. When you deal with anything electronic that use register, 99% of the time the library for them are in C. I have yet, in my career, to encounter cache manipulation or dirty cast/memory hack in anything else than C/C++. (exluding exploits... I'm talking about features)

C++ is also more strongly typed than C, the malloc you want to teach them is the perfect example, returning a very weak void*, learning that first thing to do is to change the type to whatever is convenient to you is a dangerous lesson.u

On the contrary, it shows them the importance of rigor when coding. Or the fact that bitshifting 1 and multiplication of integers by 2 is the same thing, but yield completely different results on floats...

Things that are not visible (on purpose) in strongly typed languages (Ada being the best example here) or completely ignored in "var" languages (Derp javascript...)