# cmac

Member

63

285 Neutral

• Rank
Member

• Interests
Audio
Design
Education
Programming
QA

## Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

1. ## correct use of enums

Duplicating enums is a bad, difficult to maintain practice. Define them in a common scope/file, or include them from the owner's header file. Also note you can forward declare enums so long as you specify the size of the type (eg. enum Items : int)
2. ## Some Hierarchical Pathfinding Problem I am not sure how to solve..

I'm almost certainly not understanding this correctly (it's worded a little vaguely), but it sounds like B/C/D should each be separated into two nodes for the paths that result from the two separate portals. Not sure what you mean by "the computation is wasted" though, since A* or other pathfinding algorithms will probably process the "portal #2" path first as its nodes are closer to the destination, unless you come up with some sort of heuristic that's not based on euclidean or manhattan distance.
3. ## Camera Collision

Raycast from the player's position to the desired camera position. In the event of a hit, set the camera's position to the hit location. EDIT: misread, if you're talking about a first person controller you can just use a physics library. EDIT again: just saw the Unity tag. Check out its Character Controller: https://docs.unity3d.com/Manual/class-CharacterController.html
4. ## How unwise would it be to still use flash for new game ?

I've never used it, but Doki Doki Literature Club was made in ren'py. Should be ideal for your simulation idea, not sure about the dressup though. It can run in chrome, pretty sure other browsers aren't supported though. Either way, should be a much better bet than going with flash in 2017 2018. https://www.renpy.org/
5. ## 2D Math Problem

The subtraction (red line) translates the picture so that the polygon center has become (0,0).
6. ## 2D Math Problem

Black dot = polygon center, red line = subtraction, green line = rotation, blue line = addition. As you can see, the point ends up at the desired point (90 degrees rotated around center). Overall Alvaro's explanation was much more elegant and concise than mine, so just focus on that.
7. ## 2D Math Problem

Here's a badly drawn MSPaint depiction of what I described:
8. ## 2D Math Problem

xNew = -y yNew = x This rotates a point/vector around the origin by 90 degrees The original code snippet does the same (similar -- they're mirrored, so if using the same coordinate system it would be the reverse direction), except it rotates about a point other than the origin, which in this case is the center of the rectangle. It's effectively the same as rotating around the origin, except it offsets by the center point's position in order to treat the center point as the origin. EDIT: for clarity, the two subtractions move the rectangle points to a position relative to the world origin that is the same as their position relative to their center point. Then they are rotated around the origin, then moved back (the two additions) to be relative to the center point instead of the world origin.
9. ## Looking for help with rotating sprites

Regarding range comparison, Mathf.Approximately checks if the two floats are within an epsilon, which has been ideal for me in most cases: https://docs.unity3d.com/ScriptReference/Mathf.Approximately.html
10. ## When/How often should I be using forward declaration?

Not a C++ expert (yet), but this is what I've gathered from college + research: Include headers in headers as little as possible in general. At best compile times are slowed, at worst you end up with obscure circular includes and namespace pollution. Forward declare in headers when you need to declare a pointer to a type, but do not need access to any of its information within the header file. Include the forward declared class in the .cpp file so you can access its data and operate on it. This is the easiest way to deal with classes including each other, in my experience at least. In your Game/GraphicsDevice example, Game.h will need to include GraphicsDevice because it is declared as a value type, but since GraphicsDevice only declares a pointer to Game, it can be forward declared and then included in the cpp file. I've personally found these two rules really easy to follow and handles the majority of all cases, though cases like template classes can get tricky if their implementations are inline.
11. ## Fonts dissapearing in Unity!Help!

Is your text box too short for the new font size's height?
12. ## use of shared_ptr

The parameters for std::make_shared are the arguments for the template type's constructor, you should not be using new.
13. ## keyPressed(KeyEvent e) { Globals.c = e.getKeyChar(); } doesn't work

From the API (getKeyChar): KEY_PRESSED and KEY_RELEASED events are not intended for reporting of character input. Therefore, the values returned by this method are guaranteed to be meaningful only for KEY_TYPED events. Your KeyTyped method looks like it should work so I'm not sure what's up with that (unless you have caps lock on or something?), but otherwise if you're not printing/logging the actual characters that are inputted and are instead mapping keys to actions, you should use getKeyCode() + keyPressed/keyReleased instead anyway.
14. ## Creating a proper resource manager class

https://stackoverflow.com/questions/102009/when-is-it-best-to-use-the-stack-instead-of-the-heap-and-vice-versa I think that's a reasonable way to think of the heap. Avoid it unless you need to create an object that outlives the current scope, or to circumvent stack overflow with large objects.
15. ## Vectors: Sorting and removing specific items

Not to hijack this thread (hopefully this contributes to the discussion topic), but is that generally always the best option? I'm using a very similar system to OP (vector<Renderable*>), and sorting using insertion sort on every push_back() to enforce draw order. I thought about discarding and re-populating renderables every frame, but I assumed the cost of sorting the entire array every frame was much more expensive than insertion sort on insert + std::erase(std::remove_if()) on removal. I guess I'll just have to run some performance tests and see for myself.