FreeBASIC Games Directory Forum
 Welcome, Guest. Please login or register. May 18, 2013, 06:16:42 PM 1 Hour 1 Day 1 Week 1 Month Forever Login with username, password and session length 11.5.2013 - Added a webpage for the latest FBGD competition.13.3.2013 - Members registrations temporary disabled. For all membership requests, please email me: lachie13@yahoo.com 30.11.2012 - The ninth issue of BASIC Gaming is out! Read it here: http://games.freebasic.net/forum/index.php?topic=560.022.11.2012 - Be sure to check our currently running annual FBGD game making competition. This year's theme is SEASONS OF THE YEAR, 300 \$ first place prize, and the competition runs till 18th of February. Link: http://games.freebasic.net/forum/index.php?topic=559.0

Pages: 1 2 [3]
 Author Topic: Efficient pixel drawing?  (Read 2399 times)
Brick Break
Forum Sage

Gender:
Posts: 412

 « Reply #30 on: July 16, 2010, 07:47:49 PM »

Quote
Quote
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.
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.
 Logged

Brick Break
Forum Sage

Gender:
Posts: 412

 « Reply #31 on: July 16, 2010, 08:58:39 PM »

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:
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?
 « Last Edit: July 16, 2010, 09:00:39 PM by Brick Break » Logged

Mitchell
Forum Howler

Gender:
Posts: 172

Rockin Geek

 « Reply #32 on: July 16, 2010, 11:34:17 PM »

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:
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.
 Logged

Never underestimate the destructive powers of somebody doing something new without having any clue of how to do it.
Brick Break
Forum Sage

Gender:
Posts: 412

 « Reply #33 on: July 16, 2010, 11:42:57 PM »

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:
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.
 « Last Edit: July 16, 2010, 11:45:29 PM by Brick Break » Logged

Brick Break
Forum Sage

Gender:
Posts: 412

 « Reply #34 on: July 17, 2010, 12:12:10 AM »

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

 Logged

Pages: 1 2 [3]