What Do You Need Help With? V8

[reevezy67]

This is basically where I am at for networking atm.

//Lidgren network loop with some network events built in. I hate switches.
[URL]https://gist.github.com/EReeves/7a4cf1825e9b9b7a1f9509e25c29ee81[/URL]

//The events/serialization and deserialization
[URL]https://gist.github.com/EReeves/2f1a7bafc977edf8bed74b49ca778157[/URL]

[Zyx]

Snip: This is the help thread, not what you are working on!

[inaba]

[QUOTE=Adelle Zhu;52876747]Does the firewall allow the port? Should be 3306 by default.[/QUOTE]

It does. Just had the totally crazy idea of connecting through the port through my browser, and this is what I got

[QUOTE]b���
5.5.5-10.1.23-MariaDB-9+deb9u1�Ë���@Te~k|PX�ÿ÷-�? ����������JJs%\#5"G!k{�mysql_native_password�!��
ÿ„#08S01Got packets out of order[/QUOTE]

Which just means that I'm not connecting with a database program

[Karmah]

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 [I]actual[/I] problems arise.

[Tamschi]

[QUOTE=-Xemit-;52867333]Check out my [url=https://mussorg.neocities.org/]eyesore of a webzone[/url] for some examples

I wouldn't say that I'm a beginner but I'm not an expert either[/QUOTE]

Sorry for not answering earlier.

As long as you have solid JavaScript knowledge, you can probable just go with the [URL="https://nodejs.org/en/docs/guides/"]official guides[/URL] 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.

[editline]13th November 2017[/editline]

[QUOTE=Karmah;52884140]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 [I]actual[/I] problems arise.[/QUOTE]

Does your library use deprecated OpenGL?
I know some of the old immediate mode stuff crashes when you try to debug it.

[Karmah]

[QUOTE=Tamschi;52885512]Sorry for not answering earlier.

As long as you have solid JavaScript knowledge, you can probable just go with the [URL="https://nodejs.org/en/docs/guides/"]official guides[/URL] 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.

[editline]13th November 2017[/editline]

Does your library use deprecated OpenGL?
I know some of the old immediate mode stuff crashes when you try to debug it.[/QUOTE]

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.

[paindoc]

[QUOTE=Karmah;52886164]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.[/QUOTE]

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.

[Karmah]

[QUOTE=paindoc;52886329]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.[/QUOTE]

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.

[Karmah]

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.

[jwki]

[QUOTE=Karmah;52892057]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.[/QUOTE]

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.

[Karmah]

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.

[jwki]

[QUOTE=Karmah;52893021]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.[/QUOTE]

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.

[Karmah]

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.

[paindoc]

[QUOTE=Karmah;52894348]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.[/QUOTE]

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.

[Tamschi]

[QUOTE=paindoc;52894398]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).[/QUOTE]

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.

[QUOTE]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.[/QUOTE]

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.

[paindoc]

[QUOTE=Tamschi;52896922]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.[/QUOTE]

It's just my renderer: [url]https://github.com/fuchstraumer/VulpesRender/[/url]

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.

[editline]18th November 2017[/editline]

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.

[paindoc]

So on the topic of the same project my last post was on, I know you can't export STL classes through a DLL interface - but can my classes use them as private variables for internal functions? I use std::unique_ptr in a lot of places to handle object lifetimes, and have a few usages of std::set and std::vector. None of these need to be exposed through the DLL interface though, and I'm working on cleaning up what I can but removing all my unique_ptr's and vectors just adds several negatives (which isn't compensated by compiling as a dynamic library)

Additionally, what's a good way to handle exporting static functions? Can I just declare a non-static method that calls the static method? Where do I declare and define this?

Dynamic libraries are weird, but as I move to using this thing in more projects I can see how it's useful. Being able to just distribute updated DLLs for my applications at work is much easier than re-compiling everything, even with jenkins/auto-builds

[jwki]

[QUOTE=paindoc;52908868]So on the topic of the same project my last post was on, I know you can't export STL classes through a DLL interface - but can my classes use them as private variables for internal functions? I use std::unique_ptr in a lot of places to handle object lifetimes, and have a few usages of std::set and std::vector. None of these need to be exposed through the DLL interface though, and I'm working on cleaning up what I can but removing all my unique_ptr's and vectors just adds several negatives (which isn't compensated by compiling as a dynamic library)

Additionally, what's a good way to handle exporting static functions? Can I just declare a non-static method that calls the static method? Where do I declare and define this?

Dynamic libraries are weird, but as I move to using this thing in more projects I can see how it's useful. Being able to just distribute updated DLLs for my applications at work is much easier than re-compiling everything, even with jenkins/auto-builds[/QUOTE]

I'm beginning to understand why you get the impression that DLLs are weird if you're actually exporting classes. Usually what I see being done and do myself is just exporting free functions in a C block that use pure virtual interfaces instead of concrete classes.

[Karmah]

I'm trying to shorten my code relating to message payloads for entity-component messaging but have hit a snag that I don't know how to change.

