Discussion:
“We are doomed”
(too old to reply)
Lynn McGuire
2024-01-16 22:03:41 UTC
Permalink
“We are doomed”
https://www.carette.xyz/posts/we_are_doomed/

“The only system with a good software compatibility that I know is
Windows, and this explains a ton of things keeping very old UI/UX
frameworks, software and APIs to run, for example, Windows 95 compatible
games like “Roller Coaster Tycoon”.”

“Otherwise, you are doomed.”

The C++ committee has screwed up and continues to screw up by not
creating a graphics standard for C++.

Lynn
Malcolm McLean
2024-01-19 18:17:34 UTC
Permalink
Post by Lynn McGuire
“We are doomed”
   https://www.carette.xyz/posts/we_are_doomed/
“The only system with a good software compatibility that I know is
Windows, and this explains a ton of things keeping very old UI/UX
frameworks, software and APIs to run, for example, Windows 95 compatible
games like “Roller Coaster Tycoon”.”
“Otherwise, you are doomed.”
The C++ committee has screwed up and continues to screw up by not
creating a graphics standard for C++.
Lynn
One problem that could be very easily fixed is that there is no standard
representation of a point or a vector. Whilst generally it's just a POD
structure with x and y members, the name varies, and sometimes the
dimensions are referred to by index instead of by letter. You can also
have a philosophical discussion about whether points and vectors should
be the same structures or incompatible structures.
But a simple standardisation would mean the end of pointless editing of
code just to conform to whatever the host program has chosen.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Kaz Kylheku
2024-01-19 18:35:32 UTC
Permalink
Post by Malcolm McLean
One problem that could be very easily fixed is that there is no standard
representation of a point or a vector. Whilst generally it's just a POD
structure with x and y members, the name varies, and sometimes the
For code working with 2D vectors, designers should consider complex numbers.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
Malcolm McLean
2024-01-20 13:59:08 UTC
Permalink
Post by Kaz Kylheku
Post by Malcolm McLean
One problem that could be very easily fixed is that there is no standard
representation of a point or a vector. Whilst generally it's just a POD
structure with x and y members, the name varies, and sometimes the
For code working with 2D vectors, designers should consider complex numbers.
That's a nice idea.

But I've never seen code where the horizontal axis is "real" and the
vertical "imaginary", except of course in code designed to demonstrate
complex numbers as such. Mandelbrot is my favourite test program when
getting a new system.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Chris M. Thomasson
2024-01-20 19:22:47 UTC
Permalink
Post by Malcolm McLean
Post by Kaz Kylheku
Post by Malcolm McLean
One problem that could be very easily fixed is that there is no standard
representation of a point or a vector. Whilst generally it's just a POD
structure with x and y members, the name varies, and sometimes the
For code working with 2D vectors, designers should consider complex numbers.
That's a nice idea.
But I've never seen code where the horizontal axis is "real" and the
vertical "imaginary", except of course in code designed to demonstrate
complex numbers as such. Mandelbrot is my favourite test program when
getting a new system.
Same here! :^D
Kaz Kylheku
2024-01-21 04:06:17 UTC
Permalink
Post by Malcolm McLean
Post by Kaz Kylheku
Post by Malcolm McLean
One problem that could be very easily fixed is that there is no standard
representation of a point or a vector. Whilst generally it's just a POD
structure with x and y members, the name varies, and sometimes the
For code working with 2D vectors, designers should consider complex numbers.
That's a nice idea.
But I've never seen code where the horizontal axis is "real" and the
vertical "imaginary", except of course in code designed to demonstrate
complex numbers as such. Mandelbrot is my favourite test program when
getting a new system.
Complex numbers are used for expressing mappings that have geometric
interpretations.

In 2D computer graphics, they are convenient. E.g. to rotate
a vector that is a complex number z = a + ib, you just multiply by
a complex number that is on the unit circle representing that
angle cos(theta) + i sin(theta) .

The multiplication math is exactly the same as

[ cos -sin ] [ a ]
[ sin cos ] [ b ]

Because when you multiply two complex nubmers (c + id)(a + ib),
the FOIL rule produces

ca + icb + ida + iidb

= (ca - db) + i(cb + da).

And that's just

