I am looking for help adding in a bunch more features to my real time graphics and physics simulation library. Here is a very brief overview with some screenshots and sources.

https://github.com/sysrpl/Tiny.Sim

I need help finishing the conversion to SVG based widget theming and my UI designer that uses JSON either in resources or dynamically in code, to generate UI scripts.

I'm sure the graphics part is probably OK, I won't comment on that.

But can you explain the logic behind Tiny.System ?

You have basically copied the whole of SysUtils, even redefined Exception and hooked into the exception handling functionality.

Why on earth would you do that, as it makes your code not interoperable with the SysUtils unit, meaning 99.99% of other object pascal code out there ?

If you raise an Exception object or any of its redefined descendents, any unit out there that uses SysUtils will not catch it since it is another class tree entirely.

It looks like a serious case of the 'Not Invented Here' symptom.

In my opinion, people would be crazy to help out with this effort, it's clearly a dead end.

Michael.

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

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.

'better this or that' is a matter of opinion. I won't argue that.

Please stick to facts:
your code has demonstrably become inoperable with the rest of FPC. Since there are many things you do not provide but which are needed in real-world programs, that makes it de facto useless.

Why we would forbid or discourage anyone to read the source code of an open source system is beyond me. That's why we write open source software, so you can read it ?

That aside, I don't see how your system differs from the sysutils we ship, and hence how it solves the problems you mention, in particular you're also supposed to "just know it".

I hope you or others here are not offended by either my by my library design or my rational included in this reposne.

I am not at all offended, rather the opposite:
I think it is a great pity that your code becomes inoperable with the rest of the Object Pascal ecosystem, hence my original question of "why?".

I would love to use your graphics library, but I won't because then I cannot use the rest of FPC together with it, effectively making your system useless to me, no matter how well the graphics layer works.

If you don't like the SysUtils API, I can understand it, since I myself think it has become bloated over the years. Alas, for Delphi compatibility, we must follow suit. (although some things can be remedied, see below), that you pose Tiny.System as an alternative for this: also fine, no problem.

But there is IMHO no valid reason not to base Tiny.System on top of sysutils for exception handling, except the earlier mentioned 'not invented here'.

The only solution I can think of is to split out the exception handling of sysutils into a lower-level unit with some glue to make up for the format constructor and type aliases for backwards compatibility (an old idea of mine). Then you could strip the exception code from Tiny.System and use this new unit and all would interoperate again.

But maybe then you'll probably bring up the 'unreable code' argument again ? :/

Michael.

Michael,

Since there are many things you do not provide but which are needed in real-world programs, that makes it de facto useless.

This library is intended for fast 2D/3D animated graphics with 2D physics simulations. These can be applied to things like games, kiosks, video playback, and a bunch of other use cases. Mind you I also have network sockets, a themeable UI widget system and with a designer, and other useful and fun stuff (animation storyboards, sprites, shader object and vertex buffer helpers, and so on). If you feel that providing a small runtime built around SDL2 that provides a clean start (no SysUtils, Classes, Graphics, Controls, or Forms units) makes for useless real-world programs then I don't know what else can be said to you.

Your needs are fairly limited, it seems it is centered around graphics. This is certainly one aspect of programs.

But a real-world program as I make them daily needs much more than that. What about report rendering, Database access, web components, services, various file formats ?

Just take your pick from the rich libraries provided by FPC or Lazarus. Almost none of them can be used since most use exceptions.

Yes, one could reinvent the wheel for all of them, no doubt, if you want to reinvent the wheel.

Like I said: "not invented here" syndrome.

And not very willing to cooperate either, judging by your reply. Pity.

Michael.

Thank you for your opinion.