One algorithm that should work in this situation to break the shape into convex hulls that can be drawn more easily:
1. Pick a point, add it a list A which shall be our first convex sape
2. Cycle through points going clockwise
3. Check each such point to make sure that it is further clockwise than the previously checked one
4. If it's not clockwise not, then ignore add it to a list of points left over
5. If it is clockwise, add it to the convex hull
5a. If it is clockwise and the previous one was not, run this algorithm recursively, making a new convex shape by iterating over the list of left-over points (clear left-over point list when done)
6. Continue until all points have been checked
I hope that's clear. Basically, anything that isn't still going clockwise is a new convex (recusively, since this might also need to be broken up), but anything that is, is. This isn't guaranteed to have the best possible break-up of convex shapes and I'm sure you could come up with weird shapes that it would break up inefficiently. But I suspect it will work for the vast majority of things. It is guaranteed that for any non-self-intersecting shape it will fill exactly its interior and none of its exterior. Don't expect it to work sanely with self-intersections. Also, your choice of initial point will affect how it makes the convex shapes.
Note that a convex shape can be drawn by picking any point and drawing a 'triangle fan' out from that point, like the (out-dated?) OpenGL function for that.
I'm not sure how much this data means. Everything depends upon language and programming style. In Python, for example, use of try blocks is encouraged where as in C++ it must be done with much more caution.
The project I am working on probably uses about 5 try blocks per thousand lines of Python code. I can't think of any uses in our C++ code, but there might be some and some of our code is written more in the style of C than C++ (I am less familiar with that part of our project).
Guys, have you heard that Notch developed some technology where he can store an entire, unlimited-sized world in a single short string?!
There's a lot that can be done in cool and interesting ways and is worth exploring, but everything has a downside. What's really really disappointing about this guy is that he ignores the downsides, even when he's supposedly addressing concerns other people raised.
Off the top of my head, here's things that made me go "does this guy know what he's talking about?" -Misinterpretting Notch's post as saying "This is super easy". The actual words Notch used were "It’s a very pretty and very impressive piece of technology." -All that talk about just "pushing a button" and now the bitmap is resized for different platforms and that that's all they need to do (I really don't know what he was trying to say here). Clearly the hardest part about developing games for multiple platforms is resizing the graphics. -His tesselation explanation. Was it just me or was he just describing parallax mapping? TBH, I don't know much about this -"Level of distance" and the demo that 'proved' they weren't using it (though I do believe them that they're not, just that demo is totally non-conclusive) -Him counting or estimating the number of polygons in games these days. -Acting as if the 500K triangle mesh he scanned from the elephant is unfeasible for games and as if normal mapping it to reduce polygons would be particularly difficult -Comparing triangles to "atoms" isn't fair in the first place. Just as fair would be to compare "atoms" to texels since atoms seem to have to do the work of texels as well as triangles. -And the big one: claiming it's unlimited but then not saying what he means by that just insisting that things are "infinite" or something.
Also, they should try to find an interviewer who sounds more knowledgeable and unbiased next time.
I think you're missing some of the point of this argument. I don't think many people are disbelieving that the videos they show are real. The problem is with the description of the video. Vague claims of "unlimited detail" are made without any explanation of what they really mean by that. The technique they use is well-known and existing, yet they act as if this is never-before-seen. The advantages and downsides of this technique are also well known, yet they only ever bring up the advantages. They fail to address any of the concerns that people have (sorry but "don't worry angry forum-posters we have animation in the works" doesn't count for much). These are the real concerns, not whether they have been totally faking everything.
Notch's point about memory is to show that sure, they can have this level of detail, but if they do then they need to repeat things. A lot. This has obvious downsides for games - just look how repetitive their world looks.
Wait? Why can’t I use both UDP and TCP?For realtime game data like player input and state, only the most recent data is relevant, but for other types of data, say perhaps a sequence of commands sent from one machine to another, reliability and ordering can be very important.
The temptation then is to use UDP for player input and state, and TCP for the reliable ordered data. If you’re sharp you’ve probably even worked out that you may have multiple “streams” of reliable ordered commands, maybe one about level loading, and another about AI. Perhaps you think to yourself, “Well, I’d really not want AI commands to stall out if a packet is lost containing a level loading command – they are completely unrelated!”. You are right, so you may be tempted to create one TCP socket for each stream of commands.
On the surface, this seems like a great idea. The problem is that since TCP and UDP are both built on top of IP, the underlying packets sent by each protocol will affect each other. Exactly how they affect each other is quite complicated and relates to how TCP performs reliability and flow control, but fundamentally you should remember that TCP tends to induce packet loss in UDP packets. For more information, read this paper on the subject.
But I totally agree that the current setup sounds broken: it sounds trivial for a hacker to send false packets and teleport, etc. wherever they want. Reading all the Gaffer's networking articles is probably your best bet.
I prefer the second method because it makes it obvious that each iteration has a new instance and that the instance is not supposed to be an output of the loop to be used afterwards.
If you're concerned about performance, try both and measure which is faster. If you can't measure the difference, then it doesn't which is 'faster.' My guess is that a good compiler optimizes both to be the same.
How do you explain the humble indie bundle and those numbers then?
They aren't Linux, they are portable?
You've missed the point. The Humble Indie Bundle (using a pay-what-you-want system) got a considerably higher average payment from Linux users than Windows or Mac users. The averages were: $6.68 for Windows, $9.27 for Mac, and $13.78 for Linux.
On the actual subject, I agree with other comments that when using higher level libraries the differences in developing for platforms are fairly small.
I liked how the old forums displayed username, image, etc. between posts. If we can't go back to that, I'd like to see the size of the current username area reduced considerably. The small-sized avatars were perfect, these bigger ones feel awkward and break up the content too much. Post count is ridiculous and shouldn't be shown next to every post, same with group and join date. The three graphical buttons in this area are needlessly eye-catching. I'd prefer to see either removed or perhaps have them as smaller text links to the right of the poster's name. The start new topic button doesn't belong at the end of the thread since newbies might click it by accident (though fast reply almost eliminates that problem). And it seems like it's just too easy to format a post now - even in this thread you see unnecessary red or bold or small text or fixed-width.
But overall I like the change. The new look is nice (I particularly like the main logo and its surroundings) without being gaudy. It just needs some tightening to make it truly great.
Edit: Did the default text size change or something? These last couple posts are smaller.
There's a ton of information on the web about this, but it shouldn't be too hard so I'll just give you some help.
For now, pretend it's (non-segment) line-versus-line. Each line can bey expressed as y = m1 * x + b1 and y = m2 * x + b2. The lines intersect if there is an x such that their y values are equal, that is: m1 * x + b1 = m2 * x + b2
Solve for x.
Then, determine whether that point is in the ray and the segment. Some x value will give the starting point of the ray. Any x value "before" that one won't be on the ray, so it wouldn't be a collision. The line segment yields two x values, one for each point. Only x's between those two values will yield an intersection.
Now, all you have to do is handle the case where one or both is vertical, where m would have to be infinite.
If that's not enough, just google for ray-line segment intersection, and you'll probably find a better solution than this one anyways.