how use multithread inside a class?

Pages: 123
Cambalinho (1445)
cool i win more speed heres the change on clear():
1
2
3
4
5
6
7
8
9
10
11
12
13
 
void Clear(COLORREF BackColor = RGB(0,0,0))
    {
        /*RECT rec{0,0,ImageWidth,ImageHeight};
        HBRUSH HB = CreateSolidBrush(BackColor);
        FillRect(ImageHDC,&rec,HB);
        DeleteObject(HB);*/
        for(int i=0; i<int(sizeof(Pixels)/sizeof(LPBYTE)-3); i+=3)
        {
            Pixels[i+2]=GetRValue(BackColor);
            Pixels[i+1]=GetGValue(BackColor);
            Pixels[i+0]=GetBValue(BackColor);
        }
    }

i just test and i win speed ;)
now i can have ~70FPS
correct me: is normal the FPS been between 65-70FPS(5 or even 10 FPS) on same loop?
Last edited on
salem c (3700)
> for(int i=0; i<int(sizeof(Pixels)/sizeof(LPBYTE)-3); i+=3)
Pretty sure that your speed "improvement" is because you're not doing any work here.

Whether your Pixels is just a raw pointer or a std::vector (who knows, your mind changes with the weather), this whole sizeof expression is going to evaluate to a small number.

You're NOT clearing the whole array, so of course it's going to seem quicker.

Cambalinho (1445)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
 
class image
{
public:
    int ImageWidth = 0;
    int ImageHeight = 0;
    HDC ImageHDC = NULL;
    HBITMAP ImageBitmap;
    HBITMAP oldBit;
    BITMAP bmp;
    BITMAPINFO info;
    size_t pixelSize;
    size_t scanlineSize;
    size_t bitmapSize;
    void* p;
    LPBYTE Pixels;


    void Clear(COLORREF BackColor = RGB(0,0,0))
    {
        for(int i=0; i<int(sizeof(Pixels)/sizeof(LPBYTE)-3); i+=3)
        {
            Pixels[i+2]=GetRValue(BackColor);
            Pixels[i+1]=GetGValue(BackColor);
            Pixels[i+0]=GetBValue(BackColor);
        }
    }

