@Chiho another important point about Direct X... that's only for windows or xbox. If you'd worked on nothing but iOS, Android, OSX, Linux, PS4, Nintendo... you would never have even used a wrapper around Direct X. :)
@dot_Sp0T We create our "main window" using MFC, but when we create our "second window", we don't us MFC, we use that 3rd party rendering lib (OpenSceneGraph); we let it handle windows events for both windows and this is going to cause us grief when we'll look into multi threading as it handles events for the CView that it controls, but not for the CWnd and the CWinApp that we control. This is a discrepancy in who's doing what.
We supply the CView handle of the main window to OSG and tell it "you handle the events". At some point, we'll send it the handle, but tell it "you don't handle the events anymore".
Yeah proprietary pipelines are annoying, but they definitely allow for easier innovation in new tech, as it's hard to push new things through standardization for a common spec
I'm sure companies owning products like Unity or Unreal like that, as, although it's a greater effort on their end to support the OS, it forces the end-user developers to use their engines if they want to go multi-platform without too much hassle.
hey quick jab to ecs before i make a totally wrong comment on the main: generally a system is supposed to act on the components without being prodded from the outside right? e.g. a system would have an update(delta) method and in that decides what to do based on data.
e.g. a system to move an entity would act on the Position and Speed components. (or maybe there's a Position and targetPosition)
What I've heard from people who have worked in OpenGL is that it's become messy over the years and needs a redesign. Not saying they're right, it's just what I heard from them. :)
@dot_Sp0T Yes. That's in the "classic" case. But there is no ECS police that'll fine a dev if they don't do it the "pure" way. Generally, if "a solution works for them", that's generally good enough.
I've worked with object hierarchies for some time until it did not fit my needs anymore, then changed to something else, then changed to something else as needs, knowledge about the system and knowledge about stuff in general evolved.
If someone wants to have two systems interacting together, sure, fine. The issues I see with "hybrid" approaches are generally related to the "who does what" question. "Oh, well for this we have the componentXYZ that has a function that does it, but for that feature, the code that act upon the component is in the SystemABC". It can create confusion and issues with code consistency down the road.
(I'm knee-deep in code inconsistency at the moment.)
@dot_Sp0T That might depend on the system in question. For instance, a "Network Replication" system might need to handle update packets received from a server, which you could consider "prodding from the outside"
I did have a few students lagging behind on picking groups for their first assignment, so I just paired them up randomly and told them to come with proposed swaps if they don't like the groups I picked. ;)
i kinda got stuck in a situation where i had a nearby location in lore, so i put a low-poly model of it up in the background, and my primary tester (and friend) said "hey, it would be neat to go there"
and the whole "oh gosh i wasn't planning to go this far" kinda hit me :}
i told them that i still have to restrain myself from going into a year binge of modeling out and making every sweet idea i got for the hopefully-to-be series of games
