• Content count

  • Joined

  • Last visited

  • Days Won


Nypyren last won the day on December 17 2017

Nypyren had the most liked content!

Community Reputation

12116 Excellent


About Nypyren

  • Rank

Personal Information

  • Interests
  1. Serialization/Deserialization

    You could definitely control "inline" vs "use reference id" with attributes. If it makes the most sense, you could even have inline be the default. You could automatically switch to reference ids only if a cycle is detected. Things like that.
  2. Serialization/Deserialization

    I don't know if JSON.NET intrinsically can handle object->object references. I have implemented my own reflection-based serializer before and it handles arbitrary objects, including cyclic object references (what I assume you meant by recursion). The way it works is fairly simple: Do two passes. On the first pass, traverse all reference types and make a unique ID each time you run into a new one. Skip any you've already seen. On the second pass, actually serialize data: the number of reference types, followed by the Type of each reference type (so you can support polymorphism), and finally followed by the values for all of the fields in each object. When a field is a reference type, serialize the ID (reserve a number like 0 or -1 for null). When a field is a value type, serialize its entire contents directly. Deserialization then uses FormatterServices.GetUninitializedObject (or equivalent if you're not using .Net) to create all of the reference types first, then when fields are being deserialized, references to other objects can be assigned immediately. This supports polymorphism and arbitrary graphs of objects, which as far as I know is everything that can be represented in any data structure. The underlying data can be binary, JSON, XML, or whatever you want. You can optimize each of the individual pieces of data as much as you feel like: well-known type IDs instead of names, zigzag integer encoding and field IDs/sizes like protobuf has for versioning compatibility, etc.
  3. When did immediate mode take over the web?

    But how would that change how they make money (or are unable to make money, in many cases)? My 2018 prediction is that plain old news sites will begin adding cryptominers to their own pages to increase revenue.
  4. SAT not working properly

    What have you tried? Did you use a debugger to investigate what the values are which lead to the problem? It should be pretty easy to identify the issue if you have a repro case.
  5. Commands are functions, right? If they already perform work then why does anything need to be refactored? Perform the callback within the normal work of the command's function, or wrap the command with a command which calls the original command THEN the callback, if that makes more sense. Imagine this pattern, but adapted to whatever additional complexities you require (IPC, RPC, etc). Action WrapAction(Action command, Action callback) { return () => { command(); callback(); }; } If you're dealing with IPC then you will definitely need some way of handling responses and completion which can deal with the callback. It's not overkill. If you're NOT dealing with IPC then do you really need all those intermediate objects and queues?
  6. Multiperception Game Engine

    That's literally an empty document. Are you trolling or what? Are you a chatbot? Your name would make sense in that case.
  7. C++ Linker problem.

    Templates behave differently than the standard header/cpp file dichotomy. There are lots of references online; you should be able to find comprehensive info that explains why you need to have the implementation #included.
  8. Use callbacks/anonymous methods/lambdas/whatever C++'s modern equivalent is. C# example since it's easier to demonstrate: Popup("What to eat?", new string[]{"Cake", "Cookies!"}, x => { switch (x) { case 0: eatCake(); break; case 1: eatCookiesDammit(); break; } });
  9. Multiperception Game Engine

    You say you have done some of the planning already, but then you posted two meaningless pictures. Try posting things that have meaning first.
  10. Does u,v,w texture mapping exist?

    I stand corrected. It looks like the vector-to-sampler-address step is done for us. Using Hodgman's hints, I found this which seems relevant: https://msdn.microsoft.com/en-us/library/windows/desktop/bb204881(v=vs.85).aspx
  11. Does u,v,w texture mapping exist?

    If you mean volume textures, then you need a W. https://msdn.microsoft.com/en-us/library/windows/desktop/bb206344(v=vs.85).aspx If you mean a cubemap, then no, the cube texture itself is flat and you only need U and V. https://en.wikipedia.org/wiki/Cube_mapping#/media/File:Skybox_example.png
  12. When did immediate mode take over the web?

    My experience with GUIs is that they have a whole lot of state which can be preserved between updates. If you resize your window, the layout needs to change. If you move your mouse over a button, there might be a mouse-over highlight. But if you're not constantly resizing the window, you don't need to redo the layout. If you're not constantly moving the mouse, you don't need to collision check every button or other clickable element. Keeping the UI state stored somewhere between updates so that it can be reused is called "retained mode". Usually there is no choice: Immediate mode is typically built on top of retained mode, and the code to actually render the GUI is inevitably draw calls. You can implement a pure immediate mode render-only GUI by just making draw calls, but if you discard layout and input state you end up having to redo all of your layout computations every time you want to render. The issues I've experienced with immediate mode is that the additional wrapper on top of retained mode is inefficient. If the immediate mode API doesn't include control identifiers, the wrapper layer has to spend time looking these up on each call. Retained mode GUIs have SEPARATE functions which update just what is actually needed at the moment (layout, mouse rect tests, keyboard input goes directly to whatever control has focus, etc). And those functions are only called when a change occurs. Immediate mode GUIs often jam literally everything into one function hierarchy representing the GUI hierarchy, and each individual control's function switches on what is happening (layout, input handling) and adjusts its internal retained mode state. The problem is that these APIs typically traverse the entire call hierarchy even if you don't need to, because they use the call order to determine which retained mode control ID is being referenced by the immediate mode function. If you skip calling a "Button" function in one case your entire GUI stops working. Particularly egregious examples of immediate mode GUI are Unity's OnGUI mehod, GUI and GUILayout classes. Unity basically calls your OnGUI method once per "event" (layout, paint, input handling, that kind of thing). Since much of the code in your OnGUI method may only be relevant to one or two of the event types, if you do anything other than GUI.* calls you're wasting time calculating things that will be discarded. Trying to do anything complicated with them can very quickly wreck performance. The hoops you can optionally jump through to increase performance (by avoiding irrelevant calculations in specific 'event' phases) are like writing a retained-mode interface wrapper on top of that. Unnecessary additional layers of abstraction when ideally you could just control the retained mode GUI under the hood. I haven't personally used any of the web-specific UI frameworks since I avoid web development like the plague, but my understanding is: The HTML elements are a 'retained mode' equivalent. The browser handles their layout and rendering. Why anyone would want to build immediate mode on top of that is beyond me.
  13. When did immediate mode take over the web?

    When have web developers *ever* made good decisions about technology choices? Someone decides they want something easy and minimal now, they make it available for the unwashed masses, and it spirals out of control for years. Wash, rinse, repeat.
  14. Manual syntax trees

    Maybe overload the operators on the Expression type itself (or a type specific to performing AST generation) to make the combined expression. Then the C++ parser itself will construct your AST creation calls properly due to operator precedence rules. Also it might be worth investing time in seeing whether your 'entries' can be immutable. If so, you won't need to clone() them.
  15. Token representation

    Your lexer should be a DFA built out of switch-on-character statements and state variable(s), so your tokens should be "stored" spread out across case statement character constants in certain states. Each token you recognize should have two parts - the token type ID (integer) and possibly the substring that you parsed which resulted in this token type which you then use as a value (string, enum, integer, etc). Your lexer should then pass those tokens to your parsing engine (SLR/LR/whatever) - or the parsing engine can have a loop that calls "GetNextToken". The parsing engine should primarily be dealing with the token type IDs to guide its state(s), but if you have something like a math expression evaluator you can immediately evaluate subexpressions in the middle of the parse instead of generating an AST if you want to. But if you're not writing a high performance parser it really doesn't matter what you do. Since you're even asking this question at all implies you do care, though.