Blitz bug or something else?

Archives Forums/Blitz3D Bug Reports/Blitz bug or something else?

furbrain

(Posted 2011) [#1]

Hi all, am having a strange problem with WritePixelFast. If I run the following code with the WritePixel command it works fine, however as soon as I change it to the `Fast` version I get a very strange output.

Instead of the yellow circle being drawn where it should be the 1st quarter of it is drawn in the top left hand corner of the screen, followed by the 2nd quarter in the top right of the screen. The the program quits with an "Memory Access Violation" error before drawing the remainder of the circle.

; Sin / Cos / Tan example. 


Const width = 800, height = 600 
Const radius# = .2 * height 
Const KEY_ESC = 1, KEY_LEFT = 203, KEY_RIGHT = 205 

Graphics width, height 
SetBuffer BackBuffer() 
Origin width / 3, height / 2 

angle# = 0.0 

For angle#=0.0 To 360.0 Step 0.5
	Cls 
	Color 80, 80, 0 ; pale yellow circle 
	Oval -radius, -radius, 2 * radius, 2 * radius, False 

	LockBuffer BackBuffer()

	For a# = 0.0 To Abs( angle Mod 360 ) Step .5 
		x# = radius * Cos( a ) ; (x,y) is a point on the circle 
		y# = radius * Sin( a ) ; corresponding to angle a. 
		If ( angle Mod 360 < 0 ) Then y = -y ; reverse for negative angle 
		WritePixel x, y, $ffff00 ; bright yellow 
	Next 

	UnlockBuffer BackBuffer()

	Color 255, 255, 0 ; yellow 
	Line 0, 0, radius * Cos( angle ), radius * Sin( angle ) 

	Color 0, 255, 0 ; green 
	Line 0, 0, radius * Cos( angle ), 0 
	Text radius * 1.5, 10, "Cos( angle ) = " + Cos( angle ) 

	Color 255, 0, 0 ; red 
	Line radius * Cos( angle ), 0, radius * Cos( angle ), radius * Sin( angle ) 
	Text radius * 1.5, -10, "Sin( angle ) = " + Sin( angle ) 

	Color 255, 255, 255 
	Text radius * 1.5, -30, " angle = " + angle 
	Text radius * 1.5, 30, "Tan( angle ) = " + Tan( angle ) 

	Flip 

Next

WaitKey()
End

I have a dual boot system with Win7 ultimate & XP pro, both 32bit, Nvidia 1gb 240GT PCIe gfx card & Core 2 Duo 2.13ghz cpu. All drivers are up to date as well as B3D v1.06. Does this happen on anybody elses system?.

I suspect gfx card/driver issue but am not prepared to plough thru previous drivers to find out as both systems are running perfectly as is. Any help is appreciated thanks :)

Yasha

(Posted 2011) [#2]

Note that, in order to simplify the code, rather than drawing the circle at an offset from zero, the setup simply moves the origin for all drawing operations to where it wants the centre of the circle (which as you can see affects the Line and Text commands). The coordinates to draw a pixel are given in the context of this shifted origin. WritePixel takes account of it; WritePixelFast does not.

This is probably intended behaviour rather than a bug - WritePixel is a drawing command intended to be used alongside other drawing commands, and lets you place a pixel in ARGB format for convenience. WritePixelFast on the other hand is supposed to be fast, so it would naturally ignore such things as origins and viewports and literally only set the specified buffer coordinates to the requested value - anything else is a waste of valuable CPU time in a command that's normally expected to be used in bulk.

What is a bug is that the documentation (or even the command name) doesn't draw this important distinction.

EDIT: Yeah, SLotman's explanation for the actual crash is correct - sorry, I'd assumed this was obvious and gone straight to addressing the position of the write operations.

Last edited 2011

SLotman

(Posted 2011) [#3]

		If x>0 And y>0 And x<width And y<height Then WritePixelFast x, y, $ffff00, BackBuffer() ; bright yellow

This will fix it. You were drawing outside of the backbuffer, which could be any memory area, so your program was crashing. The help page on WritePixelFast warns about that!

furbrain

(Posted 2011) [#4]

Thanks for your replies. Basically the code is just a slighty modified version of the sin etc example in the docs as i was just experimenting with what speed difference there was between the original plot version & writepixel/writepixelfast.

As i was not aware that the origin command does not affect writepixelfast command the output/error i was getting is pretty obvious now. Like you said Yasha the bug is indeed in the docs as origin states "This command sets a point of origin for all subsequent drawing commands. This can be positive or negative.", also there is no mention in the writepixelfast docs that it is not affected by the origin command.

basically to fix it now i know what was wrong is change the draw to

WritePixelFast (width/3)+x, (height/2)+y, $ffff00 ; bright yellow

& it outputs the same as the non fast version

furbrain

(Posted 2011) [#5]

Just to let you know that my amended version as well as SLotmans suggestion actually ran slower than the normal writepixel version. I presume that the extra code to plot the point in the correct position is the culprit. BTW i am talking only a few millisecs, i ran both with 50 iterations & the writepixelfast versions came in 100ms slower in total (not per iteration).

As a test to see raw throughput between writepixel & writepixelfast i just done a FOR..NEXT loop to fill an 800x600 screen which had interesting results. On win7 writepixel took 16ms while writepixelfast took 13ms while winxp took 19ms & 10ms respectively. Both where an average again over 50 iterations

Ross C

(Posted 2011) [#6]

I would try putting a 1000 ms delay right before going into your loop. Then, change your iteration to 1000 iterations, and then see the difference. You need to delay because of setup times and what not :)

furbrain

(Posted 2011) [#7]

Hi Ross, if you were refering to the original posted sin/cos/tan code i had a Delay 5000 inserted just before the start of the 1st For... loop just to make sure things had settled down etc, for example when i run a program it takes a sec or 2 for my AV to be happy that it not a virus :).

I might run a 1000 iteration next time i go shopping as believe me 50 took long enough lol, aound 11s per iteration :0.

Main thing is i got information i needed regarding the speed difference between the 2 commands & that there is a time & place for each one. Also that origin does not affect writepixelfast, so i learnt 2 things which is a nice bonus :)

Floyd

(Posted 2011) [#8]

I consider WritePixelFast ignoring Origin to be a bug. If it is an optimization then it is misguided. The simple arithmetic of adding an offset is so much faster than pixel drawing that any time saved is trivial.

And in practice it would probably be slower rather than faster. Origin is a convenience command, automatically adding an offset that would otherwise have to be done manually. If you are going to add an offset anyway why not let the compiler write the code. That should be faster that doing it yourself in the Blitz3D source.

furbrain

(Posted 2011) [#9]

Good point. Tbh i never use the origin command myself and wasn't really aware it even existed ^.^ , the code is just a very slightly modified version of the sin/cos/tan example from the docs i used it for a couple of reasons.
As it used the WritePixel command i thought i would see what difference the WritePixelFast made, and also what difference putting sin/cos/tan in a look-up table made.

Although there are other examples in the docs i could have played with it seems that i picked the right one otherwise i would not have learnt about the Origin command & its lack of use with WritePixelFast :)

I find it better playing/tinkering with other peoples code as i tend to learn & discover more about how it works etc than just reading the command ref page.

I have moved on now to the 3ddotball sample using Types instead of arrays, changing the way it colours the points etc. You can all relax as i will not be posting any bugs/problems with that lol