Further upgrading put pixel.

The Partridge Family were neither partridges nor a family. Discuss.
NaturalDemon
Posts: 97
Joined: October 28th, 2012, 8:28 pm

Re: Further upgrading put pixel.

Post by NaturalDemon » December 15th, 2012, 5:02 pm

p.s. i used ...

Code: Select all

void D3DGraphics::DrawDisc( int cx,int cy,int r,int rd,int g,int b )
{
	for( int x = cx - r; x < cx + r; x++ )
	{
		for( int y = cy - r; y < cy + r; y++ )
		{
			if( sqrt( (float)( (x - cx)*(x - cx) + (y - cy)*(y - cy) ) ) < r )
			{
				PutPixel( x,y,rd,g,b );
			}
		}
	}
}

12 ... 50px radius circular objects on a total black background and it was boggin slower.
would casting to D3DCOLOR be faster instead of using 3 seperate values?

cameron
Posts: 794
Joined: June 26th, 2012, 5:38 pm
Location: USA

Re: Further upgrading put pixel.

Post by cameron » December 15th, 2012, 6:31 pm

You do make a good point however. My main problem is I'm drawing lots of stuff on top of each other which is drawing more then it should. I need to find a way around that without a test( if statement).
Computer too slow? Consider running a VM on your toaster.

NaturalDemon
Posts: 97
Joined: October 28th, 2012, 8:28 pm

Re: Further upgrading put pixel.

Post by NaturalDemon » December 16th, 2012, 2:43 am

oh ... i need to mention ...

my gues is ...
to apply real world math ... is to sync the render proces to refreshrate of the grafixcard.
recently i read about the Hobbit using a high frame rate of 48 frames a second.

there is so much the read on ... and so limited time ...
but basicly ... rendering ... on 70mhz (normal monitor refresh rate)....
1000 miliseconds / 70 mhz(frames) = 14,28571428571429 miliseconds.

so you have about 14 milisecond to render 1 frame and present it.
(that a topic ... i still need answer on)

oh .... besides ....
remember this ...
http://msdn.microsoft.com/en-us/library ... s.85).aspx
(i showed you in you acces class question thread, but apperently the link is broken and fixed)

Code: Select all

DWORD WINAPI MyThreadFunction( LPVOID lpParam ) 
{ 
 .
..
...
} 
the threaded function returns a DWORD ... it probably can retun any other type ...

just past this function in your code and change DWORD to anything you want .... strip out the exces / add the missing essential stuff ... the stuff visual studio complains about and do some experiments ...
you can also put a copy of the putpixel(....) inside the threaded function. using a dualcore optimal : ) or 2 x 14 ms
async .... sofar i encountered no problems with sync problems ... (acces/mod the same varaibles by 2 different "objects") and i have a intel q9450.

Code: Select all

Game.h
.
..
...
void Game::StartMyThread(int x, int y, int r, int g, int b),
D3DCOLOR WINAPI Game::MyThreadFunction( LPVOID lpParam );
private:
    PMYDATA pData;
    DWORD   dwThreadId;
    HANDLE  hThread;

   typedef struct MyData {
       int r, g, b, x, y;
   } MYDATA, *PMYDATA;


Game.ccp

void Game::StartMyThread(int x, int y, int r, int g, int b)
{
    pData = (PMYDATA) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
                sizeof(MYDATA)); 
        if( pData == NULL )
        {
           // If the array allocation fails, the system is out of memory
           // so there is no point in trying to print an error message.
           // Just terminate execution.
            return; // error
        }

        // Generate unique data for each thread to work with.

        pData->r = r;
        pData->g = g;
        pData->b = b; 

        pData->x = x;
        pData->y = y;

        // Create the thread to begin execution on its own.

        hThread = CreateThread( 
            NULL,                   // default security attributes
            0,                      // use default stack size  
            MyThreadFunction,       // thread function name
            pData,          // argument to thread function 
            0,                      // use default creation flags 
            &dwThreadId);   // returns the thread identifier 


        // Check the return value for success.
        // If CreateThread fails, terminate execution. 
        // This will automatically clean up threads and memory. 

        if (hThread == NULL) 
        {
           // error
          return; // error
        }

    // # this stuff till has to be adapted to your need and another location i.e: destructor
    // Wait until all threads have terminated.
    // WaitForMultipleObjects(MAX_THREADS, hThread, TRUE, INFINITE);
    //
    // Close all thread handle and free memory allocations.
    //    CloseHandle(hThread);
    //    if(pData != NULL)
    //     {
    //       HeapFree(GetProcessHeap(), 0, pData);
    //       pData = NULL;    // Ensure address is not reused.
    //   }
}

D3DCOLOR WINAPI Game::MyThreadFunction( LPVOID lpParam )
[
PMYDATA pData; // local version
...
..
.
// Cast the parameter to the correct data type.
    // The pointer is known to be valid because 
    // it was checked for NULL before the thread was created.
 
    pData = (PMYDATA)lpParam;
...
..
.
D3DCOLOR c = new D3DCOLOR(
                  pData->r, 
                  pData->g, 
                  pData->b);

return c;
// or ...
// pSysBuffer[ pData->x  + SCREENWIDTH * pData->y ] = c;
}
just add this to your project ...
it's loosely typed ... but i think ... it should compile or be easy to fix

