Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 May 2005
Offline Last Active Dec 20 2013 10:05 AM

#5106435 Dividing by zero, on purpose

Posted by on 02 November 2013 - 08:49 AM

The very first game I wrote I didn't know how to handle events well enough to get it to quit in a natural way. So I had the escape key just divide by zero so that it would exit.


My proudest moment.

#5088188 Custom 2D geometry from a list of points.

Posted by on 22 August 2013 - 02:57 PM

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.

#4881971 How many try blocks

Posted by on 08 November 2011 - 09:38 PM

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).

#4847708 [Theory] Unraveling the Unlimited Detail plausibility

Posted by on 11 August 2011 - 08:59 AM

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.

#4845008 [Theory] Unraveling the Unlimited Detail plausibility

Posted by on 05 August 2011 - 07:54 AM

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.

#4844466 UDP in a FPS

Posted by on 04 August 2011 - 07:23 AM

You can use TCP alongside for must-be-reliable data, or you can use a reliable-UDP wrapper library for this data.

From the Gaffer On Games website that you linked to in your post, in his UPD vs. TCP article.

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.

#4821283 When to Declare Variables in Tight C++ Loops

Posted by on 09 June 2011 - 06:16 AM

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.

#4817730 Typing skills practice

Posted by on 30 May 2011 - 08:24 PM

Type Racer lets you channel your competitive edge into improved typing skills from realistic sentences.

#4796417 How easy is Linux for Game Development?

Posted by on 09 April 2011 - 11:46 AM

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.

#4762058 More general C++ questions

Posted by on 20 January 2011 - 04:01 PM

- If a case doesn't have a switch it will fall through to the next case.

I think you mean that if a case doesn't have a break, it will fall through to the next case.

#4760713 gravity with a vector?

Posted by on 18 January 2011 - 08:36 AM

Gravity applies an acceleration. This means that it directly modifies the velocity, not the position. The simplest way to model this is as follows:

position (a vector)
velocity (a vector)
gravity (a vector)

each frame:
    deltaTime = time elapsed since the last frame
    velocity += gravity * deltaTime
    position += velocity * deltaTime

The length and direction of the gravity vector then determines how strong and in which direction gravity is. For Earth, the gravity vector would have magnitude of 9.8 m/s/s or 32 ft/s/s.

#4757532 i want to make a Game.

Posted by on 11 January 2011 - 09:29 PM


The Wiki's starting guide is better (or at least more up-to-date), IMO. Also a great place to start is Google once you know what you're looking for.

#4756470 What Does Everyone Think About The New Site Layout?

Posted by on 09 January 2011 - 10:29 PM

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.

#4541598 2D Collision Detection Ray/Line Segment

Posted by on 14 October 2009 - 12:32 AM

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.

#4313931 What IDE are YOU using?

Posted by on 14 September 2008 - 11:01 PM

Visual Studios for C# and C++, and Vim + command line for Python. Windows XP.