fishtastic

If your engine doesn't need to render objects outside the viewport, then you don't need to generate those objects until you actually need to render it.

If the design of your roguelike limits player vision so they only see their surroundings, then instead of generating the 512 x 512 map in one go, you can improve the performance/memory usage by generating only the blocks around the player.

This would save a lot of initial loading time and could support maps much larger than 512 x 512.

Every few seconds the screen freezes for a fraction of a second. This happened to me on both Chrome and Firefox.

I suspect the lag is caused by garbage collection taking too much time. I ran into a similar issue on Firefox when working on my canvas game. Not sure how this can be fixed. (fwiw, I am running on this on an i5 Macbook Air)

Screamed at JavaScript for failing at big integer multiplications. Got it after rewriting in python. Here is my poorly written explanation.

--------- MAJOR SPOILERS ---------

Let's multiply unique prime numbers and count their factors.

  n         Number of factors
  2         2 (1, 2)
  2x3       4 (1, 2, 3, 6)
  2x3x5     8
  2x3x5x7   16

i.e. 2x3x5x...x500500th prime will have 2^500500 factors

The 500500th prime is 7376507 (thanks to wolframalpha), and it's not very big.

We can easily get the product of the above with 500500 multiplications while modding result of each step by 500500507 to get an answer.

Except that the product of first 500500 primes isn't the smallest number containing 2^500500 factors. This can be made smaller.

Observe that

  (2x3x5x...x500499th prime)x2

  2^500499 + 2^500498 factors.

Continuing with this, we see that

  (2x3x5x...x500499th prime) x (2 x 2)

  2^500499 + 2^500498 + 2^500498 = 2^500500 factors.

If we want continue doubling factor count by multiplying 2s, we will need to multiply by 2x2x2x2 next, and 2^8 after, which becomes inefficient quickly. Instead, why not use 3? Multiplying (2x3x5x...x500499th prime) by (3 x 3) also doubles the factor count.

So at this point, we think about doubling factor count and the ways we can do it. Out options are

<1>. Multiply by a prime that we have never used so far

<2>. Multiply by an existing prime k + 1 times, where k is the number of times it has been used

We repeat this 500500 times, using rule <1> and <2> (which can be generalized to one rule) and the result is the final answer.

  factor count          n
  2                     2
  4                     2*3 <1>
  8                     2*3*2*2 <2>
  16                    2*3*2*2*5 <1>
  32                    2*3*2*2*5*7 <1>
  64                    2*3*2*2*5*7*3*3 <2>
  128                   2*3*2*2*5*7*3*3*11 <1>

This game is quite different from Conway's Game of Life because it's not deterministic. During a turn, cells will rely on Math.random to find whether to move or divide; the direction that the cell move into is also randomized.

Can you simplify the form and save user's time by figuring out the type credit card from the number? (IIRC, all Visa cards start with 4)

I recently found that AngularJS has supports for promises. I replaced some of the callback code to use promises and it's a lot more readable.

Callbacks:

    Backend.CallA(param, function() { 
      aDone = true;
      if (aDone && bDone) { doC(); }
    });
    Backend.CallB(param, function() { 
      bDone = true;
      if (aDone && bDone) { doC(); }
    });

    var promiseA = Backend.CallA(param);
    var promiseB = Backend.CallB(param);
    $q.all([promiseA, promiseB]).then(doC);

I've started reading this after I found it on an old HN post. I went through everything except chapter 12, 13, and the latest one that just came out. I would highly recommend learning OpenGL from this tutorial if you have no prior experience with opengl or computer graphics. This tutorial dives right into shaders in the very first chapter, where as the other sources (the red book, opengl superbible) still tries to teach your fixed pipeline rendering for several chapters before introducing glsl.

As someone who's been watching professional Korean SC competition for almost 10 years, the strategy described by your brother can be found from many high class players. Unlike Warcraft3 or other RTS, units in SC have very low health. Even if you have 5% more units, you can easily lose a fight within seconds from bad unit control, bad fighting position or just bad luck. It's never a good idea to attack just because you have 5% more units. Good players will continue play cautiously to make sure the opponent never gets a chance to take those 5% back. In the end, they win by the accumulated bits of advantages from various battles or economy advantages. You don't always need an glorious "final battle" to win the game, as long as your advantage is big enough (say 50%), you opponent will know that he lost and leave the game.

This is probably why SC has become very popular and still remains very popular. There are constant conflicts throughout the game trying to increase or take back the small advantages.

Sold out online at future shop, was going to get one. I could try door crashing the store tomorrow and see if they still have the one for demo...

http://www.futureshop.ca/en-CA/product/hewlett-packard-hp-16...

As someone who also like random candies, I wonder if it is cheaper to just order candies straight from Japan (Amazon Japan or maybe Ebay?) I am stealing idea here, but that would be another way to get more candies.

How was the rendering done? I guess that some facial features are made from blended texture mapped polygons (the hair and the neck). The face and the eyes might require some other tricks.

What amazes me is how efficient the rendering is. It uses flash for rendering and is running fast on my netbook. If this could be taken into 3D games, it would make the game characters much more realistic/scary.

This explains many mysteries from Starcraft 1: bad replay file after patching, small replay file sizes, low network traffic usage from multiplayer even on big maps.

The hash value sent between player also hints the mechanism for drop hack. My guess it that the hacker would pretend to be the victim and send a bad hash values to every other players. The hash check would fail and the victim would just end up disconnected from the game. Haven't heard of such hack in SC2, wonder how they fixed it.

I wonder if the accuracy of this report was just base on some lucky guesses.

Right now, there are probably hundreds of such predictions about the future. Look at them again in 20 years, most of them will probably be incorrect. Yet there is always this one report (like this one from 1982) that will be shockingly accurate. The problem is that by then, it won't provide any useful information. We need is to know this is correct in 1982, not 2011.

That was a great use of a huge magnifying glass. If he can somehow mass produce this, it would bring the cost of making planting pots to almost nothing.

One problem with this design is that the light would deflect off the center particle and melt other sand around it. In the video, pretty much everything in 1cm radius gets melted. Unless he can somehow make it print in greater details, I can't think of a better use for this other than producing planting pots.

I found a way to do this in XP. (Vista or 7 should be similar)

1. Open "Documents and Settings\<user name>\Application Data\Mozilla\Firefox\Profiles\<profile>\extensions

2. Find the folder for the unsupported extension, there should be a file called install.rdf inside.

3. Open the file and change the <em:maxVersion> to 5.*.

Might have missed something, but that did the trick for me.

Hard to believe there will be an event like this in Waterloo, I am really interested. Hope you are okay with some newbie uw co-op students.

So the "popular I love anal" was just an accidental discovery having no relation with the actual encryption method.