    image(int Width, int Height, COLORREF BackColor=RGB(0,0,0))
    {
        ImageHDC = CreateCompatibleDC(NULL);
        ImageWidth = Width;
        ImageHeight =Height;

        ZeroMemory (&info, sizeof (BITMAPINFO));
        info.bmiHeader.biSize = sizeof(info.bmiHeader);
        info.bmiHeader.biWidth = ImageWidth;
        // pay attention to the sign, you most likely want a
        // top-down pixel array as it's easier to use
        info.bmiHeader.biHeight = -ImageHeight;
        info.bmiHeader.biPlanes = 1;
        info.bmiHeader.biBitCount = 32;
        info.bmiHeader.biCompression = BI_RGB;
        info.bmiHeader.biSizeImage = 0;
        info.bmiHeader.biXPelsPerMeter = 0;
        info.bmiHeader.biYPelsPerMeter = 0;
        info.bmiHeader.biClrUsed = 0;
        info.bmiHeader.biClrImportant = 0;

        // the following calculations work for 16/24/32 bits bitmaps
        // but assume a byte pixel array


        ImageBitmap = CreateDIBSection(ImageHDC, &info, DIB_RGB_COLORS, (LPVOID*)&Pixels, 0, 0);
        SelectObject(ImageHDC, ImageBitmap);
        pixelSize = info.bmiHeader.biBitCount / 8;
        // the + 3 ) & ~3 part is there to ensure that each
        // scan line is 4 byte aligned
        scanlineSize = (pixelSize * info.bmiHeader.biWidth + 3) & ~3;
        bitmapSize = bmp.bmHeight * scanlineSize;
        Clear(BackColor);
    }

and i get the right result than before
for every frame i call the clear()
Last edited on
Cambalinho (1445)
is there a function more faster than sqrt() from math.h?
helios (17574)
No. However, a lot of the time getting a square root is avoidable:
1
2
3
4
5
6
7
8
9
10
11
 
bool is_inside_the_circle(float center_x, float center_y, float radius, float point_x, float point_y){
    float x = point_x - center_x;
    float y = point_y - center_y;
    return sqrt(x * x + y * y) <= radius;
}

bool is_inside_the_circle_without_sqrt(float center_x, float center_y, float radius, float point_x, float point_y){
    float x = point_x - center_x;
    float y = point_y - center_y;
    return x * x + y * y <= radius * radius;
}


EDIT: There's also https://en.wikipedia.org/wiki/Fast_inverse_square_root and some people use lookup tables when they don't need too much precision.
Last edited on
Cambalinho (1445)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
float Q_rsqrt( float number )
{
	long i;
	float x2, y;
	const float threehalfs = 1.5F;

	x2 = number * 0.5F;
	y  = number;
	i  = * ( long * ) &y;                       // evil floating point bit level hacking
	i  = 0x5f3759df - ( i >> 1 );              
	y  = * ( float * ) &i;
	y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//	y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

	return y;
}

i don't get right results, maybe because i get these 2 warnings:
"warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]"
on line 9 and 11. honestly i don't know what to change here
Last edited on
helios (17574)
It's useful to actually read the article you're linked. Q_rsqrt() returns the reciprocal of the square root, not the square root.
Cambalinho (1445)
after more search i found more: https://www.codeproject.com/Articles/69941/Best-Square-Root-Method-Algorithm-Function-Precisi
i belive the:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
#define SQRT_MAGIC_F 0x5f3759df 
 float  sqrt2(const float x)
{
  const float xhalf = 0.5f*x;
 
  union // get bits for floating value
  {
    float x;
    int i;
  } u;
  u.x = x;
  u.i = SQRT_MAGIC_F - (u.i >> 1);  // gives initial guess y0
  return x*u.x*(1.5f - xhalf*u.x*u.x);// Newton step, repeating increases accuracy 
}

is much more stable than the others. the FPS count is more stable on ~70 and no less. the C++ sqrt() isn't so stable.
i'm trying, too, testing the Assembler test code:
1
2
3
4
5
6
7
 
double sqrt13(double n)
{
  __asm{
     fld n
     fsqrt
   }
}

1
2
3
4
5
6
 
double inline __declspec (naked) __fastcall sqrt14(double n)
{
	_asm fld qword ptr [esp+4]
	_asm fsqrt
	_asm ret 8
}

but aren't compatible with GNU and i don't know convert them :(
maybe they are more faster
coder777 (8444)
1
2
3
4
5
6
7
8
9
10
11
12
 
    LPBYTE Pixels;


    void Clear(COLORREF BackColor = RGB(0,0,0))
    {
        for(int i=0; i<int(sizeof(Pixels)/sizeof(LPBYTE)-3); i+=3)
        {
            Pixels[i+2]=GetRValue(BackColor);
            Pixels[i+1]=GetGValue(BackColor);
            Pixels[i+0]=GetBValue(BackColor);
        }
    }
and i get the right result than before
That's a mystery. What do you think is the result of sizeof(LPBYTE)/sizeof(LPBYTE)?

after more search i found more
Research is a good thing. Try search for 'line drawing algorithm'. Like this:

https://www.tutorialandexample.com/line-drawing-algorithm

You can separate the finding of the pixel position from the actual setting of the pixel color. Then threading can come into play.
You would need a deep understanding of what you are doing (you gain this by debugging/logging) but currently you refuse to do so...
salem c (3700)
> That's a mystery. What do you think is the result of sizeof(LPBYTE)/sizeof(LPBYTE)?
The OP only wants to hear words that comfort their world view - however deranged it is. I said the same 2 days ago, but they ignored it.

They claim 'success', because they didn't notice that a broken clear screen doesn't matter if you keep redrawing the same image over and over.

They latch onto junk magic like 'threads' and 'fast square root' as if that would transform their problem.
Then proceed to try to (ab)use a thread for every single pixel on screen.

They've been on this forum for 10 years now, yet seem no more capable than a 1-semester college student.

The entire exercise of getting high performance graphics out of Windows GDI is an exercise in https://www.urbandictionary.com/define.php?term=turd%20polishing

Cambalinho (1445)
honestly i can win much more speed.
and i have an ideia: do i need calculate the perspective on all line points or just origin and the destination points?
Last edited on
Cambalinho (1445)
i win more speed changing from(on DrawLine()):
float LineDistance =sqrt((DX * DX) + (DY * DY) + (DZ * DZ));
to:
float LineDistance =max({DX,DY,DZ});
'Bresenham in 3D': http://members.chello.at/easyfilter/bresenham.html
use the same method... ok i'm copying him ;)
i don't know the difference... but i win more speed maybe 5-10 FPS.
and change the Clear():
1
2
3
4
5
6
7
8
9
 
void Clear(COLORREF BackColor = RGB(0,0,0))
    {
        for(int i=0; i<bitmapSize; i+=3)
        {
            Pixels[i+2]=GetRValue(BackColor);
            Pixels[i+1]=GetGValue(BackColor);
            Pixels[i+0]=GetBValue(BackColor);
        }
    }

1
2
3
4
5
6
7
 
ImageBitmap = CreateDIBSection(ImageHDC, &info, DIB_RGB_COLORS, (LPVOID*)&Pixels, 0, 0);
        SelectObject(ImageHDC, ImageBitmap);
        pixelSize = info.bmiHeader.biBitCount / 8;
        // the + 3 ) & ~3 part is there to ensure that each
        // scan line is 4 byte aligned
        scanlineSize = (pixelSize * info.bmiHeader.biWidth + 3) & ~3;
        bitmapSize = bmp.bmHeight * scanlineSize;

i win more FPS.
i need a correction for win more speed: i just need calculate the perspective on Start and the End line positions or the entire line?
honestly i tryied without success :(
Last edited on
coder777 (8444)
i just need calculate the perspective on Start and the End line positions or the entire line?
You only need the perspective for start/end. However you still need to calculate the line (in 2d).

i tryied without success
What did you try?
Topic archived. No new replies allowed.
Pages: 123