SpiderPig

@Josh Do you do anything special when rendering font textures? Or is this simply an artistic issue and I need better contrast between the background and text.

I'm moving the cylinder around with a kinematic joint. As you can see in the video it will slide nicely against smooth surfaces, but anything with hard edges it can sometimes get stuck, and it keeps trying to push through it. You can see if I keep the key down to move the cylinder toward the box when it's at the corner it will go through slightly and begin to jitter. Is this a physics issue or something I should program into the controller? E.g. Stop trying to moving forward if a collision is detected (I would have thought though the physics system should be handling this).

Looks like I got what I want working with this. auto pivot = CreatePivot(world); pivot->SetPosition(child->GetPosition(true), true); pivot->SetMass(1.0f); auto plane_joint = CreatePlaneJoint(p2, p2 - p1, pivot, child); auto slider_joint = CreateSliderJoint(p1, p2 - p1, planet, pivot); This means the child object still reacts to all physics, movement on all three axis and I'm pretty sure it's doing rotation on all 3 axis too... and when it collides with the planet sphere (which gravity is acting towards) it will stop moving and then move perfectly with the planet as it rotates. I don't really like using multiple joints, so if a joint can be made to do this. That'd be awesome.

Thanks, I'll do that.

That does make more sense. The package contains a material and shader. Although I didnt think it loaded the files inside straight away...

Thanks I'll give it a go in the morning and see what happens.

The PC is running windows 10 and.... actually... I think it's integrated graphics... should that make a difference to load package though? Surly it would fail in something like the window or framebuffer if it were the GPU?

Unfortunately with a remote debug it didn't give me much to go on. GameStart... 'TheSeventhWorld_d.exe' (Win32): Loaded 'C:\Windows\System32\windows.storage.dll'. 'TheSeventhWorld_d.exe' (Win32): Loaded 'C:\Windows\System32\wldp.dll'. 'TheSeventhWorld_d.exe' (Win32): Loaded 'C:\Windows\System32\profapi.dll'. Loading package "Data/Atmosphere/Atmosphere.zip" Exception thrown at 0x00007FF745A6DCA5 in TheSeventhWorld_d.exe: 0xC000001D: Illegal Instruction. Unhandled exception at 0x00007FF745A6DCA5 in TheSeventhWorld_d.exe: 0xC000001D: Illegal Instruction.

LoadPackage is crashing on a PC where I've installed my game but am not developing on. It prints to the console "Loading Package "filename"..... etc...." and then crashes. I've confirmed that the program is not exiting LoadPackage before the crash and no other information is being printed to the console. The data does not appear to be corrupt as I have copied over all files from my PC where it works, to the other PC where it crashes. The only other thing I can think off is that it might need some library that my PC has but the other does not? I'm saying this is a bug because LoadPackage is crashing with no error to the console. Unfortunately I have no example as it seems to be on a per PC basis. Perhaps something comes to mind that might cause LoadPackage to crash?

I see of lot of information on the web saying you not allowed to redistribute the debug DLL's. I don't know why considering you can just download visual studio and get them anyway. So I guess I'll just make it that if anyone wants to run the debug build they need to install visual studio.

From what I can gather, to run a C++ debug build you need the debug DLL's which there is no redistributable for. You either need to install Visual Studio on that machine or find the DLL's and export them with that project.

Okay, I had a feeling that might actually be the case. Thanks.

It might be that the release build is failing for a different reason. But as far as the debug build goes, is there anything special I should be distributing to run the debug build of my game?

What could cause these errors when starting the debug build on another machine? The release build fails to run too. Failed to find these dll's; MSVCP140D VCRUNTIME140D VCRUNTIME140_1D ucrtbased I've installed C++ redistributables as found on the learn page. And steam is installing them anyway

Ah okay. I guess I can use multiple joints if there's no other way.

I'm not sure how you've implemented the plane joint, but up vector has a function for that. Which sounds like a plane joint to me... http://www.newtondynamics.com/wiki/index.php/NewtonUpVectorSetPin

...maybe. But I think it would be easier just to change the pin instead of setting up multiple joints. Pretty sure newton has the ability to change the pin.

Run this example and you will see that the capsule collider goes through the floor before it collides. May need to enable wireframe after it collides to see that it's below the floor. #include "Engine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Ultra Engine", 0, 0, 1280, 720, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); //Create a framebuffer auto framebuffer = CreateFramebuffer(window); //Create a world auto world = CreateWorld(); //Create a camera auto camera = CreateCamera(world); camera->SetClearColor(0.125); camera->SetPosition(0, 2, -6); camera->SetDebugPhysicsMode(true); //Create light auto light = CreateDirectionalLight(world); light->SetRotation(35, 35, 0); light->SetColor(3); auto floor = CreateBox(world, 100.0f, 0.1f, 100.0f); auto box = CreateCylinder(world, 0.5f, 1.8f); box->SetMass(1.0f); box->SetPosition(0, 4, 0); box->SetCollider(CreateCapsuleCollider(0.5f, 1.8f)); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { world->Update(); world->Render(framebuffer); } return 0; }

I believe we need a setter and getter for the pin, like for the plane joint. Other wise the only way to change this is to delete and reconstruct the plane joint. Joint::SetPin() Joint::GetPin()

I was playing around with sliders and couldn't get the child object to collider with it's parent. This example here is the same. The green cube floats straight through the blue cube. At first I thought it was because the parent had no mass. But in my project, even if both child and parent have mass there is no collision between them. https://www.ultraengine.com/learn/CreateSliderJoint?lang=cpp

This might do what I need. http://www.newtondynamics.com/wiki/index.php/NewtonConstraintCreateUserJoint I think we need a joint in Ultra that allows us to parent a physics object to anther physics object and still have everything work.

I don't know if such a joint exists, but what I need is something that will allow me to spin a planet around with a kinematic joint and have all physics objects on the surface of that planet not move. In the video here gravity goes to the centre of the sphere. You can see once the small spheres come to a rest I start to spin the large sphere with the kinematic joint and the spheres on the surface begin to rotate. I understand that this is probably the correct behavior due to inertia and what not but I want to turn it off! I need a joint that I can use to parent lots of objects to one main physics object, that regardless of how I move that larger object the child physics objects will be constrained to it - but still react to physics! Pretty much being able to use Entity::SetParent() but not breaking physics, and having physics being able to run in local space to the parent. Is this something newton can do? I might post in the forums on Newton as well.

When accessing UltraEngine.com via mobile there is no where to log in. I had to go through the learn docs to find a link that took me to a sign up page. There I found a sign in link but there's nothing on the main page. Once signed in there's also no apparent way to access your messages.

Pretty sure I got it working. I'll test it a bit more before bringing in the game though. There is a switch statement for the change in the UP vector. Depending on what axis is UP currently to what axis is the target UP direction dictates what the rotation matrix should be for both the forward and side vectors. Should work for a round planet too.