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