Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #59186 > unrolled thread

chosing "small 2d graphics library" interface

Back to article view | Back to comp.lang.c

Contents

  chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-28 18:43 -0700
    Re: chosing "small 2d graphics library"  interface Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-29 02:59 -0700
      Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 03:51 -0700
        Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-03-29 12:03 +0100
          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 05:00 -0700
            Re: chosing "small 2d graphics library"  interface gof@somewhere.invalid (Gof) - 2015-04-01 08:02 +0000
              Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-01 09:40 +0100
                Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-01 04:04 -0700
        Re: chosing "small 2d graphics library"  interface Nobody <nobody@nowhere.invalid> - 2015-03-29 12:50 +0100
          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 05:08 -0700
      Re: chosing "small 2d graphics library"  interface Jeff Higgins <jeff@invalid.invalid> - 2015-03-29 09:33 -0400
        Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 07:00 -0700
          Re: chosing "small 2d graphics library"  interface Jeff Higgins <jeff@invalid.invalid> - 2015-03-29 10:38 -0400
            Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 07:43 -0700
        Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 07:24 -0700
          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 07:32 -0700
        Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-01 05:00 -0700
          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-01 07:25 -0700
      Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 07:36 -0700
        Re: chosing "small 2d graphics library"  interface Jeff Higgins <jeff@invalid.invalid> - 2015-03-29 14:33 -0400
          Re: chosing "small 2d graphics library"  interface Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-29 12:36 -0700
          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 13:01 -0700
    chosing "small 2d graphics library"  interface asetofsymbols@gmail.com - 2015-04-02 04:12 -0700
      Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 04:56 -0700
        Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 05:10 -0700
          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 05:31 -0700
          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 09:40 -0700
      Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 13:32 +0100
        Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 05:50 -0700
          Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 14:01 +0100
            Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 06:37 -0700
              Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 14:58 +0100
                Re: chosing "small 2d graphics library"  interface Bartc <bc@freeuk.com> - 2015-04-02 15:11 +0100
                  Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 15:18 +0100
                    Re: chosing "small 2d graphics library"  interface Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-02 09:21 -0700
                      Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 09:34 -0700
                        Re: chosing "small 2d graphics library"  interface Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-02 09:47 -0700
                      Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 09:45 -0700
                        Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 09:57 -0700
                        Re: chosing "small 2d graphics library"  interface Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-02 10:15 -0700
                          Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 18:34 +0100
                            Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 18:35 +0100
                      Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 17:45 +0100
                        Re: chosing "small 2d graphics library"  interface Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-02 10:12 -0700
                          Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 18:28 +0100
                          Re: chosing "small 2d graphics library"  interface Bartc <bc@freeuk.com> - 2015-04-03 01:06 +0100
                      Re: chosing "small 2d graphics library"  interface luser droog <luser.droog@gmail.com> - 2015-04-02 17:05 -0700
                  Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 07:51 -0700
                    Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 15:56 +0100
                      Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 08:14 -0700
                        Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 16:25 +0100
                          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 08:45 -0700
                            Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 17:00 +0100
                              Re: chosing "small 2d graphics library"  interface Keith Thompson <kst-u@mib.org> - 2015-04-02 13:03 -0700
                                Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-05 14:25 -0700
                            Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 09:06 -0700
                              Re: chosing "small 2d graphics library"  interface Rosario19 <Ros@invalid.invalid> - 2015-04-02 18:22 +0200
                                Re: chosing "small 2d graphics library"  interface Rosario19 <Ros@invalid.invalid> - 2015-04-02 18:40 +0200
                                  Re: chosing "small 2d graphics library"  interface Robert Wessel <robertwessel2@yahoo.com> - 2015-04-03 00:20 -0500
                                Re: chosing "small 2d graphics library"  interface Rosario19 <Ros@invalid.invalid> - 2015-04-04 10:35 +0200
                                  Re: chosing "small 2d graphics library"  interface CHIN Dihedral <dihedral88888@gmail.com> - 2015-04-04 09:53 -0700
                          Re: chosing "small 2d graphics library" interface Noob <root@127.0.0.1> - 2015-04-03 14:27 +0200
                            Re: chosing "small 2d graphics library" interface fir <profesor.fir@gmail.com> - 2015-04-03 05:38 -0700
                Re: chosing "small 2d graphics library"  interface Jeff Higgins <jeff@invalid.invalid> - 2015-04-02 19:23 -0400
                  Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 23:46 -0700
        Re: chosing "small 2d graphics library"  interface asetofsymbols@gmail.com - 2015-04-02 08:03 -0700
          Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 16:14 +0100
            Re: chosing "small 2d graphics library"  interface Keith Thompson <kst-u@mib.org> - 2015-04-02 12:42 -0700
            Re: chosing "small 2d graphics library"  interface CHIN Dihedral <dihedral88888@gmail.com> - 2015-04-03 14:27 -0700
              Re: chosing "small 2d graphics library"  interface Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-03 14:50 -0700
        Re: chosing "small 2d graphics library"  interface Keith Thompson <kst-u@mib.org> - 2015-04-02 10:47 -0700
        Re: chosing "small 2d graphics library"  interface Bartc <bc@freeuk.com> - 2015-04-02 20:09 +0100
          Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-03 06:02 +0100
            Re: chosing "small 2d graphics library"  interface Bartc <bc@freeuk.com> - 2015-04-03 11:40 +0100
              Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-03 03:52 -0700
                Re: chosing "small 2d graphics library"  interface Bartc <bc@freeuk.com> - 2015-04-03 12:05 +0100
                  Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-03 04:36 -0700
                    Re: chosing "small 2d graphics library"  interface Bartc <bc@freeuk.com> - 2015-04-03 13:28 +0100
                      Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-03 06:04 -0700
                        Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-03 07:28 -0700
                          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-03 12:43 -0700
              Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-03 12:57 +0100
        Re: chosing "small 2d graphics library"  interface asetofsymbols@gmail.com - 2015-04-03 22:25 -0700
          Re: chosing "small 2d graphics library"  interface asetofsymbols@gmail.com - 2015-04-03 22:34 -0700
            Re: chosing "small 2d graphics library"  interface asetofsymbols@gmail.com - 2015-04-03 23:09 -0700
              Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-04 09:23 +0100
      chosing "small 2d graphics library"  interface asetofsymbols@gmail.com - 2015-04-02 07:26 -0700

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#59592

