[winterhell]

For rotating the camera with the mouse you don't need a delta time for the current frame, as long as you take snapshots of the mouse X/Y deltas every frame. Maybe you changed the resolution you are running the demo?
As for movement of the type "press&hold a button", you do need deltaFrameTime measuring the time between the current and last frame, for example just before reading the input devices. And then you have pseudo code if(player1Controller.Right.isPressed) player1Character.pos.x+=movementSpeed*deltaFrameTime.

This post has been edited by winterhell: 09 January 2013 - 05:54 AM

[Relick]

So would a sensitivity slider be better? It is using the mouse X/Y deltas, but since the mouse is run by the hardware this delta can be huge for sensitive mouses per frame while small for insensitive mouses. Now that I think about it (I was in a rush) I guess using the time delta wouldn't really help.

[winterhell]

Yep, a sensitivity slider sounds like a good idea. You'll still have to tweak the default value.

[Relick]

Ok until GUI is added, sensitivity amount just comes up in the app title along with the FPS. Scale goes from 0 (no movement) to 2 (twice as sensitive as normal). O decrements by 0.1, P increments by 0.1. It has been pushed.

Next I think its necessary to get some base classes in. Make ourselves a Math.h which includes Vector2, Vector3, Quaternion, Matrix and perhaps even Transform to tie them all together. Its simple stuff but it will be inevitably be needed throughout the engine. I can try and do these tomorrow, but I can't guarantee anything as I must revise for more exams.

As for the rest of the app, I think its time to stop putting in provisional stuff and start building what we will actually be using. A collision sphere on the camera is not necessary at the moment until we can actually get collisions implemented. I now have a pretty good grasp on how Bullet does stuff and how it works - I have abstraction classes already built up in my own project which I can pretty much just copy in. Just let me know when you are ready to add the bullet includes and I can get started on implementing and explaining it all.

[Sofox]

Alright, I've tried out your solution, and the problem is still there.
It seems I was hasty in my original diagnosis, and after looking at it more closely the problem seems to be more with the mouse warp. The cursor reaches the top of the screen and when it warps the the center, sometimes the camera resets to a position that looks straight down. Since the camera usually starts by looking down, it means that even just trying to get the camera look level requires the cursor to warp several times, one of which is bound to reset the camera meaning I can't get the camera to look up. I have to wave my mouse frantically before somehow the camera goes level and I can make small camera movements that adjust the camera without resetting it. I'm not sure what's causing this.

I do agree we need Math functions, but we don't need to put them in a class, just simple a set of standalone functions in a Math.h and Math.cpp file should be fine. Already I've committed the bare bones of this class, using the functions you've already written, to demonstrate how I think this should go.

I'm still not sure how we're going to use Bullet in this project. I'd appreciate it if you could give me a brief explanation of your abstraction classes beforehand.

As well as the above Math change, I've added to the collision mesh code so it's displayed in the world, and my next move will be the actual collision detection algorithms between sphere and triangle.

Also, as I said I would a while back, I've changed the license to MIT, there were no severe objections.

[Relick]

Sofox, on 09 January 2013 - 06:47 PM, said:

Alright, I've tried out your solution, and the problem is still there.
It seems I was hasty in my original diagnosis, and after looking at it more closely the problem seems to be more with the mouse warp. The cursor reaches the top of the screen and when it warps the the center, sometimes the camera resets to a position that looks straight down. Since the camera usually starts by looking down, it means that even just trying to get the camera look level requires the cursor to warp several times, one of which is bound to reset the camera meaning I can't get the camera to look up. I have to wave my mouse frantically before somehow the camera goes level and I can make small camera movements that adjust the camera without resetting it. I'm not sure what's causing this.

Whenever WarpMouse is called, it creates a mouse movement event. I specifically put in a check in case WarpMouse was called so that the mouse movement event it created was ignored in order to prevent the above behaviour from occurring. As I can't replicate it on Windows, I'm installing Ubuntu in order to see if it is a problem with Linux (and then I can subsequently fix it).

