Sunday, October 1, 2017

Digest for comp.lang.c++@googlegroups.com - 25 updates in 3 topics

asetofsymbols@gmail.com: Oct 01 02:33PM -0700

I don't know if this is right or even compile, now I see list as this:
#include <iostream.h>
 
#define u32 unsigned
#define i32 int
#define S sizeof
#define R return
#define F for
#define MM malloc
#define FF free
#define ooo cout
 
// Nodo generale rNode<T> di tipo T
template<class T> class rNode{
public:
T nd;
rNode* next;
};
 
//tList: Lista di rNode<T> di tipo T
template<class T> class rList{
public:
rNode<T>* pnd;
u32 sz;
//-----------------------------
 
//--- costruttori e distruttori
rList():pnd(0),sz(0){}
rList(T* p,u32 s)
{u32 i;
rNode<T>*v,*w;

pnd=0;sz=0;
if(p==0||s==0)
if(s){ooo<<"\nArgomenti del costruttore non buoni\n"; R;}
else R;
if((int)s<0)
{ooo<<"\nArgomenti del costruttore non buoni\n"; R;}
F(i=0;i<s;++i)
{if( (v=(rNode<T>*)MM(S(rNode<T>)))==0 )
{ooo<<"\nErrore memoria non sufficiente\n";
(*this).remove(0);R;
}
if(pnd==0){pnd=v; v->next=0;}
else {w=pnd;pnd=v;v->next=w;}
v->nd=p[s-i-1]; // array pushed reverse i=0=>s-1 ok; i=s-1 =>s-i-1=s-s+1-1=0 ok
++sz;
}
}
 
~rList()
{rNode<T>*p,*w;
F(p=pnd;p;p=w)
{w=p->next;FF(p);--sz;}
if(sz){ooo<<"\nErrore in size List\n";}
}
 
//--- funzione accesso array [per accedere all'elemento Lista[i] deve percorre i nodi della lista]
//se indice fuori del range >sz allora exit(1)
//se indice = sz allora alloca un nodo della lista, e aggiorna sz
T& operator[](i32 n)
{rNode<T>*v,*p,*w;
i32 i;
static T r;

if(n<0||n>sz){ooo<<"\nIndice Fuori range\n"; exit(1);R r;}
F(i=0,w=0,p=pnd;i<n&&p;++i,w=p,p=p->next);
if(p)R p->nd;
if( (v=(rNode<T>*)MM(S(rNode<T>)))==0 )
{ooo<<"\nElemento non creato \n";exit(1);R r;}
if(pnd==0){pnd=v;v->next=0;}
else {w->next=v;
v->next=0;
}
++sz;
R v->nd;
}
 
//--- funzioni elemento
void insert(T& e)
{rNode<T>*v,*p;
if( (v=(rNode<T>*)MM(S(rNode<T>)))==0 ){ooo<<"\nInsert Non Riuscito\n";R;}
if(pnd==0){pnd=v; v->next=0;}
else {p=pnd;pnd=v;v->next=p;}
v->nd=e; ++sz;
}
//--- lista.remove(0) --rimuove ogni elemento della lista
// lista.remove(&r) --rimuove salva in r l'elemento del nodo puntato da pnd
// elimina tale nodo dalla lista
int remove(T*r)
{rNode<T>*p,*w;
if(r==0) // cancell the list if r==0
{F(p=pnd;p;p=w)
{w=p->next;free(p);--sz;}
if(sz){ooo<<"\nErrore in size List\n";}
R 1;
}
if(pnd==0)R 0;
*r=pnd->nd;
p=pnd->next;
FF(pnd); --sz;
pnd=p;
R 1;
}

void print(void)
{rNode<T>*p;
ooo<<"[";
F(p=pnd;p;)
{ooo<<p->nd;
if(p=p->next)ooo<<", ";
}
ooo<<"] ";
}
 
// Operatori friend
// moltiplica due liste fino a che la size lo permette
friend T operator*(const rList& a, const rList& b)
{T r=0;
rNode<T>*pa,*pb;

F(pa=a.pnd,pb=b.pnd;pa&&pb;pa=pa->next,pb=pb->next)
r+=(pa->nd)*(pb->nd);
R r;
}

}; //fine classe rList<T>
 
