“We are doomed”

[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

[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.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

[Kaz Kylheku]

On 2024-01-19, Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> 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: @Kazi...@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

[Chris M. Thomasson]

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:

https://youtu.be/KRkKZj9s3wk

[Malcolm McLean]

On 19/01/2024 18:35, Kaz Kylheku wrote:
> On 2024-01-19, Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>> 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.

[Chris M. Thomasson]

On 1/20/2024 5:59 AM, Malcolm McLean wrote:
> On 19/01/2024 18:35, Kaz Kylheku wrote:
>> On 2024-01-19, Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>>> 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]

On 2024-01-20, Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> On 19/01/2024 18:35, Kaz Kylheku wrote:
>> On 2024-01-19, Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>>> 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 ]

[immibis]

On 1/19/24 19:17, Malcolm McLean wrote:
> 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]

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.

[Malcolm McLean]

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.

[Fred. Zwarts]

Op 22.jan.2024 om 12:16 schreef Malcolm McLean:

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]

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.

[Chris M. Thomasson]

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]

And 4-ary with (x, y, z, w)

Again I am quite fond of the GLM library. It's just nice to me.

[MarioCCCP]

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