On 22/01/24 12:16, Malcolm McLean wrote:
On 22/01/2024 00:22, immibis wrote:
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.
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)