Initial implementation of the SILENT HILL camera. Currently can perform

[Quaker762]

a transformation to vertex data to project a 3D image, as well as the position of camera (as well as its lookat() position) which is able to be set. There is currently no collision detection/camera bounds, as we haven't reversed that yet.

[Quaker762]

@z33ky We should have some 3D stuff soon! There's no way to currently control the camera (I haven't really looked at the input side of things), but its position etc can be set!

[Quaker762]

I'm thinking whether it makes sense to have strongly typed degrees & radians types. For now we can just use float, but I'll draft something up.

That's a good idea, I'll review the PR now.

This should be good to go now. I'll open another PR though, as it relies (rather, the shader program) on the shader's ProgramID, which we currently can't get publicly.

[Quaker762]

@z33ky eek, I think I fucked something up...

[z33ky]

You should be able to resolve this by rebasing on master and when it says "Patch failed at * Add angle struct" do git rebase --skip.

[Quaker762]

Wew, okay fixed. Don't rebase yet, as it relies on code from another branch.

[Quaker762]

@z33ky This should be ready to merge (totally forgot about this pr...).

After this, I should be able to test models and see if they are loaded correctly etc. Once that done we should probably give animation a crack.

Pretty soon we're going to need to work out some framework for levels/menus etc (some kind of state manager??). I'm exactly sure how the game works out which level to load, but there's a huge function in the binary that loads every single file type (for a particular level), so I assume one of the file formats has interaction data for which level to load.

[z33ky]

What's the reason for keeping the FOV parameter a float instead of an angle? Also at least the documentation should specify that it sets the horizontal FOV.

[Quaker762]

@z33ky I must have missed that, I could have sworn I had it as an angle..... I'll fix it now.

[Quaker762]

@z33ky This relies on code that hasn't been added yet (program.GetID()). I'll create another commit for it.

Guess who forgot about #116

This should work as intended haha.

[Quaker762]

You've included some tabs in the source, while we have been consistently using spaces for indentation. Please replace the tabs by 4 spaces.

Interesting, I must have modified my vim settings somewhere... I've done a retab of all files with set tabstop=4 set expandtab and set shiftwidth=4 which should rectify this.

Please resolve those.

They have been fixed. I never realised the order of the initialisation list mattered in regards to variable declaration in the class' private/public section. Sorry :P

[z33ky]

I never realised the order of the initialisation list mattered

It matters if the initializations have side-effects, e.g. with my_thing::my_thing(int n): a(++n), b(++n) {} and the creation my_thing thing{0};, the values of thing.a and thing.b will depend on the order in which a and b are defined in my_thing. If a comes after b, then thing.a == 2 && thing.b == 1 will hold, which can be counterintuitive.

[Quaker762]

Hmm, the camera in the test program should initially look at the triangle, right? It doesn't seem to do that for me anymore.

I may or may not have been setting the pitch to -90f in the initialiser list when it should have actually been yaw... Oops...

I'll have to go over the math again to make it a bit more robust, but for now it works :)

[Quaker762]

I can't move anymore in the camera test.

That's really strange, I still can... Do you mean you have no translation or rotation of the camera??

[z33ky]

Yeah but I just noticed I was using the shader from the master branch in my build directory. Whoops, my bad. It's working fine with the correct shader :)