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

[Marco van de Voort via fpc-pascal]

On 1-8-2022 11:12, Michael Van Canneyt via fpc-pascal wrote:


Hence my proposal to refactor it in sysutils, so at least the 
exception handling

can be kept common to all units.


His main objection seems to be the IFDEFING, which is hard to avoid in a 
20 targets + compiler.


Also, the browsability is doable with lazarus (which processes %MAINUNIT 
etc for navigation), and the OP doesn't explain what he used where 
source navigation failed.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Michael Van Canneyt via fpc-pascal]

On Mon, 1 Aug 2022, Ingemar Ragnemalm via fpc-pascal wrote:



Den 2022-08-01 kl. 09:40, skrev fpc-pascal-requ...@lists.freepascal.org:

Date: Sun, 31 Jul 2022 09:05:56 -0400
From: 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 ).


I have exactly the same principle for all code I create for my teaching. I 
maximize transparency and keep the size down. For graphics, I go even further 
and only depend on OpenGL and the underlying window system.


There are big libraries with lots of bells and whistles. They can be useful, 
but not to get started with. I see myself replacing 100 files with one, 
megabytes of code with kilobytes.


It is pretty hard to balance usability and minimum size but I think I am 
doing fairly well.


So, reimplementing to something smaller and more transparent is not a bad 
thing at all. It is a matter of goals.


I agree, and I don't argue with the desire to have a set of separate
routines which suits someones goals better.

But the exception handling is a real problem, because it affects ALL units,
regardless of whether it uses your 'better API' or not: 
as said it renders the code inoperable with all other code.


Hence my proposal to refactor it in sysutils, so at least the exception handling
can be kept common to all units.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Ingemar Ragnemalm via fpc-pascal]

Den 2022-08-01 kl. 09:40, skrev fpc-pascal-requ...@lists.freepascal.org:

Date: Sun, 31 Jul 2022 09:05:56 -0400
From: 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 ).


I have exactly the same principle for all code I create for my teaching. 
I maximize transparency and keep the size down. For graphics, I go even 
further and only depend on OpenGL and the underlying window system.


There are big libraries with lots of bells and whistles. They can be 
useful, but not to get started with. I see myself replacing 100 files 
with one, megabytes of code with kilobytes.


It is pretty hard to balance usability and minimum size but I think I am 
doing fairly well.


So, reimplementing to something smaller and more transparent is not a 
bad thing at all. It is a matter of goals.


/Ingemar


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Anthony Walter via fpc-pascal]

Thank you for your opinion.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Michael Van Canneyt via fpc-pascal]

On Sun, 31 Jul 2022, Anthony Walter via fpc-pascal wrote:


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.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Anthony Walter via fpc-pascal]

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.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Michael Van Canneyt via fpc-pascal]

On Sun, 31 Jul 2022, Anthony Walter wrote:


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 ).


'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.




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.


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.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Anthony Walter via fpc-pascal]

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
 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.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Michael Van Canneyt via fpc-pascal]

On Sun, 31 Jul 2022, Anthony Walter via fpc-pascal wrote:


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.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Anthony Walter via fpc-pascal]

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.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal