Only create edges in the ne,e,se,s directions as you iterate?
Though really I'd have to agree that one-way edges is probably better for usage, since you generally want to know what outbound edges are available for a specific node. If your edges are of uniform weight you can even just represent them as a vector of destination node pointers within each node.
This appears to be a misuse of inheritance. (refer to https://en.wikipedia.org/wiki/Liskov_substitution_principle) Generally you should be avoiding this type of cast and use dynamic_cast when it's unavoidable (this may be one of those cases). Trying to cast the vector itself is really not a good plan.
Could you explain more about what you're using this for? There may be a better pattern for this.
The first languages I learned were GWBASIC and Pascal. Years later I learned Visual Basic. Then a while later I learned C. Fast forward another couple years and I learned Ruby, then C++, then Lua, then a glance at Lisp... Then a ton of miscellaneous nonsense. At some point during that, learning new languages was pretty much a non-event. It's a lot more important to me what tools I have available and have something that matches up well with what I want to accomplish. These days that usually means Ruby for trivial tasks, C++ for not being a scrub (come at me), and C# for Windows tools or for working in Unity.
Anyway, my point is that I don't use the vast majority of languages that I've learned over the years, and it was over a decade from my starting point before I learned the ones that I use commonly today. However, all that I have learned up until now depends on the principles that I picked up with every language along the way. My advice is to find something that you're comfortable with and can accomplish something with, even if it's not where you want to end up. Get good at something and then expand your comfort zone at a decent pace.
Some people can leap headlong into C++ and succeed. Some people struggle to learn HTML. Software really is a moving target, so it's not really about getting where you want to be as much as it's about getting moving at the right speed and figuring out where you want to go from there.
someone here or on another recent thread was mentioning button presses on the order of 10ms. at 60Hz, you'd poll every 16.6ms. and polling would take less than 1ms most likely. so you could poll at t0=0ms, finish polling at t1= 1ms, press the button at t2 = 1.5ms, release at t3=11.5 ms, and the next poll occurs at t4=16.6ms. and just like that you missed an input entirely.
Not having to learn a made up ecmascript variant is a start. The d-n-d editor is a joke if you plan to make anything more complicated than a dead-simple platformer. GM is terribad for working in teams as well, whereas Unity has settings that make it play nice with version control. Unity has nice tools for automating animation via state machines, good physics and collision that can be fine-tuned as you desire, and works with external editors so you can code in your own environment. The component-styled UI is powerful, and the way it exposes public script members so they can be edited from the UI - even during debugging - is great. The canvas system is more powerful for making and tweaking in-game menus and HUD elements. Unity supports custom shaders without tomfoolery. Both support a kind of object hierarchy, but Unity's is similar to a scene graph, which ends up being much more convenient.
Unity also has never decided to simply disable previous PAID versions of their software, leaving people stranded and unable to continue their work unless they upgrade to the new version and deal with the massive slew of breaking changes involved in that process.
GM can be used as a tool for people that are code-phobic so that they can overcome that phobia, and it's decent for prototyping, but for serious projects I'm just picturing hours upon hours of opportunity cost.
Hey, let's do some science. Set up a simple input system that polls at 60hz alongside an input system that simply logs all input state changes as they occur, then see if you can press and release a key fast enough to miss the polling.
Since you're only checking against AABBs, create an AABB that encloses the start and end positions of the ball for your dt. Every brick intersected by that is a candidate. That's your broad phase.
Calculate the time of impact (use FLOAT_MAX for misses) for each block, then pick the one with the lowest time.
Once you find that you advance the ball to that point in time, apply the effects of the impact, then integrate again with the remaining dt, doing however many impacts are necessary until the dt is consumed.
but is it really common to show gamepad bindings as "Button0"-"ButtonX"?
Yes, apart from XInput it's usually just numbered buttons. It's not hard for the user to figure out during key mapping. If you push a button and it says "Button 1" then chances are you're pushing button 1. There's really no standard to these things, so trying to predict what's what will only piss off the people that you guessed wrong for.
If you're interested in a specific controller then you can just have an option to label the buttons for that controller specifically. For example, some XInput games have an option for "Dualshock 3" that changes the XBox button labels to their SCP Driver equivalents. (Usually it's just a matter of loading a different texture for the button images.)
'Fraid not. One of the reasons DInput was deprecated is that gamepads and other HIDs are not standardized. If you're concerned about this kind of conflict the best thing to do is to offer custom key-binding support to the user. If you're exclusively concerned with gamepads then consider using XInput instead, as it has become something of a de-facto standard for gamepads on Windows.
Please don't. JRE (and plugins) is a huge annoyance for users. You may want to look into JS and the HTML5 canvas instead. There's plenty of material available for that. Just google HTML5 game development and see what comes up.