Messages

16

General / Taking the time control approach - questions

« on: April 11, 2010, 06:06:54 pm »

Sure...

Code: [Select]


#define FPSRATE 1.f/65.f  //It has to be this, otherwise the game runs at half speed.  It hates 60.f

...

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
//LOOP, LOOP, LOOP, LOOP, LOOP, LOOP, LOOP, LOOP, LOOP, LOOP, LOOP, LOOP, LOOP, LOOP!!!!!!!!
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
float countor = 0.f;
sf::Clock clocky;
while (bGameGoing && App.IsOpened())
{ GameInputClass& playerInput = GameInputClass::GetInput(); //Keyboard recognized...
playerInput.GetGameplayKeys();
//Escape goes to exit
//-------------------------------------------------------------------------------------
if (playerInput.bEscKey)
{ bGameGoing = false;
gameState = 1;
}

countor += clocky.GetElapsedTime();
while (countor >= FPSRATE)
{ countor -= FPSRATE;
GameLogic();
}
GameRender();
countor += clocky.GetElapsedTime();
if (countor < FPSRATE)
{ sf::Sleep(FPSRATE - countor);
countor = FPSRATE;
}
clocky.Reset();
frameRate = 1.f / frameClock.GetElapsedTime();
frameClock.Reset();

//Wait to get a proper time in-between frames...
//-------------------------------------------------------------------------------------
}


17

General / Taking the time control approach - questions

« on: April 11, 2010, 05:56:05 pm »

Okay, I've gone and tried this.  This is similar to the problem I had before where trying to get a frame rate of 60 makes it so the game doesn't run fast unless a lot of things are being updated.

FRAMERATE was set to 1.f/60.f

18

General / Taking the time control approach - questions

« on: April 11, 2010, 05:22:40 pm »

What you're doing looks kinda like what I was originally trying, though a bit more sophisticated.

What does FRAME_RATE = in your example?

One thing I'm noticing is that with my new approach, things don't move a fixed number of pixels.  Like, I want the player to always move at a rate of 4 pixels, player shots at a rate of 12, etc.  Right now, the player goes between 4-5, mostly towards the 4.  The animation can look jittery because of the inconsistent movement rate...  I've been studying other games and they seem to have the rate locked.

I'll give your proposal a go.  Thanks.

19

Graphics / Shape with a hole

« on: April 11, 2010, 05:52:46 am »

You might be able to draw a circle shape that has 0 alpha and an outline.

Try:  SHP_Whatever = sf::Shape::Circle(MidPointX, MidPointY, Radius, sf::Color(0,0,0,0), 1.f, sf::Color(0,0,255));

Where the last color is your desired colors.  I just picked blue to demo.

20

General / Taking the time control approach - questions

« on: April 11, 2010, 05:43:33 am »

Okay, I've been trying to do this new approach rather than depending on FPS...  Here's a snippet of my player code.

Code: [Select]


#define PLAYER_SPEED 160.f
float MoveY = 0.f;
float MoveX = 0.f;
if (GetEventsControls.bDownKey) //Vert.
MoveY += PLAYER_SPEED;
else if (GetEventsControls.bUpKey)
MoveY -= PLAYER_SPEED;
if (GetEventsControls.bLeftKey) //Horiz.
MoveX -= PLAYER_SPEED;
else if (GetEventsControls.bRightKey)
MoveX += PLAYER_SPEED;
//Focus mode
if (GetEventsControls.bLshift)
{ MoveX /= 2;
MoveY /= 2;
}
MoveX = MoveX * App.GetFrameTime();
MoveY = MoveY * App.GetFrameTime();
game.playerHitX += (int)MoveX;
game.playerHitY += (int)MoveY;


Basically, with it right now, it SEEMS to be precise...  I have to multiply by 160 to get a result that actually moves...

The HitX and HitY is the center point of the player and it is drawn relative to that point.  The main problem, though, is I want this number to be an int always.

Is there anything better I can be doing with this or does this look acceptable?  Thanks!

21

Graphics / SetScale in 1.6 displaces the graphics

« on: April 09, 2010, 07:34:41 pm »

I don't know if this is going to be fixed, I was originally not planning to do a 1.7 release.

Eh, we can hold out till 2.0.  

22

SFML projects / My SFML project - shoot 'em up game

« on: April 09, 2010, 06:43:51 pm »

I see, well, 64-65 isn't bad.

The main reason why I'm obsessing over this is because it's the way I'm used to counting things.

For instance, I have the player move at 4 pixels every FRAME.  I use the frames for counters, etc.

I've gotten accustomed to:  15 frames = .25 seconds.  180 frames = 3 seconds, etc.    

