Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: chosing "small 2d graphics library" interface |
| Date | 2015-04-03 06:02 +0100 |
| Organization | go, ion artisan! |
| Message-ID | <mfl6ra$j7$1@dont-email.me> (permalink) |
| References | <ba08a0b0-e761-430f-9c23-458f7f14667d@googlegroups.com> <e59b0d75-7803-4223-aefb-74988f23be81@googlegroups.com> <mfjcqk$cs2$1@dont-email.me> <mfk43f$clv$1@dont-email.me> |
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
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web