On Saturday, April 4, 2015 at 4:35:30 PM UTC+8, Rosario19 wrote:
> On Thu, 02 Apr 2015 18:22:12 +0200, Rosario19 <Ros@invalid.invalid>
> wrote:
> 
> >On Thu, 2 Apr 2015 09:06:24 -0700 (PDT), fir wrote:
> >
> >>ps. as to executable this is pure winapi graphics app do not changes anything in system,
> >>do not make any internet connection etc,
> >>is not aany kind of malware
> >>I am testing my system by antivir and do not detect i got any contagious virus here
> >>(so as far as i can be sure 99.99% I think
> >>it is not any kind of damege soft and can 
> >>be just used)
> >>
> >>afaik shoul also work in linus through wine emulator, or maybe in wirtual machine or something
> >
> >i seen you speak of array of 8 MB or more...
> >they seem big array to me...
> 
> yes what about
> 
> typedef struct foto 
> {//  2D  or 3D foto
>  unsigned   zmax;
>  unsigned   ymax;
>  unsigned   xmax;
>  unsigned   *pixel;
>  unsigned   *bpixel;
> };
> 
> so one pixel would be one value 32 bits R G B  each 8 bit [0..255] +
> one 8 bit used for other
> 
> bpixel would be the imagine where 1 pixel is 1 bit  ... one array of
> bit where 0 means in (x,y,z) is void
>           1 means in (x,y,z) there is one point 
> 
> >why not break that imagine in N parts as a math partition 
> >and allow N processor in rebuild redisign that imagine or pictures [i
> >don't know the right word] each that read write its own piece of sub
> >picture??
> >
> >i think could be more fast
> >it would be enougth break the imagine in parts and assign each part to
> >the cpu...
> >

I think GIMP and GTK were available 
for images. But the 3D object and 
the 3D printing is not yet. Thus, 
it is good to check the classical 
libraries to evolve into the new
application domain.

[toc] | [prev] | [next] | [standalone]

#59510 — Re: chosing "small 2d graphics library" interface

On 02/04/2015 17:25, Richard Heathfield wrote:

> No, the source code is far more important. We can use the source code
> to create an executable program if we care enough, but we can't
> extract the C source from the executable program, so we have no way
> to judge the quality of the code.

As the saying goes, "I wanted to change the world, but they wouldn't
give me the source code."

Regards.

[toc] | [prev] | [next] | [standalone]

#59513 — Re: chosing "small 2d graphics library" interface

W dniu piątek, 3 kwietnia 2015 14:27:47 UTC+2 użytkownik Noob napisał:
> On 02/04/2015 17:25, Richard Heathfield wrote:
> 
> > No, the source code is far more important. We can use the source code
> > to create an executable program if we care enough, but we can't
> > extract the C source from the executable program, so we have no way
> > to judge the quality of the code.
> 
> As the saying goes, "I wanted to change the world, but they wouldn't
> give me the source code."
> 
I do not gave a source for projects i am working on (at least not all and at least in not every moment)
My own code has no special look and nothing special here, code is normal though messy
becouse i got such messy working style
(though optimised, also not greatly as masters of optimistation could do, but somewhat)
So nothing special to look here (*).. I giva many fragments of the pices i working an and asking for some hints

(*) simpletons could laugh at bad naming etc, as simpletons do but it has not much sense
(as im still working on my coding style and at
all i do not care to much on code being to 
tidy)

[toc] | [prev] | [next] | [standalone]

#59496

On 04/02/2015 09:58 AM, Richard Heathfield wrote:
>
> Whether the article is /valuable/, however, is another matter. If it has
> value to asetofsymbols@gmail.com then it was worth writing and posting.
> If it has no value to him or her, but has value to someone else who
> reads it, then again it was worth writing and posting. The fact that
> *you* consider it valueless doesn't really matter to anybody except *you*.

Your article spawned some more in-depth discussion of the subject which
interested me in this thread. Thanks to you and Malcolm McLean for the
discussion. Thanks also to the catalysts, fir and asetofsymbols.

[toc] | [prev] | [next] | [standalone]

#59504

W dniu piątek, 3 kwietnia 2015 01:25:08 UTC+2 użytkownik Jeff Higgins napisał:
> On 04/02/2015 09:58 AM, Richard Heathfield wrote:
> >
> > Whether the article is /valuable/, however, is another matter. If it has
> > value to asetofsymbols@gmail.com then it was worth writing and posting.
> > If it has no value to him or her, but has value to someone else who
> > reads it, then again it was worth writing and posting. The fact that
> > *you* consider it valueless doesn't really matter to anybody except *you*.
> 
> Your article spawned some more in-depth discussion of the subject which
> interested me in this thread. Thanks to you and Malcolm McLean for the
> discussion. Thanks also to the catalysts, fir and asetofsymbols.

fine that people are interested in coding graphics - but sad that they are not try to focus on discussing lib header here - which is 
more unique and has more sense (is far more unique and interesting subject), 
holiday is coming maybe there one would have some time

[toc] | [prev] | [next] | [standalone]

#59456

I'm not agree in
struct pointd { double x,y;};

I would prefer
struct pointf { float x,y;};
Because here float would be
32 bit as int 
and one can do one union for
represent integer points too

struct point {
  union{float f;
        int   i;
       }x;
union{float f;
        int   i;
       }y;
};

[toc] | [prev] | [next] | [standalone]

#59457

On 02/04/15 16:03, asetofsymbols@gmail.com wrote:
> I'm not agree in
> struct pointd { double x,y;};
>
> I would prefer
> struct pointf { float x,y;};
> Because here float would be
> 32 bit as int

This is commonly true, although the standard doesn't actually require 
either float or int to be precisely 32 bits; nor does it require them to 
be the same size as each other.

Floats can take up less memory than doubles (typically only half as 
much). On the other hand, many functions that you might want to use in 
graphics (for example, sin(), cos(), pow(), sqrt()) generally take 
doubles. There may also be hardware speed advantages to choosing doubles 
(or indeed floats! - the standard is silent on this matter).

> and one can do one union for
> represent integer points too
>
> struct point {
>    union{float f;
>          int   i;
>         }x;
> union{float f;
>          int   i;
>         }y;
> };

How would that be useful? I don't quite see the point. If your internal 
universe representation requires floating point (for example, your base 
unit might be metres, say, but you sometimes need to represent objects 
that are not an exact number of metres long), then how would a union 
with int help you? And if your universe doesn't require floating point, 
then how would a union with floating point help you?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#59487

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 02/04/15 16:03, asetofsymbols@gmail.com wrote:
>> I'm not agree in
>> struct pointd { double x,y;};
>>
>> I would prefer
>> struct pointf { float x,y;};
>> Because here float would be
>> 32 bit as int
>
> This is commonly true, although the standard doesn't actually require
> either float or int to be precisely 32 bits; nor does it require them
> to be the same size as each other.
>
> Floats can take up less memory than doubles (typically only half as
> much). On the other hand, many functions that you might want to use in
> graphics (for example, sin(), cos(), pow(), sqrt()) generally take
> doubles.

With any modern implementation, such functions are available for all 3
floating-point types, for example sinf() for float, sin() for double,
and sinl() for long double.  (Or you can use <tgmath.h> and just use the
name "sin".)

If you're stuck with pre-C99 implementations for some reason, then yes,
you need to use the double functions, since the float and long double
functions won't be available (except perhaps as an extension).

>          There may also be hardware speed advantages to choosing
> doubles (or indeed floats! - the standard is silent on this matter).

True.  Using double rather than float is usually a good idea anyway,
unless you need to store a *lot* of values and the space saving is worth
the loss of range and precision.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#59554

On Thursday, April 2, 2015 at 11:14:36 PM UTC+8, Richard Heathfield wrote:
> On 02/04/15 16:03, asetofsymbols@gmail.com wrote:
> > I'm not agree in
> > struct pointd { double x,y;};
> >
> > I would prefer
> > struct pointf { float x,y;};
> > Because here float would be
> > 32 bit as int
> 
> This is commonly true, although the standard doesn't actually require 
> either float or int to be precisely 32 bits; nor does it require them to 
> be the same size as each other.
> 
> Floats can take up less memory than doubles (typically only half as 
> much). On the other hand, many functions that you might want to use in 
> graphics (for example, sin(), cos(), pow(), sqrt()) generally take 
> doubles. There may also be hardware speed advantages to choosing doubles 
> (or indeed floats! - the standard is silent on this matter).
> 
> > and one can do one union for
> > represent integer points too
> >
> > struct point {
> >    union{float f;
> >          int   i;
> >         }x;
> > union{float f;
> >          int   i;
> >         }y;
> > };
> 
> How would that be useful? I don't quite see the point. If your internal 
> universe representation requires floating point (for example, your base 
> unit might be metres, say, but you sometimes need to represent objects 
> that are not an exact number of metres long), then how would a union 
> with int help you? And if your universe doesn't require floating point, 
> then how would a union with floating point help you?
> 
> -- 
> Richard Heathfield
> Email: rjh at cpax dot org dot uk
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line 4 vacant - apply within

I think the concept of the 
separation of the interface display device and the graphic objects to be modeled is useful. As far as I know
the free GIMP library interfaces
can be checked. Most GIMP soure codes
are written in C.

[toc] | [prev] | [next] | [standalone]

#59560

On Friday, April 3, 2015 at 10:27:17 PM UTC+1, CHIN Dihedral wrote:
> 
> I think the concept of the separation of the interface display 
> device and the graphic objects to be modeled is useful. As far as I know
> the free GIMP library interfaces can be checked. Most GIMP soure codes
> are written in C.
>
The question is where the "display hardware" begins and the "software"
ends. It used to be quite simple. But modern systems use programmable
GPUs, so it's not a case of constructing a raster in software and then
passing it on the the hardware any more. (You can still do that, of
course, but not with acceptable performance for interactive systems). 

[toc] | [prev] | [next] | [standalone]

#59480

Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> #define NUM_DIMENSIONS 2
>
> struct point
> {
>   double dimension[NUM_DIMENSIONS];
> };
>
> For notational convenience, let's alias that type:
>
> typedef struct point Point;

[...]

> struct edge
> {
>   Point vertex[2];
> };
>
> and again, let's alias the type:
>
> typedef struct edge Edge;
>
> A "face" is a series of edges that, taken together, mark off a region
> of our universe. A face can have many edges, but it turns out to be
> convenient to restrict ourselves to three, forming a triangle. Why is
> this convenient? Well, firstly, we can use triangles to build up any
> other shape we want, so it doesn't cost us much, but more importantly
> we can specify exactly 3 of something really easily, whereas
> specifying n of anything requires us to play games with dynamic
> allocation. We will have to do that anyway at some time, but there's
> no need to have that level of complexity at this primitive a
> level. So:
>
> struct face
> {
>   Edge edge[3];
> };
>
> typedef struct face Face;
[...]

With this representation, a Face (representing a triangle) stores each
vertex point twice.  It can also represent a triangle whose edges are
disconnected, which I presume would be invalid.

I suggest:

    struct face
    {
      Point vertex[3];
    };

And perhaps "struct triangle" would be clearer than "struct face", since
you've already decided (reasonably IMHO) that all faces are triangles.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#59483

[Originally sent to 'Richard Heathfield' instead of the group, by 
mistake. Don't know how that happened as I don't have a button for it. 
Please ignore that anyway]

On 02/04/2015 13:32, Richard Heathfield wrote:
 > On 02/04/15 15:11, Bartc wrote:

 >> (even if I didn't necessarily agree with all of it).
 >
 > Ah, excellent! If you would be so kind as to point out, preferably in 
 > a reply to that article rather than this one

Nothing serious, just small details and some personal preferences.

 > although I think perhaps we should go to double, since the
 > extra cost is small and the gain can be quite significant.
 >
 > struct point
 > {
 >    double x;
 >    double y;
 > };
 >
 > is therefore a reasonable way to go.

Possibly. But if this is going to end up in something like OpenGL or 
DirectDraw, I think they are still based on single precision (maybe GPUs 
are as well).

Double precision is definitely needed for area suchs as 
mapping/geographic work where you might want to represent detail that is 
a long way from the origin. But at the level asetofsymbols seems to be 
at, and working in 2D, then 'int' coordinates could even do.

 > struct face
 > {
 >    Edge edge[3];
 > };
 >
 > typedef struct face Face;

(A point about C: I wouldn't bother with struct tags, I'd just go 
straight to the typedef.)

Keith I think mentioned that the endpoints are likely to be duplicated 
with this scheme, taking more storage and twice the processing.

(Also, in some kinds of 3D models, you could have a bunch of vertices, 
superimposed on which are a set of edges, each of which is an index into 
the set of vertices, and a set of faces, each of which is contains three 
indices into the set of edges, or they can directly index three vertices.

But 3D introduces other complications too. Your scheme will do to get 
started.)

 > But wait! A face has a colour.

Eventually. But when you think about a scheme where vertices, edges and 
faces are separate, which have the colour? Maybe it makes more sense for 
a face to have the colour, but usually faces also form part of a 
continuous surface of a single colour. So it's a bit wasteful to repeat 
the same colour hundreds of times.

Also, if you have a shape which is a collection of faces, you might want 
to render the same shape in different colours.

And in some graphics APIs I've used, colour is anyway considered an 
attribute not attached to an entity. So some arguments for keeping the 
colour separate, but this way will work as well!

 > void SplitColour(unsigned char *r, unsigned char *g, unsigned char *b,
 > unsigned char *a, Colour c)
 > {
 >    if(r) *r = GetRed(c);
 >    if(g) *g = GetGreen(c);
 >    if(b) *b = GetBlue(c);
 >    if(a) *a = GetAlpha(c);
 > }

 > Doing it this way, you can pass NULL for any channel you don't care 
about.

I think a struct with r,g,b,a fields would be simpler, but might need 
some conditional set up if the order of RGB varies. (Under Windows, RGB 
order differs anyway depending on what you're doing.)

 > struct framebuffer
 > {
 >    unsigned long int height;
 >    unsigned long int width;
 >    Colour **pixel;
 > };
 >
 > typedef struct framebuffer FrameBuffer;

That's reasonable, and it makes it possible to use normal 2D C array 
operations to read and write from it.

But it's complicated to set up, as you go on to demonstrate (freeing 
also, but that may not needed for a framebuffer that persists to the end 
of execution.) And, when interfacing with anything else, then usually a 
framebuffer as a single block is expected.

Also, unless all access is via x, y coordinates, sometimes you need to 
be able to step from one row to another, and for that you will need that 
'stride'.

 > It should now be obvious that you can set a pixel to a given colour like
 > this:
 >
 > int SetColour(FrameBuffer *fb, Colour c, unsigned long x, unsigned 
long y)
 > int GetColour(FrameBuffer *fb, Colour *c, unsigned long x, unsigned 
long y)

OK, although I would have called them Set/GetPixel, with the latter 
returning the pixel value.

(I've never heard of returning a status from such a pair of functions; 
who's going to sit and check the return value of every pixel operation? 
What will they do if it fails? To test if a point is within the frame, a 
dedicated function can be used. And functions operating at a higher 
level then pixels, will their own clipping methods.)

 > For a more general line-drawing algorithm, look up Bresenham. Once you
 > can draw an arbitrary line in any direction (it's not hard, honestly!),
 > you can write yourself a DrawFace() function, at which point (I hope)
 > there'll be no stopping you.

You mean draw the edges of the face? Filling the interior is a bit 
harder. But something to watch out for when drawing the face edges is to 
avoid drawing touching edges twice. So for a 'wireframe' rendering, 
working with edges rather than faces is better.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#59499

On 02/04/15 20:09, Bartc wrote:
> On 02/04/2015 13:32, Richard Heathfield wrote:
>   > On 02/04/15 15:11, Bartc wrote:
>
>   >> (even if I didn't necessarily agree with all of it).
>   >
>   > Ah, excellent! If you would be so kind as to point out, preferably in
>   > a reply to that article rather than this one
>
> Nothing serious, just small details and some personal preferences.

Let's take a look, then, shall we?

>
>   > although I think perhaps we should go to double, since the
>   > extra cost is small and the gain can be quite significant.
>   >
>   > struct point
>   > {
>   >    double x;
>   >    double y;
>   > };
>   >
>   > is therefore a reasonable way to go.
>
> Possibly. But if this is going to end up in something like OpenGL or
> DirectDraw, I think they are still based on single precision (maybe GPUs
> are as well).

Somehow I don't think this is going to end up there.

> Double precision is definitely needed for area suchs as
> mapping/geographic work where you might want to represent detail that is
> a long way from the origin. But at the level asetofsymbols seems to be
> at, and working in 2D, then 'int' coordinates could even do.

Yes, maybe. There are limits, of course. If we want millimetre-accurate 
measurements for our object co-ordinates and 32-bit ints, then our 
universe can't be bigger than 4000km. That's probably good enough, as 
long as we don't want to drive a racing car from one USA coast to the 
other. If we go to centimetre-accurate measurements, objects can start 
to look pretty strange from some angles when you're zoomed reasonably 
close in. Floating point survives rotation (and scaling) rather better. 
And if you're going to use floating point anyway, my philosophy has 
always been to use double, for much the same reason that we generally 
use int rather than short int unless there is a specific reason to do 
otherwise.

>
>   > struct face
>   > {
>   >    Edge edge[3];
>   > };
>   >
>   > typedef struct face Face;
>
> (A point about C: I wouldn't bother with struct tags, I'd just go
> straight to the typedef.)

Yeah. I'd bother with the tags, though, because in reality my header 
would look something like this:

typedef struct face Face;

(with no struct def in sight, because that would be tucked in a private 
header).

>
> Keith I think mentioned that the endpoints are likely to be duplicated
> with this scheme, taking more storage and twice the processing.

Yes, I saw that (thanks, Keith, quite right). So there you are, that's 
an improvement right away.

> (Also, in some kinds of 3D models, you could have a bunch of vertices,
> superimposed on which are a set of edges, each of which is an index into
> the set of vertices, and a set of faces, each of which is contains three
> indices into the set of edges, or they can directly index three vertices.

Sure. I think the key point here is to determine how you plan to model 
the world, and then design your data structures according to that model, 
and then not allow yourself to get too distracted by other possible ways 
of modelling the world - which is not to say that you shouldn't spend 
some time thinking about alternatives.


> But 3D introduces other complications too. Your scheme will do to get
> started.)

I've written a rudimentary 3D graphics engine (I got as far as viewing 
edge-drawn objects from any angle and distance), and can attest to the 
fact that it is considerably more complicated than 2D. Writing a 3D 
graphics engine from scratch to the point where you're happy with it 
could easily consume an entire lifetime of work, whereas I was able to 
write a 2D engine reasonably quickly, including things like sprite 
animations.

>
>   > But wait! A face has a colour.
>
> Eventually. But when you think about a scheme where vertices, edges and
> faces are separate, which have the colour? Maybe it makes more sense for
> a face to have the colour, but usually faces also form part of a
> continuous surface of a single colour. So it's a bit wasteful to repeat
> the same colour hundreds of times.

That makes a lot of sense. So where would *you* store the colour? I 
suppose we could store it in the object structure (that is, the struct 
that contains the high level details for the structure, such as its 
current position, velocity, and acceleration).

<snip>


> I think a struct with r,g,b,a fields would be simpler, but might need
> some conditional set up if the order of RGB varies. (Under Windows, RGB
> order differs anyway depending on what you're doing.)

I think you have to define an RGB order for yourself (and by all means 
make it as compatible as possible with your most likely platform) for 
internal use, and then translate if and when you have to for interfacing 
to hardware. But I think the struct would be a mistake. A union of 
unsigned long and unsigned char[4] might work well, though, but yes, 
then you'd have to be very, very careful about endianness.

>
>   > struct framebuffer
>   > {
>   >    unsigned long int height;
>   >    unsigned long int width;
>   >    Colour **pixel;
>   > };
>   >
>   > typedef struct framebuffer FrameBuffer;
>
> That's reasonable, and it makes it possible to use normal 2D C array
> operations to read and write from it.

In fact, it makes writing general graphics code quite easy. Nonetheless, 
I'm coming round to your view!

>
> But it's complicated to set up, as you go on to demonstrate (freeing
> also, but that may not needed for a framebuffer that persists to the end
> of execution.)

That doesn't bother me, because it's a once-only complication. Write it, 
get it working, forget it.

> And, when interfacing with anything else, then usually a
> framebuffer as a single block is expected.

That does bother me. I still haven't gotten around to testing out 
Malcolm's JPEG codec, mostly because I'd have to spend the - what, five 
minutes? - writing an interface between his format and mine.

>
> Also, unless all access is via x, y coordinates, sometimes you need to
> be able to step from one row to another, and for that you will need that
> 'stride'.

Stride has the added advantage that you can copy a rectangle easily in a 
single memcpy, rather than having to loop through the rows.

>
>   > It should now be obvious that you can set a pixel to a given colour like
>   > this:
>   >
>   > int SetColour(FrameBuffer *fb, Colour c, unsigned long x, unsigned
> long y)
>   > int GetColour(FrameBuffer *fb, Colour *c, unsigned long x, unsigned
> long y)
>
> OK, although I would have called them Set/GetPixel, with the latter
> returning the pixel value.

So would I. Dunno what I was thinking.

> (I've never heard of returning a status from such a pair of functions;
> who's going to sit and check the return value of every pixel operation?

SetColour was initially void. When I was writing GetColour, I started 
off with Colour GetColour(FrameBuffer *fb, unsigned long x, unsigned 
long y), and realised that I had no good way to complain if x or y were 
out of bounds. It all kind of went downhill from there. :-)

>   > For a more general line-drawing algorithm, look up Bresenham. Once you
>   > can draw an arbitrary line in any direction (it's not hard, honestly!),
>   > you can write yourself a DrawFace() function, at which point (I hope)
>   > there'll be no stopping you.
>
> You mean draw the edges of the face? Filling the interior is a bit
> harder.

A little bit, yes. I would do it like this:

1) if your triangle does not have a horizontal side, split it into two 
triangles that share a horizontal side. Then call this routine twice, 
once for each triangle. Otherwise:
2) for each row of the triangle, find the leftmost and rightmost pixels 
to be affected, using something like Bresenham (or indeed Wu) to make 
this determination.
3) Colour each relevant pixel in the row, using a horizontal line-draw.

Horizontal line-drawing is ideal because you can use memcpy. Paint one 
pixel the right colour. Now you can memcpy that pixel to the next one. 
Now you can memcpy those two pixels to the next two. Then you can memcpy 
those four pixels to the next four. And so on, until you've done half or 
more, at which point you do the rest in a single op. It's just book-keeping.

> But something to watch out for when drawing the face edges is to
> avoid drawing touching edges twice. So for a 'wireframe' rendering,
> working with edges rather than faces is better.

Unless, of course, you adopt Keith's idea of doing away with edges 
completely.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#59505

On 03/04/2015 06:02, Richard Heathfield wrote:
> On 02/04/15 20:09, Bartc wrote:

> And if you're going to use floating point anyway, my philosophy has
> always been to use double, for much the same reason that we generally
> use int rather than short int unless there is a specific reason to do
> otherwise.

(When I first starting doing this stuff, floating point was done in 
software. Double-precision was much slower, and I didn't start using it 
until I was sure of hardware support. Even now, I'm not sure that even 
common processors such as ARM fully support it in hardware.)

>> But 3D introduces other complications too. Your scheme will do to get
>> started.)

