All Activity

This stream auto-updates     

  1. Past hour
  2. Cache Coherency and Object Update

    Because of Amdahl's law - you want your most common operations to be cache-friendly because you get the most overall decrease in latency by optimizing the parts of the program that take up most of its execution time. Practically, this tends to mean designing your data layout in such a way that your access patterns minimize cache misses. It's not so much that such operations are the most common, so much as you could structure things such that you make them the most common. I agree in principle, but OP is asking about cache coherency and how to structure his program in a way that's cache-friendly... It's not that they're reflecting inheritance, it's more that implementation inheritance is reflecting a special case of composition. Does a car have wheels, an engine, and a steering wheel, or is it a SteerableGasolinePoweredVehicle which is a GasolinePoweredVehicle which is a Vehicle? Suppose I want a drawable component that isn't positioned in the scene or even a skeletal mesh that isn't in the scene, but is instead a UI element drawn at a fixed screen position? Do I have to create a CSkeletalMeshComponentForUI class? What should that derive from? And why do I care that a CSkeletalMeshComponent can be placed in the scene if my code doesn't deal with the scene, anyway? Suppose I'm writing code that only cares about the mesh and shouldn't care where it is, or even that it's renderable? As I understand it, it's actually the current thinking in the object-oriented world at large to prefer composition over inheritance. Deep inheritance hierarchies are considered a bit of an anti-pattern nowadays. Most "is-a" relationships are better modelled as "has-a" relationships - a "CSkeletalMeshComponent has a transform" is more straightforward to understand, less coupled, and is less design restrictive than "CSkeletalMeshComponent is a drawable-compononent-with-a-transform." To go back a bit: I encourage you to try other models. Just because some major engines use this kind of hierarchical design doesn't mean you need to - or even should. Big engines tend to be big due to exposure and inertia and featuresets - you know, the business stuff - not because their gameplay architectures are superior.
  3. I have some ideas

    Probably either a blog (if you just want to put complete ideas out there), or the Design or Writing forums (depending if your ideas are more about gameplay or setting/story - if you want feedback/discussion) then.
  4. Today
  5. I have some ideas

    Cool, thanks... Just have ideas, not looking for a team or anything...
  6. I had a bit of time, so I programmed approach (2): #include <iostream> #include <vector> #include <cmath> #include <cstdlib> double const gravity = 9.81; struct Polynomial { std::vector<double> c; // coefficients in decreasing degree order size_t degree() const { return c.size() - 1; } double &operator[](size_t i) { return c[i]; } double operator[](size_t i) const { return c[i]; } Polynomial(std::vector<double> const &c) : c(c) { } }; bool extract_root(Polynomial &polynomial, double &root) { size_t degree = polynomial.degree(); for (int attempt = 0; attempt < 5; ++attempt) { // Start with a random guess root = -1.0 + 2.0 * double(std::rand()) / RAND_MAX; // Refine the guess several times double value, derivative; for (int attempt = 0; attempt < 30; ++attempt) { value = derivative = 0.0; for (size_t i = 0; i <= degree; ++i) { value = root * value + polynomial[i]; if (i < degree) derivative = root * derivative + polynomial[i] * (degree - i); } double old_root = root; root -= value / derivative; // Newton-Raphson iteration if (root == old_root) break; } if (std::abs(value) < 1e-6) goto DONE; } return false; // No root found DONE:; // Divide by (x - root) double carry = 0.0; for (size_t i = degree + 1; i --> 0;) carry = root * (polynomial[degree - i] += carry); polynomial.c.pop_back(); return true; // Success! } std::vector<double> find_all_real_roots(Polynomial polynomial) { size_t degree = polynomial.degree(); std::vector<double> roots; for (int i = 0; i < degree; ++i) { double root; if (extract_root(polynomial, root)) roots.push_back(root); else break; } return roots; } double aimCannon(double cannonLength, double muzzleSpeed, double aimPoint_x, double aimPoint_y) { // I am going to use short names so the formulas below don't get too long double const l = cannonLength; double const s = muzzleSpeed; double const x = aimPoint_x; double const y = aimPoint_y; double const g = gravity; Polynomial p(std::vector<double>({ 0.25*g*g, 0.0, g*y - s*s, -2*l*s, x*x + y*y - l*l })); double t = 1e40; for (double r : find_all_real_roots(p)) { if (r > 0.0 && r < t) t = r; } if (t == 1e40) throw "No solution found!"; return std::atan2(y + 0.5*g*t*t, x); } int main() { try { double const cannonLength = 1.0; double const muzzleSpeed = 15.0; double const aimPoint_x = 10.0; double const aimPoint_y = 5.0; std::cout << "Aiming for (" << aimPoint_x << ',' << aimPoint_y << ") at speed " << muzzleSpeed << ".\n"; double const angle = aimCannon(cannonLength, muzzleSpeed, aimPoint_x, aimPoint_y); std::cout << "The angle is " << angle << '\n'; for (double t = 0.0; ; t += .1) { double x = std::cos(angle) * (cannonLength + muzzleSpeed * t); double y = std::sin(angle) * (cannonLength + muzzleSpeed * t) - 0.5 * gravity * t * t; std::cout << "t=" << t << " (" << x << "," << y << ")\n"; if (x >= aimPoint_x) break; } } catch (char const *msg) { std::cout << "ERROR: " << msg << '\n'; } }
  7. I have some ideas

    Welcome to GameDev.net! We have a blog section where you can post entries, forums for Game Design & Theory, and Writing for Games where you can get feedback on ideas, and a Beginners forum where you could get advice on developing your own ideas. We also have a Hobby Projects forum where non-commercial projects can recruit teams (commercial projects would go in the Jobs section). Depending on exactly what you want to do, one of those is likely to be the appropriate place.
  8. Where can I put them???
  9. Cache Coherency and Object Update

    I don't know , that seems like a lot of convoluted steps to reflect inheritance in my opinion. The skeletal mesh component is a subclass because it has a special tick function (performs animation) , and allocates a special render proxy that knows how to render skeletal meshes (CSkeletalMeshRenderProxy) , it also knows what data it needs to send to the rendering thread. Each drawable component has this type of specific logic.
  10. Cache Coherency and Object Update

    Why should such an operation be the most common? If a system needs to read data from N components in order to update one, then so be it. There's no conclusion you can draw from this. Even from a performance perspective, there will be little difference on modern caches between accessing multiple arrays in sequence versus accessing their elements interleaved. And if you ever each the scale where it matters, you'll have much bigger issues to deal with. What you should be more worried about is handicapping the design of your components and systems to meet unnecessary requirements, and making it that much harder to actual implement non-trivial gameplay with the ECS. It defeats the purpose of having one if you can't do what you to with it, and ultimately cause the kind of coupled spaghetti code mess you were trying to avoid in the first place.
  11. If you are building games and projects in Unity and targeting the Universal Windows Platform (UWP), you may have noticed than in the recent Unity releases this was actually broken. What you end up seeing in your build UWP project in visual studio is the following error: If you dig further, you may also expose the underlying error code here: This prevents you building / updating projects from Unity to the UWP Platform. Once discovered, both Unity and Microsoft worked closely together to resolve the issues and updated their respective parts as quickly as possible. Fixing the problem The fix for this problem is fairly easy. However, it is a little time consuming (unless you have a mega fast download connection) as mostly it requires updating to the latest Unity and Visual Studio patch releases. 1: Install Unity 2017.1p5 or 2017.2p9 The first step, is to simply update your installation of Unity: If you are on Unity 2017, then this is 2017.1p5 (or newer) If you are on Unity 2017.2, then this is 2017.2p9 (or newer) For the 5.x cycle, just update to the latest patch (although I haven’t tested this) This will update both Unity and your install of the Visual Studio Tools for Unity 2: Update VS 2017 to 15.3.3 Once Unity is up to date, you will need to update your installation of Visual Studio. If you are still on VS 2015, then there is no action but you won’t be able to build UWP packages targeting the newer Creators update and won’t be able to build Mixed Reality platform. To update Visual Studio 2017, simple close all open instances of Visual Studio and launch the Visual Studio Installer Once it’s running (the first step may be to update the installer first), simply hit “Update” on your specific instance of Visual Studio (the installer will happily update ALL installed instances if you wish) and once it’s complete you will be on the latest version. Open Visual Studio to verify, click “Help –> About Visual Studio” in the menu and you should be running 15.3.3 (or newer). If not, check your internet connection and try running the installer again. 3: (Optional) Set player settings for project to .NET & .NET4.6 (NOT IL2CPP, not tested but reports say it doesn’t play nice with Live) Not strictly required but highly recommended for UWP projects, is to update the .NET Api Compatibility Level that is used in your built project. This allows you to use more modern C# 6 functionality if you wish without causing errors when you build it in Unity. To update this, open the Player Settings window in the editor using either “Edit –> Project Settings –> Player” in the editor menu, or using the “Player Settings” button on the “Build Settings” build window. In the Other section on this configuration page you will find the following settings. Not to be confused with the “Scripting Runtime Version”, which I’m told breaks UWP project builds (although I haven’t personally tested yet) 4: Build project targeting UWP SDK 14393 or higher To build for Modern UWP, you need to be targeting a minimum API level of 14393 (Anniversary Edition), For Mixed Reality builds you will need a minimum API level of 15063 (Creators Update). Either will work but you need to ensure you select the version that is right for your target. The current advice with new builds is to always target the latest but that is completely up to you. You will find the SDK selection on the “Build Settings” screen when you have the “Universal Windows Platform” target selected: 5: Open project in VS Once you have built your project, open it in Visual Studio to continue. 6: UPDATE NETCore NuGet package to 5.4+ <- without this, it still doesn’t work In testing I have found this is critical still for existing projects or when you build your first (ever) UWP project, you need to have the latest NETCore NuGet package downloaded and available else it will fail. you don’t have to update the other NuGet packages if you don’t want to (UWP Packages come bundled with the Application Insights NuGets for Windows Store integration for example), just the NETCore package. To check and update the versions of the NuGet packages, right-click on the “Solution” in the “Solution Explorer” within Visual Studio and select “Manage NuGet Packages for Solution…” Alternatively, you can also simply right-Click the “References” branch in your projects structure, also in the “Solution Explorer” in VS, this however will only show/update the NuGet’s installed in that single project and not the entire solution: Once the NuGet manager is open you will see the installed NuGet packages, with a notification if any updates are available (provided you have an internet connection). Simply select the NuGet package to update, NETCore in this case, select the version to update to on the right and click “Install”. You will then be walked through a set of screens to accept the license for that package (if one exists) and then a final “get out of jail free” accept or reject screen. Once complete, all the required references included in that package will be updated. 7: Build and Run for x64 only (x86 or Arm is a no go still) With everything in place, all that is left is to build your project. By default, Unity still insists on selecting the ARM platform as the default (don’t know why but I guess it’s too small a thing to want to change), so you will need to update this to the x64 platform (don’t use x86 unless you really need it, most UWP systems all target x64 now). After that, you can build. If you are unsure about which Solution Configuration to select (read, Build Type), remember what they are there for: Debug Used obviously for debugging, enables extra debugging information to be sent to an attached instance of Visual Studio (whether you run it from Visual Studio or just “attach” to it later). Will cause a performance hit when running but this is needed so you can walk through the code if there are any issues. It will also enable the debug window inside Unity to report errors to the screen should they occur. Release Builds the project but without all the debugging stuff. just runs your project. With Unity however, it’s keen to note you are still running your entire project with all the superfluous code that Unity has in a project. DO NOT SHIP THIS!!! Master This is a special Solution Configuration (just for Unity) that also runs code in Unity to strip mine unnecessary code / services and packages everything together neatly. This makes your Unity project run as fast as it can. <- SHIP/PUBLISH THIS!!! All well and good With everything in this article, you should have no further issues building your UWP projects and once you have gone through it at least once (I’ve found) you need not do it again (apart from updating NuGets, you should always do that) Any issues, let me know or comment on this post.
  12. Sky Domes

    This sounds like it might be a face winding order problem or normals are pointing the wrong way. Using a cube is the simplest and if textured well enough you won't notice a difference between it and a sphere, no matter how many sides it has. This looks very simple, but I haven't tested it, it uses openGL but the steps are pretty much the same regardless. It looks like a series of tutorials so maybe he explained other parts that you need to fully implement it. http://www.mbsoftworks.sk/index.php?page=tutorials&series=1&tutorial=13 I would like to point out that the skybox should ONLY show the sky/sky and clouds. The cube map example image in the tutorial is a bad example for a skybox. If you need more help, you might need to start a new topic, since matt77hias asked about subdividing the geometry, and make an icosphere appear flatter.
  13. Important Information For Your First STEAM Release

    There is another interesting thing. You'll notice that when you start setting everything up Steam expects you to complete the Trading Card stuff even if your game is NOT eligible for them yet. The game and Store page will not be reviewed by Valve until this step is fully completed, at least this is how I understand it...
  14. You know that you can't overwrite the descriptors while they're in use by the GPU, right? There's no automatic driver versioning.
  15. Updated Release Date

    Ok now that my build and store page have both now been approved by Steam I have a new release date October 6th. It will be available on Steam, Itch.io and GameJolt. As far as I know everything is setup and ready to go on GameJolt and itch.io so I just have to push the release button and they should be good. From the documentation it appears it should be that easy with Stem as well. So mark your calendars and be ready to play. On another note I also, while waiting for Steam, have started the work on a new game. I'm still working out the details and getting everything figured out so I can start development soon. I can't wait to apply what I learned through making Farkle Friends and apply it to a new game. I have a few other ideas for future games as well. More details on my next game will be coming soon hopefully.
  16. Cache Coherency and Object Update

    In my world, more than one level of inheritance is "deep inheritance." And I use implementation inheritance extremely rarely - interface inheritance happens more often, but is still only one level deep. If your inheritance is just about code sharing, you could implement more or less the same architecture using composition - instead of inheriting, you'd have your CSkeletalMeshComponent contain components of the previous types and delegate to them. You should only use inheritance if you need to be able to take a pointer to a CSkeletalMeshComponent and use it like it's a CSceneComponent instead. Do you really need that, or can you just register the CSceneComponent with a system that deals with those components without caring about what object contains it?
  17. This is great stuff. Really helpful. I would not have thought of creating accounts (i.e. an agency user) or debugging as being wishlist features myself. As for whether Enjin will be just as half assed? maybe, maybe not. However the developers are highly aware of many of the common issues plagueing payments in general but they are also a more tightly focused team whereas Facebook has the Microsoft problem i.e. building very generally. As for the FB/Unity SDK Changes, are you talking about stuff completely deprecated? or stuff they have to leave out until they update for newer interfaces or dependencies? I would think that just relates to good general software architecture i.e. factory design pattern and other similar such techniques. I'm really fishing for specifically badly designed payment solutions or particular issues, whether unintentional or from lack of experience i.e. team has fintech but not gaming background or something
  18. Cache Coherency and Object Update

    Ah.. I'm not exactly ready to make that jump. Hiearchal components Is a model that I see game engines like, unreal , cryengine, lumberyard, decima, and etc use and personally it makes more sense to me. There are a lot of components that in some sense contain similar logic. I.e a skeletal mesh component and a static mesh component. They both require a transform, they both require a render proxy(my engine is multithreaded so the render thread has a version of each "drawablecomponent" which provides draw logic. They both need a way to sync data to the rendering thread, so there is a lot of logic that they share, in reality, the only difference they have is in their "update" function. My hierarchies aren't exactly deep though, they just exist and make maintenance of code a lot easier. They definitely have an issue with cache coherency, which is what I was trying to get at when talking about the benefits of ecs.
  19. Thanks for the info. Since we are on the topic, just curious to know whether it's optimal to use: The DESCRIPTORS_VOLATILE flag, create one big descriptor table and let the driver manage the versioning Separate the tables based on update frequency? The first scenario will have only one SetRootDescriptorTable call from app code. Not sure about driver code. The second scenario will have multiple SetRootDescriptorTable calls depending on the update frequency and the driver has to do no versioning since the app manages it. Thanks
  20. The order of matrix multiplication matters, so in Camera::GetViewMatrix() you may have to uncomment this line, I don't know how glm::lookat calculates the view matrix. //_viewMatrix = glm::lookAt(GetEye(), target, glm::vec3(0.f, 1.f, 0.f)); // Set Because this maybe be in the wrong order, you could just reverse the multiplication to check, or use glm::lookat: _viewMatrix = rotate * translate; Also, as a side note you can combine Camera::InitOrtho & Camera::CreateOrtho since they're both really small functions (2-3 lines) and CreateOrtho calls InitOrtho.
  21. First off nice job. The game is looking really good and is something I would definitely play. The dungeon seems fine to me... However, if you want some more depth you'll probably have to create more detailed and or darker textures for the floor at least. Maybe the brightness of the silver/grayish tiles are taking away from the dungeon vibe? Feels more like a facility than a dungeon. Dungeons are dark and dreary I suppose. Also lighting will be key too. You'll need to use the right light colors to create the mood you want e.g., darker dungeon textures with soft green lighting juxtaposed with red lighting. Maybe have those lights coming off wall fixtures or other objects. Afterwards see how the level feels with and without the flash light. Just some suggestions because you asked....honestly though, what you showed so far looks very cool.
  22. Cache Coherency and Object Update

    Indeed. With my approach (and the ECS approach), there would also be no inheritance hierarchy, and components would be pure or nearly-pure data. Just based on that inheritance hierarchy, I'm assuming you store your components in heterogeneous containers in your game objects? That's going to be difficult to make cache-coherent, I think. I'm also wondering what a "component" represents in your system. Deep inheritance hierarchies on components seems unusual, given that an advantage of using components is getting away from deep inheritance hierarchies. What are you getting out of this decomposition?
  23. test walk

    Hey not bad! Not sure what type of feed back you're looking for but I can try and provide some constructive criticism if you're open to it. Focus on your main key frames i.e., contact and passing for both the right and left side. The stronger your keys the better the animation will look. The walk just feels stiff. Without knowing anything about the character like her attitude, reason for being, etc. It's hard to gauge what you intended the walk to convey. So take my comments from the POV of a casual human walk. To get around the stiffness you'll need more rhythm in the hips, i.e., slight twist depending on what leg is in play and proper dips and rises (squash and stretch). Once you are happy with the main keys and they are solid. You can focus on really putting some personality into the walk in your in-betweens and break down keys. The main keys will continue to carry the animation at this point. Just can't stress enough how important it is to tighten up the main key poses. Ya gotta really sell each pose for contact and passing as it should/will drastically improve the animation....the human eye catches everything. Good luck and good job so far
  24. Cache Coherency and Object Update

    I don't think that would work in the current component system I have set up. Currently my hierarchy is like this : CEntityComponent (base class of all components) - CSceneComponent (base class of all components with a local/world transform and bounds) - CDrawableComponent ( base class for all components that should be registered with the renderer) - CSkeletalMeshComponent ... etc.. It seems that your approach is for systems that have one "CTransformComponent" . In my engine, a static mesh can be attached to a skeletal mesh , these two items would be in completely different systems, making your approach impossible.
  25. Cache Coherency and Object Update

    Well, for starters, this assumes that you keep your components in some kind of contiguous sparse array, where the components' "physical indices" don't need to be the same as their "logical indices" (ie. their entity identifiers), hereafter referred to as a "component container." The brute force way you could do that would be to have two entirely separate, hardcoded component containers. When you update the components, you'd run the same update loop on both containers, one right after the other. This is a bit off the top of my head, but suppose you could keep them in the same array, but just arrange the elements such that parents always come before children, and the rest of the ordering doesn't matter? So (for example), you might have the first 5 components be parent/childless components, and the next 3 be child components, and keep a "physical" index to the first child component. Re-parenting a component would just mean swapping components around. You make one of the parent components a child component by swapping the new child with the last parent, then decrementing the physical index to the first child component. You unparent a child component by swapping the child component with the first child, then incrementing the physical index to the first child component. This way, the parents and children still live in contiguous memory and you still have O(1) parent/unparent operations. Of course, this requires that your components be stored in contiguous memory even when there are deleted components, that they be able to be swapped in memory, and that you never take pointers to components.
  26. Looking for vents/strong opinions on In-game payments

    The only hell I ever had with payments is receiving them. Paying for something is so dam easy over the net you can do it by accident, receiving payments involves a huge amount of paperwork and setup. Isn't this what EnjinCoin is just going to be. I mean Facebook has some of the best 3rd party tools around and anyone that has ever used it will tell you it's as buggy as hell. I mean look at Facebook and Unity. With the Unity 2017 upgrade and Facebook Unity SDK 7.10 you loose a lot of the functions you had before because both updated and made changes. So most users prefer to use a older Unity and a older Facebook SDK and a older JDK and a Older openSSL. How is EnjinCoin going to avoid this? Allow people a way to create accounts for others. I often help out small indie developers and often these people have no idea how to setup adverts and sales in there games. Helping them with it is a huge pain because I often have to wait for them to create the necessary accounts and I can't do it for them. Debugging tools. I can't tell how many times I have setup payments in a game not knowing if it's going to work when published or not. So some way to fake user accounts and payments would be nice.
  27. Cache Coherency and Object Update

    Could you give me an example of partitioning components? I don't think I understand what you mean by it.
  1. Load more activity