int mainx(void)
{int i,r;
rList<int> lista;
lista.print();
for(i=0;i<10;++i)
lista.insert(i);
lista.print();
r=lista.remove(&i);
ooo<<"i,r="<<i<<", "<<r<<"\n";
lista.print();
R 0;
}
 
int main(void)
{int arr[]={0,0,7,0,5,0,0,8,0,4}, r;
int ar1[]={0,0,0,5,6,0,0,0,0,5};
u32 i;
rList<int> la(arr, S arr/S(int));
rList<int> l1(ar1, S ar1/S(int));

ooo<<"la=";la.print();ooo<<"\n";
ooo<<"l1=";l1.print();ooo<<"\n";
r=la*l1;
ooo<<"Result: la*lb="<<r<<"\n";

// try to use vector way la[i], that it is not O(1) as vector and array
F(i=0,ooo<<"la=[";i<la.sz;++i)
ooo<<la[i]<<" ";
ooo<<"]\n";
R 0;
}
 
/*
Print from main():
la=[0, 0, 7, 0, 5, 0, 0, 8, 0, 4]
l1=[0, 0, 0, 5, 6, 0, 0, 0, 0, 5]
Result: la*lb=50
la=[0 0 7 0 5 0 0 8 0 4 ]
*/
fir <profesor.fir@gmail.com>: Oct 01 01:22AM -0700

rotozumer is a routine that displays bitmap
on screen (which is also a bitmap so this is like
copying bitmap onto bitmap) but the input bitmap
(you may call it 'sprite') will be rotated by given angle and scaled by given zoom
 
the method is just to iterate on spirite all pixels, totate them (this is multiply by rotated base vectors that
sescribes rotation and zoom) and set this roteted zoomed pixels to screen (yet if zoom is like 2.0 the sampling of the input should be not by +1 step but more like +0.5 to not make holes in output)
 
my unoptymised and not much edited for names etc function for this is that
 
inline void Rotate2d(float* x, float* y, float angle)
{
float xt = (*x) * cos(angle*degree360) - (*y) * sin(angle*degree360);
float yt = (*x) * sin(angle*degree360) + (*y) * cos(angle*degree360);
 
*x = xt;
*y = yt;
}
 
 
void DrawSprite2(float pos_x,
float pos_y,
char* file,
int sprite_bitmap_pos_x,
int sprite_bitmap_pos_y,
int sprite_bitmap_end_x,
int sprite_bitmap_end_y,
float angle = 0 ,
float zoom = 1,
int sprite_centre_bitmap_x = -1,
int sprite_centre_bitmap_y = -1
 
)
 
{
 
if(sprite_centre_bitmap_x<0 || sprite_centre_bitmap_y<0)
{
sprite_centre_bitmap_x = (sprite_bitmap_pos_x + sprite_bitmap_end_x)/2;
sprite_centre_bitmap_y = (sprite_bitmap_pos_y + sprite_bitmap_end_y)/2;
 
}
 
 
float sprite_width = sprite_bitmap_end_x - sprite_bitmap_pos_x + 1 ;
float sprite_height = sprite_bitmap_end_y - sprite_bitmap_pos_y + 1;
 
 
 
float Ax = sprite_bitmap_pos_x - sprite_centre_bitmap_x ;
float Ay = sprite_bitmap_pos_y - sprite_centre_bitmap_y ;
float Bx = sprite_bitmap_end_x - sprite_centre_bitmap_x ;
float By = sprite_bitmap_pos_y - sprite_centre_bitmap_y ;
float Cx = sprite_bitmap_end_x - sprite_centre_bitmap_x ;
float Cy = sprite_bitmap_end_y - sprite_centre_bitmap_y ;
float Dx = sprite_bitmap_pos_x - sprite_centre_bitmap_x ;
float Dy = sprite_bitmap_end_y - sprite_centre_bitmap_y ;
 
Rotate2d(&Ax,&Ay, angle);
Rotate2d(&Bx,&By, angle);
// Rotate2d(&Cx,&Cy, angle);
Rotate2d(&Dx,&Dy, angle);
 
 
float dxdx = (Bx-Ax)/sprite_width;
float dydx = (By-Ay)/sprite_width;
 
float dxdy = (Dx-Ax)/sprite_height;
float dydy = (Dy-Ay)/sprite_height;
 
float x, y;
 
 
for(float j=sprite_bitmap_pos_y-sprite_centre_bitmap_y; j<sprite_bitmap_end_y-sprite_centre_bitmap_y; j+=.7/zoom)
{
for(float i=sprite_bitmap_pos_x-sprite_centre_bitmap_x; i<sprite_bitmap_end_x-sprite_centre_bitmap_x; i+=.7/zoom)
{
unsigned color = sprites_buf_[sprite_centre_bitmap_y + int(j)][sprite_centre_bitmap_x + int(i)];
 
x = 0*sprite_centre_bitmap_x + i * dxdx*zoom + j*dxdy*zoom;
y = 0*sprite_centre_bitmap_y + i * dydx*zoom + j*dydy*zoom;
 
if(color==0) {} else SetPixelSafe(pos_x + x, pos_y + y, color);
 
 
}
}
 
 
}
 
 
the problem is clipping, if sprite is rotated positioned and zoomed often quite large parts and a lot of pixels destinate out the screen - and here in that routine i clib them all per pixel (in "SetPixelSafe")
 
