1. Post #601
    Gold Member
    Karmah's Avatar
    December 2007
    6,836 Posts
    I'm working on a library right now that uses OpenGL.
    The library is based off of an older project of mine which worked fine

    However, when I use it in a project, nSight crashes when starting graphics debugging, and RenderDoc crashes when trying to view a captured frame.

    What do I do? My application works fine, and I don't see any opengl error or glfw errors being reported while my application is running.
    I would like to be able to use these programs because of how handy they are when actual problems arise.

  2. Post #602
    Gold Member
    Tamschi's Avatar
    December 2009
    8,616 Posts
    Check out my eyesore of a webzone for some examples

    I wouldn't say that I'm a beginner but I'm not an expert either
    Sorry for not answering earlier.

    As long as you have solid JavaScript knowledge, you can probable just go with the official guides and the API reference (listed on the same page).
    The rest is more general web security knowledge and knowing what kind of information you may legally process and which you may not, depending on where you live and which areas you target.

    I'd recommend a programming book, but I haven't read any about Node.js specifically so far.

    Edited:

    I'm working on a library right now that uses OpenGL.
    The library is based off of an older project of mine which worked fine

    However, when I use it in a project, nSight crashes when starting graphics debugging, and RenderDoc crashes when trying to view a captured frame.

    What do I do? My application works fine, and I don't see any opengl error or glfw errors being reported while my application is running.
    I would like to be able to use these programs because of how handy they are when actual problems arise.
    Does your library use deprecated OpenGL?
    I know some of the old immediate mode stuff crashes when you try to debug it.

  3. Post #603
    Gold Member
    Karmah's Avatar
    December 2007
    6,836 Posts
    Sorry for not answering earlier.

    As long as you have solid JavaScript knowledge, you can probable just go with the official guides and the API reference (listed on the same page).
    The rest is more general web security knowledge and knowing what kind of information you may legally process and which you may not, depending on where you live and which areas you target.

    I'd recommend a programming book, but I haven't read any about Node.js specifically so far.

    Edited:



    Does your library use deprecated OpenGL?
    I know some of the old immediate mode stuff crashes when you try to debug it.
    Shouldn't, because the library is based off of my last standalone project, which I could debug fine with nSight. (I'm working on a library that I can use in additional projects, like the one that isn't debugging right)
    I use just 4.5.

  4. Post #604
    Gold Member
    paindoc's Avatar
    March 2009
    9,263 Posts
    Shouldn't, because the library is based off of my last standalone project, which I could debug fine with nSight. (I'm working on a library that I can use in additional projects, like the one that isn't debugging right)
    I use just 4.5.
    This happens for me in Vulkan when I have API errors that aren't caught by my application, and I enable API validation. Try disabling API validation if it's enabled in RenderDoc, and/or run demoscenes for your library (or make them if you don't ahve them), starting at the most basic triangle and working up.

    OpenGL is weird with error logging, though. It feels a lot easier to have them and not see them, vs the validation layers in Vulkan, so I'm not sure how much help I can give.

  5. Post #605
    Gold Member
    Karmah's Avatar
    December 2007
    6,836 Posts
    This happens for me in Vulkan when I have API errors that aren't caught by my application, and I enable API validation. Try disabling API validation if it's enabled in RenderDoc, and/or run demoscenes for your library (or make them if you don't ahve them), starting at the most basic triangle and working up.

    OpenGL is weird with error logging, though. It feels a lot easier to have them and not see them, vs the validation layers in Vulkan, so I'm not sure how much help I can give.
    Sounds good.
    I noticed this problem really early on as well, so I think I'll try to recreate the error with as minimal content as possible, and also try to overhaul my error reporting to catch even more things if possible.

  6. Post #606
    Gold Member
    Karmah's Avatar
    December 2007
    6,836 Posts
    I'm taking a second stab (a year-ish later?) at entity-component systems, but I'm having a little bit of difficulty wrapping my head around how they are actually used, specifically.

    The whole idea is to strip an entity down into self-contained modules, right? So entities effectively becomes 'blind' to their own components after creation, correct?
    Strip a renderable prop down into a Prop and a mesh component, where the prop entity just stores component pointers?

    Since the prop no longer knows anything about its components, I'm assuming that the components themselves have to register themselves into specific systems that deal with their specific class type, correct? Like a mesh component registering itself into a geometry manager that can iterate over all of it's meshes for rendering, rather than iterating over all the props.
    Or is there a different ideal / better approach?

    Also I assume I wouldn't be defeating the purpose of this system by having an entity create its own components, and potentially sharing the reference of a given component to another component, such as a transformation component being used in a collision or mesh component for the same entity.

  7. Post #607

    May 2016
    176 Posts
    I'm taking a second stab (a year-ish later?) at entity-component systems, but I'm having a little bit of difficulty wrapping my head around how they are actually used, specifically.

    The whole idea is to strip an entity down into self-contained modules, right? So entities effectively becomes 'blind' to their own components after creation, correct?
    Strip a renderable prop down into a Prop and a mesh component, where the prop entity just stores component pointers?

    Since the prop no longer knows anything about its components, I'm assuming that the components themselves have to register themselves into specific systems that deal with their specific class type, correct? Like a mesh component registering itself into a geometry manager that can iterate over all of it's meshes for rendering, rather than iterating over all the props.
    Or is there a different ideal / better approach?

    Also I assume I wouldn't be defeating the purpose of this system by having an entity create its own components, and potentially sharing the reference of a given component to another component, such as a transformation component being used in a collision or mesh component for the same entity.
    The problem I see with ECS how they're being presented in online resources and open implementations is that they get hung up on semantics and try to cram the whole application into this generic framework of how things should work together and this leads to such confusion as you're expressing here.

    Example, components registering themselves with some sort of manager.
    What does iterating over a list of references to a certain type of component buy you that you don't get by just iterating over all components or all entities and extract what you need while doing it?
    Nothing really. It *feels* a bit more tidy maybe.
    The point of "systems iterating over their components" essentially was that systems only iterate over the *data* they need - and that does NOT mean they only iterate over a list of pointers to the data they need, it means visiting the ACTUAL DATA. As in they touch the memory they need to touch in a way that benefits them. In the case of rendering for example, you usually want high performance in that system so you want good data access patterns. Iterating over some sort of collection of references to rendering components that live somewhere else is not a good data access pattern. Iterating over an array of rendering components would be. Essentially, systems should manage the data they need to access in order to function themselves. That means you duplicate data. Which is okay. It means you need to synchronize some data between systems, and that can get complex.

    What I'm trying to say is, ECS has become too much of a formalized idiom and people are often missing the actual point behind splitting your entity data up. It's to give subsystems the flexibility they need in order to function optimally, to decouple them, NOT to couple them in just another way.

    My recommendation is, look at the different subsystem your application has - I'm assuming this is still that flashy engine of yours - and think about what data they need to function, and then make them work using only that data. Then put your game object model on top of that, instead of interleaving everything. One thing that VERY OFTEN happens when people try to implement an ECS is that they think that the same rules have to apply to gameplay components and low level engine system components - which is completely insane, gameplay systems have completely different requirements than say a renderer. Yes, commercial engines present you with a unified interface for both, but if you look at how they work they do NOT assume the same architecture. In most cases, their generic component systems are put on top of very specific systems and just act as interfaces into them but they do NOT serve as primary data model for those systems.

    For example, a transform "component" merely serves as an interface for the gameplay programmer to be able to control an entities transformation, but rendering, physics, animation, do NOT access the data stored inside that component. They maintain their own transformation information and there's a well defined point of synchronization between them, ideally. Think of systems as consumers and producers of data instead of them acting on some shared data set. The game object system is just a high level representation of your game world that is easy to manipulate and access, but your low level systems have their own representations that is optimal for them to work with.
    Reply With Quote Edit / Delete Reply Windows 10 Chrome Show Events Useful Useful x 1Agree Agree x 1 (list)

  8. Post #608
    Gold Member
    Karmah's Avatar
    December 2007
    6,836 Posts
    Okay, so I was on the right track for having components self-register into appropriate systems then.

    Are you saying that components should never be aware of any other component and should never share data?
    How might transformational data be synchronized amongst an entity and its components?
    Continuing the example with a prop, it might have a transform component, a rendering component (which needs to read transform data), and a collision component (which needs to read and write transform data)

    The solution isn't obvious to me at first glance.

  9. Post #609

    May 2016
    176 Posts
    Okay, so I was on the right track for having components self-register into appropriate systems then.

    Are you saying that components should never be aware of any other component and should never share data?
    How might transformational data be synchronized amongst an entity and its components?
    Continuing the example with a prop, it might have a transform component, a rendering component (which needs to read transform data), and a collision component (which needs to read and write transform data)

    The solution isn't obvious to me at first glance.
    You copy the data at some defined point during your frame. For example, rendering always kicks off at the end of a frame, so at some point before starting off the rendering, you copy object transforms over into your rendering world.
    And re: self-registering, they should be created *by* the system ideally. So that system can manage how components are allocated and laid out in memory internally.

    My point is you have a *separate* view of the world that contains exactly the data required to perform the task at hand for each domain.
    Reply With Quote Edit / Delete Reply Windows 10 Chrome Show Events Useful Useful x 1 (list)

  10. Post #610
    Gold Member
    Karmah's Avatar
    December 2007
    6,836 Posts
    Okay I think I understand now.

    I've switched over to the factory pattern of generating both entities and components, storing them in maps with char*, vector pairs. I now access entities and components from their respective systems by name type and uint index. With this, whenever I need an entire list of a particular type of component, I can just query the Component Factory by name.

    Based on what I've read online today, I may need to build a sort of messaging system between entities and their components, allowing for some further complex interactions, like "Hey, I updated()" like events.

  11. Post #611
    Gold Member
    paindoc's Avatar
    March 2009
    9,263 Posts
    Okay I think I understand now.

    I've switched over to the factory pattern of generating both entities and components, storing them in maps with char*, vector pairs. I now access entities and components from their respective systems by name type and uint index. With this, whenever I need an entire list of a particular type of component, I can just query the Component Factory by name.

    Based on what I've read online today, I may need to build a sort of messaging system between entities and their components, allowing for some further complex interactions, like "Hey, I updated()" like events.
    Delegates? I've kinda wanted to tackle that sort of system for a while now, partially because C++14/17 lets you make a log of that stuff much more compile-time based (thus, more static and safe and less messy).

    I recently mentioned this in WAYWO, but are there any good places to ask for code reviews on larger codebases? the code review stackexchange doesn't feel quite apt for larger stuff.

  12. Post #612
    Gold Member
    Tamschi's Avatar
    December 2009
    8,616 Posts
    Delegates? I've kinda wanted to tackle that sort of system for a while now, partially because C++14/17 lets you make a log of that stuff much more compile-time based (thus, more static and safe and less messy).
    Does C++ have somewhat formalised events?
    A high-level pattern would be pretty good here, if possible, since there's significant boilerplate for multicast (with plain single-cast delegates, at least) and the interface is error-prone if too public.

    I recently mentioned this in WAYWO, but are there any good places to ask for code reviews on larger codebases? the code review stackexchange doesn't feel quite apt for larger stuff.
    Unless it's an open-source project with a topic people will be interested in (in which case I'd probably put it on GitHub and request reviews via commit comments), you probably have to pay money for this.

  13. Post #613
    Gold Member
    paindoc's Avatar
    March 2009
    9,263 Posts
    Does C++ have somewhat formalised events?
    A high-level pattern would be pretty good here, if possible, since there's significant boilerplate for multicast (with plain single-cast delegates, at least) and the interface is error-prone if too public.



    Unless it's an open-source project with a topic people will be interested in (in which case I'd probably put it on GitHub and request reviews via commit comments), you probably have to pay money for this.
    It's just my renderer: https://github.com/fuchstraumer/VulpesRender/

    I've gotten some incidental criticism: I post about it a lot in /r/Vulkan since people are always asking "how should I abstract X?" or "can I do Y in Vulkan?" and I feel confident enough in my abstraction and codebase to share it as an example. I think it's in a good state, and I'm really quite happy with the project: it's got demoscenes, it works on all three major platforms, and the code is mainly self-documenting with supplementary doxygen comments (and a doxygen file included in the repo).

    I just want to push it to be better, since I need to take this and start making it more usable as a generalized rendering system for people who aren't graphics programmers.

    Edited:

    in which case, I'll probably not modify that code and instead use VulpesRender as a package of Vulkan-wrapping primitive objects. I think that's where it works best, instead of trying to make it a do-everything rendering system.
    Reply With Quote Edit / Delete Reply Windows 10 Chrome Show Events Programming King Programming King x 1 (list)