>>> But wait! A face has a colour.
>>
>> Eventually. But when you think about a scheme where vertices, edges and
>> faces are separate, which have the colour? Maybe it makes more sense for
>> a face to have the colour, but usually faces also form part of a
>> continuous surface of a single colour. So it's a bit wasteful to repeat
>> the same colour hundreds of times.
>
> That makes a lot of sense. So where would *you* store the colour? I
> suppose we could store it in the object structure (that is, the struct
> that contains the high level details for the structure, such as its
> current position, velocity, and acceleration).

There is no straightforward answer about where to store the colour. It 
all depends.

Possibly bringing in 3D at this level was a mistake. In 2D, you don't 
really deal with individual triangular faces much. You tend to have 
lines and shapes, with outlines and solid fill, and these may be just 
geometry, or part of a stored model complete with attributes such as colour.

However even in 3D, if Ford were designing a new vehicle body full of 
complicated curved surfaces, would they store a fixed colour for it? 
Cars come in a variety of colours!

>> You mean draw the edges of the face? Filling the interior is a bit
>> harder.
>
> A little bit, yes. I would do it like this:
>
> 1) if your triangle does not have a horizontal side, split it into two
> triangles that share a horizontal side. Then call this routine twice,
> once for each triangle. Otherwise:
> 2) for each row of the triangle, find the leftmost and rightmost pixels
> to be affected, using something like Bresenham (or indeed Wu) to make
> this determination.
> 3) Colour each relevant pixel in the row, using a horizontal line-draw.

