Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 30 Aug 2011
Offline Last Active Aug 20 2012 12:45 PM

#4969675 Collision Detection HELP!

Posted by on 14 August 2012 - 07:28 PM

you are using assignment in your if tests...line 22 and 27.

You've also neglected to test outside the top and left.

please look up axis aligned bounding box collision.

#4906578 Separating axis theorem

Posted by on 26 January 2012 - 05:23 PM

public Projection(double min, double max){

seems backwards. shouldn't it be: this.min = min; no?

#4905891 Switching from Console to 2D

Posted by on 24 January 2012 - 03:41 PM

1) SFML/SDL is the norm here, I did some windoes GDI stuff but it's not nearly as good as using something ontop of opengl.

2) Wrote text games with some ANSI terminal graphics. Then wrote battleship using SVGA rendering in pascal... bleh! moved on and up through C++ and opengl

3) I would not use game programming as the source of learning C++/programming because there are aspects of the language and programming designs that you would want to know first before coding a game. What I mean is: wouldn't it be nice to know if a hash, an array, a linked list, a binary tree or a map would be best suited to handle the data you are considering handling for your game? That's not something you want to recode, trying each structure to determine the best fit. That's something you would like to be able to have some background understanding of before using them in a game.

#4905555 Have i choosed the right path for beginners?

Posted by on 23 January 2012 - 02:43 PM

understand containers,
understand pointers,
understand memory management/cleanup

nobody likes an unstable game. good or bad won't matter when it crashes alot.

#4903821 Implementing "Rewind Time", like in the Prince of Persia - Sands of t...

Posted by on 17 January 2012 - 05:00 PM

What happens to your physics or particle pathing if you use negative time as your timestep?

if for instance particles animated exactly backwards for path and effects using a negative timestep, you wouldn't have to record anything but their "fizz out" locations to spawn backwards animating particles as it rewinds the scene.

#4903359 MMO Networking

Posted by on 16 January 2012 - 02:41 PM

I would recommend the common method of TCP/IP for login and initial connection, then transition over to UDP for gameplay. Typical FPS connectivity is advised because it is based around an authorative server which is a must for any MMO. The rates of update probably do not need to be as high as with an FPS, but if you have PVP then you will need a reasonable rate. What you will want to do is use a normal client-server prediction system which you can find threads about here. You will also want to partition your world somehow and have it generate snapshots for each partition with players in them. Then it can just dump the area snapshot to all players within that zone instead of trying to create custom visibility based snapshots per player. You could further improve snapshot performance on a very busy area by updating hostile elements in the snapshot more than friendly elements to allow a person to get informaiton that could save them.

#4884742 Handling textures with XNA and inheritance

Posted by on 16 November 2011 - 04:28 PM

well you can declare a static in each of the child classes if that is what you want.
That will make it so all soldiers use the soldier's static rectangle and all the defenders use the defender's static rectangle.

but if each instance of each class needs its own personal rectangle, then you already have it defined just fine.

even if you added a protected Rectangle to the character class, it would work fine, just like health.

I was under the impression you only wanted to define the rectangle once for all instances of the class. <-- in this case a class static is worthwhile.

#4884654 Collision Response With Penetration Depth

Posted by on 16 November 2011 - 01:40 PM

by doing the axes seperately you are getting messed up. the reason is this:

if you do the x axis penetration check you will definitely get moved outside the x axis bounds of the platform
then when you do the y axis penetration check, you will also definitely get moved outside the y axis bounds of the platform. basically, even though your platform is a long rectangle, the bounds testing ensures that you will not "penetrate" the infinite 2 surfaces you would find if you extruded the platform along each axis seperately. That is why you end up corner to corner.

first test if there is a collision : if you have penetration in the x axis, first test for penetration in the y axis as well before you calculate a correction.

I believe the separating axis theorem is what you are after.:

If there is no x overlap - there is no collision. break out early
OR If here is no y overlap - there is no collision. break out early

if there is x overlap - if there is also y overlap - collision - calculate penetration/correction- done
OR if there is y overlap - if ther eis also x overlap - collision - calculate penetration/correction - done

when you calculate the overlaps: do not just compare your left < their right.. because what if BOTH your left AND your right edges are < their right..
need to be more complete on those tests.

#4880579 walking enemy - better algorithm sfml c++

Posted by on 04 November 2011 - 01:24 PM

I thnk a big question here is.. can this enemy ever be knocked off its path? If not, then there's no concern about it needing intelligence to path around walls.

please be sure you define the limits of what this sprite is to do.. Our tendencies around here are to sometimes set you down the path of creating First person shooter enemies capable of hopping small hurdles, work in teams and patha round a graph representation of the game world....

