Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2022-08

Re: Here is real time graphics and physics simulation, library

3 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Ingemar Ragnemalm

Den 2022-08-01 kl. 09:40, skrev

Show quoted text 13 lines
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 is a matter of goals.

/Ingemar

Michael Van Canneyt
to Ingemar Ragnemalm
Ingemar Ragnemalm wrote 29 lines
Den 2022-08-01 kl. 09:40, skrev > 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 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.

Marco van de Voort
to Michael Van Canneyt
Michael Van Canneyt 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.