jHaskell

Members
  • Content count

    244
  • Joined

  • Last visited

Community Reputation

1856 Excellent

About jHaskell

  • Rank
    Member
  1. Weird fears?

    I don't think I have any real fears, rather just things I dislike or find annoying. I also can't recall having an actual nightmare, though I have had dreams that have woken me up from surprise. One in particular was actually quite funny... I had one dream where I was working on my car, hunched over the front working in the engine bay. I turned around to grab another wrench from my toolbox, and there's a Skyrim bear in all it's digital glory and he takes a swipe at me just as I turn around and notice him. That one didn't just wake me up, but had me bolt upright in my bed blurting out, "What the f#@%!" in exactly the same fashion as a few days earlier when I was playing Skyrim, sneaking through the woods, and turned around to find a bear right behind me, attacking me just as I see him. So that's about the closest thing I've had to a nightmare, that I can remember anyways. I rarely remember my dreams though.
  2. At what time do you sleep and wake up?

    I've gotten pretty regular in the last few years. Go to bed at 11:00, get up at 6:00. I used to be fairly irregular, both in times I'd got to bed and get up, and how much sleep on any given night I'd get.
  3.     That post is really on the subject of kernel mode vs user mode synchronization, which is related to, but separate from the subject of context switching.  Either method will block and potentially switch out a thread.  On a side note, if you only ever create no more threads than there are cores to run on, you'll never have a thread switched out, but you will still have to deal with synchronization.   Regarding synchronization, if the overhead of the synchronization is genuinely an issue, then the solution isn't in the method of synchronization but the design of the system.  Specifically, you've broken your tasks down too small.  Take the trivial task of summing a million floats as an example.  In the extreme, if we break the problem down to passing and summing pairs of floats to the worker threads, then synchronization becomes a major overhead no matter what solution you use.  Never mind that you've completely destroyed your cache hit rate in the process (another topic entirely).  If instead we block out large chunks of floats for each worker to process (ie send blocks of 250k floats to each of 4 workers), then synchronization becomes insignificant no matter what solution you use.
  4.     A context switch between processes is expensive (mainly because each process has it's own memory space that must be saved/restored).  A context switch between threads within the same process should be fairly efficient.   If your producer and consumer threads are all in the same process, then you should be perfectly fine using condition variables and letting the OS handle it.
  5. The Official Car Modding and Racing Thread

      Just suck it up and do it once.  Chances are pretty good you'll find a way to do it quite regularly.   I autocross 25-30 times a year.  I'm only about 40 minutes away, but I run dedicated AutoX tires so I have to swap wheels/tires at the site after arriving and before leaving.    My car:       No power mods yet.  Just suspension:  Shocks, springs, swaybars, control arms, camber plates, torsen diff, 18x105 wheels and 315/30 tires   Power mods are planned for next spring.  Essentially this: http://www.brenspeed.com/cj519.html only I'll piecemeal it together myself as I'm going to do something different for exhaust and local dyno tuning.   And a video from an Autocross run last year: https://www.youtube.com/watch?v=HBzyLYb5gA8
  6. Zombie types (enemies)

    I would make the SWAT zombie a possible modifier to all zombie types.  Conceptually speaking, a SWAT officer that's been killed and becomes a zombie could be any type of zombie; walker, runner, boomer, spitter, alarmer; now with better armor.   Also, I would view walkers as just more damaged versions of runners (in particular more damage to the legs, which is the cause of their reduced mobility).  So, as runners take damage, they become walkers.   On the alarmer, it should be possible for the player to detect the alarmer before the alarmer detects the player, and instead of just spawning addtional zombies, the alarmer just pulls in existing zombies from a large radius.  This would give players the option of trying to clear out all nearby zombies before engaging the alarmer, or just charging in guns blazing.   As for distinct looks, a cheap and easy option is just distinct colorations.  Give spitters a green or yellow tint, alarmers a red tint, etc.
  7. Best bet for a first interview is almost always to dress professionally.  No offense intended, but if you're trying to rely on a shirt to make them remember you, you've already lost.  You need to be the one showing enthusiasm and excitement, not your attire.  That's what will make you memorable.  You should have ample opportunities during the interview to work in discussion of their latest game, and even the local food joint.  The important thing is to have something worthwhile to say.  Being a Dev position, the talking points better be largely technically oriented.
  8. Checking collisions of all entities in a 2D RPG

      I would prefer the following slight variation, which avoids the following problems:   Testing an object against itself. Testing object 0 against object 1, and later testing object 1 against object 0. std::vector<sf::Sprite> objects; size_t num_sprites = objects.size(); for (int i = 0; i < num_sprites; i++){ for (int j = i + 1; j < num_sprites; j++){ if (objects[i].getGlobalBounds().intersects(objects[j].getGlobalBounds())){ // collision! } } }
  9. Try just outputting the endpoints for your octagon and see if they look appropriate.   given the low 'resolution' and unsquare nature of the ASCII view,  drawing short lines is going to look wonky with the aliasing that occurs when the lines are quantized.     Rotate that diamond about 20º and see how nice the lines look.  A 45º angle aliases quite nicely.   The lower the resolution, the more a circle will look like an n-sided polygon.  A 1 pixel diameter circle is going to render as a square.  A 16 pixel diameter circle is going to look similar to an octagon.   On the flip side, even at high resolutions, a sufficiently high enough n-sided polygon is going to look like a circle.  A 100-sided polygon would take a fairly high resolution to render clearly as a polygon and not appear to be a circle.
  10. In a non smoking times

    Could say the very same back to you.   Yes I have researched both side of stories, did you? And what specifically we need to investigate about the official story when everybody knew it. Otherwise it would not be official.     While I've always been a big fan of not making unfounded claims...  In all honesty, I don't need to do a shred of research to KNOW that regularly inhaling smoke is bad for your health.
  11. In all the IDEs I've used with auto-complete, hitting Tab will also go to the end of whatever auto-complete section you are currently in.
  12.   One word:  Security.   Not to say that the computer today is definitively more secure, but the large bulk of the time any Enterprise product takes to load is establishing secure connections with servers.  If you look at actual disk and cpu activity, you'll find only about 10-15% overall load on both.
  13.   I have a very different definition of Destroyed.
  14. Are you getting the oculus rift?

    I'm personally more interested in FOVE VR, primarily for foveated rendering; the eye tracking supposedly allows them to only render the portion of the view you're actively looking at in full res, which should significantly reduce hardware requirements for VR systems.
  15. Your development workflow

      We call that Agile.