[fpc-pascal] Here is real time graphics and physics simulation library

[Anthony Walter]

Michael, it's the same logic behind my now 12 year old Bare game system
that did the exact same thing. I am creating a small lPascal ibrary that
removes a lot of cruft and depends minimally on SDL for creating windows,
managing input, handling sound, threads / mutexes. and move most of the
core of what you need into a single unit (Tiny.System). In to browsable and
organized uint replaced all string handling with much more efficient and
powerful functions (see my FTP client and other socket protocols, my JSON
parser, ), I also add in multicast delegates for events, path handling,
file handling, file search, stream handling, and better threads (my simple
threads were copied into ).

One of the big problems IMO of the FPC base library, as compared to Delphi,
which I have brought up here before, is that in 1995 - 2001 while people
were using Delphi, they could learn by reading the source code to
SystUtils, Classes, Controls. This is something I found to be invaluable,
not only as a much better way of gaining an understanding of what is
happening, but also a better way of debugging and painting.  As I have
mentioned before, and have received the response that you're not supposed
to read the source code with the FPC base library, you're supposed to just
already know it.

Here are some tidbits from one of those past discussions"

> "I cannot share code, obviously, but I'll say that the code is a big mess
of
> IFDEFS, used in what seems to me an inconsistent manner (if there is any
logic, I fail
> to see it). Lazarus has understanding of IFDefs, but the Delphi IDE does
> not (just as it does not understand include files), killing the code
> navigation, making it hard to navigate or understand these unit."

> "I normally do not visit these units, so it doesn't harm me, but when I by
> accident ended up there I remarked it...
> I think the problem is more on the poor guys that must maintain it :)"
>
> "These units are not this way for the sake of browsing, but for the sake
of
> maintainability."


> "And honestly, I cannot even remember when I had to look up something in
> sysutils or system. I expect experienced people to know these units better
> than the back of their hand. For beginners I think documentation is better
> suited."

And lastly:

> "In short: the RTL will stay as it is, because it's a proven design
without
> better alternatives available."

Well, here I present one alternative from my own imagination. Maybe some
people might see this alternative and find inspiration, where in this
alternative most of the stuff you need for your general purpose programming
in one unit, and other more specialized functionality in others. For
example the the Tiny.Application has window and context creation, base
scene and widget, as well as input from mouse, keyboard, joystick, and
haptics. The Tiny.Graphics unit defines everything you need for drawing as
well as image handling. The Tiny.Physics unit has everything you need for
physics simulation. Everything is organized into browsable units, with
documentation right above most everything (in the form of comments).

Regarding separating the documentation, I am not sure if you remember
<https://cache.getlazarus.org/images/desktop/bare-documentation.png> but my
Bare library has a really good HTML based help system that is autogenerated
from the source code. This Tiny library will use my same HTML help
generator when I finish adding in a few more features including converting
themes to use SVG theme definition files and a UI designer which uses JSON
to store and recall UIs based on the custom widget system. My HTML help
generator also relies heavily on both grouping content (via the [group]
indicator in comments, but also includes detailed information about each
unit).

Oh and to preempt a side discussion about why also I wrote a widget system
(why not just use the LCL controls right?) here is a brief demonstration
from the SVG icons playground demo included in this release:

https://streamable.com/cv137g

I hope you or others here are not offended by either my by my library
design or my rational included in this reposne.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20220731/eb4231ca/attachment.htm>