I have a template class of Message Payload, with 2 attributes: ID and a template payload.
For convenience sake, I want to typedef specific payload types with the payload class type and a unique ID for said class type.

The verbose solution I had before was just explicitly subclassing each payload type giving it its own correct ID and payload.

I'm doing something like this:

// Trying to avoid explicitly writing many subclasses and use templates instead
template<typename T>
class DLL_EXPORT Message_payload : public Message
{
public:
    ~Message_payload();
    Message_payload(const T &data) : m_typeID(-1), m_payload(data) {};
    T GetPayload() const { return m_payload; };
    void SetPayload(const T &data) { m_payload = data; };

protected:
    // unsigned int m_typeID; Message class has this attribute
    T m_payload;
};

// Can I make these have its own specific m_typeID without writing out the whole class again?
typedef Message_payload<string> Payload_Set_Model_Dir; 
typedef Message_payload<Transform> Payload_Set_Transformation; 

[paindoc]

[QUOTE=JWki;52909188]I'm beginning to understand why you get the impression that DLLs are weird if you're actually exporting classes. Usually what I see being done and do myself is just exporting free functions in a C block that use pure virtual interfaces instead of concrete classes.[/QUOTE]

Yeah, and that is the most ideal usage. But in this case it's really the only way to do it (that, or I could possibly go header only but also oh god i don't want to do that).

Afaik, I should be safe, to a point. Exposing classes is fine so long as you don't change the ABI based on updates or compiler versions: only letting primitive types be really accessed by a "client" should make that happen. it's the passing of a std::string made with the vs140 toolset into an executable using the v141 toolset that can be a problem, and so on

changing the ABI can also be done by re-ordering class member variables and (ofc) adding new variables so you have to be really careful about that. Which is probably one of the few reasons thing's like the pimpl idiom still exist

[Karmah]

I solved my problem.

I wanted to be able to create data payloads that had their own unique ID I could retrieve from them so that when trying to read the message somewhere I could just grab its ID and typecast the object it to the correct class.
This is a trivial problem, but I didn't want to have to keep writing a fuckload of classes with their own descriptive names, especially considering many would share the same type of payload. For instance, I may want a message class to deliver "loadModelDirectory" and also another "setName", but both would have identical payload types.

The solution was 2 parts:
1) use templates
2) use 'typeid'

The base class of Message has a virtual function that returns 0, but the templated variety expands on it and returns the typeid of its own template class.

Then, to shorten the code, I use typedefs to write an explicit variety of the message payload that I can use. I don't need to do it this way, but it makes reading message-creation code more clear.

In case anyone googles this and lands here, here's my solution in code form:

class Message {
public: 
    // ... generic message functions ... //
    virtual const char GetTypeID() { return 0; }
}

template<typename T>
class Message_Payload : public Message {
public:
    ~Message_Payload();
    Message_Payload(const T &data) : m_payload(data) {};
    
    virtual const char* GetTypeID() { return typeid(T).name(); }

    T GetPayload() const { return m_payload; }

private:
    T m_payload;
}

Creating convenient names for specific types of payloads in a single line

typedef Message_Payload<vec3> Payload_SetColor;
typedef Message_Payload<Transform> Payload_SetTransform;
typedef Message_Payload<string> Payload_SetDirectory;

And decoding a particular message

void SpecificComponent::RecieveMessage(Message *message)
{
    const char* typeID = message->GetTypeID();
    if (typeID == typeid(vec3) { // without loss of generality, can do this to any data type
        // Cast entire message to the templated type
        Payload_SetColor *msg = (Payload_SetColor*)message;
        const vec3 &payload = msg->GetPayload();
        // Do stuff with payload
    }

[Antianan]

So you basically reinvented type erasure. Also it's probably better to return references to the actual payload.

[Karmah]

Hadn't heard of the term before, but now I have something else I can read and study up on

[reevezy67]

I need some help with my math. Or maybe it's something else.

Anyway, I',m trying to rotate some colliders, here's what is happening, the first picture is the original.
[IMG]https://i.imgur.com/dUwWzPF.png[/IMG]
After rotating.
[IMG]https://i.imgur.com/q2lSAT3.png[/IMG]

How it's implemented.

var obj = collidersGroup.objects[i];

//Rotate around local origin.
var rads = MathHelper.ToRadians(0);var points = new Vector2[4];
points[0] = new Vector2(0, 0).rotate(rads);//Topleft
points[1] = new Vector2(obj.width,0).rotate(rads);//Topright
points[2] = new Vector2(obj.width, obj.height).rotate(rads);//BotRight
 points[3] = new Vector2(0, obj.height).rotate(rads);//BotLeft
                

//Add world coordinates back;
for (var o = 0; o < 4; o++)
{
      points[o] += new Vector2(obj.x, obj.y);
}    

//From here the vertices are put in to a collider object and rendered etc.

                
//AND THE ROTATE METHOD
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static Vector2 rotate(this Vector2 vec, float radians)
{
         var ca = Math.Cos(radians);
         var sa = Math.Sin(radians);
         return  new Vector2(
               x: (float)(ca * vec.X - sa * vec.Y),
               y: (float)(sa * vec.X + ca * vec.Y)
          );
}

[editline]21st November 2017[/editline]

Fixed it, I should just rotate around the origin as is.

[editline]21st November 2017[/editline]

The whole way I looked at this is wrong though, tiled doesn't convert the coordinates to isometric ones like I thought. Anyone got any good resources on isometric projection?

[editline]21st November 2017[/editline]

[IMG]https://i.imgur.com/bgxtSPj.png[/IMG]
c:

Actually super easy. Depending on the angles you are using.

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static Vector2 ToIsometric(this Vector2 vec)
{
    return new Vector2()
    {
     X = vec.X - vec.Y,
     Y = (vec.X + vec.Y) / 2
    };
}

[scarface]

Anyone have experience with PrestaShop 1.7 ? It has an really poor documentation. I want to change the related products/accessories ( by creating an module ), but I can't find the right hook for it.

[Karmah]

[QUOTE=antianan;52910248]So you basically reinvented type erasure. Also it's probably better to return references to the actual payload.[/QUOTE]

So if I understand this correctly, the general pattern is this:
1) Base class (Foo) which is pretty much nothing
2) Subclass base (Foo::Bar), using a template, store template data as member
3) Need to store any data type? Create new Bar of desired type, store pointer to super class Foo

