PureBasic Forums - English

why do

StartDrawing(SpriteOutput(#sprite_fond))
Box(0,0,EcranX,EcranY,RGB(0,0,0))
StopDrawing()

and not :

StartDrawing_Sprite(#sprite_fond)
Box(0,0,EcranX,EcranY,RGB(0,0,0))
StopDrawing()

StartDrawing_screen(#sprite_fond)
Box(0,0,EcranX,EcranY,RGB(0,0,0))
StopDrawing()

why do

CreateSprite(#fourmi, 8, 16,#PB_Sprite_Texture)

StartDrawing(SpriteOutput(#fourmi))
Box(2,0,4,16, RGB($D6,$74,$3F))
StopDrawing()

CreateSprite3D(#fourmi3D, #fourmi)

and not :

CreateSprite(#fourmi, 8, 16,#PB_Sprite_Texture, 3D) ;

StartDrawing(SpriteOutput(#fourmi))
Box(2,0,4,16, RGB($D6,$74,$3F))
StopDrawing()

just a flag to turn a sprite in 3D

etc ...


and I do not initsprite, start3D, stop3D, no need for the user
as related to the functions used!

I mean, it is obvious that using 'CreateSprite3D'
I request the initialisation of the 3D



these functions adds weight to the language for nothing


this is my opinion

> these functions adds weight to the language for nothing

nope.

1)

StartDrawing starts the access to a drawing output channel by its handle.
this handle could be delivered by any PB internal function to return such a handle,
but you can use ANY handle that represents a drawable output,
like the DeviceContext of any WindowElement you can request from the OS.

why put a dozent additional function names there, when you still need StartDrawing( OutputHandle ) to provide full functionality?


2)

A Sprite3D is a 3D object that has four vertices and a texture connected with it.
A Sprite is a bitmap, can be used as a texture when present in the GraRAM.

It is not possible to Draw on a Sprite3D, because this Object has no bitmap, just a pointer to a bitmap.

additionally, you can create many Sprite3D out of the same texture and let them
all have different rotations and sizes without influencing each other.


3)

Start/Stop of any functionallity are seperated functions because they need relatively much time.
it's best for the Programmer to have full control over it when to call it and how often.


4)

the initialisation is only needed once.
testing on every command if the init already was fulfilled would significantly slowing down the functionality.

you may want to display thousands of sprites in the same frame.
if each command tested if the environment was initiated, you could NEVER manage this.


so, my opinion:
it feels good to know what is done and when.
It maybe oldskool, but I like it.

have all the control is in effect an explanation

but I find it a little heavy

"control" isn't the main argument, it's "performance".

imagine how mofo sloooooooooooooooooooow it would be,
if every command was wrapped into it's own start/stop...

It makes the language more modular. If you want the extra fluff you can write those functions yourself.