World: r3wp

yes, but for the dimension aspect, specifically the largest accumulated 
edge, for example may accumulate errors.


when people start Adding up values and then multiplying them... I've 
had my share of headaches in 3D with this.

Advanced coders who are using more complicated algorithms must make 
adjustments anyway, so they can force the ceiling if needed.

But, yes, rounding is continuos where it matters the most and discontinuous 
where it matters the least

if I'm forced to use rounding on the rebol side very often, I think 
I'd rather have a tiny overhead in the native datatype that tries 
to stay integer until a result forces it. 

exactly like integer math which returns decimals when it must:

>> 4 / 2
== 2
>> 4 / 2.0
== 2.0
>>

and a new float-pair! datatype is complicated to support in addition 
to an integer pair?

Not really worth it. Would create even more problems.

it would really be nice if the datatype had a little state which 
allowed it to be integer or float and call appropriate math based 
on this... 

but I have no idea how this math is managed internally, so cannot 
easily grasp how complex or how this would affect speed.

it might also complicate the extension part of things I guess.

clearly

perhaps just doing a simple round is best, as long as everyone knows 
that rule.


That sounds good to me. The ky point being that we know the rules. 
Simple ROUND may not be the best choice for graphics, but I'll defer 
to those with more experience in that area.

IMHO, there are two options: 1) require "integral" values (as Ladislav 
says) for certain things like make image! etc., producing an error 
when they are not, and let the user use ROUND; 2) always use floor 
or ceil or even round, but make sure people know (ie docs).

The ROUND option looks to have prevailed

Update: The go.r test code is now running properly in A101 with the 
fully converted PAIR datatype and changes to the AGG API to accept 
both pairs and gobs using float values.


It turns out that because AGG wants floats for most spatial values 
anyway, the PAIR change makes the code smaller and faster.


Certainly more can be done to minimize the interface to AGG now (removing 
the double trampoline within the API) but that's a project for Cyphre 
when he returns from the islands ;)

In addition, I should note that all functions that require integral 
PAIR! fields now perform an internal round to "snap" them to nearest 
integers.  This applies not just to things like image size specs, 
but also to values like image pixel index pairs (something we support, 
but not often done, AFAIK)

The biggest issue in this PAIR change is that of comparison... such 
as in equality and zero tests. I plan to make the same rules apply 
as those for DECIMAL! -- but this will require more design work.

For example, a pair may have a value that is *almost* zero, but not 
*really* zero.  "You know the drill."

Thanks Carl.
Though for AGG, I don't expect a lot (in term of speed gain).

IMHO, the main overhead comes from the involved arithmetic using 
floating point decimals.
Matrix computations are costly with floating numbers.

But The final rasterization uses fixed point decimals and floats 
could have been avoided, i guess.
So maybe there is a major room improvement here.

Round half up, round half out, round half even, or round half odd?

Carl you have a point there ... pair! are used mostly related to 
VID ....  and as pairs in fact represents a pixel matrix you have 
dot something  numbers

CARL ONE ASK CAN AGG   BE MERGED WITH AMD/ATI OPEN CL Technology 
? ( some thing like a background application that would detect what 
hardware you have and use multi hardware CPUs GPUs to run those expensive 
task. Once again  what in rebol can be an very expensive task .... 
answer a state of art webbrowser rendering engine with flash silverlight 
support....  IF we can bring rebol to that state i think no one will 
look at it as a toy ... then the question is way doing a webbrowser 
in rebol ?  REply is because i love rebol :). But on a ground level 
if you want to enter in competition with the other languages and 
prove the interrest of the rebol method then you have to be able 
to do what the others can do )


This open CL adition can too benefits non graphical applications 
i don't know how but  why not saying look rbeol is not dead it's 
the futur and as the futur it provides the best way to use the futurs 
technology. And that's a field none of hte interpreted languages 
now in day have done ...

one last request i'm almost blind can someone make this font bigger 
 thank you ...

Shadwolf, Little Red Riding Hood remarked that the grandmother's 
eyes were very big!

Steeve Matrix are costly in computations only if you do it with a 
CPU not designed on purpose to do those kind of tasks.... But with 
a GPU it's EASY CAKE ...Question is can we be hardware ignorant or 
not ?

Grahma hum ... getoff the didguise you pervert !!!

(the font is so small i don't see what i'm writing and my glass are 
just renewed ... the Font 6px SUX ....

You can print to html and then enlarge it there

graham i can use a software grow lens  too  .... BUT the better way 
is to have the font in 14 px like in any civilised software :)

problem is i'm not sure rebol 2.3.2.15  from decembre 2005 is the 
best rebol VM for altme ...  2005 ....  TWO  THOUSAND AND FIVE !!!

since then a lot have been done altme could use a agg rendering method 
insteas of a VID face concatenation etc...