The way I went about it [I]this time[/I] was like this:

class Message
{
private:
    // Base class, store references to these
    struct PayloadConcept {
        virtual ~PayloadConcept() {}
        virtual const char* GetTypeID() { return 0; }
    };

    // Derived class of specific type. Create these, store pointer to base class
    template <typename T>
    struct PayloadModel : PayloadConcept {
        PayloadModel(const T& t) { m_data = t; }
        virtual ~PayloadModel() {}
        virtual const char* GetTypeID() {
            return typeid(T).name();
        }
        const T &GetData() const { return m_data; }
    private:
        T m_data;
    };

    PayloadConcept *m_payload;


public:
    // Create the message
    template< typename T > 
    Message(const T& obj) : m_payload(new PayloadModel<T>(obj)) {}
    ~Message() { delete m_payload; }

    // Casts the payload into the supplied type, and returns a reference to the stored data
    template< typename T> 
    const T &GetPayload() const { return dynamic_cast<PayloadModel<T>*>(m_payload)->GetData(); };    

    // A quick way of determining if the payload type matches the supplied type (instead of casting and checking for null)
    template< typename T> 
    bool IsOfType() const { return strcmp(m_payload->GetTypeID(), typeid(T).name()) == 0; }
};

Which affords me the ability to work with them like this:

entity->ReceiveMessage(Message(Transform(...)));
entity->ReceiveMessage(Message(0.578f));

and

if (message->IsOfType<std::string>()) {
    const auto &payload = message->GetPayload<string>();
    Asset_Manager::load_asset(m_model, payload);
}

[WTF Nuke]

Type erasure is more like: some type that stores different types within itself. std::function and std::any are some such types. Polymorphic allocators are another. Delegates are an example of type erasure. [URL="https://github.com/ldionne/dyno"]dyno[/URL] is a library for type-erase polymorphism. The general idea is some non specific type that holds the details of specific types.

[editline]21st November 2017[/editline]

Some quick notes about your impl:

Make PayloadConcept's (really an interface not a concept) methods pure virtual.
Use typeindex instead of typeid and just compare those instead of typeid.name (no guarantees on uniqueness).
Use a unique_ptr instead of for m_payload.

Also I haven't really been following but really consider if you need a dynamic solution (RTTI) when a static solution would do fine (knowing the event type at compile time).

[gmoddertr]

I am working on a steam bot with c# at the moment. I want to be able to use the console constantly to send messages. I did that using something like;

            Start:
            string command = Console.ReadLine();

            if (command == "clear")
            {
                Console.Clear();
                goto Start; // to handle new commands
            } 

This code works, the problem is "Start": loop and "Console.ReadLine" interrupts other callbacks and voids. For example, I cant receive messages from people while I am in "Console.ReadLine" sequence. Whenever I exit the loop with "not" using the goto thing, it works, other voids/callbacks re-start working. How would you go with that?

[Antianan]

[QUOTE=WTF Nuke;52913368]
Use a unique_ptr instead of for m_payload.[/QUOTE]

I've tried implementing stuff like that myself some time ago by the way, but using shared pointer instead, which allows to either make an actual copy of the class' underlying data or just a light copy by simply incrementing the pointer's counter. Not sure if it's a good idea though.

[paindoc]

[QUOTE=antianan;52914087]I've tried implementing stuff like that myself some time ago by the way, but using shared pointer instead, which allows to either make an actual copy of the class' underlying data or just a light copy by simply incrementing the pointer's counter. Not sure if it's a good idea though.[/QUOTE]

You get some overhead with that, though I'm not entirely sure how much. I'd weigh it based on how often you find yourself doing light copies.

unique_ptr, however, has practically no overhead to speak of. There's honestly very little reason to have raw pointers as class or struct members, anymore