If floating point is part of this and scaling of these triangles is 
allowed, even in 2D, then it can get more elaborate. You might be zoomed 
in so much into the triangle that all you need to do is fill the frame 
with the colour. Or you're zoomed in just enough to end up drawing a 
7-sided irregular polygon.

At some point you will need to convert coordinates which might 
conceivably be at -2.581e233 (thanks to your doubles!), into something 
more practical. Otherwise, there might be an awful lot of pixels to 
process before some of them end up in the framebuffer.

For these sorts of reason, I would have different tiers of API, with an 
integer-based 2D API at the bottom. Although floating point is also 
viable with a bit more work, and the 2D system in PostScript works 
extremely well using floating point.

(I think PostScript keeps geometry and colour separate too! However the 
sort of API I have in mind wouldn't concern itself with an object model, 
and I'm not sure PS does either.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#59506

W dniu piątek, 3 kwietnia 2015 12:40:38 UTC+2 użytkownik Bart napisał:
> Possibly bringing in 3D at this level was a mistake. In 2D, you don't 
> really deal with individual triangular faces much. You tend to have 
> lines and shapes, with outlines and solid fill, and these may be just 
> geometry, or part of a stored model complete with attributes such as colour.
> 
in real good looking 2d apps/games it is probably none of the above - its probably 
bitmap sprites or vector fill shapes (?) based 
on beziers (im not quite sure but probably those are two main options)

[toc] | [prev] | [next] | [standalone]

#59507

On 03/04/2015 11:52, fir wrote:
> W dniu piątek, 3 kwietnia 2015 12:40:38 UTC+2 użytkownik Bart napisał:
>> Possibly bringing in 3D at this level was a mistake. In 2D, you don't
>> really deal with individual triangular faces much. You tend to have
>> lines and shapes, with outlines and solid fill, and these may be just
>> geometry, or part of a stored model complete with attributes such as colour.
>>
> in real good looking 2d apps/games it is probably none of the above - its probably
> bitmap sprites or vector fill shapes (?) based
> on beziers (im not quite sure but probably those are two main options)

Yes, you have scalable vector graphics, and then images and textures of 
of which sprites are a form of.

And then you have text which might not fit into either of those 
categories (certainly, having scalable solid-filled text is rather 
specialised and hard to get right - I've tried it).

But this is about a fairly basic library and getting started.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#59508

W dniu piątek, 3 kwietnia 2015 13:06:08 UTC+2 użytkownik Bart napisał:
> On 03/04/2015 11:52, fir wrote:
> > W dniu piątek, 3 kwietnia 2015 12:40:38 UTC+2 użytkownik Bart napisał:
> >> Possibly bringing in 3D at this level was a mistake. In 2D, you don't
> >> really deal with individual triangular faces much. You tend to have
> >> lines and shapes, with outlines and solid fill, and these may be just
> >> geometry, or part of a stored model complete with attributes such as colour.
> >>
> > in real good looking 2d apps/games it is probably none of the above - its probably
> > bitmap sprites or vector fill shapes (?) based
> > on beziers (im not quite sure but probably those are two main options)
> 
> Yes, you have scalable vector graphics, and then images and textures of 
> of which sprites are a form of.
> 
> And then you have text which might not fit into either of those 
> categories (certainly, having scalable solid-filled text is rather 
> specialised and hard to get right - I've tried it).
> 
> But this is about a fairly basic library and getting started.
> 
ye but i would like to mention anyway that those simple shapes form lines probably do not get impresive looking game...

thus i need to head to beziers - i had not implemented it yet to much bezier curve is
very easy to draw
(its even fast) ->

void DrawBezier(float ax, float ay,
                float bx, float by,
                float cx, float cy,
                float dx, float dy, 
                  unsigned color)
{

  float step = 1.0/1000.;

  for(float t=0; t<=1; t+=step)
  {

    float t1 = 1.-t;

     float x = ax*t1*t1*t1 + 3*bx*t1*t1*t + 3*cx*t1*t*t + dx*t*t*t;
    float y = ay*t1*t1*t1 + 3*by*t1*t1*t + 3*cy*t1*t*t + dy*t*t*t;

    SetPixel(int(x),int(y), color);

  }

}

though i got 2 problems here
1) how to calculate how much pixels do i 
need to set (the length of the corve?)
[here above is hardcoded 1000 pixels, yuck]

2) if i will build a closed shape from few
such beziers, how do i should fill with a color to be fast?

(i was not doin or reading to much on it yet maybe someone could hint something)?

[toc] | [prev] | [next] | [standalone]

#59512

On 03/04/2015 12:36, fir wrote:

> thus i need to head to beziers - i had not implemented it yet to much bezier curve is
> very easy to draw

> void DrawBezier(float ax, float ay,
>                  float bx, float by,
>                  float cx, float cy,
>                  float dx, float dy,
>                    unsigned color)
> {
>
>    float step = 1.0/1000.;

> though i got 2 problems here
> 1) how to calculate how much pixels do i
> need to set (the length of the corve?)
> [here above is hardcoded 1000 pixels, yuck]

You can use the same method as for the line drawing: work out the 
extents of the curve and estimate the number of pixels. Although is 
quite a lot of work and the estimate might still be too low or too high.

So try a different approach:

Look at the thread "C-Programming", a post by Ben Bacarisse on 
17-12-2014, which gives a recursive way of creating Bezier curves.This 
way you don't need to calculate how many steps in advance.


> 2) if i will build a closed shape from few
> such beziers, how do i should fill with a color to be fast?

