Dark Bit Factory & Gravity

PROGRAMMING => Freebasic => Topic started by: Clyde on May 09, 2006

Title: Feeding Pixels
Post by: Clyde on May 09, 2006
What are your thought on sending pixels to a buffer for screen rendering?

At present I am using a subroutine call to send positions and colours to, but is it best to be plotting directly to the buffer without the need for a seperate sub? Is there any real advantage, or merly personal preference?

Just curious,
Clyde.
Title: Re: Feeding Pixels
Post by: Rbz on May 10, 2006
IMHO, this just a personal preference, for FB code, there's no speed improvement.
Title: Re: Feeding Pixels
Post by: Clyde on May 10, 2006
I see, it's purely coders choice. :p

Cheers,
Clyde.
Title: Re: Feeding Pixels
Post by: Stonemonkey on May 10, 2006
Taking it down to assembly or machine code there are a few extra instructions when calling a function or sub which will slow things down a bit when there's a lot of pixel writing and reading.
One thing that can be done (there's a lot more that can be done though) is to use #define, it's just the same as writing the code inline (as opposed to using subs/funcs) but a little neater.

Code: [Select]
#define writepixel(x,y,argb) screen_buffer(x+y*wwidth)=argb
#define readpixel(x,y) screen_buffer(x+y*wwidth)

dim shared as integer wwidth,height
wwidth=640
height=480
dim shared screen_buffer(0 to wwidth*height-1) as integer

sub main
  Â  
  Â  writepixel(100,100,&hff00ff)
  Â  
  Â  print hex$(readpixel(100,100))
  Â  
end sub

main
sleep

instead of calling the function each time the code will be inserted from the #define

EDIT: and you'll need to add tiny_ptc to actually see anything.
Title: Re: Feeding Pixels
Post by: Clyde on May 10, 2006
Thankyou so much for the info there Stonemonkey.
Never used a define before, and real handy to know.

Will try this out in the morning. Wicked.

Cheers man,
Clyde.
Title: Re: Feeding Pixels
Post by: Clyde on May 10, 2006
Ok, about to try the define approach.

Firstly a question, is that in replace of a sub / function call?
Just that I've not touched defines before.

Cheers,
Clyde.
Title: Re: Feeding Pixels
Post by: Stonemonkey on May 10, 2006
with the following define at the start of your code:

#define writepixel(x,y,argb) screen_buffer(x+y*wwidth)=argb

at any point in the code where you have:

writepixel(x,y,argb)         'where x,y and argb can be variables or values or whatever

it is replaced by:

screen_buffer(x+y*wwidth)=argb

before it's sent to the compiler.
Title: Re: Feeding Pixels
Post by: Clyde on May 10, 2006
Thanks mate.

So no need to bother with declaring any subs / funcs,  just use the define in place ofr?

Cheers,
Clyde.
Title: Re: Feeding Pixels
Post by: Stonemonkey on May 10, 2006
No problem clyde. Another thing you could do is to use pointers. A pointer contains a memory address and if you've used tiny_ptc then you'll already have used a pointer:

ptc_update @screen_buffer(0)

@screen_buffer(0) points to the first element of the buffer array (tells tiny_ptc what memory address your screen buffer starts at so it knows what data to copy to the graphics card)

but you can use your own pointers for doing other stuff like:

dim pixel_pointer as integer pointer

pixel_pointer=@screen_buffer(0)+(x+y*wwidth)
or
pixel_pointer=@screen_buffer(x+y*wwidth)

will store the address of a particular pixel in pixel_pointer and you can read/write data using

*pixel_pointer=argb  Â 'to write

argb=*pixel_pointer  Â 'to read

and you can move on to the next pixel just by:

pixel_pointer+=1Â  'this actually adds 4 to the value in pixel_pointer, pointer arithmetic is taken care of by the compiler and since an integer uses 4 bytes then 4 has to be added for it to point to the next integer.

which is useful for when rasterising triangles or sprites and anything else that involves moving across lines of pixels as you don't have to keep recalculating for each pixel.

Don't worry too much if you don't follow this straight away clyde as it can take a bit of time to get used to but i thought i'd post this as it might be of use to some and is also part of the reason for avoiding subs or functions for filling individual pixels.
Title: Re: Feeding Pixels
Post by: Clyde on May 10, 2006
Much appreciated and thanks very much dude.
Title: Re: Feeding Pixels
Post by: Clyde on May 11, 2006
Having slight bother with this at the moment, everything's appearing on the top line of the screen.

Code: [Select]
Const XRES=640
Const YRES=480

Dim Shared ScreenBuffer( XRES*YRES)

#define FeedPixels(x,y,argb) Screenbuffer(y*XRES+x)=argb


I also tried putting FeedPixels(buffer(),x,y,argb) Buffer(y*XRES+x)=argb. It didnt go down too well with compiling.
 
Title: Re: Feeding Pixels
Post by: Stonemonkey on May 11, 2006
I just tried this and it seems to work ok

Code: [Select]
option explicit

#define PTC_WIN
#Include Once "tinyptc.bi"

Const XRES=640
Const YRES=480

Dim Shared ScreenBuffer( XRES*YRES)

#define FeedPixels(x,y,argb) Screenbuffer(y*XRES+x)=argb

If(ptc_open("test",xres,yres)=0) Then
End -1
End If

dim as integer x,y

do
  Â  for y=50 to 100
  Â  Â  Â  for x=50 to 100
  Â  Â  Â  Â  Â  feedpixels(x,y,&hff00ff)
  Â  Â  Â  next
  Â  next
  Â  ptc_update @screenbuffer(0)
LOOP UNTIL INKEY$<>""

ptc_close
end

Title: Re: Feeding Pixels
Post by: Clyde on May 11, 2006
Smart and Cheers Stonemonkey mate. Dont know what I pigged up.

Thankyou,
Clyde.