the thing i love in  viva-rebol.r is that you can grow and skrink 
the texts at light speed

viva-rebol.r is a R2 project isn't it?

when you have a rebol 2005 below alte me the message is  ---> ALTME 
wasn't enhanced since at least 5 years i'm a very buzy man and anyway 
i don't give a damn if people use it or not ...

graham yes but viva-rebol would be such a nice kid with his brand 
new open CL powers :)

Altme has been enhanced a few times recently

Are you using an old version??

no ... but it's still microcopic font size  good if you have 10/10 
 on both eyes bad if you have -7,25 /10 an -6,75/10 on both eyes

CARL what about -12.244x-12.21 matrix don't negative floating  numbers 
deserves their own pair! too ? ( if we are loosin time in stupidity 
why not playing to game to the core ?)

i see what a pixel is  i don't see what half a pixel could be ... 
and the reason is be able to see  those half pixels i would need 
a screen that can display when and eyes that can render them to my 
brain wich will never ever be the case in this life ... So personnally 
Carl i wouldn't be sad is matrix are rounded.

CPU are not feated with matrix computations because the industry 
decided that matrix area was such a big thing that they needed a 
spécific library and a specific hadware extensivly optimised to perform 
those computations. and so the GPU accellerated enhanced for opengl 
and DirectX is born.... Now in day the industry use most likely the 
DirectX because  well 90% of the personal computers are windows and 
that 100% of them support DX so 100% of the sold PC games are done 
that way... And that allow to cut cost when another company like 
unreal tech for example make a game engine you buy it and you save 
alot of time and monney the only thing you will have to do then is 
to create the specific IHM for your game and all the visual /audio 
content. then your project  time spent is shorted by 2 or 3 years...

since unreal shows you can do blasting High definition photorealistic 
close to the perfection 3d real time rendering engine with DirectX 
then the other will say ok we need our own DX engine cause DX is 
the only one able to do this ... Then you have the GPU founders that 
will say ok since the game industry wants and need DX then we will 
enclose in our harware GPU alot of  optimisations for DX ... or even 
the next DX version noone use now in day .. buuuuut we will be ready 
!

AGG is not the best place to put OpenCL support. OpenCL is not very 
useful for accelerating graphics, and that is what AGG would need. 
A standalone OpenCL dialect would be more useful. Graphics acceleration 
uses other APIs, like OpenGL or Direct2D. AGG isn't 3D, so using 
OpenGL or Direct3D would be equivalent to reimplementing Direct2D 
on platforms that don't support it.

If the standalone OpenCL dialect was also translatable to CUDA it 
would be even better :)

Or maybe DirectCompute on Win7/Vista.

Brianh hum actually when i we display things using agg the cu is 
used only and if we want to do extensive computing visual effects 
like zoom spining things etc ... hten the cpu will be extensively 
used ... and since rebol doesn"t take advantage of  multi CPU  or 
CPU <- to ->GPU communication then the extensive computation loops 
are not enhanced. Problem is now in day NVIDIA is so expensiv no 
one buy it  10 ATi cards are sold for 1 nvidia card and in a very 
near future AMD CPU will be mixed with ATI GPU  into a single chip 
(APU fusion). This is the tendency of the computing area so if you 
have to support 1 paralelle design i would go for the AMD /ATI  couple 
instead of  betting on a close to death horse...

As for seeing a partial pixel, the writer of AGG demonstrated (in 
an unrelated post) using anti-aliasing to do 1/256 horizontal pixel 
positioning.

but yes brianh you got the point when you relay on hardware then 
you have to choose what technology you support i know rebol main 
target is to be hardware / OS / driver abstracted .. but then you 
have a toy language anyone laught about that  can't bring anyway 
the same thing on every OS computer a part some very basic features 
like networking, encryption etc...

The semantics for a GPGPU dialect in REBOL would likely be pretty 
high-level, and could be translatable to different GPUs by using 
different compiler backends. It's not necessarily a good idea to 
bet it all on one horse when you can support them all just by being 
a bit general. We wouldn't have to do major tweaking for a specific 
GPU architecture, since the level of speedup would be great for even 
a half-assed translation.

It's not a toy language, it's a high-level language. The compiler 
would handle the details. That is like calling C a toy language.

BrianH probleme is  rebol doesn"t tends to relay on a spécific thing 
or another it's phylosophy is to be an easy way to do easyly easy 
things ... when you want to get your self out of that scope you are 
 facing hella difficulties  why should i code 99% of a project in 
C and then do a  dialect to do the last 1% of rebol action code

Um, you must not be working on the same things I am. I do tough stuff 
in pure REBOL quite often. The only C I see is there to implement 
low-level dialects used by REBOL, but those aren't as often needed 
as DO or PARSE dialect code.