Quote

I do agree we need Math functions, but we don't need to put them in a class, just simple a set of standalone functions in a Math.h and Math.cpp file should be fine. Already I've committed the bare bones of this class, using the functions you've already written, to demonstrate how I think this should go.

I'm not sure what your objection is to having classes like Vector3, however AFAIK you are the more experienced coder so if there is a better way to do it then please let me know for the future.

Quote

I'm still not sure how we're going to use Bullet in this project. I'd appreciate it if you could give me a brief explanation of your abstraction classes beforehand.

If you are able to get on the IRC tonight I can explain in full.

[Xaklse]

Relick, on 09 January 2013 - 05:41 PM, said:

Next I think its necessary to get some base classes in. Make ourselves a Math.h which includes Vector2, Vector3, Quaternion, Matrix and perhaps even Transform to tie them all together. Its simple stuff but it will be inevitably be needed throughout the engine. I can try and do these tomorrow, but I can't guarantee anything as I must revise for more exams.

If you're going to use Bullet...

#include "vectormath/vmInclude.h" //An optional header file from Bullet Physics,
                                  //provides functions for 3D/4D vectors,
                                  //3x3/4x4 matrices and quaternions.

typedef Vectormath::Aos::Matrix3 Matrix3;
typedef Vectormath::Aos::Matrix4 Matrix4;
typedef Vectormath::Aos::Quat Quat;
typedef Vectormath::Aos::Vector3 Vector3;
typedef Vectormath::Aos::Vector4 Vector4;

[Relick]

Xaklse, on 10 January 2013 - 03:21 PM, said:

Relick, on 09 January 2013 - 05:41 PM, said:

Next I think its necessary to get some base classes in. Make ourselves a Math.h which includes Vector2, Vector3, Quaternion, Matrix and perhaps even Transform to tie them all together. Its simple stuff but it will be inevitably be needed throughout the engine. I can try and do these tomorrow, but I can't guarantee anything as I must revise for more exams.

If you're going to use Bullet...

#include "vectormath/vmInclude.h" //An optional header file from Bullet Physics,
                                  //provides functions for 3D/4D vectors,
                                  //3x3/4x4 matrices and quaternions.

typedef Vectormath::Aos::Matrix3 Matrix3;
typedef Vectormath::Aos::Matrix4 Matrix4;
typedef Vectormath::Aos::Quat Quat;
typedef Vectormath::Aos::Vector3 Vector3;
typedef Vectormath::Aos::Vector4 Vector4;

Thanks for that, I hadn't realised that Bullet had separated their vector stuff. It's definitely interesting stuff.

@Sofox, this is one of the reasons I want to use Bullet - they implemented Sony's SIMD vector maths library into it. This means that the physics can handle more objects at a lower cycle cost meaning more detailed collision etc. Using Xaklse's code we can even make use of this ourselves (with little implementation effort) and it gives the designer even more resources to use in their game.

This post has been edited by Relick: 10 January 2013 - 04:01 PM

[Relick]

Hey Sofox, not sure what's happened but after pulling your commit, I can't get it to run. It builds fine on Fedora, Ubuntu and Windows but opening the app just makes it close again straight away.

EDIT:
After debugging, I have found the problem is definitely in AddTriangle, and it crashes on this line:

mesh.triangles[mesh.triangleCount] = t;

Perhaps because you never initialise mesh.colMesh before that point (as far as I can tell)?

Fixed it by adding

mesh.colMesh = me_collision_mesh();

before the first AddTriangle. Pushed the fix. Now I can get to fixing that mouse problem ^.^

EDIT:

The only way I could replicate the problem was by turning on virtual mouse integration in VirtualBox. This caused the problem because even though WarpMouse was being called, since VirtualBox had control of the mouse it never actually moved into the centre of the window. However, if I disable the integration (so the mouse is locked to Fedora), then it worked fine.

When you move your mouse to the edge of the window, does it actually warp to the middle?

