Advertisement Jump to content
  • Advertisement

uavfun

Member
  • Content Count

    246
  • Joined

  • Last visited

Community Reputation

744 Good

About uavfun

  • Rank
    Member
  1. Option 1: Use quaternions. They don't suffer the same issues as yaw/pitch/roll-based rotations. D3DX has all you need. Option 2: Store a 3x3 rotation matrix. The first row/column (I forget which way around it is in D3D) will be your X/side vector, the next your Y/up vector, then finally your Z/forwards. Then you can compound rotations to your heart's content simply by matrix multiplication (and possibly periodically reorthonormalizing the matrix so that all the directions stay parallel.) The easiest way to construct that kind of matrix from a direction and (approximate) up vector is to take their cross product for the left/right vector, then take the cross product of that vector and the direction to get an up vector that's exactly perpendicular to the direction, then stick them all in a matrix (this is how LookAt-style camera functions generally work)
  2. uavfun

    Transvestite or Variables [Poll]

    It is possible to add DB query syntax directly to the language, see for example LINQ. It's not a simple matter of cut-and-pasting SQL into everything, though. A badly designed database interface in a system that uses databases heavily can bring the whole thing down. Also - DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU!
  3. uavfun

    whilst statement

    No, on the grounds that Perl would then have to have untilst
  4. and he has no pants on Remember - Drunk code and posts are responsible for billions of dollars in lost revenue every year.
  5. uavfun

    Untitled

    CNN Breaking News - Mushu (NYSE: MUSH) drops 10% in aftermarket trading amid drunken party scandal - CEO comments: "I hope i runk'd remember this in the mornign" (AP)
  6. uavfun

    Tic-Tac-Toe

    Source + installer (needs .NET Framework 2.0). AI is moderately stupid, it will go for an obvious win or block yours but that's about it. Summary of victory checking, since someone was asking about it: For each player 'p': bool won = false; for (int i = 0; i < 3; i++) { // Column if (gameBoard == p && gameBoard[i + 3] == p && gameBoard[i + 6] == p) won = true; // Row if (gameBoard[i * 3] == p && gameBoard[i * 3 + 1] == p && gameBoard[i * 3 + 2] == p) won = true; } // Diagonal if (gameBoard[4] == p) // center { if (gameBoard[0] == p && gameBoard[8] == p) won = true; if (gameBoard[2] == p && gameBoard[6] == p) won = true; } Nothing fancy, just brute force. Yeah, I was bored. Yeah, I'll get back to the asteroids thing.
  7. uavfun

    Bouncing Boob Tutorial (nsfw, animated nudity)

    The good-looking textured light-sourced bouncy fun smart and stretchy page has an article on making a squishy 3d gel (quick summary - make a bunch of weighted nodes/balls (hee!) in a grid, and attach them together with springs). I see enormous potential, especially combined with the string and cloth stuff.
  8. Download C# source and ClickOnce installer Needs .NET Framework 2.0 Tidied up a bit, looks a little nicer now. I've set it to open near the mouse, without going off-screen or covering the taskbar, and close on deactivation, so it's more like an overgrown balloon tip than a complete window. Note: The noon/midnight lines should be fairly accurate (I would guess within an hour, as long as I haven't mucked up anything), but only compared to the actual position of the sun, NOT local time. Daylight savings/summer time, for example, throws things off substantially - the sun doesn't suddenly rise and set an hour earlier/later. The 6am/6pm lines (between the light and dark regions), however, are not intended to match the actual sunrise/sunset, they're just a rough guess (and again, they won't match local time). The day/night regions should actually be shaped something like this. Yes, more Asteroids stuff is coming, as soon as I get a chance to work on it.
  9. Nope, MDX will be part 4 - it needs to be a proper Asteroids first, which means no fancy graphics. Then, Part 5 will be SUPER SECRET PLAN
  10. Download C# source code and ClickOnce installer - requires .NET Framework 2.0 Designing the Asteroid class Most of the movement code is the same for the player and the asteroids. The asteroids' movement is somewhat simpler since they have some initial random velocity, but never accelerate, but this can be achieved simply by leaving the Acceleration property as 0. It is therefore useful to keep the movement code in a common base class, GameObject and have the Player class simply set the acceleration and turning rate to the desired values, then ask the base to calculate the updated position. We can also extend the GameField object that was used before to track the size of the playing area to also track the current list of objects. This lets all of the update and drawing operations be performed at once with a single call. Sprites Consider a theoretical simple game with the following types of object:Player, with animated sprite with different images for walking, shooting, etc. Monster, with animated sprite Obstacle, with either a single sprite image or an animated sprite Various powerups, with a single sprite image each Although there are four types of object, there are only two types of sprite - static, with a single image, and animated, with many images - and some objects may even have the same behaviour, but different types of sprite. Also, there is no need to duplicate the sprite objects - only one copy of each bitmap needs to be stored, rather than one per object. It is much easier to create a seperate inheritance hierarchy with a Sprite base class, and give the game objects an instance of Sprite, than to build the drawing into every object type. Maintenance also benefits, since drawing code for each type of sprite is kept in one place, and when a new type of sprite is added, every type of object gains use of it. This is even more important in a complex 3D game, where there may be a mesh representing the object's appearance, a simpler mesh used for collision detection, as well as geometry (possibly not a mesh) and associated information such as mass of each component used for the physics engine. Merging all of them into one class would create a useless clutter. The Asteroids2 sample provides a Sprite base class, as well as two implementations. One simply draws a polygon; the other contains a collection of individual Sprites. The Player class uses this to seperate the ship and its exhaust, so it can disable the exhaust sprite when the engine is not in use (rather than keeping two seperate sprites, one for engine on and one for engine off). Asteroid generation The algorithm used here is fairly simple: generate a certain number of points spaced evenly around a circle. Then, set the radius at each point to a random value. for (int i = 0; i < numberOfVertices; i++) { float angle = 2 * pi * (float)i / numberOfVertices; float radius = random between minRadius, maxRadius; Vertex = Vector2(radius * cos(angle), radius * sin(angle)); } The number of vertices and the exact overall size of the asteroid can both be varied as well. Velocity and, if the asteroid needs to spin, the rate of rotation should also be random. angle could also be varied randomly, possibly by applying a random offset. Alternatively, a set of points with random positions (in either cartesian or polar coordinates) could be generated, and the resulting array sorted by polar angle. Next time: Bullets, collision detection and scoring.
  11. Download C# source code and ClickOnce installer - requires .NET Framework 2.0 The first step is to get the ship moving around the screen properly. For now, there are no asteroids, and the ship is just a line. Although the example game is written in C#, the math and logic will be very similar in most languages, and are far more significant than the details of the implementation. The code excerpts below use the Vector2 class included in the source. It provides basic operations such as addition and multiplication through overloaded operators. You can just store the components seperately if you want, and perform individual operations on them (ax = bx + cx; ay = by + cy; rather than a = b + c;). However, this tends to complicate the code unnecessarily, and is much harder to manage, since you have twice as many variables (worse, in 3D, three times as many). Movement in AsteroidsThe game uses a basic Newtonian physics system. The ship has a position, velocity, and orientation. The direction the ship faces is independent of the direction it's moving in. If you turn the ship, it will continue to move in the same direction. If you release the thrust key, the ship should continue to move for some time (inertia) Turning the ship We need to be able to handle the user pressing two keys at once. This often happens by accident in fast gameplay - the right key is pressed enough to contact before the left is fully released, or the user starts to switch from left to right, presses the left key, then changes their mind before releasing the right key. Therefore, we need to keep track of whether each button is pressed, rather than simply set the direction whenever a key is pressed or released. Some input systems simply specify whether every key is up or down. In this case, the ship can be allowed to stop turning if both keys are pressed at once. It is usually preferrable to continue in the direction of whichever key was pressed last, however. This is fairly easy to do with event-based input (such as Windows Forms or messages in MFC or plain Win32). bool keyLeft, keyRight; // When the left arrow is pressed: keyLeft = true; TurnDirection = left; // When the left arrow is released: keyLeft = false; if (keyRight) TurnDirection = right; else TurnDirection = 0; // On update: float deltaTime; // time in seconds since last update if (TurnDirection == left) direction -= deltaTime * turning speed in radians per second; else ... For games that allow both forwards and backwards movement, the up/down keys can be handled similarly. Updating the position Vector2 position, velocity, acceleration; ... calculate acceleration based on what direction the ship is pointing, and whether the user is pressing the thrust button ... position = position + velocity * deltaTime + acceleration * (deltaTime * deltaTime / 2); velocity = velocity + acceleration * deltaTime; This comes from basic physics. The last position term tends to make the results more stable if the framerate varies. It still won't be perfect - the ship's movement will be slightly different at different update rates - but it's about as good as it gets without resorting to far more complicated integrators. Finding the acceleration Given an angle in radians representing the ship's direction (direction), we can find the acceleration from thrust with: acceleration.x = amount * cos(direction); acceleration.y = amount * sin(direction); // Drag acceleration = acceleration - (small number) * velocity; The trigonometric functions always use radians. Also, with more complex physics involving rotating objects, you will frequently find you'll have to either use radians or add factors of pi to formulas. Of course, it's a lot easier to understand an angle shown in degrees, but the user never gets to see the angle here, except indirectly through the appearance of the ship. Even if you must display the angle to the user or allow them to enter it, it's easier to store things as radians internally and convert on entry/display than to perform the conversion over and over in every calculation. We also subtract a small amount of the current velocity to provide drag. This will gradually bring the ship to a stop if all of the controls are released. Under thrust, it will also cause the ship's direction of motion to tend to turn towards the direction it's facing - the sideways component of the velocity is soaked up by drag, while the forward component is continuously replaced by the engines. Restricting the top speed Some possible approaches:Allow the ship to continue to accelerate indefinitely. This can cause problems with collision detection - if the ship moves fast enough, it may pass through objects. At high speeds it may also be difficult for the player to see how the ship is moving so they can slow it down. Set the multiplier used for drag to the desired top speed divided by the acceleration. This is the easiest, but gives the programmer less control over the ship's movement. Set a speed cutoff. The sample does this by reducing acceleration whenever the next velocity update (velocity = velocity + acceleration * deltaTime) would cause the ship to reach an excessive speed. Wrapping around the edge of the screen If the X or Y coordinate exceeds the size of the playing area, we can use the modulus (%) operator - new X = old X % width. This won't work for negative values, however. We could just add width to the coordinate until it's greater than 0, but this is somewhat inefficient, and could cause the app to freeze if the position is somehow corrupted. new X = width - (-old X % width) produces the proper result without looping. Notice, however, that this can cause the ship to disappear from one side while the back is still partially visible. Moving asteroids will also have this problem. This could be solved by moving the edge of the game field slightly off-screen, or by drawing up to 4 copies of the ship when it's near the border. In the latter case, collisions with asteroids near the border must also be handled carefully. In the former, the border will probably need to change size dynamically based on the object's size. Next time: Proper graphics and asteroids.
  12. Download C# source and ClickOnce installer Needs .NET Framework 2.0 Double-click to open the fancy world clock/map: The yellow line is noon, blue is midnight. The bright/dark areas are split at 6:00 AM and 6:00 PM. It's not 100% accurate given the peculiarities of time zones (and of course the sunset/sunrise times are rough guesses at best, especially near the poles) but if one of the lines is over England, then that's the GMT/UTC time. (Although, again, not necessarily the local time due to daylight savings) I was planning on putting in a list with local time for cities around the world, but it turns out to be rather annoying. You can get the local time zone information, and Windows does have a list of time zones somewhere (check the Date and Time control panel), but you can't easily get at that list. (And, of course, you would still need a list of cities with lat/lon and time zone)
  13. Download C# source and ClickOnce installer Needs .NET Framework 2.0 Double-click to open the fancy world clock/map: The yellow line is noon, blue is midnight. The bright/dark areas are split at 6:00 AM and 6:00 PM. It's not 100% accurate given the peculiarities of time zones (and of course the sunset/sunrise times are rough guesses at best, especially near the poles) but if one of the lines is over England, then that's the GMT/UTC time. (Although, again, not necessarily the local time due to daylight savings)
  14. uavfun

    Taskbar calendar icon

    The clock thing normally only shows the date if the taskbar is 2 rows high or more (precious, precious code space...) - otherwise, it's only in the tooltip. Which, like all tooltips, is flaky. For Asteroids... I'm thinking either MDX or just straight GDI+. Really, the point is to show the mechanics, not fill it up with pages of explosion-drawing code.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!