Convex or concave shape? Needing to be clipped or not? Crosses itself or 
not? With 'islands' or not?

One way is to start with a cleared 1-bit image the same size as the 
display, draw the closed shape into that, then floodfill the inside (and 
you work out the extents as you go along). Then use that as a mask to 
colour/shade the main display.

But there are many ways of filling a region defining by a border of set 
pixels (and yet others where the border is approximated by a closed 
polygon of short vectors).

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#59514

W dniu piątek, 3 kwietnia 2015 14:28:41 UTC+2 użytkownik Bart napisał:
> On 03/04/2015 12:36, fir wrote:
> 
> > thus i need to head to beziers - i had not implemented it yet to much bezier curve is
> > very easy to draw
> 
> > void DrawBezier(float ax, float ay,
> >                  float bx, float by,
> >                  float cx, float cy,
> >                  float dx, float dy,
> >                    unsigned color)
> > {
> >
> >    float step = 1.0/1000.;
> 
> > though i got 2 problems here
> > 1) how to calculate how much pixels do i
> > need to set (the length of the corve?)
> > [here above is hardcoded 1000 pixels, yuck]
> 
> You can use the same method as for the line drawing: work out the 
> extents of the curve and estimate the number of pixels. Although is 
> quite a lot of work and the estimate might still be too low or too high.
> 
> So try a different approach:
> 
> Look at the thread "C-Programming", a post by Ben Bacarisse on 
> 17-12-2014, which gives a recursive way of creating Bezier curves.This 
> way you don't need to calculate how many steps in advance.
> 