this is much wastefull, and optimistation of this routine is very important as sprites, esp big sprites or sprites that are zoomed to be big may take real lot of time on cpu
(rotozuming big screen size or overscreen sprites sadly may take like 40 ms which is deadly slow (where small ones may take like 1 ms which is ok)
 
so how to speed it up?
(id someone want to see how it runs i may ulpoad te win32 exe showing how it worx)
"Öö Tiib" <ootiib@hot.ee>: Oct 01 03:18AM -0700

On Sunday, 1 October 2017 11:22:36 UTC+3, fir wrote:
> often quite large parts and a lot of pixels destinate out the
> screen - and here in that routine i clib them all per pixel
> (in "SetPixelSafe")
 
I trust that with such problem your concept is backwards.
It does not loop over destination view and find out what point of what
original bitmap should there be. Instead it does something else.
Christian Gollwitzer <auriocus@gmx.de>: Oct 01 12:33PM +0200

Am 01.10.17 um 10:22 schrieb fir:
> (you may call it 'sprite') will be rotated by given angle and scaled by given zoom
 
> the method is just to iterate on spirite all pixels, totate them (this is multiply by rotated base vectors that
> sescribes rotation and zoom) and set this roteted zoomed pixels to screen
 
This is the worst possible method to do it concerning quality.
 
 
> if(color==0) {} else SetPixelSafe(pos_x + x, pos_y + y, color);
 
...and this is probably your speed issue, if this SetPixel function
calls out into the WIN-API. You are calling a drawing function for every
single pixel - extremely slow due to overhead. Instead, you should
rotate the image in a buffer, and then call a function which blits the
whole buffer to the screen.
 
> so how to speed it up?
> (id someone want to see how it runs i may ulpoad te win32 exe showing how it worx)
 
A classic method of image rotation with good quality is Paeth rotation,
which consists of three shear deformations along the coordinate axes.
For best overall performance, you shouldn't use the Win-API for drawing,
but instead OpenGL. There you can directly specify a transformatino
matrix, and the computation will be offloaded to the GPU.
 
Christian
fir <profesor.fir@gmail.com>: Oct 01 04:09AM -0700

W dniu niedziela, 1 października 2017 12:33:26 UTC+2 użytkownik Christian Gollwitzer napisał:
> but instead OpenGL. There you can directly specify a transformatino
> matrix, and the computation will be offloaded to the GPU.
 
> Christian
 
setpixels write to ram but they do clipping on per pixel level which means 4 ifs must be executed for every pixel that pass to screen (and 1 to 4 for each one that not pass) which is propbably deadly to efficiency
 
thats why i need big scale clipping
 
now i think i need to do cliping on perscanline level
becouse this just takes sprite scanlines and draws them skewed to screen, i probably need just to clip this shewed line to screen
 
this line is inner loop of this
 
for(float j=sprite_bitmap_pos_y-sprite_centre_bitmap_y; j<=sprite_bitmap_end_y-sprite_centre_bitmap_y; j+=.7/zoom)
{
for(float i=sprite_bitmap_pos_x-sprite_centre_bitmap_x; i<=sprite_bitmap_end_x-sprite_centre_bitmap_x; i+=.7/zoom)
{
unsigned color = sprites_buf_[sprite_centre_bitmap_y + int(j)][sprite_centre_bitmap_x + int(i)];
 
x = pos_x + i * dxdx + j*dxdy;
y = pos_y + i * dydx + j*dydy;
 
if(color==0) {} else SetPixelSafe(x, y, color);
 
 
}
}
 
question is how to do it exactly.. i even gos somewhere some cliping routine but must find it
 
btw check how ir runs (i mean this unoptimised version)
 
minddetonator.htw.pl/rotozoomer.zip
 
(win32 app no malware)
fir <profesor.fir@gmail.com>: Oct 01 04:17AM -0700

W dniu niedziela, 1 października 2017 13:09:38 UTC+2 użytkownik fir napisał:
 
> btw check how ir runs (i mean this unoptimised version)
 
> minddetonator.htw.pl/rotozoomer.zip
 
> (win32 app no malware)
 
also see side question ,
normally i could samble input sprite just
doin
 
for(y)
for(x) { }
 
but if sprite is rotated esp by 45 degrees it make hols in output as width become sqrt(2)*width long
- which is 1.414.. thats why i need to sample in more density thats why i multiply pessimisticaly sampling coordinates * .7 but for less angles i dont need to multiply by .7 just by 1.0
 
does someone know the exact equation for this factor releted to angle at which i rotate sprite, (it my just gove length of rotated line in pixels (i mean line roted by some angle is shorter in pixels (if i said longer i made mistake) its geometrically the same long but in covered pixels its shorter as pixels are squares)
 
whats thet equation
 
float len = foo(angle);
?
"Öö Tiib" <ootiib@hot.ee>: Oct 01 04:26AM -0700

On Sunday, 1 October 2017 14:18:04 UTC+3, fir wrote:
> for(x) { }
 
> but if sprite is rotated esp by 45 degrees it make hols in output as width become sqrt(2)*width long
> - which is 1.414.. thats why i need to sample in more density thats why i multiply pessimisticaly sampling coordinates * .7 but for less angles i dont need to multiply by .7 just by 1.0
 
That would also go away if you would iterate over destination coordinates
and find what point there should be instead of iterating over source
coordinates.
fir <profesor.fir@gmail.com>: Oct 01 04:37AM -0700

W dniu niedziela, 1 października 2017 13:26:50 UTC+2 użytkownik Öö Tiib napisał:
 
> That would also go away if you would iterate over destination coordinates
> and find what point there should be instead of iterating over source
> coordinates.
 
i think iterating over source is better, i just need do proper cliping
 
ps i revrited the loop slightly
 
for(float j=bot_wing; j<=top_wing; j+=.7/zoom)
{
for(float i=left_wing; i<=right_wing; i+=.7/zoom)
{
unsigned color = sprites_buf_[sprite_centre_bitmap_y + int(j)][sprite_centre_bitmap_x + int(i)];
 
x = pos_x + i * dxdx + j*dxdy;
y = pos_y + i * dydx + j*dydy;
 
if(color==0) {} else SetPixelSafe(x, y, color);
 
 
}
}
 
those loops just iterate over input sprite but coordinates are reshifted to give 0,0 in point that was chosen as sprite centre
 
for example if sprite is 200x 200 and centre is in 50 50 it will be
 
for(float j=-50; j<=150; j+=.7/zoom)
for(float i=-50; i<=150; i+=.7/zoom)
 
i need to do cliping but it seems also i would needto reverse transform this cliping points on input sprite points
fir <profesor.fir@gmail.com>: Oct 01 04:48AM -0700

W dniu niedziela, 1 października 2017 13:37:41 UTC+2 użytkownik fir napisał:
 
> for(float j=-50; j<=150; j+=.7/zoom)
> for(float i=-50; i<=150; i+=.7/zoom)
 
> i need to do cliping but it seems also i would needto reverse transform this cliping points on input sprite points
 
i must think a bit...
 
 
clipping i would just do like that
 
 
for(float j=bot_wing; j<=top_wing; j+=.7/zoom)
{

px = pos_x + left_wing * dxdx + j*dxdy;
py = pos_y + left_wing * dydx + j*dydy;
 
qx = pos_x + right_wing * dxdx + j*dxdy;
qy = pos_y + right_wing * dydx + j*dydy;

if!(ClipLineToScreen(&px,&py,&qx,&qy)) continue;
 
 
for(float i=left_wing; i<=right_wing; i+=.7/zoom)
{
unsigned color = sprites_buf_[sprite_centre_bitmap_y + int(j)][sprite_centre_bitmap_x + int(i)];
 
x = pos_x + i * dxdx + j*dxdy;
y = pos_y + i * dydx + j*dydy;
 
if(color==0) {} else SetPixelSafe(x, y, color);

 
}
}
 
assuming that i will wrote good cliping line routine (i had some but remember it was problematic )
 
but how thetn to reberse those clipped points to inner for coordinates? (just count distances rescale by this distorting factor and subb add to edges? (sounds weird)
fir <profesor.fir@gmail.com>: Oct 01 05:00AM -0700

W dniu niedziela, 1 października 2017 13:48:43 UTC+2 użytkownik fir napisał:
 
px = pos_x + left_wing * dxdx + j*dxdy;
py = pos_y + left_wing * dydx + j*dydy;

qx = pos_x + right_wing * dxdx + j*dxdy;
qy = pos_y + right_wing * dydx + j*dydy;

if!(ClipLineToScreen(&px,&py,&qx,&qy)) continue;

or maybe i just do here inversed rotation (rotate by -angle again but how exactly, first -pos then -rotation or first -rotation and then -pos? (yet zomm comes)
 
do this moatric rotation is orthogonal is there a trick for easy reversing?
fir <profesor.fir@gmail.com>: Oct 01 05:09AM -0700

W dniu niedziela, 1 października 2017 14:00:39 UTC+2 użytkownik fir napisał:
 
> if!(ClipLineToScreen(&px,&py,&qx,&qy)) continue;
 
> or maybe i just do here inversed rotation (rotate by -angle again but how exactly, first -pos then -rotation or first -rotation and then -pos? (yet zomm comes)
 
> do this moatric rotation is orthogonal is there a trick for easy reversing?
 
my wild gues it could be (without zoom, assumng zoom is 1.0 for simplicity)
 
 
px = pos_x + left_wing * dxdx + j*dxdy;
py = pos_y + left_wing * dydx + j*dydy;
 
qx = pos_x + right_wing * dxdx + j*dxdy;
qy = pos_y + right_wing * dydx + j*dydy;

if!(ClipLineToScreen(&px,&py,&qx,&qy)) continue;
 
lwx = (px-pos_x) * dxdx + (py-pos_y)*dxdy*(-1);
// lwy = (px-pos_x) * dydx*(-1) + (py-pos_y)*dydy;
 
 
rwx = pos_x + (qx-pos_x) * dxdx + (qy-pos_y)*dxdy*(-1);
// rwy = pos_y + (qx-pos_x) * dydx*(-1) + (qy-pos_y)*dydy;
 
but im not sure and my head started to hurt
Christian Gollwitzer <auriocus@gmx.de>: Oct 01 02:13PM +0200

Am 01.10.17 um 13:37 schrieb fir:
>> and find what point there should be instead of iterating over source
>> coordinates.
 
> i think iterating over source is better, i just need do proper cliping
 
No, it's not, and you have been told the reason multiple times. Why do
you try to sharpen a wooden knife instead of using a sharp blade?
 
 
Christian
fir <profesor.fir@gmail.com>: Oct 01 05:14AM -0700

W dniu niedziela, 1 października 2017 14:09:27 UTC+2 użytkownik fir napisał:
 
> rwx = pos_x + (qx-pos_x) * dxdx + (qy-pos_y)*dxdy*(-1);
> // rwy = pos_y + (qx-pos_x) * dydx*(-1) + (qy-pos_y)*dydy;
 
> but im not sure and my head started to hurt
 
anyway something like that seem reasonable and maybe when i rest i will test it
fir <profesor.fir@gmail.com>: Oct 01 05:19AM -0700

W dniu niedziela, 1 października 2017 14:13:35 UTC+2 użytkownik Christian Gollwitzer napisał:
 
> > i think iterating over source is better, i just need do proper cliping
 
> No, it's not, and you have been told the reason multiple times. Why do
> you try to sharpen a wooden knife instead of using a sharp blade?
 
i dont think yu understand it - if you understand tell me why its not better?
 
in this reversed way i would need to count area for which it should reach for pixels, which seem unnatural to me, here i got the area naturalely
also if i skip onj transparency color i dont need to do transformation on such transparent pixels in reversed method i would need to do transformation only to see that pixel is transparent
Christian Gollwitzer <auriocus@gmx.de>: Oct 01 03:49PM +0200

Am 01.10.17 um 14:19 schrieb fir:
 
>> No, it's not, and you have been told the reason multiple times. Why do
>> you try to sharpen a wooden knife instead of using a sharp blade?
 
> i dont think yu understand it - if you understand tell me why its not better?
 
Because when you iterate over the destination pixels, you will ensure
that you hit every pixel only once. The source will come from
non-integer locations, which is "easily" dealt with interpolation. The
simplest solution is trilinear interpolation which weighs all four
pixels surrounding the non-integer location that you hit. More
sophisticated interpolation schemes exist (look up bicubic or Lanczos
filtering). Without filtering your turned image will look very ugly.
 
Iterating over the destination pixels will also be faster due to the
architecture of current computers. It is faster if you write a block of
memory in a single continuous row, while reading from scattered
locations (so called "gather" operation) than to do it the other way
round ("scatter" operation)
 
Finally, to deal with transparency, you only need to enhance your blend
operation. If you use Paeth's algorithm or any other, where the pixels
outside of the source image are set to fully transparent, you will most
likely get the expected result.
 
Christian
fir <profesor.fir@gmail.com>: Oct 01 07:00AM -0700

W dniu niedziela, 1 października 2017 15:49:40 UTC+2 użytkownik Christian Gollwitzer napisał:
> outside of the source image are set to fully transparent, you will most
> likely get the expected result.
 
> Christian
 
what you say is opinion and not the proof
(becouse other factiors also come to play, other than mentioned)
 
(hovever im not sayin there is no sense in it, this filtering my have some point,
 
as to read from sequential write to skewed beats write to sequential read from skewed im not sure - maybe..)
 
anyway you should note i dont want the
best quality algorithm, i can think on more fast one (and in raw wersion im not sure if this reversed is faster) im searchng for easier to write and run..
and esp as i got what i got i want now only slightly to improve what i got and that is on question
(at later stage i could try both and compare now easiest seem to just run this one)
fir <profesor.fir@gmail.com>: Oct 01 08:03AM -0700

W dniu niedziela, 1 października 2017 14:14:47 UTC+2 użytkownik fir napisał:
> > // rwy = pos_y + (qx-pos_x) * dydx*(-1) + (qy-pos_y)*dydy;
 
> > but im not sure and my head started to hurt
 
> anyway something like that seem reasonable and maybe when i rest i will test it
 
hell it dont work, it meens i would need to start detailed long debug sesion (esp as my line clipping routine is probably wrong)
fir <profesor.fir@gmail.com>: Oct 01 08:17AM -0700

W dniu niedziela, 1 października 2017 17:03:50 UTC+2 użytkownik fir napisał:
 
> > > but im not sure and my head started to hurt
 
> > anyway something like that seem reasonable and maybe when i rest i will test it
 
> hell it dont work, it meens i would need to start detailed long debug sesion (esp as my line clipping routine is probably wrong)
 
i once tested line cliping algorithms and it made problem as line defined on ints and one defined on floats canbe somewhat incompatible
 
other problem was that if i clipped int-based line to also int based clipped line
the result of clipping was uncompatiblle with a part drawed by bresenham b-couse bressenham remembers fractional parts when entering slipped area and starting new integer line in the edge points (line that not remembered those fraction parts at start end end) was giving a bit different line than oryginal
 
i would even rethink how to define both integer and float coordinates of pixels,
should 0. 0. point point center of top left pixel ot its tol left corner? this decisian has serious consequences (even probably influences the speed of some routines slightly)
fir <profesor.fir@gmail.com>: Oct 01 08:47AM -0700

W dniu niedziela, 1 października 2017 17:17:23 UTC+2 użytkownik fir napisał:
> the result of clipping was uncompatiblle with a part drawed by bresenham b-couse bressenham remembers fractional parts when entering slipped area and starting new integer line in the edge points (line that not remembered those fraction parts at start end end) was giving a bit different line than oryginal
 
> i would even rethink how to define both integer and float coordinates of pixels,
> should 0. 0. point point center of top left pixel ot its tol left corner? this decisian has serious consequences (even probably influences the speed of some routines slightly)
 
some notes
 
if i chose 0. 0. at the centre of the pixel i got some like unsymetry which is weird, on the other hand int coordinates of pixels give identical unsymetry,
there would be unsymetry but
conversion form int coordinates to float will be more natural
 
consequences are hhovever even more serious (think on drawing adjacent rectangles when 0. 0. is in ppixel corners or centres, to draw lines center-pixel coordinates are beter but to write
adjacent shapes seems worse
 
yet other complication is if to use c natural cast in such graphics it probably works just wrong in both scenarios (i would need to rethink it a bit hovever)
 
in short writing some routines only on int coordinates alllows me to not make this float decision but when i need
to do cliping etc or more care on details i just need to taks this float coordinate decision
 
im closer to establish 0. 0. point in the centre of first pixel it is becouse
othervise i would need to think wierdly on integer coordinetes (in integer coordinates i just think on centres of the pixels) or having two uncompatible
sets and that would be very confusing
(when for example set_pixel(1,1) would work other than set_pixel(1., 1.))
(in such way here one couls say integer rulez floats not floats rulez integers)
 
yet still i would need to be careful on
default float to int casts (which afair
just eat one column and one row as they
both cast .9 .9 and -.9 -.9 to 0 0
 
where according to convention .9 .9 could yeild to 1 1 and -.9 -.9 to -1 -1
first pixel spans -.5 to .5 im not sure
what to do with edges (probably will need to treat it always with special atention? :C) and dont even know what c expression realizes such cast, just round(x) ?
fir <profesor.fir@gmail.com>: Oct 01 09:05AM -0700

W dniu niedziela, 1 października 2017 17:47:34 UTC+2 użytkownik fir napisał:
 
> where according to convention .9 .9 could yeild to 1 1 and -.9 -.9 to -1 -1
> first pixel spans -.5 to .5 im not sure
> what to do with edges (probably will need to treat it always with special atention? :C) and dont even know what c expression realizes such cast, just round(x) ?
 
anyway it seems that only after that consideration i could think how to design clip_line function, .. it must be float coz as i said integer clipline just dont work
 
if i rest maybe i will write some notes on this (it is somewhat boring work but sadly it must be somewhat done)
asetofsymbols@gmail.com: Oct 01 03:09AM -0700

What about the use
sizeof(node<T>)
in a template, it return the correct size? Thank you
 
example the sizeof() used in function below
 
template<class T> class node{
public:
T el;
node*next;// is it better here "node<T>*next;" instead?
}
 
template<class T> class list{
public:
node<T>* pnd;
int sz;
 
function(void)
{int s=sizeof(node<T>);
....
}
}
Marcel Mueller <news.5.maazl@spamgourmet.org>: Oct 01 12:29PM +0200

> What about the use
> sizeof(node<T>)
> in a template, it return the correct size? Thank you
 
Yes. sizeof is reliable within templates since the generic arguments
must be known at compile time anyway.
 
 
Marcel
asetofsymbols@gmail.com: Oct 01 03:41AM -0700

Thank you
 
so cast is ok too, for example I in a template have something as (where T is the type of the template
)
node<T>*p=(node<T>*)malloc(sizeof(node<T>)
 
Whould be ok...(if p points to one element node<T>)
Marcel Mueller <news.5.maazl@spamgourmet.org>: Oct 01 01:05PM +0200

> )
> node<T>*p=(node<T>*)malloc(sizeof(node<T>)
 
> Whould be ok...(if p points to one element node<T>)
 
It would work.
 
But why not to use operator new which needs nether a cast nor sizeof?
 
 
Marcel
"Öö Tiib" <ootiib@hot.ee>: Oct 01 04:17AM -0700

> )
> node<T>*p=(node<T>*)malloc(sizeof(node<T>)
 
> Whould be ok...(if p points to one element node<T>)
 
In C++ uninitialized memory buffer may be cast into object type only
on limited cases. You can check it compile time with static_assert
if it is ok or not:
 
static_assert(std::is_pod<T>::value, "T must be POD type.");
 
Or it may be better to use new instead of malloc and cast.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)