• Advertisement

a light breeze

  • Content count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About a light breeze

  • Rank

Personal Information

  • Interests
  1. The problem with Asimov's laws is that they set an impossibly high standard. Asimov's first law: "A robot may not injure a human being or, through inaction, allow a human being to come to harm.". Now, the global death rate is around 0.8% of the total population of the Earth per year. Given the current global population of 7.6 billion, that's around 60 million deaths per year, or 170 thousand per day. Just about all of these deaths are, in an abstract sense, preventable, which means that our hypothetical AI operating under Asimov's laws will have to prevent these 170 thousand deaths each day before it can even look at the second law. Some of these deaths will be relatively easy to prevent (1.25 million deaths per year from traffic accidents), some are going to be much harder (old age, freak accidents, deliberate murder and suicide), and some are going to be as good as impossible (mass starvation in an ever-increasing population once all other causes of death are eliminated).
  2. what is the appeal of fps games?

    The original Doom was fun because it was primarily a exploration/puzzle game with some combat thrown in. The combat served a purpose in adding an element of danger to the exploration, but it wasn't the point of the game. Hexen was even better in that regard: prettier, more interesting world, deeper puzzles, more rewards for exploration. I've played lots of shooters, but those two are the ones that stand out in a positive way.
  3. A simple set of rules: If it's passed by value, it's [in]. If it's passed by const reference, it's [in]. If it's passed by rvalue reference, it's still [in]. If it's passed by non-const non-rvalue reference, it's either [out] or [inout]. If it's a pointer, you have a choice: either treat it as a reference (so pointers to const are [in], pointers to non-const are [out] or [inout]), or treat it as a value (so all pointers are [in] unless the pointer itself is passed by reference). Both conventions work. The latter is more formally correct, but the former is probably more useful. Pick one and stick with it, and above all stay consistent.
  4. Debate: Proper Time For Microtransactions?

    I also value my time more highly than my money. That's why I uninstall any game that wastes my time with grinding or annoys me with microtransactions. I already have enough non-abusive games in my backlog to last for the rest of my life, so why would I put up with any abuse at all from my games?
  5. A good way to avoid extermination in RTS?

    That does happen sometimes. It doesn't always happen, at least not to the same degree, and if you're writing the game, you can choose to either let it happen or not let it happen. Historically, there were all sorts of factors that influenced if this happened, such as: The loyalty of the army. (Paid mercenaries are likely to join the conqueror, soldiers with personal loyalty primarily to the previous ruler are not. Soldiers with loyalty to the country could go either way.) The perceived legitimacy of the conqueror's rule. Quality of life under the conqueror, as compared to the previous ruler. The realistic chances of driving the conqueror out. Regardless, dealing with local unrest is fundamentally a different proposition than fighting an opposing army. Even if the local rebellion is eventually successful in driving out the invaders, this doesn't do the previous ruler any good if he has been killed in battle or captured and executed. So if the game is about the conflict between rulers A and B, then the game is over with a victory for A if B is captured and killed, even if A will ultimately fail to hold on to the conquered land.
  6. A good way to avoid extermination in RTS?

    Capture the enemy capital and/or the enemy leader, and it doesn't matter how many troops the losing side has left: you have won, they have lost, this is now your land, and that army that used to fight you is now your army.
  7. error compiling on gcc/x64 with address sanitizer

    I used the bare minimum to compile the file, i.e. "g++ -fsanitize=address -c angelscript/source/as_callfunc_x64_gcc.cpp". However, I am getting the same error when I use your command line. Maybe you're testing on a different version of gcc? Like I wrote in my original post, I'm running gcc 5.4.0 on Lubuntu 16.4 LTS (Xenial Xerus).
  8. Is this the right place to report errors in AngelScript? I have found a compile error that affects both v2.31.2 and the latest svn. I am using gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 running on Lubuntu 16.04.3 LTS. The error is in as_callfunc_x64_gcc.cpp. Without address sanitizer, the file compiles correctly, but with address sanitizer, I get the following error message: angelscript/source/as_callfunc_x64_gcc.cpp: In function ‘asQWORD X64_CallFunction(const asQWORD*, int, funcptr_t, asQWORD&, bool)’: angelscript/source/as_callfunc_x64_gcc.cpp:162:82: error: ‘asm’ operand has impossible constraints "%rdi", "%rsi", "%rax", "%rdx", "%rcx", "%r8", "%r9", "%r10", "%r11", "%r15"); ^ The root cause appears to be register exhaustion due to address sanitizer reserving some registers for its own use. Changing the "r" constraints on the input parameters to "g" constraints appears to fix the problem: Index: angelscript/source/as_callfunc_x64_gcc.cpp =================================================================== --- angelscript/source/as_callfunc_x64_gcc.cpp (revision 2407) +++ angelscript/source/as_callfunc_x64_gcc.cpp (working copy) @@ -157,7 +157,7 @@ " movq %%rdx, %4 \n" "endcall: \n" - : : "r" ((asQWORD)cnt), "r" (args), "r" (func), "m" (retQW1), "m" (retQW2), "m" (returnFloat) + : : "g" ((asQWORD)cnt), "g" (args), "g" (func), "m" (retQW1), "m" (retQW2), "m" (returnFloat) : "%xmm0", "%xmm1", "%xmm2", "%xmm3", "%xmm4", "%xmm5", "%xmm6", "%xmm7", "%rdi", "%rsi", "%rax", "%rdx", "%rcx", "%r8", "%r9", "%r10", "%r11", "%r15");
  • Advertisement