I found it it is :
>>>>>


 JohnF wrote: 
> 
>> Tim Rentsch <t...@alumni.caltech.edu> wrote: 
>>> <<snip>> 
>>> As for recursive implementations in C having no practical utility, 
>>> that may be true for factorial, but it certainly is not true for 
>>> other uses.  In particular, for Fibonacci numbers, the fastest 
>>> implementation in C I have seen used a recursive definition (ie, 
>>> the C code was itself recursive). <<snip>> 
>> 
>> Various algorithms, like generating bezier curves and some fractals, 
>> are naturally recursive -- pretty easy to express and code recursively,
>> and will pretty much drive you crazy if you try to think it through 
>> and code it iteratively, regardless of language. 
> 
> Some fractals, I'd agree with. Bezier curves, though? It never even occurred 
> to me to draw these recursively, and I didn't have any particular difficulty 
> with the iterative method. Am I doing something wrong? 

I am sure you are not doing anything wrong, but there are other ways. 

The usual recursive solution comes in two flavours both, based on what's 
called De Casteljau's algorithm.  In one flavour you use this 
numerically, but the prettiest version is a direct geometric realisation 
of it.  To 

  draw_curve(p1, c1, c2, p2); 

(that's the curve from p1 to p2 using c1 and c2 as control points) you 
calculate 6 mid-points and draw two smaller curves: 

  p1c1 = mid(p1, c1); 
  c1c2 = mid(c1, c2); 
  c2p2 = mid(c2, p2); 
  p1c1c1c2 = mid(p1c1, c1c2); 
  c1c2c2p2 = mid(c1c2, c2p2); 
  m = mid(p1c1c1c2, c1c2c2p2); 

  draw_curve(p1, p1c1, p1c1c1c2, m); 
  draw_curve(m, c1c2c2p2, c2p2, p2); 

To see what's happening, draw the lines p1-c1, c1-c2 and c2-p2.  Now 
draw lines between the mid-points of each consecutive pair of these 
lines.  Then do the same between the mid-points of every consecutive 
pair you now have... and so on.  (If you are like me, you need to draw 
it to see what's happening but it's just the high-tech version of the 
art with string and nails that I remember doing at school.) 

The recursion stops (and you draw a line) when some metric becomes small 
enough.  You can use a recursion count, some measure of the distance 
between the end points, or some measure of the "bend" in the curve (or 
some combination of these, of course). 

<<<<<<<<<

do this 
 draw_curve(p1, p1c1, p1c1c1c2, m); 
  draw_curve(m, c1c2c2p2, c2p2, p2); 
recipe is special that it preserves the shape when dividing the curve on two?
(control points are outside of the bezier so
im not sure what mid of some p1 and c1 yields to)

this may be usefull but it is a lot of mid's
calculation on each pair - compared to strightforward multiplies in normal bezier
I will most probably test it but maybe there is some quick aproximation ot the length that will run ok? (could be bit easier) I will try to find something






> 
> > 2) if i will build a closed shape from few
> > such beziers, how do i should fill with a color to be fast?
> 
> Convex or concave shape? Needing to be clipped or not? Crosses itself or 
> not? With 'islands' or not?
> 
> One way is to start with a cleared 1-bit image the same size as the 
> display, draw the closed shape into that, then floodfill the inside (and 
> you work out the extents as you go along). Then use that as a mask to 
> colour/shade the main display.
> 
> But there are many ways of filling a region defining by a border of set 
> pixels (and yet others where the border is approximated by a closed 
> polygon of short vectors).
> 