Concise definition of what the character is supposed to do will allow you to implement systems that are useful.

The original post makes me believe it's simply an enemy that walks. like old enemies in Mario that didn't care where Mario went, they just did their pathing and if he hit them, he got hurt.

#4880333 mouse to ray - sphere collision detection help

Posted by on 03 November 2011 - 05:29 PM

double d = intersectRaySphere(entity.getPosition(), shootingRay, Vector3(0, 100, -300), 30);you have the unprojected coordinates on the far plane and the source of the gun (character). what you are passing in is not the proper ray.

to get the ray do

farCoords = projectedMouse( mx, my);

then shootingRay = farCoords - entity.getPosition(); now i know this isn't the gun muzzle position but you can easily sub that in for the getposition(),, im just using stuff from your code that I can name.
then shootingRay.normalize();

then do
double d = intersectRaySphere(entity.getPosition(), shootingRay, Vector3(0, 100, -300), 30);
this will fire a ray from your entity at a sphere of radius 30 around the enemy character's coordinates of (0,100,-300)

#4880302 mouse to ray - sphere collision detection help

Posted by on 03 November 2011 - 03:57 PM

from what I gather:

c is magnitude of ray origin to sphere center.

v is c converted along vector rv since rv is a unit vector the dot product wth lengthed vector Q would return length along rv direction

There is a line segment perpendicular to rV passing through sphere center at a length v along rV direction. The length of this segment is (c*c) - (v*v).

the ray intersecting with the sphere will have the first (closest) intersection point at distance sR (radius of shphere) from sphere center sO.

ths is also alon vector rV. so now we have two points along rV. we know the length to one is sRr and the other forms a segment perpendicular to rV. The collision point and v distance point form a right triangle wth sR as the length of the hypotenuse.

so the distance ALONG rV to the collision point is v- sqrt( (sr*sr) - ((c*c)-(v*v)) ). they represented d as the big portion in the brackets.

This function appears to work fine.

Are you applying your final distance along rV to indicate collision point? if rV is not normalized you may end up with strange results.

your collision point should be rO + (rV*finaldist).

#4880279 AABB Bounding Box collision help!

Posted by on 03 November 2011 - 02:59 PM

You aret esting their minimum point as less than your view volume maximum point. you OR this set of object with those that have their maximum point greater thatn your view volume minimum point.

lets think abot the first part. so they pass since their min is less than view.max. well that's true, but what about their max vs your min? you only tested them against the one corner, you didn't actually see if they were bound within the box or interected. same applies to the test on the other side of the OR. what you probably end up with is having nearly everything pass through as visible.

you could add a faster test using spheres first.

#4864427 How to make my own gui using opengl and SDL and C++ or whateva? :)

Posted by on 21 September 2011 - 04:38 PM

I have to point out. Maybe you should design you hud and menus for your game prior to making gui code. That's if you are making a game. This will allow you to be very precise about the feature set you require.
From there you can design it to be extendable for future generic use in any game you want to make but for now, you'll have the feature set you need for your game.

UI systems can get very complicated and then require alot of support assets (images, video, icons) to make use of their more advanced features. You run the same risk as people sitting down and coding generic game engines instead of the engine they need for their specific game.

A prime example: Will you need Scroll bar functionality? really? will you actually need it?

it's a default part of most UIs you see in applications, but in your game.. will there actually be enough stuff in any menu or text field requiring scrolling?

#4864235 Particle System Design Question

Posted by on 21 September 2011 - 09:56 AM

What they are describing is similar to multiple audio tracks overlayed to produce a final product.

So a laser burning a wall would be:

Channel A: sparks effects
Channel B: Beam effects
Channel C: Smoke effects
Chnnel D: Hot spot overlay blended onto wall surface

For a channel based system, you are building heirarchies of control where you can selectively disable entire groups from rendering. The particles themselves in this case are just triangle stripped quads.
so it can be like
Particle System Manager:
            particle Top level controller
                       Particle effect controller
                       Particle effect controller
                       particle effect controller
            particle Top Level controller

Then you could register each effect controller within groups like above, BEAMS, SPARKS, SMOKE (using enum bitflags)
then you could selectively disable groups of particle controllers across all particle systems

many games use this for audio with voice, sfx, music channels with their own amplitude sliders. When a sound is to be played, it's sent along with a channel tag for proper volume adjustment.

#4861698 printf disadvantages?

Posted by on 14 September 2011 - 01:17 PM

the matrix screen saver......

Seriously though
if you mean that using printf or some self implemented variant to render debug text to a console in a game engine is a bad idea. Yes and no. warning messages detailing a function failing.. good. Rendering information using printf style eplisis (...) set of arguments per frame. your performance will drop miserably.

so yeah, good and bad.