Jump to content
  • Advertisement

DekuTree64

Member
  • Content Count

    575
  • Joined

  • Last visited

Community Reputation

1170 Excellent

About DekuTree64

  • Rank
    Advanced Member

Personal Information

  • Role
    Programmer
  • Interests
    Art
    Audio
    Design
    Education
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. DekuTree64

    Steering Behaviors written for Angelscript?

    It's probably working correctly. If max velocity is 1.5 pixels per frame, and the objects are several hundred pixels apart, then it will indeed take several hundred frames to get there. And since the target will have moved several hundred pixels during that time, you should aim several hundred pixels ahead of its current position. Looking at that seek function in your original post, it should be fine if the target position passed to it is far away from the current position. And the line velocity.limit(maxspeed) in the update function should prevent velocity from ever going too high.
  2. DekuTree64

    3D game design with no engine / code orientated

    I agree. 3D from scratch (matrix math and rasterization, using something like SDL to get pixels on the screen) is great fun and highly educational. Depending on how much time you have, you could either do wireframe, solid color triangles, or textured and shaded. But if you really want to do gameplay code (making characters move around and interact), you might consider going 2D so you're not either using an engine that has all the code done for you, or spend all your time just trying to get up and running. There's surprisingly little difference between 2D and 3D gameplay code, so most of what you learn should be applicable to 3D in the future.
  3. DekuTree64

    Steering Behaviors written for Angelscript?

    I think the idea is to aim ahead of the target so you'll intercept it in the future, rather than heading toward its current position and missing it since it will have moved by the time you get there. Lines 2 and 3 calculate how many frames it will take to reach the target object if you go straight toward it at full speed. Then line 4 calculates where the object will be after that many frames have passed, and line 5 heads toward that position. It's not a very accurate prediction, but probably makes for more organic looking behavior, in addition to taking relatively little processor time. The vector length function should return sqrt(x*x + y*y). If yours is missing the square root, that could explain the unexpectedly large numbers. Also, what are the units for velocity? Pixels per frame? What is your frame rate? If T is 500 that means it should take 500 frames to reach the target, which would be 8.333 seconds at 60fps.
  4. DekuTree64

    Gyro + Accel values into useful values.

    In the sweeping arc case, I think you'll feel acceleration away from the center of the circle (centrifugal force). So like the portrait up/down shake, (0, variable, 0), where variable is a fairly stable value, either positive or negative depending on which way you're spinning. But there will also be a varying gravity vector added to it, and I'm not sure offhand how to separate that out. The gyro will give you the rotation rate, but that will be indistinguishable from spinning-in-place. In the angled shaking case, you are correct that at rest you should see ( 0.7, 0.7, 0 ) with sign flipping depending on which orientation it is. But when shaking, only one axis will vary, same as in landscape or portrait orientation. Now if you shake up/down/left/right while in angled orientation like this, you will get two axis variation: But that may not be needed for your application. Another thing to be aware of is an awesome sensor called BNO055, which has 3-axis accelerometer, gyro, and compass sensors, and some very clever programming to sort out the absolute orientation of the sensor with respect to the earth (the 3 axes are east/west, north/south, up/down), and separates out the gravity vector from other acceleration (this is the part that would be most useful in your case). You can probably get by without it for this project, but it might make things easier.
  5. DekuTree64

    Steering Behaviors written for Angelscript?

    Yes, that's for limit. SetMag would be pretty much the same but without the if. float oldMag = sqrt(v.x * v.x + v.y * v.y); v.x = v.x / oldMag * newMag; v.y = v.y / oldMag * newMag;
  6. DekuTree64

    Steering Behaviors written for Angelscript?

    If there aren't built-in functions for it, you can always do it manually. float speed = sqrt(velocity.x * velocity.x + velocity.y * velocity.y); if (speed > maxspeed) { velocity.x = velocity.x / speed * maxspeed; velocity.y = velocity.y / speed * maxspeed; }
  7. DekuTree64

    Separating components of a free form rotation

    If I'm understanding the problem correctly, then how about keeping track of the TargetOrientation the same way you did originally, but then having a separate CurrentOriantation which continuously rotates toward TargetOrientation? One way to do it would be CurrentOrientation = Quaternion.Slerp(CurrentOrientation, TargetOrientation, 0.5), so every frame you rotate half way between the last visual orientation and the target, giving an exponential deceleration as you approach the target. Another way would be to get the difference between the current and target orientations (inverse transform target by current), convert to axis-angle, and then rotate around that axis but use an angular velocity that's either constant or updated separately so you can do acceleration/deceleration. Something like Quaternion delta = Quaternion.Concatenate(targetOrientation, Quaternion.Conjugate(currentOrientation)); Vector3 axis; float angle; Quaternion.GetAxisAngle(delta, &axis, &angle); currentOrientation = Quaternion.Concatenate(Quaternion.CreateFromAxisAngle(axis, angularVelocity), currentOrientation);
  8. The basic idea is to translate so the zoom center is at the origin, then scale, and then translate back. But that should be equivalent to scaling and then translating by zoomCenter*scale-zoomCenter, or something like that.
  9. DekuTree64

    Fast Approximation to memcpy()

    On ARM CPUs, stmia and ldmia are usually better than single load/store instructions. Especially for memset, you can fill 8 registers with the value and write 32 bytes per instruction :) Or unroll it to 32 stmia instructions and get a whole KB per iteration. But dealing with unaligned addresses/non-multiple-of-32 size is a pain.   Mostly I'd be looking at why you're copying so much data around every frame in the first place.
  10. 1. If you're passing the same ResourceManager to everything everywhere, then you may as well just make it a global. Singleton is just a fancy name for a global to try and make it sound less evil. You could even go C style and interact with it strictly via global functions rather than OOP style.   2. Don't pass App to the NetworkManager, pass whatever members of App that the function actually needs to interact with. Or in some cases it's better to use a pass-by-value approach, where the NetworkManager function takes some arguments and/or returns a value, and App handles the job of fetching the arguments from its members and feeding the return value to whatever member needs it.   3. I think the GameState thing is good as-is. It's ok if changing the App state involves more than just creating a new GameState object.
  11. CTM * ScaleMatrix will get one result, ScaleMatrix * CTM will get another. One will be applying the scale "inside" the coordinate system defined by CTM, the other will scale around the world axes. I'm not sure which is which offhand, but I'm pretty sure "inside" is what you want. Then a Y scale matrix will scale the local Y axis, so it will have the same effect whether it's done before or after a rotation.   Something that took me a long time to notice is that a row-major rotate/scale matrix is really just an array of axis vectors. In 3D, with a 3x3 matrix, the first 3 elements are the X axis (1,0,0 in an identity matrix), middle 3 are the Y axis (0,1,0 identity), and last 3 are the Z axis (0,0,1). After rotating, those axis vectors will be pointing in different directions, but they'll still be orthogonal to eachother. And the length of each axis vector is the scale for that axis. Instead of applying a Y scale matrix, you could cheat and simply multiply the middle 3 elements by the Y scale you want :)   In 2D, the first 2 elements are the X axis (1,0) and the second two are the Y axis (0,1), and the same rules apply. It's actually simpler, but a bit harder to see the beauty of it in 2D, at least for me.
  12. DekuTree64

    Coding-Style Poll

    I'm nowhere near as picky as I used to be.   Usually I use braces and member variable/function names like this: if (mPosition.y < 0) {     doSomething(); } Except I prefer not to use braces on single line if statements. Not terribly annoying, but I do think it hurts readability a bit.   One exception I make to my normal bracing style is in switch statements. Normally I don't like to use braces around cases, but if I need a variable, then I do it like this: switch (something) { case 0:     qwer();     break; case 1: {     int a = 0;     asdf(a);     } break; case 2:     zxcv();     break; } Not only does it save two lines, it keeps the indentation level the same without looking as funky as it does if the braces are on their own lines. But again, I could easily give it up if it went against a project's style standard.   I like the m prefix to differentiate member variables from local variables/function arguments, so it's more clear where the side effects are. And I think it looks nicer than m_ and is slightly faster to type.   Classes, structs and global functions are all upper camel case with no prefixes. I would be slightly annoyed if I had to use the C prefix for classes.   Global variables are prefixed with g, constants prefixed with k, enum values with e. I could easily be talked out of any of those, although I do think global variables should have something to mark them as the necessary evils that they are ;)   Long ago, I used Hungarian prefixes on variable names, but I hate them nowadays.   One thing that really bothers me is excessive use of single-letter variable names. It's ok for x, y, z, one or two loop iterators, and stuff like that. But it can quickly turn unreadable if you have a big equation with lots of them. That's why I like programming better than math/physics :) Use meaningful names so you don't have to memorize what each variable is. Long names are ok, especially on things that aren't used very often.   I like spaces around operators so equations don't get too crowded looking. I'd be pretty annoyed without them.   I don't have much preference on spaces around the parentheses of if statements/loops/etc., but I usually do them like the examples above.   Tabs and spaces have plenty of potential drama. Especially if someone uses a different tab size than everyone else, and makes a big table where everything is aligned with tabs. I have a bit of OCD to make my code tab-independent, where I use tabs only at the beginning of lines, and then use spaces between tokens to align things. So even if you change the tab size, it just shifts the whole block left or right but the alignment remains correct.
  13. The IDE doesn't really matter. C++ is more or less the same whichever one you use. Just need to figure out where it is that you type in libraries to link, like sdl.dll if you're using SDL.   Don't worry too much about OOP. It's a good approach for a lot of things, but not the be-all-end-all of programming. Most likely you'll end up inventing it yourself when you need it :)   Regardless of which API you use, the basic approach to realtime programming is to use a function that returns a real time value, such as the WinAPI function GetTickCount(). It continually counts up in milliseconds, so if you want to run at 30 frames per second, do something like this: int lastTick = GetTickCount(); while(1) {     int thisTick = GetTickCount();     if (thisTick - lastTick >= 1000/30)     {         lastTick = thisTick;         UpdateFrame();     } } And I would recommend running at fixed frame rate. Variable frame rate is a pain, and not particularly beneficial for most 2D games.   The basic idea of graphics is that the screen is a huge array of pixels, and each pixel is a number representing its color. Every frame, you update character positions and such based on player input and enemy AI, and then copy all the background and sprite images to the screen at their updated positions. Draw the background first, and then the sprites, so they'll overwrite part of the background. Sprites are actually rectangles, but can look like any shape by using a color key (when copying pixels from the sprite image to the screen, check if the pixel is the transparent color, and if so, skip copying it).   Library code often handles all the pixel copying for you, but if you like a barebones approach where you do it all yourself, then SDL is the best. I like to allocate my own chunk of memory to use as the screen (32 bit pixels), and blit 8 bit paletted images to that using my own code. Then when the frame is done, lock the SDL screen surface and copy my screen buffer to it.
  14. To do interpolation instead of extrapolation, when you read the input state, timestamp it in the future by a constant amount (probably one frame's time). Then the current time will be between the previous input state and the most recent state. Or more specifically, if t is between 0.0 and 1.0, you get interpolation, and greater than 1.0 becomes extrapolation.   That approach is called lockstep, and only works on fast local networks like between handheld game systems. I have worked on games that used it to run at 30fps in perfect synchronization with no added latency (and therefore no need for any prediction or interpolation), but it is very tricky making sure that everything (including the main random number generator) gets called identically on all systems. And I'm not sure I'd ever trust floating point to come out exactly the same unless you can ensure that both CPUs are exactly the same model. Fixed-point is entirely predictable, though. But for PC games, and especially over the internet, you'll have to use a packet system to inform players about events, and use prediction while you wait. And when you do receive a packet, setting the position immediately could make things jumpy, so it may be better to interpolate between the old predicted position and new predicted position so it looks smooth even if it's less accurate.   I've never actually done internet multiplayer, but you'll probably need to declare one player to be the boss, who resolves conflicts between events if necessary.   Approach #1: When you shoot at someone, you can check if you hit your target at its visible position on the local machine, and if so, send out a packet to everyone else saying "hey, I just shot Doofus in the arm", and everyone including Doofus will accept that as fact, even if he had actually rounded a corner before the shot was fired.   Approach #2: Send a packet to Doofus saying "hey, I shot you", and if he agrees that it was plausible for him to be shot, he sends out a packet to everyone saying "that guy just shot me". That gives Doofus an opportunity to modify the event, if he was actually past the corner a significant amount of time before the shot was fired, or if he'd done some special move to block the shot.   Approach #3: Send a packet to boss saying "I just shot Doofus", and if boss agrees, then he sends out a packet to everyone.   In the first two approaches, you can end up with conflicts, like if two players believe they picked up the same item. The third approach allows the boss to resolve that before it happens. Alternatively you could do one of the first approaches, but have the boss check for conflicts among all the information he receives and send out corrections to everyone when necessary. But it's also wise to think in terms of what is the most fun. If it doesn't cause any problems, you could just let both players have the item.
  15. First of all with this kind of thing, you need to iron out the details of how it should behave. Is it possible for game code to request data to be displayed on one of the panels while it's already open? Should it queue and wait for a button press, or automatically slide out and slide in with the new text, or instantly redraw without sliding out and in? What if there's a blue panel request while the orange panel is open? Is the blue panel simply ignored and never displayed, or queued so it will slide in after the orange panel is dismissed? And how should the popup window behave?   I agree with the others that you need a manager object. Something that owns the overlay and all the panels. Game code sends panel requests to the manager, and it coordinates their behavior. Then you don't need a refcount on the overlay. Just a logical OR of all panels' visibility. If they're all hidden offscreen, then disable the overlay, otherwise enable it. If needed, the manager can also have a queue of panels and popups, and after a close event, display whatever is the next highest priority thing in the queue.
  • 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!