Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 18 Jan 2008
Offline Last Active Yesterday, 03:10 PM

#5255496 Preventing "stun lock" issues in third person melee combat

Posted by samoth on 04 October 2015 - 05:23 AM

The problem is that whilst the enemy is bent over in pain from the player attack they are unable to run away or hit back, therefore the player could hit them again and again whilst they are clutching their stomach or otherwise reacting badly to being hit.

The movie industry seems to perfectly agree with that:

I think it's not a problem as long as you don't make it first-hit-is-insta-win. A penalty for being hit as well as being knocked back adds depth, as long as it's not overdone. Stun-like penalties should happen occasionally or when a special skill is used, but not every time.
I'm currently implementing and experimenting with a system where each hit (even one entirely absorbed by armor) gives a small overall penalty which wears off after short time.
The idea behind that is that no matter what kind of hero in heavy armor you are, three peasants attacking you with clubs have a reasonable chance of taking you down (whereas one peasant has little or no chance against a knight with a sword). Zerging is an obvious problem in such a model, so there needs to be a reasonable cap. But otherwise, it seems to work pretty well so far (interesting for sieges where large groups of archers shoot volleys of arrows, too -- while you may be "immune" to single arrows due to your awesome armor, a volley still has a chance of hitting you).
Also, I'm playing with an optional amount of physics-relevant kickback (not just animations) according to weapon and opponent's size/strength. The idea is that with certain particularly heavy weapons, you may be able to effectively push back or swipe an opponent, including the possibility to push him off a bridge or into a chasm. This seems to be somewhat more problematic and less awesome for players, since it has a lot of insta-win potential (but it should still be great for elite or boss opponents, this has been done for many years). More experiments needed.

#5255103 How exactly does localizations of apps translate to more downloads?

Posted by samoth on 02 October 2015 - 04:34 AM

