• Content count

  • Joined

  • Last visited

Community Reputation

1856 Excellent

About jHaskell

  • Rank

Personal Information

  • Interests
  1. Second question first: With the additional requirement of simulating traffic and lane navigation, you're probably now looking at a navigation mesh, which is really just a specialized form of graph that overlays your landscape geometry. The nav mesh provides additional information about where specifically on the map entities can travel. It can also include, for example, preferred direction of travel for multi-lane roads. Traffic lights and behavior around other vehicles would be handled by the AI separate from the nav mesh. First question: At some point along the line of generating the scene, somebody has to define what is navigable road and what is off limits. If the meshes you are using don't have these defined in some way, then it's simply up to you to do so. Now you may be able to key off things like textures to aid in this task. Any poly that's using a road surface texture is likely part of a road. Defining lanes of travel may possibly be done programmatically if you have consistent lane widths, but even this will likely require some hand massaging to handle special cases. This is part of the purpose of level editors.
  2. How to protect yourself and your game?

    Implementation is by far the most important part of any game. Good implementation of a rehashed idea will be far better than poor implementation of an original idea. And if an idea is never implemented at all, it's guaranteed to make zero money. My point is, don't get so paranoid with protecting your idea that nothing ever comes of it.
  3. Sounds to me like what you really want is a graph that represents your road network and then perform the pathfinding on the graph.
  4. 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.
  5. 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.
  6.     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.
  7.     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.
  8. 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
  9. 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.
  10. 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.
  11. 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! } } }
  12. 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.
  13. 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.
  14. 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.
  15.   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.