[ c -d ] [ a ] = [ ca - db ]
[ d c ] [ b ] = [ da + cb ]
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
Malcolm McLean
2024-01-22 11:22:25 UTC
Permalink
Post by Kaz Kylheku
Post by Malcolm McLean
Post by Kaz Kylheku
Post by Malcolm McLean
One problem that could be very easily fixed is that there is no standard
representation of a point or a vector. Whilst generally it's just a POD
structure with x and y members, the name varies, and sometimes the
For code working with 2D vectors, designers should consider complex numbers.
That's a nice idea.
But I've never seen code where the horizontal axis is "real" and the
vertical "imaginary", except of course in code designed to demonstrate
complex numbers as such. Mandelbrot is my favourite test program when
getting a new system.
Complex numbers are used for expressing mappings that have geometric
interpretations.
In 2D computer graphics, they are convenient. E.g. to rotate
a vector that is a complex number z = a + ib, you just multiply by
a complex number that is on the unit circle representing that
angle cos(theta) + i sin(theta) .
The multiplication math is exactly the same as
[ cos -sin ] [ a ]
[ sin cos ] [ b ]
Because when you multiply two complex nubmers (c + id)(a + ib),
the FOIL rule produces
ca + icb + ida + iidb
= (ca - db) + i(cb + da).
And that's just
[ c -d ] [ a ] = [ ca - db ]
[ d c ] [ b ] = [ da + cb ]
Yes I know. I did complex numbers at high school.

But whilst you could use the Argand plane as your graphics surface and
thus represent all points as complex numbers, I've never actually seen
anyone do so, and the axes are always given different labels. Except of
course in Mandelbrots or other programs concerned with complex numbers
themselves.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Chris M. Thomasson
2024-01-22 20:22:35 UTC
Permalink
Post by Malcolm McLean
Post by Kaz Kylheku
Post by Malcolm McLean
Post by Kaz Kylheku
Post by Malcolm McLean
One problem that could be very easily fixed is that there is no standard
representation of a point or a vector. Whilst generally it's just a POD
structure with x and y members, the name varies, and sometimes the
For code working with 2D vectors, designers should consider complex numbers.
That's a nice idea.
But I've never seen code where the horizontal axis is "real" and the
vertical "imaginary", except of course in code designed to demonstrate
complex numbers as such. Mandelbrot is my favourite test program when
getting a new system.
Complex numbers are used for expressing mappings that have geometric
interpretations.
In 2D computer graphics, they are convenient. E.g. to rotate
a vector that is a complex number z = a + ib, you just multiply by
a complex number that is on the unit circle representing that
angle   cos(theta) + i sin(theta) .
The multiplication math is exactly the same as
   [ cos -sin ] [ a ]
   [ sin  cos ] [ b ]
Because when you multiply two complex nubmers (c + id)(a + ib),
the FOIL rule produces
    ca + icb + ida + iidb
   = (ca - db) + i(cb + da).
And that's just
   [ c  -d ] [ a ]  =  [ ca - db ]
   [ d   c ] [ b ]  =  [ da + cb ]
Yes I know. I did complex numbers at high school.
But whilst you could use the Argand plane as your graphics surface and
thus represent all points as complex numbers, I've never actually seen
anyone do so, and the axes are always given different labels. Except of
course in Mandelbrots or other programs concerned with complex numbers
themselves.
Usually a vector, say 2-ary (x, y), x is the horizontal axis and y is
the vertical axis. This matches a complex number x + yi:

+y
|
-x--0--+x
|
-y

x is real, y is imaginary. :^)
Chris M. Thomasson
2024-01-19 21:58:26 UTC
Permalink
Post by Malcolm McLean
Post by Lynn McGuire
“We are doomed”
    https://www.carette.xyz/posts/we_are_doomed/
“The only system with a good software compatibility that I know is
Windows, and this explains a ton of things keeping very old UI/UX
frameworks, software and APIs to run, for example, Windows 95
compatible games like “Roller Coaster Tycoon”.”
“Otherwise, you are doomed.”
The C++ committee has screwed up and continues to screw up by not
creating a graphics standard for C++.
Lynn
One problem that could be very easily fixed is that there is no standard
representation of a point or a vector. Whilst generally it's just a POD
structure with x and y members, the name varies, and sometimes the
dimensions are referred to by index instead of by letter. You can also
have a philosophical discussion about whether points and vectors should
be the same structures or incompatible structures.
But a simple standardisation would mean the end of pointless editing of
code just to conform to whatever the host program has chosen.
Fwiw, I am very fond of the following header only library:

https://github.com/g-truc/glm

Works great and makes it rather straightforward to port to GLSL shaders.
I basically use it everyday for stuff like:


