Print

[chilin_dude]

i could host it for you if you want! pm me for details

[StrongBad]

Alternatively, you could just make an announcement on the forums and post it to the newsgroups.  That's a good start.  Or maybe notify the news reporters for X-S.

[Videogamebuyer14]

GO HOMESTAR RUNNER!!!!    

[sicman]

typedef struct _D3DDISPLAYMODE
{
UINT Width;
UINT Height;
UINT RefreshRate;
D3DFORMAT Format;
} D3DDISPLAYMODE;

D3DDISPLAYMODE mode;
D3DDevice::GetDisplayMode( &mode );

I haven't tried it yet..







i noticed that in that post of yours...have you played with it at all? it seems like that could be a good way to limit the frame rate of a game...



then i suppose if I limits the framerate of the game,  I woul dhave to add a nbew function to my XBapp:


class myapp:public XBapp
{
      void LogicLoop();
}


and then change the Run() function to be similiar to this:

run()
while(not time to draw)
{
  get input
  LogicLoop();
}
else
{
  FrameRender()
  Render();
}

or, if i limited the framerate WITH D3D, how would the original RUn() work?

sinc eit goes run()
stuff....
RENDER();



would D3D just kind of pause on the render?

[jippie]

QUOTE (sicman @ Apr 10 2003, 04:35 PM)

typedef struct _D3DDISPLAYMODE { UINT Width; UINT Height; UINT RefreshRate; D3DFORMAT Format; } D3DDISPLAYMODE; D3DDISPLAYMODE mode; D3DDevice::GetDisplayMode( &mode ); I haven't tried it yet.. i noticed that in that post of yours...have you played with it at all? it seems like that could be a good way to limit the frame rate of a game...

nope haven't needed too, what I'm doing is fast enough..

QUOTE

run() while(not time to draw) {    get input    LogicLoop(); } else {    FrameRender()    Render(); } or, if i limited the framerate WITH D3D, how would the original RUn() work? since it goes run() stuff.... RENDER(); would D3D just kind of pause on the render?

Not following so well. Why do you want to do what you are doing?

[sicman]

well, simply put, Graphics are the slowest operation you can do on a computer. Which means teh render function could take up to 10 times longer to execute then a logic loop (a  loop that handles input, and updates logic..ai, etc.)


what normally is done is a loop liek this

while(counter>1)
{
do logic();
counter--;
}
else
{
draw graphics
}


where counter is incremented by a timer every ____ number of seconds. this keeps the game logic runninga t teh same speed across every different computer, which isnt ia problem here, but it also keeps it running at a constant speed even iff drawing to the screen takes different amounts of time each frame, or there are a lot of models on the screen nad the logic updates slowly, etc.

i guesds ill  mess with it myself.

[jippie]

QUOTE (sicman @ Apr 10 2003, 11:33 PM)

well, simply put, Graphics are the slowest operation you can do on a computer. Which means teh render function could take up to 10 times longer to execute then a logic loop (a  loop that handles input, and updates logic..ai, etc.) what normally is done is a loop liek this while(counter>1) { do logic(); counter--; } else { draw graphics } where counter is incremented by a timer every ____ number of seconds. this keeps the game logic runninga t teh same speed across every different computer, which isnt ia problem here, but it also keeps it running at a constant speed even iff drawing to the screen takes different amounts of time each frame, or there are a lot of models on the screen nad the logic updates slowly, etc. i guesds ill  mess with it myself.

Oh sorry your trying to limit the framerate, then what you did above would work. The only difference I would use a timer instead. As the count how many loops still depends of fast the computer is..

#define _FRAMERATE 20 // this will give you 50 frames/sec

while(QUIT == false)
{
   do logic();
   if( 0 == GetTickCount() % _FRAMERATE)
   {
      Render();
   }
}


Jippie

[BenJeremy]

QUOTE (jippie @ Apr 12 2003, 08:15 AM)

QUOTE (sicman @ Apr 10 2003, 11:33 PM) well, simply put, Graphics are the slowest operation you can do on a computer. Which means teh render function could take up to 10 times longer to execute then a logic loop (a  loop that handles input, and updates logic..ai, etc.) what normally is done is a loop liek this while(counter>1) { do logic(); counter--; } else { draw graphics } where counter is incremented by a timer every ____ number of seconds. this keeps the game logic runninga t teh same speed across every different computer, which isnt ia problem here, but it also keeps it running at a constant speed even iff drawing to the screen takes different amounts of time each frame, or there are a lot of models on the screen nad the logic updates slowly, etc. i guesds ill  mess with it myself. Oh sorry your trying to limit the framerate, then what you did above would work. The only difference I would use a timer instead. As the count how many loops still depends of fast the computer is.. #define _FRAMERATE 20 // this will give you 50 frames/sec while(QUIT == false) {    do logic();    if( 0 == GetTickCount() % _FRAMERATE)    {       Render();    } } Jippie

Well, the XTL framework provides a nice run loop, so my first advice is, don't stray from that structure.

Once you do that, it's pretty simple to surround the Render() call like so:

CODE

