Efficient pixel drawing?

[Brick Break]

Do you mean multiplying the color values of all pixels by a constant?

I mean how would you avoid multiplying by 4? It costs processing time.

 
I'll rewrite the drawPixel sub so you don't need to multiply by 4, but trust me, integer multiplication is the least of your performance concerns. Operations of data on the processor are extremely fast.

ETA: I haven't tested it, but here's what I got. I knew I could shave a line somewhere.

Code: Select All | Copy To Clipboard

sub drawPixel(x as integer, y as integer, c as uinteger)
/' Note: this is the quick and dirty way to get the address
of the pixel. I hard coded in 4 since I'm using
32 bit (32 bit = 4 bytes) screen. This is definitely
not the proper way to do it. '/
dim as uinteger ptr puiPixel = cptr(uinteger ptr, screenPtr()) + (x + screenWidth*y)

' Draw to the pixel by setting it's value directly
*puiPixel = c
end sub

It works! No way! NO WAY! This is INSANE! All of my dreams have come true! Finally I can make my 3D rendering engine! This is amazing!

The next thing I'm going to do is make a quick pixel plotting demo that compares pcopy with lock/unlock.

[Brick Break]

Oh cool! I was able to simplify your code even further! Simply by assigning the buffer to screenptr() as a uinteger, I eliminated the need for cptr()! Now the function looks like this:

Code: Select All | Copy To Clipboard

public sub dot(byval x as integer,byval y as integer,byval c as uinteger)
dim as uinteger ptr puiPixel=screenWidth*y+x+sgfxPointer
*puiPixel=c
end sub

But something is still being multiplied in there. Is there any way to get rid of that?

[Mitchell]

Oh cool! I was able to simplify your code even further! Simply by assigning the buffer to screenptr() as a uinteger, I eliminated the need for cptr()! Now the function looks like this:

Code: Select All | Copy To Clipboard

public sub dot(byval x as integer,byval y as integer,byval c as uinteger)
dim as uinteger ptr puiPixel=screenWidth*y+x+sgfxPointer
*puiPixel=c
end sub

But something is still being multiplied in there. Is there any way to get rid of that?

Cool. No, there's no way to get rid of that multiplication. When converting from 2d (screen coordinates) to 1d (linear buffer stored in memory), there has to be multiplication somewhere. But don't worry, it's trivial. If you're going to make a 3d engine, there will be tons of multiplications, divisions, and other stuff.

If you're really worried, here's this little tidbit: multiplying a value in a cpu register is an order of magnitude *faster* than fetching a variable straight from RAM. Granted, your computer hardware works hard in the background to make sure the most important values in RAM are available on a cache so that there isn't a long wait, but still your cpu is fast. IIRC, a cache miss takes 200 cycles to get a variable. A generic operation in the processor takes about 5 cycles, although some operations are actually multiple operations. Still, division - which is one of the heavier on-chip operations - takes somewhere in the ballpark 40 cycles.

[Brick Break]

Oh cool! I was able to simplify your code even further! Simply by assigning the buffer to screenptr() as a uinteger, I eliminated the need for cptr()! Now the function looks like this:

Code: Select All | Copy To Clipboard

public sub dot(byval x as integer,byval y as integer,byval c as uinteger)
dim as uinteger ptr puiPixel=screenWidth*y+x+sgfxPointer
*puiPixel=c
end sub

But something is still being multiplied in there. Is there any way to get rid of that?

Cool. No, there's no way to get rid of that multiplication. When converting from 2d (screen coordinates) to 1d (linear buffer stored in memory), there has to be multiplication somewhere. But don't worry, it's trivial. If you're going to make a 3d engine, there will be tons of multiplications, divisions, and other stuff.

If you're really worried, here's this little tidbit: multiplying a value in a cpu register is an order of magnitude *faster* than fetching a variable straight from RAM. Granted, your computer hardware works hard in the background to make sure the most important values in RAM are available on a cache so that there isn't a long wait, but still your cpu is fast. IIRC, a cache miss takes 200 cycles to get a variable. A generic operation in the processor takes about 5 cycles, although some operations are actually multiple operations. Still, division - which is one of the heavier on-chip operations - takes somewhere in the ballpark 40 cycles.

Then how come some higher-level languages like javascript slow way down with a lot of division operations? In DarkBASIC, you can get a whole frame per second more if you simplify your addition operations. I like peace of mind, I can tell you that, and you are amazing, but I'm worried that if I'm overwriting the same pixel five times there will be a performance hit.

[Brick Break]

Disregard what I said for now. I'm sure it's trivial. Expect a demo of some basic features within a couple days.