immibis
2024-01-22 00:22:00 UTC
Permalink
Post by Malcolm McLean
One problem that could be very easily fixed is that there is no standard
representation of a point or a vector. Whilst generally it's just a POD
structure with x and y members, the name varies, and sometimes the
dimensions are referred to by index instead of by letter. You can also
have a philosophical discussion about whether points and vectors should
be the same structures or incompatible structures.
But a simple standardisation would mean the end of pointless editing of
code just to conform to whatever the host program has chosen.
And what should be the data type of the coefficients of the vector? And
what should? Why not also have matrices? What is the maximum dimension
supported? Are homogeneous coordinates a built-in feature? No, leave the
graphics stuff to a graphics team.
Malcolm McLean
2024-01-22 11:16:41 UTC
Permalink
Post by immibis
Post by Malcolm McLean
One problem that could be very easily fixed is that there is no
standard representation of a point or a vector. Whilst generally it's
just a POD structure with x and y members, the name varies, and
sometimes the dimensions are referred to by index instead of by
letter. You can also have a philosophical discussion about whether
points and vectors should be the same structures or incompatible
structures.
But a simple standardisation would mean the end of pointless editing
of code just to conform to whatever the host program has chosen.
And what should be the data type of the coefficients of the vector? And
what should? Why not also have matrices? What is the maximum dimension
supported? Are homogeneous coordinates a built-in feature? No, leave the
graphics stuff to a graphics team.
It should take a template, so any type can be used for the coefficients.
Unless you have some weird and wonderful ideas, it will of course be
scalar.
I'd recommend a 2D with x and y and a 3D with x, y and z. Humanity is
not going to be elevated to a higher dimension any time soon. No
homogenous co-ordinates. No angle / magnitude notation. No need for
matrices because we already have a natural representation of the these,
since C++ supports 2 dimensional fixed size array.
Needing to store points in 2D or 3D space is a common requirement, and
code needs to communicate with other modules. One of which will be the
graphics system, which may well have requirements beyond simple points
in space, but will include such a requirement.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Fred. Zwarts
2024-01-22 11:34:46 UTC
Permalink
Post by Malcolm McLean
Post by immibis
Post by Malcolm McLean
One problem that could be very easily fixed is that there is no
standard representation of a point or a vector. Whilst generally it's
just a POD structure with x and y members, the name varies, and
sometimes the dimensions are referred to by index instead of by
letter. You can also have a philosophical discussion about whether
points and vectors should be the same structures or incompatible
structures.
But a simple standardisation would mean the end of pointless editing
of code just to conform to whatever the host program has chosen.
And what should be the data type of the coefficients of the vector?
And what should? Why not also have matrices? What is the maximum
dimension supported? Are homogeneous coordinates a built-in feature?
No, leave the graphics stuff to a graphics team.
It should take a template, so any type can be used for the coefficients.
Unless you have some weird and wonderful ideas, it will of course be
scalar.
I'd recommend a 2D with x and y and a 3D with x, y and z. Humanity is
not going to be elevated to a higher dimension any time soon. No
homogenous co-ordinates. No angle / magnitude notation. No need for
matrices because we already have a natural representation of the these,
since C++ supports 2 dimensional fixed size array.
Needing to store points in 2D or 3D space is a common requirement, and
code needs to communicate with other modules. One of which will be the
graphics system, which may well have requirements beyond simple points
in space, but will include such a requirement.
According to Einstein, humanity lives already in a four dimensional
space; time is the fourth dimension.
There are many problems in physics and other fields with even more than
4 dimensions, so it would be short-sighted to limit the library to 3
dimensions.
In addition one could ask how far the standard library must go. What
operations must be supported? Calculate the length of a vector, allowing
non-Euclidian spaces?
Malcolm McLean
2024-01-22 12:31:57 UTC
Permalink
Post by Fred. Zwarts
Post by Malcolm McLean
Post by immibis
Post by Malcolm McLean
One problem that could be very easily fixed is that there is no
standard representation of a point or a vector. Whilst generally
it's just a POD structure with x and y members, the name varies, and
sometimes the dimensions are referred to by index instead of by
letter. You can also have a philosophical discussion about whether
points and vectors should be the same structures or incompatible
structures.
But a simple standardisation would mean the end of pointless editing
of code just to conform to whatever the host program has chosen.
And what should be the data type of the coefficients of the vector?
And what should? Why not also have matrices? What is the maximum
dimension supported? Are homogeneous coordinates a built-in feature?
No, leave the graphics stuff to a graphics team.
It should take a template, so any type can be used for the
coefficients. Unless you have some weird and wonderful ideas, it will
of course be scalar.
I'd recommend a 2D with x and y and a 3D with x, y and z. Humanity is
not going to be elevated to a higher dimension any time soon. No
homogenous co-ordinates. No angle / magnitude notation. No need for
matrices because we already have a natural representation of the
these, since C++ supports 2 dimensional fixed size array.
Needing to store points in 2D or 3D space is a common requirement, and
code needs to communicate with other modules. One of which will be the
graphics system, which may well have requirements beyond simple points
in space, but will include such a requirement.
According to Einstein, humanity lives already in a four dimensional
space; time is the fourth dimension.
There are many problems in physics and other fields with even more than
4 dimensions, so it would be short-sighted to limit the library to 3
dimensions.
In addition one could ask how far the standard library must go. What
operations must be supported? Calculate the length of a vector, allowing
non-Euclidian spaces?
No-one is saying that you can't devise your own structures if you want
to write programs to solve problems in general relativity. The idea is
to have a common standard for the common requirement to represent pints
and vectors in 2d and 3d spaces, so that routines writen in C++ can
communicate with each other without the need for adapter code or rewriting.
However having decided on a representation for points, there is also a
very strong case for a standard library for basic operations on those
points, such as taking the length of a vector. However probably not
non-Euclidian spaces. Again, some people will want to write software
that operates in Hilbert space or other non-Euclidean space, but it's
likely to be specialised, and so you can't expect much support from the
standard library.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
Chris M. Thomasson
2024-01-22 20:24:09 UTC
Permalink
Post by Malcolm McLean
Post by immibis
Post by Malcolm McLean
One problem that could be very easily fixed is that there is no
standard representation of a point or a vector. Whilst generally it's
just a POD structure with x and y members, the name varies, and
sometimes the dimensions are referred to by index instead of by
letter. You can also have a philosophical discussion about whether
points and vectors should be the same structures or incompatible
structures.
But a simple standardisation would mean the end of pointless editing
of code just to conform to whatever the host program has chosen.
And what should be the data type of the coefficients of the vector?
And what should? Why not also have matrices? What is the maximum
dimension supported? Are homogeneous coordinates a built-in feature?
No, leave the graphics stuff to a graphics team.
It should take a template, so any type can be used for the coefficients.
Unless you have some weird and wonderful ideas, it will of course be
scalar.
I'd recommend a 2D with x and y and a 3D with x, y and z. Humanity is
not going to be elevated to a higher dimension any time soon. No
homogenous co-ordinates. No angle / magnitude notation. No need for
matrices because we already have a natural representation of the these,
since C++ supports 2 dimensional fixed size array.
Needing to store points in 2D or 3D space is a common requirement, and
code needs to communicate with other modules. One of which will be the
graphics system, which may well have requirements beyond simple points
in space, but will include such a requirement.
And 4-ary with (x, y, z, w)

