Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

196 Neutral

About _Flecko

  • Rank
  1. _Flecko

    Projectile launching

    Hey everyone, thanks for all your help! I believe I've solved it: k=x/cos(a) * sqrt(g/2(y-xtan(a))) I just solved it by hand, it turned out to be a lot simpler than it looked, everything cancels nicely :) When I checked it it seemed correct. Also, the case where the square root is undefined is kind of neat - y-xtan(a) needs to be negative for it to work, and it's only positive if the point (x,y) is above the trajectory you'd get if there were no gravity - meaning, of course, that no matter how fast you launch your projectile, it can never reach the point! Anyway, thanks again for the response, no more computer solvers for me :p
  2. _Flecko

    Projectile launching

    Hey, I'm trying to solve the following problem: given a launch angle, at what speed must I launch a projectile so that on its way down it will pass through some point? Assume the only force acting on the projectile is gravity. Here's how I've tried to solve it; there is, as you'll see, something wrong with the result, so maybe you can find the mistake I'm making. Let the angle be a, the speed k, the point (x,y), the initial velocity (vx,vy), gravity g with g<0, t time. Assume for simplicity that the projectile starts at (0,0). x=vx*t=kcos(a)*t so t=x/kcos(a) y=vy*t+(g*t^2)/2 so 0=(g*t^2)/2+ksin(a)*t+y so t=(-ksin(a) +- sqrt((ksin(a))^2+2gy))/g but since we're launching the projectile upward and we're interested in its position as it descends, and g is known to be <0, we're only interested in the root t=(-ksin(a)-sqrt((ksin(a))^2+2gy))/g so x/kcos(a)=(-ksin(a)-sqrt((ksin(a))^2+2gy))/g However, using a computer solver, I get k = +- (sqrt(g)*x*sec(a))/sqrt(2y-2xtan(a)) which is undefined because g<0. So what's going on - is my reasoning flawed? is the solver jerking me around (would anyone who has mathematics software mind double checking that result)? Thanks for reading. Max
  3. _Flecko

    Depth sorting

    That was more or less what I was doing. However, after a good deal of strugglin, I realized why I'm having so much trouble making it work: because it is -impossible- to do it the way I was trying to :) There is no linear order on the depth of whole objects - cubes, faces, etc. That is, if you're treating objects like a cube as a single unit, you can't find a strict order to draw objects in. If my scanner was set up I'd show you proof; basically if you assume there is a linear ordering, you construct a situation where you have two objects a and b where it is simultaneously true that a is in front of b and that b is in front of a, which contradicts that such an ordering could exist. So, now I gotta find a different way to do it. [Edited by - _Flecko on June 10, 2006 5:45:19 PM]
  4. I'm working on an isometric game where the tiles are squares, and having a hard time figuring out how to depth-sort objects. Have a look: (use arrow keys to move the red box, space to jump). At the moment, it sorts from front to back, then top to bottom where there are ties. If you jump on the low wall to the right and move towards the back, you'll see the problem: the wall gets displayed over the box, even though it ought to be the other way around. The problem is that since the box's front-back coordinate is at that point less than the wall's, it gets sorted behind. What's the proper way of computing depth in a situation like this? Is there any linear ordering of objects based on their coordinates that gives what should be in front of what? [Edited by - _Flecko on June 10, 2006 12:09:28 AM]
  5. I recently noticed I was getting very choppy performance on a simple Managed DirectX app while running windowed. The program only has to draw half a dozen polygons and some text, so it didn't seem quite right. So using the DXUtil timer, I tested it. In both of the following graphs, the red points represent time spent on drawing operations (everything from Device.BeginScene() to Device.EndScene()), the green points represent the time taken by Device.Present(), and the blue points are the rest of the time. windowed: fullscreen: I think it's clear where the problem is :) you can't really see on the graph, but the shortest amount of time that Device.Present() takes for the windowed app is about the same as the amount of time it almost always takes for the fullscreen. So, I was curious if anybody had an idea what might cause such huge variance in the amount of time that Device.Present() takes. I was thinking it could be that the backbuffer size or format was wrong or something like that, but I haven't been able to figure it out yet. In case it'll help, here's my setup code: //Create presentation parameters pres=new PresentParameters(); pres.SwapEffect=SwapEffect.Discard; pres.AutoDepthStencilFormat=DepthFormat.D16; pres.Windowed=windowed; if (!windowed) { width=pres.BackBufferWidth=640; height=pres.BackBufferHeight=480; pres.BackBufferFormat=Format.X8R8G8B8; } else { width=pres.BackBufferWidth=ClientSize.Width; height=pres.BackBufferHeight=ClientSize.Height; pres.BackBufferFormat=Format.X8R8G8B8; } pres.BackBufferCount=1; //Get some hardware caps Caps hardware=Manager.GetDeviceCaps(0,DeviceType.Hardware); CreateFlags flags=CreateFlags.SoftwareVertexProcessing; //Default createflags //Use hardware vertex processing if available if (hardware.DeviceCaps.SupportsHardwareTransformAndLight) { flags=CreateFlags.HardwareVertexProcessing; if (hardware.DeviceCaps.SupportsPureDevice) flags|=CreateFlags.PureDevice; } //Turn off event handlers Device.IsUsingEventHandlers=false; //Create the device and hook its events device=new Device(0,DeviceType.Hardware,this,flags,pres); device.DeviceReset+=new EventHandler(onDeviceReset); Thanks everyone :)
  6. I recently released a game I'd finished to find that it only works for about 1/3 of people - for the rest, the game gives a "failure to initialize error." First I thought I hadn't included all the Managed DirectX components necessary in the installer or something, but then somebody with a clean Windows installation got it working fine, and even on the machines where it doesn't work it manages to go fullscreen briefly before it breaks down. Then I thought I might be doing something unsupported on some video cards, but a friend with the exact same card as me couldn't get it working. All the machines I currently have access to run the game fine, which makes debugging kind of tough. It seems like I can rule out bad installer and hardware incompatibility as the problems, but why else would it run on some machines and not others? The game is here: if you want to have a look for yourself...if anyone for whom it doesn't work that has VS .NET / the CLR debugger wouldn't mind running a debug build, that would be awesome too.
  7. _Flecko


    Ok, now I feel dumb for not knowing about this :) I always thought you needed to be able to do unmanaged debugging or something that I couldn't because I only have Visual C# to get this working right...I'm pretty sure I can't get all the same debugging info as everyone else, but just switching to debug mode makes DX actually speak up when I'm doing something wrong instead of just letting it slip until memory gets corrupted. Thanks :)
  8. I'm having some trouble getting my Managed DirectX game to run on lower quality graphics cards (it's fairly basic 2D using orthographic projection, so it ought to be able to). The problem is that at times when I'm loading and unloading resources, an AccessViolationException is thrown from within Direct3D, usually inside VertexBuffer.Dispose() - the root of the call stack is presumably the garbage collector. It's unpredictable exactly when it will happen, but it's bound to if you play a few levels. Problem is, that's all the info I have, and I don't know how to approach this to get more info to figure out what went wrong. Last time this happened, it turned out after days of searching that I was using 16 bit indices in my index buffers, which a lot of video cards don't support, but I basically found that through guess and check. If anyone has any leads on this for me - what kind of mistakes commonly cause this type of exception, what it actually means, debugging techniques I might try - I would appreciate it very much.
  9. Ok, I can't say I understand quite how it works, but I got the premade installer to work for my game - thanks. One question, which cab files do I have to include? I'm using the December 2005 SDK so I know I don't need to include files from the redist directory that start with, say, october2005, but there's also a bunch of files like and - do I need those? Which ones do I need? I'd like to trim it down as much as possible, since I'm distributing this online.
  10. I've got a release candidate for my Managed DirectX game ready, and here comes the moment I've been dreading: how the hell I'm supposed to get it working on peoples' computer. I remember this being a huge problem last time I tried to run managed DirectX on machines that didn't have the actual SDK installed, and now before I start trying to distribute anything I want to get this completely straight. I want to make a nice, neatly packaged installer that will make sure the user has the requirements - .net 1.1, DirectX 9.0c, and whatever it is they have to install to make Managed DirectX apps work - and either install them or direct them to the website where they can get an installer if they don't. I'd rather not host the now enormous (40 meg!) contents of the redistributable folder in the SDK, so if there's a way around it I'd like to know. Can anyone who's been through this give me an idea how I'm supposed to go about this?
  11. _Flecko

    Pixel-perfect scaling

    -I am using a textured quad in orthographic projection, not sprites -the 0.5px thing is explained here:
  12. I'm working on the finer details of my 2D library ( and one of them is getting pixel-perfect display of textures on screen for when it really matters - it might not be that important in-game, but for UI sharp imagery matters. I've read on mapping texels to pixels, and (thanks to a suggestion from someone who was using the library) have implemented an elegant solution to that problem by offsetting texture coordinates on all vertices by (0.5,0.5). I've encountered another similar problem, though: pixel-perfect scaling. My library uses textured quads, and generally you put lots of different textures in a single image file so that you can render a ton of distinct objects all in one shot. A common thing to do in something like UI systems would be to take a very tiny texture, perhaps only a pixel high or wide, for something like an edge to a window or the middle of a button and scale it out to produce the final image. As an example, consider this texture: the dot might be the edge of a window, and we stretch it out to make a line (obviously in a real app it would be something more intricate that actually requires a texture, but the idea is the same). So, given the coordinates of the corners of the dot in terms of actual pixels on the image, I compute the u,v coords by dividing by the image's dimension. Those coords are assigned to vertices - with the 0.5,0.5 offset, but I've tried it without and it looks even worse, the same problem applies. When I scale it out, what I get is this: That's with texture filtering turned on. Turn it off, and the result is a solid block like I want, but it's a rather inelegant and inefficient solution to constantly have to change the sampler state, and it seems like there must be a better way. obviously, the surrounding image is bleeding in - Make the background in the texture blue, and it will fade to blue instead - so it would seem like an issue with the texture coords in use. Is it possible to get this image to scale perfectly with texture filtering on, or is that just not possible?
  13. _Flecko

    Braking algorithms for AI

    In my 2D game there are a number of vehicles that move in one or two dimensions, and I'm having trouble getting the AI to brake so that they'll stop at a desired position. Some vehicles, like the jeep, have an actual brake button (which is necessary because the slope of the terrain influences their velocity), others like the helicopter can be braked by accelerating in the opposite direction or just waiting for drag to slow them down. The controls are such that the player (AI or human) is either accelerating it in some direction at a constant, predetermined rate or not at all. For this reason, some estimation will probably need to be used, since there are a finite number of rates of acceleration the vehicle could have at a given time. So, my question is, what are some good ways for having the AI figure out what controls to press in order to stop at a given position.
  14. I'm trying to get antialiased text by prerendering letters to a texture and storing their coordinates for later use. I do this by rendering a large font to one texture, then rendering that scaled down to my main texture. The problem is that it doesn't look too nice: That's a screenshot of the texture it outputs (it has a transparent background, but I've rendered it to a black background here). As you can see there are partially transparent pixels, but it just doesn't look good. I've tried many combinations of font sizes and texture filters, none of them come out too well. How is this generally done?
  15. _Flecko

    Texture Collision Map

    It is rarely worth doing pixel-by-pixel collision detection. The best solution depends a lot on the nature of the game, but typically I will use sets of bordering line segments for oddly-shaped sprites, which is a good solution because it can give you as little or much accuracy as you need. However, note that this is still an O(n^2) algorithm for sprites with n-edge maps - you will often improve your performance a lot by doing some quick preliminary exclusion test. For example: right now I'm working on a project that uses rigid bodies in 2D, so I've got a set of particles and edges connecting them. I want to see if bullets cross the edges. However, the game area is big and the vast majority of bullets are not hitting anything the vast majority of the time. Test 1: take the radius of the sprite's bounding circle, computed at construction time, and add it to the length of the bullet's motion vector (which gives the radius of a circle that bounds its motion over the last frame). See if the two radiuses add to less than the distance between the bullet and the center of the bounding circle, because if they do, we can quit early having done barely any work. I do another more accurate test (distance from the sprite to the closest point on the bullet vector) before I finally do the actual collision detection - it hurts marginally more in rare cases, and helps a lot in the majority of cases. Stay on the lookout for geometric tricks that can save you CPU time.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!