alh420

Members
  • Content count

    1120
  • Joined

  • Last visited

Community Reputation

5995 Excellent

About alh420

  • Rank
    Contributor

Personal Information

  • Location
    Sweden
  • Interests
    |programmer|
  1. I've never been much for AAA games. They all seem like bland rehashes of well tried game features with trope filled mildly interesting stories to me. But I guess that is what you get when you need to feed a hundred people, and need to make well informed choices and play it safe. Small game studios and one/two man teams foolish enough to try new ideas are where it's at I try to buy a few of those every month, to support them, and sometimes you find a gem worth spending a bunch of hours on.
  2. I'm pretty sure this is nothing new, and any perceived trends is only confirmation bias. A case in point these relationships can work is the current president of France...
  3. I think you should look again at Nypyrens suggestion. The equivalent code to your latest posted, using just pointer casts would be this: inline AnsiString loadstringstream(int & index, char * data) { int len = *(int*)(data + index); AnsiString str{(data + index + sizeof(int)),len}; index += len + sizeof(int); return str; }   And that's it! No unnecessary copies and allocations.
  4. Another note on appearance of science. Kerbal Space Program is a good example of that. It's very sciency-focused, but all the physics are very simplified (yet still detailed) and distances and forces gameified for it to become a fun game. Don't fall in the trap that it has to be scientifically _accurate_ to appeal to the crowd that wants science in their games. I don't agree with the assumption that No Man Sky mainly failed because of too little science, I think it failed because of too little game, and an experience that quickly became repetitive and uninteresting. Maybe more science would have helped to create a game, but if it didn't address the interactivity of the game, I don't think it would help.
  5.   I think you mean, "an easy to implement and easy to understand" approach. I don't think you should ever think your current approach is "the best" one, there almost certainly is something better out there waiting to be discovered! That said, I'm not so sure just random arrangements of predefined content would make something fun. Case in point is no man sky. Because that is all that game is, a random arrangement of predefined content, which our pattern recognizing brains quickly discard as uninteresting after the first few non-lasting wow moments. The game will lack depth. Discoveries not only has to have a unique look, but a unique use, to be really interesting, and here is when it starts becoming really difficult to pull off. How to do that, and still design the game play experience, and make it all balanced? Without it again becoming too formulaic. An approach that seem to somewhat work is to give the player only a limited but well designed tool set, and then hope to trigger the players creativity, and combine it with content sharing between users. (case: Minecraft) I'm glad to hear there is lots of research going on in the field :)
  6. Great looking teaser and presentation You've got my vote! :)
  7. Overwatch, Diablo, DOTA, Skyrim, Call of Duty to name a few realtime games with cooldowns. Also turn based games like XCom might have a cooldown to stop you from using an ability every turn. 
  8. For UI scaling, it should definitely be enough to just rely on DisplayMetrics. Do you really need a "sanity check"? (and how would you do it? A big list of device IDs? All you have is the information you get from DisplayMetrics, afaik there is no other way to know the physical size of the device) I still doubt there are devices which report truly garbage values there. If they did, wouldn't all apps fail on that device, since the application framework relies on DisplayMetrics internally to select resources for and scale the android UI? If a device manufacturer have chosen to report a very different DPI (like 180 instead of 240) it would mean all UI on that device looks smaller then on a "normal" android device, but in that case the user is likely to be accustomed to a smallish UI. It's of course a nice service to your user to provide a UI scaling option, but I don't think it is something that need to be a priority. I totally agree that it would be really nice if the device manufacturers got their shit together and just reported the actual DPI though... In our game we have a multitouch gesture engine with lots of complicated and quick gestures, and if we don't know the physical size of the device we can't give a consistent game play experience across devices. There are other issues that makes that practically impossible though, so we decided relying on DisplayMetrics is "good enough".
  9.   Is it really that bad? We're using those functions and on all phones and tablets I've tried they return reasonable numbers. A lot more reasonable then doing that rough estimation that is clearly very wrong on very many devices. (There are plenty of 7 inch tablet, and phones of many sizes) I've got a few user reports that might indicate they are not perfect, but I've not yet encountered anything in the wild with actual garbage values. I'd love to see some actual statistics on how bad it is. You've succeded in making me paranoid though, I'll definitely keep a closer lookout for it from now...       If you need perfect dimensions at all times you should have some calibration. If you just need a rough estimate of DPI or physical screensize, I'd use the DisplayMetric values. You will get something roughly right most of the time. Until frob comes up with some stats, I will continue to assume they are roughly right (a few % error) in at least 90% of the devices, which should be "good enough" and a lot less work intensive.
  10. Have you enabled mip mapping for the textures?   If that's not enough, maybe you can use a better filter for generating the mip maps?
  11. The movie is called just "GoldenEye" but the game is called "GoldenEye 007".  Also considering how famous the N64 game is (sometimes called "the greatest game of all time"), and the line "These have never existed before. This is the first-ever release of its kind.", I think it was pretty clear it wasn't the movie soundtrack.   Thanks for publishing it L. Spiro!
  12. If you put a breakpoint in your onTouchEvent, you should be able to see in your debugger where it is called from, if you are really curious. You could also download the source code to android, and see exactly how it works.   But it is not vital information, as noted above, you can just rely on it being called by the OS/application framework when needed.
  13. This must be a relatively new thing. I haven't tried this in years, but there was a time where stack space had to be preallocated and going beyond the stack caused a crash. My information may be out of date. A dynamic stack really doesn't make much sense though as that is basically what the heap is or was. Maybe the line is being blurred?       Don't confuse the data segment with the stack. Globals are not allocated on the stack, so stack limitations shouldn't matter for their size. There is likely OS differences in how much memory can be allocated for the data segment too though, but I'd expect the limit to be pretty large for modern OS:es.   I can't say I know, but my gut feeling is that the difference between defining a global variable with the space, or do one call to malloc at startup is minimal though. Possibly malloc is a tiny bit slower to allocate, but as soon as it's allocated, the difference should be nonexistant, memory is just memory after all.   If your memory management is better or worse then what malloc provides would highly depend on how you choose to implement it, and what your expected usage is...   Edit: Ninjad by the King :P
  14. Have you possibly updated your sdk recently, and/or changed the target sdk version you are building for?   I think the problem might be a too new SDK version, that the UI preview can't handle.   You could try lower the targetSdkVersion in your AndroidManifest.xml, possibly also changing the build target in the project properties to one with a lower API level.   Might be a problem if you really need the higher API version, but maybe you can switch down temporarily to get your UI changes in.   Only other option I can think of is doing it "by hand" by editing the xml files directly.
  15.     Yes, you can use 3 points to find the equation for the plane. But you don't have to. You can also use just one point and a normal to derive the equation for the plane, just as you yourself says. (just skip step one and start with a normal and a point). You never _need_ the 3 points. 3 points is a redundant description (9 values) of the plane equation, which need exactly 4 values. It's just a convenient way to use 3 points to _find_ the 4 values you _need_ for the plane equation.   Just as I said, you know this, this is just communication problems (or possibly trolling)