if you should use this stuff and encounter sync problems in the future .. you need to put a mutex/lock on the variables you want to change and prevent other threads from modding it while you are working on it.

User avatar
chili
Site Admin
Posts: 3948
Joined: December 31st, 2011, 4:53 pm
Location: Japan
Contact:

Re: Further upgrading put pixel.

Post by chili » December 16th, 2012, 3:18 am

Okay, some things I wanna add or clarify.

1. the assert() lines are resolve to empty statements in release, so no slowdown there.
2. testing to see if the sprite is outside of the window is a good start if you're making a game that supports scrolling etc., but
3. if the sprite is partially out of the window, you should not then resort to testing every single pixel drawn; you should then recalculate the coordinates to draw to and from on the destination and source and then copy as usual; testing for every pixel is slow
4. there are two more ways I can think of the significantly speed up the drawing of sprites: SSE2 and multithreading; I have implemented an SSE2 blitter and it is considerably faster and also has the advantage of supporting alpha blending by default. I'm not sure about multithreading; it would probably depend on the memory archietecture of you system as to whether you would see any performace there.
5. You could probably beat or come close to the optimum CPU performance by using the 3D pipeline to draw sprites (and it would free up the CPU to do other work). We will be doing this eventually.

6. With the current version of sprite drawing and putpixel, you should be able to draw thousands of average-sized sprites... what exactly are you doing? You might be looking at the wrong place to solve your performace issues if you have any.
Chili

cameron
Posts: 794
Joined: June 26th, 2012, 5:38 pm
Location: USA

Re: Further upgrading put pixel.

Post by cameron » December 16th, 2012, 4:08 pm

Thanks chili. Soon i would like to use a SSE2 blitter to draw sprites.
Computer too slow? Consider running a VM on your toaster.

cameron
Posts: 794
Joined: June 26th, 2012, 5:38 pm
Location: USA

Re: Further upgrading put pixel.

Post by cameron » December 16th, 2012, 4:10 pm

Will we ever be making an SSE2 blitter in the tuts?
Computer too slow? Consider running a VM on your toaster.

NaturalDemon
Posts: 97
Joined: October 28th, 2012, 8:28 pm

Re: Further upgrading put pixel.

Post by NaturalDemon » December 16th, 2012, 4:30 pm

Did you view chili last video?

Maybe you should inherit from surface .... draw you oject and store a pointer to a D3DCOLOR surface or multiple surfaces .... instead if dynamicly drawing your object eacht frame ... i'm just brainstroming ..... but i'm sure this avoids a few loops and givrs more room for the data management ....

what thinks chili about timing the frames?
Is there a way to sync to the v-sync?
Render your frame while waiting on the next v-sync and present it.
How it's done ... broh?

p.s. i was reading on the psysics of sonic the hedgehawk(me owned a mega cd) ....
It would record data 16 frames back or something .... and i have tough about it usefullness and it's actualy done. too

NaturalDemon
Posts: 97
Joined: October 28th, 2012, 8:28 pm

Re: Further upgrading put pixel.

Post by NaturalDemon » December 16th, 2012, 5:05 pm

@Cameron

i rather would have a 6 hour video on linear math, the dotproduct, .... .
I would like know how to use angles, drag, air resistance, left/right hand draw, ... how to produce believeble motionss, that is what is keeping me busy ..

User avatar
LuX
Posts: 1492
Joined: April 22nd, 2012, 12:33 pm
Location: Finland

Re: Further upgrading put pixel.

Post by LuX » December 16th, 2012, 5:21 pm

A great way to speedup the pixel call would be to create a lookup table. This limits what you can do, but will make things a lot faster. To give an example, the tank game I'm working on uses a lot of arrays to check values that made it go at around 25-30 fps. After changing the game to use lookup values I got it back to an acceptable 16 ms/f, that is barely over 60 fps.

In all what I did is change my "valueArray [ 480000 ]" to "valueArray [ 800 ] [ 600 ]" Well, I needed to allocate it so actually "char** valueArray", but you get the idea. The thing is, this uses a lot more memory, but if you use the same size D3DCOLOR surfaces you could create an integer lookup table:

for ( int y = 0; y < 600 ... x = 0; x < 800 ) { lookup [x][y] = x + 800 * y; }

Now instead of having to calculate the location, you can simply look it up. Get the idea of this and you can fit it in your program nicely. Just remember it uses a lot of memory so keep the amount of lookup tables small.
ʕ •ᴥ•ʔ

User avatar
LuX
Posts: 1492
Joined: April 22nd, 2012, 12:33 pm
Location: Finland

Re: Further upgrading put pixel.

Post by LuX » December 16th, 2012, 5:26 pm

To add to the subject further, it really depends for what and where you need the pixels to be improved, because there's a ton of ways to make it a lot faster, but those only apply to certain ways, so you need to think the improvements as separate idea.

For example alpha pixels using SSE will make putting pixels faster, but won't help for normal pixels at all, if not make them even slower. Besides when we get to rendering pixels using the graphics card, drawing stuff will be less of a bottleneck.
ʕ •ᴥ•ʔ

Post Reply