...somwhere in the source: #define LIMIT_FPS   30    ...somewhere in init code of App object:    m_dwNextFrameTimer = GetTickCount()+(1000/LIMIT_FPS);   ...in Run():    if ( GetTickCount() > m_dwNextFrameTimer )    {        m_dwNextFrameTimer = GetTickCount()+(1000/LIMIT_FPS);        Render();    }

This will get the desired result, with a minimum of fuss.

Really, use the XTL. It's already a nice framework, and will save you the trouble of re-inventing the wheel.

Eventually, I'll strip down MXM to provide a nice extension to the XTL using a state-driven model for the application. It's also what I use in X-Marbles.

[sicman]

actually, i was trying not to limit the frame rate per say, but to set the logic to run at a certain interval.. so that the game runs constantly despite the framerate. I did it in a vetry similar way to the code you posted up there ^^ Ben, except that it sets the logic to execute a certain number of times a second, while rendering in the spare time. Im going to add in a minimum frame rate check in there too.. I have recently discovered the XTl, and ive made good use of it. I stripped some stuff out, reorgonize some of the code, and i have a nice running version

is there possibly a MIRC channel for homebrewing?
or a place for posting tutorials, example source? i would love to help the homebrew people.

[jippie]

QUOTE (sicman @ Apr 12 2003, 09:24 PM)

actually, i was trying not to limit the frame rate per say, but to set the logic to run at a certain interval.. so that the game runs constantly despite the framerate. I did it in a vetry similar way to the code you posted up there ^^ Ben, except that it sets the logic to execute a certain number of times a second, while rendering in the spare time. Im going to add in a minimum frame rate check in there too.. I have recently discovered the XTl, and ive made good use of it. I stripped some stuff out, reorgonize some of the code, and i have a nice running version is there possibly a MIRC channel for homebrewing? or a place for posting tutorials, example source? i would love to help the homebrew people.

Sorry again, but if you limit the framerate would this not give you more time to do the logic??
Maybe I should just shut-up, as I don't know what I'm talking about :-)

jippie

[sicman]

well it does, yes. but just limiting the framerate isnt going to give more time to do the logic, since the RUn() loop goes
Logic();
render();

the whole process gets to wait in the render function for it to draw, which would then limit your logic to the frame rate.


i used basicly did what ben said, but set up the logic to execute a certain number of times a second, so that the framerate will draw as fast as it can, yet my logic will run at an exact interval.    i am a ninja.

[knepley]

Just a side note, you shouldn't really ever limit framerate, you should just time your animations and movements by doing delays against a linear function like GetTickCount().

[sicman]

good point, that would be easier, i guess. well, i never truely limit the frame rate. I limit the logic rate.. ie, i set the logic to update at intervals, made it easier on my behalf.

for example, i could set the logic to execute 200 times a second

this way, if i wanted something to move, i would move it by a very small number ( .1) or something

so that collision detection would be very easy.  this is they way i did it in 2D.


so say , for instance, i update the way you are talking about.


if(player is pushing up)
{ player.x position = player.x positon + (velocityPerSecond * elapsed time since last logic/movement call)

thats what i should do, correct?


what would then be the easiest way to handle collision detection then? epescially if i have a very small object (2x2x2) that moves extraordinarily fast (VelocityPerSecond=300)? if the drawing, theoreticaly, exceeded 1/2 or something, and the small objected moved by a velocity of 150... i could very easily miss several collsions.

with limiting logic, the speed of an object per logic call rarely exceeded 1, so i never ran into trouble with things liek that happening.

any ideas/concepts i may be thinking about wrong? or point me in the direction of how to think?

[sicman]

yeah, that cleared some things up., basicly what i figured out before. what im lost at currently is how to collision detect against that? so that i dont have things like bullets flying through thin walls or thin models. in fact, im really lost at collision detection here. not really any idea how to work it. im new to this 3d world of programming.

i can figure out how to do bounding box collision on 3d objects, not to hard, but how would i incorperate this idea of time in this? such as my question of the bullet flyijng through a thin wall, or a single polygon?

[lubby]

Ok its quite easy really on one hand.. and can get very complicated on another..

1 simple way to do it , although not the most efficient. Using a rocket as an example here seems its a fairly slow weapon

Every frame update your rockets position you should have current_pos and new_pos.

_ newpos = currentpos + speed * time _ (dont forget direction in this equation - use vectors)

Do a line interection test with your geometry every frame using current/new pos. If your line starts on one side of a walls plane and ends on the others you have a definate collision. This is a basic way of course you will then want to find an exact point of collsion but thats going way out of scope here.


For instant weapons, shotgun/machinegun etc (also works with slow weapons)

You will need to trace a line through your geometry and find the point of first collision with an objects plane. this results in an exact point of collision you can then fire your weap and let it go uninterupted until it reaches this point. then explode it/hit wall or whatnot. Dont forget check collision against enemies as well if using slow weaps, again you can check this instantly before hand.

There a lot more to this than i can possibly write down here do a search around on the web you will find much information that will go into this with a lot more detail.

gluck!