this flodd fill i remember form C64 is dead slow think, I think i may only consider not cliped, closed, no-holes version (made from one long curve of n beziers) but it could be both convex-and concave

maybe i just need store x points in lines
then if sgot such result

line[17] is  20  56  59 104 189 234
i konw i need to draw 3 
x-scanlines: 20-56 59-104 189-234
but this will fail if given x point is
both move up move down place (and is 0-pixel
long scanline for itself) how to resolve this
?


> -- 
> Bartc

[toc] | [prev] | [next] | [standalone]

#59521

W dniu piątek, 3 kwietnia 2015 15:04:45 UTC+2 użytkownik fir napisał:
> W dniu piątek, 3 kwietnia 2015 14:28:41 UTC+2 użytkownik Bart napisał:
> > On 03/04/2015 12:36, fir wrote:
> > 
> > > thus i need to head to beziers - i had not implemented it yet to much bezier curve is
> > > very easy to draw
> > 
> > > void DrawBezier(float ax, float ay,
> > >                  float bx, float by,
> > >                  float cx, float cy,
> > >                  float dx, float dy,
> > >                    unsigned color)
> > > {
> > >
> > >    float step = 1.0/1000.;
> > 
> > > though i got 2 problems here
> > > 1) how to calculate how much pixels do i
> > > need to set (the length of the corve?)
> > > [here above is hardcoded 1000 pixels, yuck]
> > 
> > You can use the same method as for the line drawing: work out the 
> > extents of the curve and estimate the number of pixels. Although is 
> > quite a lot of work and the estimate might still be too low or too high.
> > 
> > So try a different approach:
> > 
> > Look at the thread "C-Programming", a post by Ben Bacarisse on 
> > 17-12-2014, which gives a recursive way of creating Bezier curves.This 
> > way you don't need to calculate how many steps in advance.
> > 
> 
> I found it it is :
> >>>>>
> 
> 
>  JohnF wrote: 
> > 
> >> Tim Rentsch <t...@alumni.caltech.edu> wrote: 
> >>> <<snip>> 
> >>> As for recursive implementations in C having no practical utility, 
> >>> that may be true for factorial, but it certainly is not true for 
> >>> other uses.  In particular, for Fibonacci numbers, the fastest 
> >>> implementation in C I have seen used a recursive definition (ie, 
> >>> the C code was itself recursive). <<snip>> 
> >> 
> >> Various algorithms, like generating bezier curves and some fractals, 
> >> are naturally recursive -- pretty easy to express and code recursively,
> >> and will pretty much drive you crazy if you try to think it through 
> >> and code it iteratively, regardless of language. 
> > 
> > Some fractals, I'd agree with. Bezier curves, though? It never even occurred 
> > to me to draw these recursively, and I didn't have any particular difficulty 
> > with the iterative method. Am I doing something wrong? 
> 
> I am sure you are not doing anything wrong, but there are other ways. 
> 
> The usual recursive solution comes in two flavours both, based on what's 
> called De Casteljau's algorithm.  In one flavour you use this 
> numerically, but the prettiest version is a direct geometric realisation 
> of it.  To 
> 
>   draw_curve(p1, c1, c2, p2); 
> 
> (that's the curve from p1 to p2 using c1 and c2 as control points) you 
> calculate 6 mid-points and draw two smaller curves: 
> 
>   p1c1 = mid(p1, c1); 
>   c1c2 = mid(c1, c2); 
>   c2p2 = mid(c2, p2); 
>   p1c1c1c2 = mid(p1c1, c1c2); 
>   c1c2c2p2 = mid(c1c2, c2p2); 
>   m = mid(p1c1c1c2, c1c2c2p2); 
> 
>   draw_curve(p1, p1c1, p1c1c1c2, m); 
>   draw_curve(m, c1c2c2p2, c2p2, p2); 
> 
> To see what's happening, draw the lines p1-c1, c1-c2 and c2-p2.  Now 
> draw lines between the mid-points of each consecutive pair of these 
> lines.  Then do the same between the mid-points of every consecutive 
> pair you now have... and so on.  (If you are like me, you need to draw 
> it to see what's happening but it's just the high-tech version of the 
> art with string and nails that I remember doing at school.) 
> 
> The recursion stops (and you draw a line) when some metric becomes small 
> enough.  You can use a recursion count, some measure of the distance 
> between the end points, or some measure of the "bend" in the curve (or 
> some combination of these, of course). 
> 
> <<<<<<<<<
> 
> do this 
>  draw_curve(p1, p1c1, p1c1c1c2, m); 
>   draw_curve(m, c1c2c2p2, c2p2, p2); 
> recipe is special that it preserves the shape when dividing the curve on two?
> (control points are outside of the bezier so
> im not sure what mid of some p1 and c1 yields to)
> 
> this may be usefull but it is a lot of mid's
> calculation on each pair - compared to strightforward multiplies in normal bezier
> I will most probably test it but maybe there is some quick aproximation ot the length that will run ok? (could be bit easier) I will try to find something
> 
> 
> 
i found some post on it

>>>>>>>

The generic formula for a parametric curve length is

Sum[0,1]( sqrt((dx/dt)^2+(dy/dt)^2+(dz/dt)^2)*dt )

BTW, to "verify", for a classical function curve y=f(x), just replace t by x, discard z and you get Sum[xa,xb]( sqrt(1+(dy/dx)^2)*dx )

Since your Bezier spline is of degree 3, dx/dt is of degree 2. (dx/dt)^2 is of degree 4, etc ... All in all you end up with the integration of the square root of a degree 4 polynomial in t.

Then there should be enough litterature on the www for you concerning numerical or formal integration techniques. But this can easilly be solved formally :

Go there http://torte.cs.berkeley.edu:8010/tilu and you'll get the formal answer you need. Select Mathematica as language and type (indefinite integration : finding a primitive):

sqrt(a*x^4+b*x^3+c*x^2+d*x+e)

You'll get (control by differentiating the result, it's easy):

             5          4          2          3
sqrt (1/5 a x  + 1/4 b x  + 1/2 d x  + 1/3 c x  + e x)


And in fact replace x by 1 since you just integrated between 0 and 1 and this makes 0 at 0.

length = sqrt(1/5a + 1/4b + 1/2d + 1/3c + e)

I hope you understood how to get a, b, c, d and e from your spline.

With a quick SSE or 3DNow sqrt or the "Carmack" sqrt, you can have both precision and speed. Google with Gamedev search engine to know more about quick sqrts. 

<<<<<<<<<<<<<<<<<

but here is not explained how to get those a b c d e values....

Other idea comed to my mind is to take say 5 segments of the bezier cals 5 sqrt lengths for lines aadd some 50% and take this - a bit slow
probably

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web