It just depends. Note that "localization" is not just about text (that is, language). It can be a lot, lot, lot more (no, it doesn't stop at how you display numbers and dates, either). But let's stay with localization == translation.


You need to assume that not everybody speaks English, and not everybody wants to speak (or read) English even if they could. For a real classic, try and get something from a French person if all you speak is English. So yeah, if your app is properly localized, people will generally like it more.


On the other hand, bad translations will hurt more than they help, especially on the users that understand English. Microsoft is the classic example. The translations of just about everything in Windows are abysmal, and the computer-generated translations that they have on MSDN and on their help center are totally unintellegible gibberish. I'm considering myself at least moderately qualified, but I regularly find myself shouting "What the fuck is this word supposed to mean?". Just try to figure how a layman will feel. Choose any average service or policy on a German Windows system, and then figure out what it does or what its English name is. Good luck.

#5253966 Currency in post-apoc / zombie world?

Posted by samoth on 25 September 2015 - 04:43 AM

It's a great idea, though I do not think it would realistically (or even semi-realistically work). Knowledge is cool insofar as it has zero weight, and it is immediately useful. But it has the disadvantage of being neither "accumulative" nor "returnable".


You don't like my selfmade coins (mussels, ammo), think the one I gave you is too light? No problem, hand it back, I'll give you another. You think one coin is not enough? Here's another, identical one.


With knowledge, assuming you do not suffer from dementia, there is no way of returning the trade good (short of killing you). Also, once you know something, gaining that knowledge again has no value to you, so you would not trade something physical for an information that you already know. On the other hand, you can always claim that you already knew that information, and it is hard (maybe impossible) to prove you wrong. Even a 5 year old already knows the "I only wanted to check that you know it, too" trick.

And then, in a game, players will inevitably share knowledge out of game, so the currency is worthless.


Unless... unless knowledge is something like "crafting plans" that you can use exactly once (or N times) and then the plan is somehow magically destroyed. That might actually work really well.

#5253863 Currency in post-apoc / zombie world?

Posted by samoth on 24 September 2015 - 01:47 PM

If you have the resources to cast lead shot sized for a muzzle loader and build a new muzzle loading gun, then you have the resources to cast lead bullets and build tools to reload bullets
Well, for zombie killers, there's nothing like brass bullets. laugh.png

#5253621 Currency in post-apoc / zombie world?

Posted by samoth on 23 September 2015 - 04:02 AM

I remember from a sci-fi story onboard a spaceship between crewmembers  opium dealers and tycoons the exchange of 'favors' between individuals kinda nebulous but valuable in that when owed you could ask for anything reasonable the person could supply.

Jin qua's half coins! That was such a cool plot... unluckily it doesn't really scale so well (at least, I couldn't imagine how to do that).

#5253272 Skeletal animation is hella slow

Posted by samoth on 21 September 2015 - 04:41 AM

For the setUniform() issue, I didn't quite get you.
Can you explain further on how I'm supposed to implement "reading an integer from a memory location and using that instead" without an std::map?
What you are currently doing is, you look up N locations as needed by providing strings like "Bone[0]", "Bone[1]", ...."Bone[20]" to the GL. That is legal, but it is horrible. The GL will have to look up the string in a map every time.


First of all, one needs to realize that locations are quasi-constant. Unless you change shaders, they will not change. Therefore it is enough to get the locations once before you start drawing the first skinned model (not every time you set a bone!). You could cache the values somewhere, for example in a map of your own (but this is still an awful idea! read on).


Second, you need to realize that you are not actually interested in individual uniforms with distinct names, but you are only setting elements of one single array. Thus, mapping strings to locations is entirely nonsensical. Rather, you can store them all in a simple array of integers and use the location in bone_locs[4] if you want to set "Bone[4]". No need to map strings to integers, no overhead of using a map or hash map.


Next, you need to realize that the Bones array is, well... an array, and glUniform[1234]fv allows you to set any number of values with one single call. You therefore only ever need one location, the location of the array, and you can set all bones with a single call, using a single location ("Bone", which is constant, and can be cached). So... no need for an array either.


After that, the next step would be to realize that on reasonably new (5 years or so) hardware you can use buffer objects in combination with instancing. Either map/unmap a buffer or use glBufferData and orphan to upload all bones and additional data for all your skinned models with same geometry in one go. Then draw N instances of the mesh in one draw call and use the instance ID so the vertex shader knows where to pull the bone data from. With array textures, it's a breeze to give each guy his own pants and t-shirt etc. -- just pack all that in the same block.


The last thing to realize is that if you target the latest generation of hardware (actually the latest two) you do not even need to map/unmap or orphan buffers all the time. Instead, do a persistent mapping of a buffer worth 3 times the size that you need, and go round and round in a circular manner while drawing from the parts that you don't write to, Use fences to be sure not to stomp over memory that's still being read from. Search for Cass Everitt "Approaching Zero Driver Overhead" if you are interested in this.

#5253025 Skeletal animation is hella slow

Posted by samoth on 19 September 2015 - 07:11 AM

Nope. Do you think I should implement such thing? Here's the current (inefficient, I suppose..) implementation:

GLint ShaderProgram::getUniformLocation(const GLchar *name) const


GLint location = glGetUniformLocation(_id, name);
if(location == -1)
Log::instance() << "uniform doesn't exist: " << name << "\n";

return location;

This is your lookup in "something like a std::map", done by the GL. No matter how the implementation does the c-string to location translation (presumably with a hash map, but you cannot know for sure), this is a heavyweight thing. Although, admittedly, the function is const qualified, so there is a chance that the compiler might eliminate some calls (if you're lucky... which is better than nothing).

Should I implement that?

No. You should not implement such a thing yourself either, you should not at all translate from strings to integers in that way for every bone. No matter what algorithm you choose (linear search, binary tree, hash map, ...) they all suck. Even if someone tells you "but hash maps are O(1)". They may be, but that's irrelevant.


You need to consider what happens when you call such a function. Let's assume that the GL implementation uses a hash map. You pass in pointer to a 10-character string. The GL now iterates over every character of that string, calculating a hash. Then it looks into the bucket of its hash map and finds an entry. Now it must compare the string stored at that entry with your string (iterating over it again) to be sure that it's really a hit, not a collision. Now it retrieves the integer and passes it back to you. Add overhead of a function call to that.


Now, compare that to

a) reading an integer from a memory location and using that instead


b) not fiddling with single uniforms at all, but throwing a whole block of memory (containing a thousand of them) at the driver in one go

#5253023 Why std::copy is faster than std::memcpy ?

Posted by samoth on 19 September 2015 - 07:00 AM

For any relatively trivial pod type, the compiler will probably just replace std::copy, or a simple for loop copy, with an intrinsic memcpy.
That is of course absolutely true, but since there exist trivial POD types and not so trivial non-POD types, and std::copy performs optimally for either one, you should still prefer std::copy over memcpy.


Even if there is no immediately obvious advantage/disadvantage in some particular, isulated case... be consistent.


Better always use the same thing for every type than use memcpy for one half "because it works, too" and std::copy for the other half, only to discover half a year later that you wasted two work days hunting down a bug where move constructors weren't called because you accidentially used memcpy when you shouldn't have.

#5252852 Skeletal animation is hella slow

Posted by samoth on 18 September 2015 - 04:52 AM


Because you do this...

//upload finalMatrix to shader
std::string str = "Bones[";
char buf[4] = {0};
_itoa_s(bone->index(), buf, 10);
str += buf;
str += "]";
_shaderProgram->setUniform(str.c_str(), bone->finalMatrix());

.. for every bone. That's killing you.


Not only are you doing hundreds/thousands (depending on how many models you have and how many bones per model) of memory allocations and reallocations with copies, you also have thousands of individual calls setting one uniform each. (Also, I am very much inclined to believe that the harmless call _shaderProgram->setUniform(...) does a lookup in a std::map or similar... it does, doesn't it?)


What do you think e.g. the two harmless statements str += buf; and str += "]"; result in? They require (at least) two calls to strlen, quite possibly (unless the string implementation over-allocates sufficiently) two reallocations and copies, and creation/destruction of two temporaries.

That's not a lot per se, but it's unnecessary, and it's something that you do many (hundred, thousand) times in a rather time-critical part of your program.


Setting lots of individual uniforms one by one not only means adding a lot of GL/validation overhead, but also means having to do one DMA transfer per uniform, unless the driver is able to batch them together. Transfers have a high latency and thus are very expensive. Luckily, drivers do this kind of optimization and are rather good at it, too. But how can drivers do that?

When it uploads one uniform, the driver looks in the command stream whether there are any other uniform changes already queued (before the next draw command only!). If it finds any, it sends them all together in one transfer. Strictly, that's a violation of the API, but it's one that you don't know about since it produces no externally visible difference.


Now, if you spend some significant time between setting one uniform and another (because you do a lot of needless string manipulations) then chances are that the driver will always only find one uniform in the queue (or very few), and must choose between doing extra transfers, or doing a bulk transfer with all your uniforms at a later time (presumably just before the next draw command), both of which are less favorable.

#5252840 Currency in post-apoc / zombie world?

Posted by samoth on 18 September 2015 - 03:16 AM

But if you buy 50 ammo that must logically cost more than 50 ammo casings (if ammo casings are used as currency for each ammo fired you get "one money" back).
Get rich exponentially! Fire all your ammo, buy more ammo than you had before, fire all your ammo, repeat. Wouldn't that be great! biggrin.png


But I still like the idea, it's actually a nice one. Casings have a lot less weight than full rounds, and while they are useful (make new ammo) they are at the same time not immediately useful.


It may also bring a new angle of resource management into the game. You can keep ammunition for use, or you can disassemble/fire it if you need a big amount of money for buying a larger gun or such. Then you can use it to buy stuff, but now it isn't good for killing zombies any longer. Which makes your journey to the merchant (with only a few operative rounds left in your pocket) more of a challenge.

#5252493 Currency in post-apoc / zombie world?

Posted by samoth on 16 September 2015 - 05:33 AM

In the event of a zombie apocalypse, the survival of paper money seems highly unlikely. The coins that supplement the paper money, though, seems a lot more durable. Coins like pennies, nickels, dimes, quarters are common in North America, and would still be common enough to exist after your average apocalypse, even if there's no continuing production.
Also, coins can be used as anti-tyrant ammo as seen in cinema:


Though in a more realistic setting, I would be concerned losing a hand or two getting a result like this out of coin ammo:






The thing why I don't believe coins would be too successful is that they have no real value. They are of course much better than paper money, which merely has the value of toilet paper (any other value that it has is purely based on a promise made by your government, which already isn't worth a lot now but surely is worth nothing in a zombie apocalypse).


You can eat tuna cans, but you can't eat (well, you sure can swallow, but to no avail) nickels or dimes. The rare metal in them is not really all that rare, so there is not much of an incentive hoarding them for "better times" when society has been rebuilt, 10 or 20 years later. Other than for example gold, they'll be pretty worthless. But even gold quickly loses its value when there is nothing to eat around. In order to carry a noticeable amount of money, you would have to carry dozens of kilograms worth of pennies.


Now, canned tuna, or ammunition, or even clean bottled water is not particularly valuable either -- to us. But they all have a huge situational value when there is nothing to eat, only reeking water, and lots of zombies that want to kill you. Nobody will trade a pair of shoes for 20 kilograms of coins when the winter is nigh. But he might as well risk cold feet for six bottles of water or two dozen rounds of ammo.

#5252203 Currency in post-apoc / zombie world?

Posted by samoth on 14 September 2015 - 09:34 AM

People making their own ammo is not a problem for the currency. If you own a mine dig gold nuggets, your gold is as good as any other gold (apart from, maybe, purity). But the mere fact that you produced it doesn't mean it has no value (or that the value of other gold nuggets is reduced... unless you produce a thousand tons).


Of course someone might make fake ammo out of empty shells and homemade (molten and remolded) bullets. But it would still take one (non-burned) detonator cap per round, and as long as the ammunition fires, it is as good as any other ammo.


It would be trivial to verify whether someone is trying to cheat on you in any substantial trade, too (by giving you e.g. recycled bullets in empty shells). If you can't tell by the weight alone, reach into the bag, take out one round, and fire it. If it doesn't fire, it isn't valid.

A round might -- rarely -- malfunction even if you are not being cheated, so to be sure reach in again. If the next round doesn't fire either, you can be very confident that you are being cheated.


One might be able to smuggle one or two counterfeit rounds into a bag of 100 during a trade, but any substantial scam would have a significant risk of being detected. And you sure don't want to be caught cheating on someone living in a post-apocalypse world who owns both a gun and ammunition. laugh.png


Now, how do you tell how much charge is left in a wristwatch battery? That isn't nearly as easy.

#5252179 How can I save/flush the offline data to disk and start it from there next ti...

Posted by samoth on 14 September 2015 - 08:00 AM


Apart from that, you could of course simply let the computer on over night. Or you could go the same route that every IDE goes.


What happens if you build a project with 20,000 files in Visual Studio (or in Eclipse) and you abort the build after 1,500 files? Next time you tell it "build all", it will not build the 1,500 files for which object files exist that have a timestamp equal to the corresponding source file.


Surely, any task that takes several hours can be broken down into sub-tasks that take only a few minutes and that can be saved to disk as you go. Then just a final pass is needed assembling all the pieces together (just like the link stage). If the output of one step is needed for another, you can also restore to a workable state very quickly from saved intermediate results when starting the build process again the next day.


If a terrain file exists that has the same timestamp like your terrain creation parameters, you need not recreate that patch of terrain. If a "walkable" file that refers to this terrain exists, and it has the same timestamp as the terrain, you need not recalculate its path. etc etc.

#5252177 Currency in post-apoc / zombie world?

Posted by samoth on 14 September 2015 - 07:51 AM

Ammunition would be a pretty good currency.


It's small, countable, every discrete unit ( = coin) has the same value, it's reasonably safe against counterfeiting, and it even serves a practical purpose. Since your life may literally depend on presence of ammunition, everybody will be willing to accept it as currency, too.

Also, it's initially abundant, but becomes rare and rarer with nobody producing more ammunition (post-apocalypse), which counters inflation of the currency.



Turns out Forbes Magazine stole my idea!



And it looks like in New York, Nebraska, and Kentucky they are actually doing it!


#5252045 Convincing AntiVirsus, im not a virus

Posted by samoth on 13 September 2015 - 09:50 AM

Well I'm using Avast with "DeepShield", "Auto Sandbox" and "Community" disabled and I have no problem with it. Ironically, those are exactly the features that I paid money pay for, compared to the free edition (which I find quite good, better than the version that you pay for).


All in all, I wouldn't want to run without Antivirus at all (besides, Windows doesn't really allow you to, anyway) but there are not many good choices. Microsoft's antivirus is abysmal, I have it on my convertible and it regularly fucks up the complete device (running while I'm using the device and using up 100% CPU on one core) making it unresponsive, or draining the battery while the lid is closed and you'd expect that you can still use the device the next morning. There is apparently no way to disable its live scan functionality, either.


Kaspersky turns even a powerful desktop machine entirely unusable, Symantec likewise (and Symantec doesn't even detect some very obvious things like browser hijacks, I've just had this on my wife's laptop which is some typical enterprise-crap setup with ten thousand policies and Symantec installed locally and automated monthly remote registry and system file scans -- she got a notice from IT dept that she was "required to remove spyware" within two days, and Symantec simply reported "no problems").


Malwarebytes is a nice and fast on demand-scanner (which did find that hijack in 4 minutes) but it is pretty useless since it silently ignores iSCSI drives and SMB shares. With the download folder being the primary entry vector and that one living on iSCSI on my system, that's no go.

While I can still understand that it might not work with SMB for some obscure reason (a well-known Adobe program does, too), failing to scan iSCSI devices is a big WTF... they are (or should be) indistinguishable from a real drive.