Again I am quite fond of the GLM library. It's just nice to me.
MarioCCCP
2024-01-31 00:17:20 UTC
Permalink
Post by Malcolm McLean
Post by immibis
Post by Malcolm McLean
One problem that could be very easily fixed is that there
is no standard representation of a point or a vector.
Whilst generally it's just a POD structure with x and y
members, the name varies, and sometimes the dimensions
are referred to by index instead of by letter. You can
also have a philosophical discussion about whether points
and vectors should be the same structures or incompatible
structures.
But a simple standardisation would mean the end of
pointless editing of code just to conform to whatever the
host program has chosen.
And what should be the data type of the coefficients of
the vector? And what should? Why not also have matrices?
What is the maximum dimension supported? Are homogeneous
coordinates a built-in feature? No, leave the graphics
stuff to a graphics team.
It should take a template, so any type can be used for the
coefficients. Unless you have some weird and wonderful
ideas, it will of course be scalar.
I'd recommend a 2D with x and y and a 3D with x, y and z.
Humanity is not going to be elevated to a higher dimension
any time soon. No homogenous co-ordinates. No angle /
magnitude notation. No need for matrices because we already
have a natural representation of the these, since C++
supports 2 dimensional fixed size array.
Needing to store points in 2D or 3D space is a common
requirement, and code needs to communicate with other
modules. One of which will be the graphics system, which may
well have requirements beyond simple points in space, but
will include such a requirement.
Looking at the variety of image formats, I tend to think
that the coordinate system and RAM representation is still
the least of the problems, and that colour space
representation (bits depths, order, endianness, transparency
support) could be even worse.
Also, at some point, every library has to interact with the
OS to load/unload images into the display driver, which is
at best posix-copliant, but still depends a lot on the OS
internals.

Graphics that wont' show up on screen is not very appealing
or useful.
Here a lot of graphic SW had to be rewritten migrating from
X to Wayland.

So RAM representation is really the least hard part. The
worse is how to load/save a variety of formats to/from disk,
and how to display the results on screen. How to move large
block of pixels avoinding flickering, etc

Since external libraries handle all this, it's not that
difficult to have also its own RAM representation of pixels,
vectors and geometry.
I think that creating a standard for this won't solve the
other main problems.
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP
Loading...