With the faster frame rate, it'll obviously be speedy and lower it'll be slow.  I guess I could look into trying to use the clock objects, though would I need to have one of those with everything?  That's the main reason why I didn't bother with those as I didn't really get using them.

23

SFML projects / My SFML project - shoot 'em up game

« on: April 09, 2010, 06:18:49 pm »

Yeah, I know it's not a big difference.  I guess having it be locked or "mostly locked" is just something I'm obsessing over.

24

SFML projects / My SFML project - shoot 'em up game

« on: April 09, 2010, 07:56:27 am »

Runs perfectly fine on my computer where it reads a constant 66.6 fps.  The number of bullets on screen at once is terrifying! I die in like 2 seconds. 0_0

Well, it'll be a bit more reasonable in the real deal.  I was just messing around with stuff for this.

66.6 eh?  It's 64 for me...  I'm definitely hoping to find a way to better regulate this...   :?

25

SFML projects / My SFML project - shoot 'em up game

« on: April 09, 2010, 06:36:52 am »

I updated the zip file in the message above this.  Just wondered if anyone could test and report speeds.  Thanks.

26

Graphics / SetScale in 1.6 displaces the graphics

« on: April 08, 2010, 06:02:46 pm »

Dammit... It was reported a long time ago, and I was pretty sure that I already fixed it.

This is really annoying.

Hey, it's not a huge deal for me.  I'm only using it for 2 stationary graphics and can just offset them for the moment.

Game logic is keeping me too busy to care.  

27

Graphics / Different sprite width/height behavior in 1.6?

« on: April 08, 2010, 04:46:35 am »

This seems to related to the scale post I made a bit earlier. Hope we get an update.

28

Graphics / SetScale in 1.6 displaces the graphics

« on: April 08, 2010, 02:15:41 am »

So, I've got this small graphic and when I used setscaleY on it to make the thing taller.  In 1.5 it worked fine, but here, I need to set its Y position higher in order for it to be positioned correctly...  I am using a scale of 60.

The greater the scale value is, the lower down it goes.  Setting the center to 0,0 does nothing either.

Any thoughts or is this just a bug?

UPDATE:  It also does it with X coordinates too.

29

SFML projects / Bullet hell (Touhou) fangame

« on: April 06, 2010, 04:23:17 am »

Neat.  I'm also doing a Shmup, though wanna do my own twist on things.  I'm in the process of trying to figure out a good way to get enemies to get loaded in from a file properly.  I'd like to know how you got the blue glowing effects on things.  The whole graphic side of this concerns me.

30

General / 50% CPU usage... thoughts on improvement

« on: April 02, 2010, 04:54:35 pm »

Can you show us your main loop ?

Sure...

Code: [Select]


while (bGameGoing && App.IsOpened())
{ App.Clear(); //Wipe screen
playerInput.GetGameplayKeys();
//Escape goes to exit
//-------------------------------------------------------------------------------------------
if (playerInput.bEscKey)
{ bGameGoing = false;
gameState = 1;
}


//-------------------------------------------------------------------------------------------
//Update anything...
//-------------------------------------------------------------------------------------------
it1 = GameObjs.begin();
while(it1 != GameObjs.end())
{ //(*it1)->Update();
if((*it1)->Update())
{ delete *it1;
it1 = GameObjs.erase(it1);
}
else
++it1;
}

//-------------------------------------------------------------------------------------------
//Display!
//-------------------------------------------------------------------------------------------
/-------------------------------------------------------------------------------------------
Draw all objects...
//-------------------------------------------------------------------------------------------
for (int drawPass = 1; drawPass < 7; drawPass++)
{ for(it1 = GameObjs.begin(); it1 != GameObjs.end(); ++it1) //Go through the list and update ALL!
{ if ((*it1)->drawPriority == drawPass)
(*it1)->Draw();
}
}

//A bunch of App.Draw statements go here.  I left them out as they aren't relevant.

App.Display();
//Wait to get a proper time in-between frames...
//-------------------------------------------------------------------------------------------
bool bGo = true;
while (bGo)
{ float Time = frameClock.GetElapsedTime();
if (Time >= 1.f/60.f)
bGo = false;
}

frameRate = 1.f / frameClock.GetElapsedTime();
frameClock.Reset();
}


Basically, the while Loop at the end is what makes the CPU go to 50%.  If this while loop is NOT present and I use the setFramerate to 60, the game lags big time until it's updating a lot of stuff.

The while loop at the end, if I add:  else, Sleep(1); and change it to 1.f/80.f seems to work, but that just feels sloppy.