This post has been edited by Relick: 12 January 2013 - 07:34 AM

[Sofox]

Thanks for the fix Relick.

Yeah, whenever the cursor hits the edge of the screen, the mouse does warp to the middle. It's at that same instant that the camera sometimes resets.

[Kharen]

I really hate to be "that guy", but I've been trying to avoid asking this for what seems like forever, and it's really bugging me...

Are there any updates to this project? Not updates as in "We're nearly done!" or "We finished this part, have some pictures!", but simply things like how development is going or what you're working on at the moment. I've been following this, just not posting because I don't know anything that would be helpful to you guys.

Anyways, I'm sorry for bugging you and asking what has to be the most annoying thing ever, but I really don't want this project to end up dead. A few days ago, a scanlation group that was translating one of my absolute favorite mangas had their website finally go down after an eternity of no updates whatsoever, so there wasn't anything like a message saying that they were finished or anything, it just stopped. I'd hate to have this happen here. If you're throwing in the towel, saying something would be nice. If you're not and I'm worrying for nothing, then confirmation would be nice as well.

[Relick]

I drop in IRC every other day to see if anyone is in there, however there usually isn't. I don't get a chance to speak with Sofox for long enough in order to sort out his mouse problem or understand why he opposes making / typedef from bullet maths classes. Now I've got end of main school exams coming up so I'm focusing on them until about halfway through June. If I get time I'll just be making some commits to get the thing rolling again.

If you want to speak in IRC about what you could do to help I'm in there now.

This post has been edited by Relick: 26 February 2013 - 02:33 PM

[Kharen]

Uh... I don't actually know how to use an IRC program. Also, I don't think I know much of anything I can do to help. My PC is from early '09, and has an overheating problem, so I can't do anything like modeling. I don't know any programming except for barely enough to read code and work out what it does. I don't know enough to edit it or find mistakes. The only thing I can think of that I can do right now is test things to see if they work on low-end PC's, and I don't think that's all too helpful.

I just wanted to know if the project was still going or not. I'm sorry I can't do anything to help.

[Rolken]

This particular rocket fell over on the launch pad when a soft breeze rolled by.

But if you're interested in game tech, Fabien Sanglard regularly posts great game engine analyses and discourses, which could be an interesting place to start learning about it.

[Sofox]

Hey guys, sorry for the lack of updates. Truth is a bunch of real life things have been taking all my attention from Mobius. Just recently I had to finish a few assignments that took up a lot of my attention.

Looking forward to the next few months, I will be busy, but will have a less busy week here and there. I can't promise constant activity, but I'll try to get more stuff done on the project in the future. Sorry I dropped the ball in the meantime, which is exactly what I criticised the previous project leader for doing...

Relick, we'll need to talk about the issues you mentioned. I'd assumed you were going to look at the mouse control details yourself or at least revert the changes for the time being which I suggested you doing. To be honest, in general if a commit someone make causes problems, it's their responsibility to either fix it quickly or revert it (especially in our case since we only have one main branch). It honestly was a bit of a blow to my motivation on the project to see changes that screwed with what I had been working on and then having those changes interfere every time I tried to test the engine, even if I was testing something completely unrelated. In any event, it's silly it's been left this long. People working on the same code should communicated and coordinate so I'll try to head to the MobiusEngine IRC channel and we can discuss it more in real time.

Kharen, IRC is something we've all had to learn to do at some point. It's just a case of installing a program and following a guide. Usually, you just need to find the right place to enter your server name, chatroom name, and your own user name and the rest is just minor details about the program itself. The most common program to use is mIRC which you can get here: http://www.mirc.com/ and you should be able to find instructions on the internet.
Testing on low spec computers is a helpful task. As for other skills, for programming, just download Code::Blocks from here: http://www.codeblocks.org/ and try coding in that. It's not the best IDE, but you can write code and then have it compile and run at the click of a button which is good if you're just trying to get familiar with code.

This post has been edited by Sofox: 06 March 2013 - 04:54 AM