Jump to content

AggrorJorn

Members
  • Posts

    4,816
  • Joined

  • Last visited

Everything posted by AggrorJorn

  1. It just happened again with a test project. I found the problem though. The project worked perfectly but after removing the suo file (of which git suggests that you put in the ignore file) , it no longer works. Problem now is that I have really deleted it from computer (it is not in the trash bin.) Rebuilding simply wont work anymore.
  2. The joint creation requires a child and parent object. The joint itself is not an entity.
  3. Actually, I was extremely sarcastic. I am not even making this project for ios and android. it will take a long time before it is even in beta.
  4. Closed beta is on Monday. Beta is thursday. Release Mac and pc on wednesday. Thursday ios and android. Friday bugfixing, 1 free dlc release. Should be doable.
  5. Thanks Rick and Furbolg. It is really interessting to read about it and it certainly applies for the game that I am creating. The thing is: I am already glad that I got this far with the engine and console. I haven't even started on the game itself. This might be something for later when I have better skils with C++, engine design and design patterns. I think I am going to stick with what I have for now, but who knows, if my game would reach a 'completion within sights' range and performance is starting to go downhill, I will be forced to look in to this anyway.
  6. I have slider joints successfully working but I am left with a problem. Right now my object can move beautifully across the x axis. But now lets say that both the parent (a pivot) and the child (a box) are rotated 30 degrees. The code for the joint is this: slidingDoorJoint = Joint::Slider(0,0,0, 1,0,0, slidingDoor,slidingDoorPivot But what if I my object is rotated 30 degrees? I tried setting the rotation of the joint itself but that doesn't work. try it yourself: #include "App.h" using namespace Leadwerks;App::App() : window(NULL), context(NULL), world(NULL), camera(NULL) {} App::~App() { delete world; delete window; }//sliding Door Pivot* slidingDoorPivot; Model* slidingDoor; Joint* slidingDoorJoint; bool App::Start() { //Create a window window = Window::Create("_12_Joints");//Create a context context = Context::Create(window); //Create a world world = World::Create();//Create a camera camera = Camera::Create(); camera->Move(0, 1, -4); camera->SetRotation(0,0,0); Light* light = DirectionalLight::Create(); light->SetRotation(45,45,0); //Sliding door Shape* slideDoorShape = Shape::Box(0,0,0 ,0,0,0, 2,4,0.2); slidingDoorPivot = Pivot::Create(); slidingDoorPivot->SetPosition(-2,0,0); slidingDoorPivot->SetRotation(0,30,0); slidingDoor = Model::Box(2,4,0.2); slidingDoor->SetShape(slideDoorShape); slidingDoor->SetMass(1); slidingDoor->SetPosition(-2,0,0); slidingDoor->SetRotation(0,30,0); slidingDoorJoint = Joint::Slider(0,0,0, 1,0,0, slidingDoor,slidingDoorPivot,-2, 2); slideDoorShape->Release();return true; } bool App::Loop() { //Close the window to end the program if (window->Closed()) return false; float sliderForce = window->KeyDown(Key::E) - window->KeyDown(Key::Q); slidingDoor->AddForce(sliderForce* Time::GetSpeed() * 2,0,0); Time::Update(); world->Update(); world->Render(); context->Sync(false);return true; }
  7. That sounds like a huge gain. For the game that I am creating this could make quite a difference. So basicly I would create gameObjects and place them in 1 of the following lists instead of just a components list: The following lists come to mind: InitedList (Components that are initialised but not updated or draw. Think about a static model, particle or texture) UpdateList (Components that are updated. player, AI etc) DrawList(Components that are drawn. GUI related components) UpdateDrawnList(Components that are updating and drawing, dynamic GUI's) Please correct me if I am wrong and thank you for the feedback.
  8. I would really like to see some sort of gizmo or other visual representation for Joints. For instance: Ball Joints could have a little sphere mesh while Hinges could have a small cylinder mesh. Right now we have to create a visual representation ourselves.
  9. Thanks furbolg. Are you referring to empty Draw() and Update() calls? If so, what I want to do is something like interface for these functions like: IDrawable and IUpdateable. That way only if they posses these interfaces, components will be drawn or updated.
  10. Lua tutorials The new tabbing tags for werkspace make it possible to create multiple tabs inside a tutorial. I felt the immediate urge to make use of this by creating a special Lua tab. This tab contains the entire source code from the video tutorial, only converted to Lua. The first tree tutorials are already updated: http://www.leadwerks.com/werkspace/page/tutorials/_/shapes-and-physics-r10
  11. Besides making tutorials I am also working on my own project. It is my biggest one yet, but I think I have enough knowledge to get at least really far. Right now I am building my own engine on top of Leadwerks 3. The entire project is written mainly in C++. Component Based engine design. Since Leadwerks is very flexible you can do a lot of different things with it. The Lua scripts in the editor are a good example of component based design. However if you switch to C++ you don't have this directly at your disposal for C++. That means you would have to implement it yourself. Of course there are tons of ways of doing this but this blog shows how I do it in my project. Instead of Component Based Design you can also choose to go for 'Direct programming' like Josh describes in his blog here. Both approaches have their pros and cons. The reason I am going for Component Based Design is because I want to create code that is highly flexible and can be interchanged between projects. The GameObject class The current system that I have is a combination of direct (hierarchical) and component based design. The following image shows how it starts. The first class is the GameObject. The gameObject is completely empty at first, meaning it doesn't contain any models or textures. The only thing that it contains are components. Every frame all the updates that are enabled are being updated and/or drawn. This is the core of the component based design. Lets say we create a Player Gameobject. We can add several components to it: ModelComponent WalkComponent JumpComponent FPSCameraComponent HealthGUIComponent Now lets say for instance that we want to have TPSCamera instead of a FPSCamera. All we need to do is remove the FPSCameraComponent and add a new TPSCameraComponent. Not only is this system very flexible, it allows us to create components that can be easily shared throughout your project and perhaps even other projects that also use this component based design. The Component class Every component is derived from the Component class. The component class itself is abstract and thus can not be instantiated. Increasing complexity When you look at the first 2 images, you will notice that some functions and variables are exactly the same. Most programmers will come to the conclusion that this is a bad design. So for that reason we enhance our design as follows: This means that a GameObject is also a component. The complexity hereby increases but works a lot better when it is properly integrated. (Note that the images are toned down a bit to simplify the idea.) It is debatable whether GameObject inherits from Component instead of the other way around. I decided to go for Component since it is called a Component Based Design and not a GameObject Based Design. FSM and Components At some point I came to the conclusion that it is not always necessary to create an entire component structure to get the desired hierarchy in a level. For instance in a menu it is easier to create a (finite) state machine rather then having to switch between components. Although components work perfectly well for menu's, I think it is a good principle to think about where to use FSM's and where to use Components. The Scene class The component based design is far from finished but the basics already work. The last thing that I show in this blog is the scene class. The scene class inherits from GameObject (and thus also Component) and contains a list of Components/GameObjects. Every gameObject that is created needs to be added to this list in order to be updated or drawn. I specifically want a scene to have a camera so that I allways know that when I load a new scene, a camera is being created. Thanks for reading. Jorn
  12. It might be a little advanced for most people, but I would love an article about shaders.
  13. I am using 2012 but I have 2010 installed. If you use 2012, make sure that you do not upgrade the project to 2012 when you first open the project in 2012. I don't know about code blocks.
  14. function pointers are the only thing that I have tried so far. For commands that don't have any parameters it does the trick just fine I think. When I look at the best answer of this topic, there are plenty of solutions. I could use Lua but I am worried that it gets really messy when I try to call stuff inside C++. I also want to improve my C++ skills rather then Lua. (everything I learn about lua is a nice extra). I will try the provided solution and will also try other solutions.
  15. @Mumbles: Thanks for your time as well Mumbles. Let me first explain what I am trying to create: an ingame console. The first step is a simple command like 'DebugPhysics'. When this text is entered it should invoke a function without any parameters. The function pointers seem like a good approach. Once that works I also want to implement functions that take parameters. I will try this once I get home. @Rick: I am not at home right now so it might be that I have typed wrong in this post. //Header std::map<string, void*> myMap; void (*pointerToFunction)(); //CPP void MyFunction() { printf("test"); } //init in cpp pointerToFunction = &MyFunction; myMap.insert(pair<string,void*>(["Test", pointerToFunction));
  16. Great tutorials Acefelis. If I have time left for modeling I will surely make use of these.
  17. thanks for the answer. I tried that but it just gets me a different error: Expression must be a pointer to a complete object type. I also tried: (*(myMap["Test"]))();
  18. I am trying to call functions by storing them in a map with function pointers. I can't seem to figure out how the invoking of these functions are done: init pointerToFunction = &MyFunction; myMap.insert(pair<string, void*>("Test", pointerToFunction)); somewhere in update() myMap["Test"](); I get the error here that the object preceding the parentheses should be a void pointer.
  19. What I eventually did was create a new project on E:/. I didn't delete, change or moved any file, folder or setting, I just recreated the classes that I needed via Add->Class and then it finally worked. However as soon as I move the app.h or cpp in to another filter, things start to go down hill. Even if you place it back in the original state, it wont work again.
  20. Glad you fixed it. Things like this are so enormously time consuming.
  21. For private projects I use bitbucket as well. I haven't changed anything from the original folder structure.
  22. Tutorial #11: Classes Source code: http://www.leadwerks.com/werkspace/page/tutorials/_/classes-in-c-r32
  23. Yes they are, but the location is just the source folder.
  24. I do have my located on another hard drive and that works okay for me. The only thing that seems to mess it up for me is either: creating filters and store the app.h and app.cpp in these filters Placing the app.cpp and app.h in a different or sub folder from its original location $project/Source/
  25. Ahh superb. Its working now. The errors I get now are not related to these classes, so that is good news. I guess I am spoiled from using C# and Java. Thanks you both. this has been very helpful.
×
×
  • Create New...