Register    Login    Forum    Search    FAQ

Board index » Everything




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post Posted: February 29th, 2012, 9:59 pm 
 

Joined: February 26th, 2012, 12:08 pm
Posts: 23
Hi there Chilli my man! Hello everyone!
I have a doubt concerning the little game i´m developing using Chillis frame... It´s a shamefull version of Pacman.
My doubt is this: how to draw borders and static obstacles without loading them everytime frame refreshes?
The thing is that my game becames very slow when he has to build that ton of border and obstacles pixels.
Since they are static all the way is there some way to load an image to make the borders or something?
Resuming: pacman controled by player runs perfectly well when the borders and obstacles are not loaded into frame... When they are load into the frame the pacman runs slower than before.

Ps: sorry for my bad english.

Cheers people!!


Top 
 Profile  
Reply with quote  
 Post Posted: March 1st, 2012, 2:06 am 
Site Admin
User avatar

Joined: December 31st, 2011, 4:53 pm
Posts: 3448
Location: Japan
Hey luskas:

I think it's awesome that you're trying to make a game on your own initiative! There are some things I want to tell you, but I'm at work right now so it will have to wait. I can definately help you out there bro, so just wait bit 8-)

_________________
Chili


Top 
 Profile  
Reply with quote  
 Post Posted: March 1st, 2012, 1:58 pm 
Site Admin
User avatar

Joined: December 31st, 2011, 4:53 pm
Posts: 3448
Location: Japan
Okay, first thing: some semantics. I think you're confusing a technical term here so I want to make absolutely sure that we're on the same page.

luskas wrote:
pacman controled by player runs perfectly well when the borders and obstacles are not loaded into frame... When they are load into the frame the pacman runs slower than before.


Loading some graphic generally means opening a file on the harddisk and reading it into memory. What you want to say here I believe is "drawing", "rendering", or possibly "blitting". We'll go with "drawing" for now.

Now, your idea of not redrawing the static elements of your game scene every frame is not without merit. In fact, back in the good old days when drawing to screen took forever, that is exactly how they did it.

Today however, drawing has become a lot faster and so nobody goes through the trouble anymore of saving the unchanged parts of the frame and only redrawing what has moved. For one thing, in a 3D game the whole scene generally changes every single frame, so that approach isn't even an option.

So that leaves us with one problem: if todays hardware is so fast that we can redraw all the pixels on the screen (800x600) many many times over in a refresh period (frame), why is your game stalling?

The answer is that the current PutPixel() function is excruciatingly slow. But don't worry, we can fix that! In fact, it was my plan to go over revamping PutPixel() either in Lesson 13 or Lesson 14, but since you have a need of it, I will show you right here how to speed up PutPixel() by a factor of over 50 (I haven't actually measured it, but once you change the code as I will show you below, it will get a fucksauce lot of faster bro! 8-))

Here's what you do:

1st-> Change D3DGraphics.h so that the end looks like this:
Code:
private:
   IDirect3D9*   pDirect3D;
   IDirect3DDevice9*   pDevice;   
   IDirect3DSurface9*   pBackBuffer;
   D3DLOCKED_RECT   rect;
};


2nd-> Change the beginning of D3DGraphics::D3DGraphics in D3DGraphics.cpp:
Code:
D3DGraphics::D3DGraphics( HWND hWnd )
: pBackBuffer( NULL )
{


3rd-> Replace PutPixel(), BeginFrame(), and EndFrame() in D3DGraphics.cpp with this:
Code:
void D3DGraphics::PutPixel( int x,int y,int r,int g,int b )
{
   ((D3DCOLOR*)rect.pBits)[ x + (rect.Pitch >> 2) * y ] = D3DCOLOR_XRGB( r,g,b );
}

void D3DGraphics::BeginFrame()
{
   pDevice->Clear( 0,NULL,D3DCLEAR_TARGET,D3DCOLOR_XRGB(0,0,0),0.0f,0 );
   pDevice->GetBackBuffer( 0,0,D3DBACKBUFFER_TYPE_MONO,&pBackBuffer );
   pBackBuffer->LockRect( &rect,NULL,NULL );
}

void D3DGraphics::EndFrame()
{
   pBackBuffer->UnlockRect();
   pBackBuffer->Release();
   pBackBuffer = NULL;
   pDevice->Present( NULL,NULL,NULL,NULL );
}


Do this stuff and you'll be flyin' bro! 8-)

And zip up your project and post it when you're done!

_________________
Chili


Top 
 Profile  
Reply with quote  
 Post Posted: March 1st, 2012, 2:44 pm 
 

Joined: February 26th, 2012, 12:08 pm
Posts: 23
Man i can´t thank you enough for the help you´re giving us... In fact i was wondering what motivates people to share the knowledge learned by so many years of study and self learning.
I´ve been around tutorials for some time and never been so interested in game programming like right now... And that thanks to you bro.
So i thank you for keep bearing with us noobies and for the quick response to my question.
I will be home afternoon to try this one out... I will update in few hours. Then i will zip and post what i have so far...
Once again THANK YOU and sorry for my bad english. :)

Cheers!


Top 
 Profile  
Reply with quote  
 Post Posted: March 1st, 2012, 7:03 pm 
 

Joined: February 26th, 2012, 12:08 pm
Posts: 23
Oh-oh!! Now we´re talking :)... Way lot faster dude! Well i was reading on other tutorials about directx on c++. I came across the so called backbuffer... Maybe later you could talk about that stuff :).
For now it´s awesome the support you gave us so far and i´ll be waiting for your next video.
Meanwhile i will advance in my program to post here later.
See ya soon my friend!

Thanks!


Top 
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
 
Post new topic Reply to topic  [ 5 posts ] 

Board index » Everything


 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for: