Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: Cheb's project will be here.

  1. #11
    PGDCE Developer de_jean_7777's Avatar
    Join Date
    Nov 2006
    Location
    Bosnia and Herzegovina (Herzegovina)
    Posts
    286
    That's a lot of dedication to support windows 98. I was thinking about it too, but it may make more sense to eventually try to add a win9x platform back into fpc 3.2 rather than use 2.6.4, if at all possible. Since it can work for DOS, I assume it should be able to work for Windows 9x. Since I depend on generics a lot, I can't go back below 3.0.4. But this is not a priority for now, or maybe ever.
    Existence is pain

  2. #12
    Well, I started developing my engine back in 2003 when I was still using Win98. I kept going at it when I finally moved to Win2k in 2004.

    Quote Originally Posted by de_jean_7777 View Post
    but it may make more sense to eventually try to add a win9x platform back into fpc 3.2
    Not a chance.
    Why? Because it would require making Windows unit use dynamic loading, making a lot of the functions declared there procedural variables.
    The Windows unit in 2.6.4 was effectively *crippled* because of Win98 support in that compiler version. It misses a lot of really useful functions you have to add by yourself if you use 2.6.4.

    I also believe a lot of string handling routines would have to be adapted to detect Win98 and hack around its limitations... which is not always possible, because how do you determine the system locale? It's not always possible. I use a dirty hack "if no Unicode support found assume Russian/cp1251", such things would not fly for the fpc rtl.

    There are too few people interested in Win98.

    WinXP, on the other hand... But WinXP already has all of the WinAPI functions there and working -- except maybe some exotic ones endemic to Win7/8/10. But these should be exceedingly rare.

    Also, there is an abyss of time between WinXP (supported til 2014) and Win98 SE installed from an original CD of 1999 I am aiming to support.

  3. #13
    Postponed again, due to one definitely, decidedly, I swear I'll never do that again, rehaul.

    1. Compatibility with fpc 2.6.4 dropped forever (now requires 3.2 on Windows and 3.0.4 on Linux)
    2. Support of Windows 98 dropped forever (now requires XP and up).
    3. My unique split architecture is limited to developer mode only, which is limited to Win32 only. Now by default the modules are parts of the main executable.
    Reason: exception handling in threads created by DLLs still does not work in Linux, requiring an exception hack. Doable (I made one for Win32, after all) but why waste so much effort?
    Also saves extra effort on not having to interface a lot of bells and whistles things between the mother exe and the module dll (which is a royal pain because you have to dumb everything down to a C-like API with pointers instead of arrays and strings). Lots of purely cosmetic things are cut out of the devmode DLL now. The DLL doesn't know anything about mother's modules list, on clicking module select it passes control to the hub module built into the exe. It can't have custom loading screen background. And so on.

    P.S. Just look at that double wrapper which allows the DLL working with TSTream instances created by the mother executable. First it is cast to ptruint and called "handle" and a small API made to access its methods via flat cdecl functions accepting handle as one of the parameters. Then, on the DLL side, a class is derived from TStream where methods call on that mother API. Results in a perfectly working TStream on both sides, but implementing it was so much pain

  4. #14
    An embarrassing oopsnik about forgetting edge cases.
    I was using per-thread records to store exception data, error messages & backtraces, self-profiling counters.
    Instead of threadvar it was organized as a linked list so every time pointer to it was asked, the chain was searched for one with the right thread id.
    Last Sunday I finally redid it using threadvar.
    I did not change the API, the function is still called and still allocates the record the first time it is asked for. It just uses threadvar to store and retrieve it. But the linked list is still used, reserved for exactly two cases: the module's thread manager collating error messages from all threads at shutdown and the histogram renderer, which iterates over all known threads.
    Looking at histograms made me realize the blunder causing uncaught exceptions on exit.

    See that mysterious unnamed thread and the main thread's bar being empty?
    That's where I forgot that the record for the main thread should not be allocated via New, the pointer must point to a specific global variable which is the start of the linked list.

    I also had enough with the horribly convoluted and distributed state machine of the control panel (which I am still trying to wrangle into a separate built-inmodule) playing tricks and taking me on wild goose chases.
    I nuked it and am now re-making it from scratch. As I should have from the start.

    Also, I decided to make the control of the verbose log (aka verbal diarrhea mode) granular instead of "on" and "off". Finding points of interest in kilometer-long walls of text was becoming tiresome. Soon I will be able to switch verbose logging separately for gapi, database, framework, path processing, loading external function pointers and so on.
    The debugging executable version would be left for cases of extreme debugging.

  5. #15
    I'm having problems with my engine logs too, so I'll redesign it. I think I'll define a empty "Log" class that just skips logs and extend it in a class that actually writes the log files. Then you can create as many log objects you want (maybe just an empty one) then you can assign them to each engine's subsystem. This way you can organize them as you want. For example, if you want no logs, assign the empty one to all; if you want a different log file per subsystem, create as many as you need; for only one big huge file, create one and assign it.
    No signature provided yet.

  6. #16
    Quote Originally Posted by Ñuño Martínez View Post
    Then you can create as many log objects you want (maybe just an empty one) then you can assign them to each engine's subsystem.
    Nice
    I couldn't do that, simply because I am restricted to procedural APIs: the devmode module DLL cannot use classes of the mother executable.

    For me, there's also a question of performance, any logging has to be wrapped into
    if Verbose then AddLog(...)
    because sometimes I stick logging in time-sensitive areas.
    If I do simple
    VerboseLog()
    instead, which checks conditions on its own, that's still a lot of passing around strings, "array of const", maybe IntToHex here and here - and hello, slowdown.

    So as I do that anyway, I just upgraded from
    if Mother^.Debug.Verbose
    to
    if Verbose(<condition>)
    , which simply checks an enum against a set.

    for example,
    Code:
        if Verbose(vla_Chepersy) then AddLog(
          'Freezing the database state, the memory manager has %0Mb committed'
          + ' in %1 blocks'
          ,[Cps.MemoryManager.TotalAllocatedSysMem div (1024 * 1024),
             Cps.MemoryManager.NumBlocks]);
        MOVE(chepersy.Cps, SavedChepersyState, sizeof(chepersy.Cps));
        FillChar(chepersy.Cps, sizeof(chepersy.Cps), 0); // NO deinit!

    But! More importantly, I finally found a good alternative to LGPL, which I used since the very beginning in 2006, and switched my engine to MPL 2.0
    It allows what I am aiming for (static linking with map scripts of questionable reputability auto-converted from the ACS language to Pascal) while still allowing to use my code in a GPL project if someone so wishes.
    Turns out I had accumulated lot of third party code, with a zoo of different licenses, all of that had to be reviewed and addressed.
    Chentrah
    Copyright (C) 2002-2021 ChebMaster (user5543@chebmaster.com)

    The source code is covered by following licenses:
    The OpenGL and OpenGL ES 2.0 headers
    under SGI Free Software License B

    The JEDI DirectSound headers
    under dual MPL 1.1 and LGPL

    The Broadcom library headers (c) 2012, Broadcom Europe Ltd
    under custom free permission
    - see un_gles_raspberry_pi.h

    The Vampyre Imaging library
    (see the 3rdparty folder)
    under dual MPL 1.1 and LGPL

    The modified part of paszlib (un_unzip.pp)
    under custom free permission
    - see LICENSE-paszlib.txt

    The modified parts of Free Pascal RTL (various parsers of debugging info)
    under modified LGPL 2.1 allowing linking into executables regardless of license
    - see LICENSE-FPC.txt

    The rest of the engine
    under MPL 2.0 - which allows use under GPL/LGPL 2.1 or later

    If some source file does not contain license information
    it means I forgot to embed the MPL2.0 notice.
    Poke me with a stick.

    Please see how I handled a dwarf parser unit borrowed from RTL and tell me I didn't do it wrong
    Code:
    {
        Modified by ChebMaster in 2018 to integrate into Chentrah
    
        This file is part of the Free Pascal run time library.
    
        Copyright (c) 2006 by Thomas Schatzl, member of the FreePascal
        Development team
        Parts (c) 2000 Peter Vreman (adapted from original dwarfs line
        reader)
    
        Dwarf LineInfo Retriever
    
        See the file LICENSE-FPC.txt, included in this distribution,
        for details about the copyright.
    
        This program is distributed in the hope that it will be useful,
        but WITHOUT ANY WARRANTY; without even the implied warranty of
        MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
     **********************************************************************}
    This is the file LICENSE-FPC.txt, it applies to modified fragments of
    the Free Pascal Run-Time Library (RTL)
    distributed by ChebMaster (user5543@chebmaster.com).

    The source code of the Free Pascal Runtime Libraries and packages are
    distributed under the Library GNU General Public License
    (see the file LICENSE-LGPLv2.txt) with the following modification:

    As a special exception, the copyright holders of this library give you
    permission to link this library with independent modules to produce an
    executable, regardless of the license terms of these independent modules,
    and to copy and distribute the resulting executable under terms of your choice,
    provided that you also meet, for each linked independent module, the terms
    and conditions of the license of that module. An independent module is a module
    which is not derived from or based on this library. If you modify this
    library, you may extend this exception to your version of the library, but you are
    not obligated to do so. If you do not wish to do so, delete this exception
    statement from your version.

    If you didn't receive a copy of the file LICENSE-LGPLv2.txt, contact:
    Free Software Foundation
    675 Mass Ave
    Cambridge, MA 02139
    USA
    Last edited by Chebmaster; 27-03-2021 at 08:50 AM.

  7. #17
    P.S. More elaboration on dropping Win98 support (after investing so much effort, sniff).

    Alas, the said support became an unsustainable effort sink. All for a vanishingly small fraction of hardware that
    1. is compatible with Win98
    2. has Directx9 - class video card
    3. has OpenGL 2.0 drivers for Win98 for said video card

    I should have done this much, much earlier. It was Ok while my target was OpenGL 1.2 or even when I updated that to 1.4. But when I mage my absolute minimum GLES2 and its desktop substitute GL 2.1 it was time to bury the venerated dead.

    The last nail into coffin was my decision to drop support for video cards without NPOT2 support (I have one, GeForce FX5200). Incidentally, FX5200 was the only video card I have that has Win98 OpenGL 2.0 drivers.

    As a result I am free to drop supporting Free Pascal 2.6.4 (hello, generics, I missed you so much)

    Rest assured, I am still supporting WinXP. I cannot find reasons not to.

  8. #18
    PGDCE Developer de_jean_7777's Avatar
    Join Date
    Nov 2006
    Location
    Bosnia and Herzegovina (Herzegovina)
    Posts
    286
    Quote Originally Posted by Chebmaster View Post
    P.S. More elaboration on dropping Win98 support (after investing so much effort, sniff).
    Yeah, it's not worth it. WinXP is still supported by FPC, so that works more or less with no effort. My engine will support gl 1.2 as one of the renderers, so there's hope I'll be able to port it for older platforms, but really not a priority.
    Existence is pain

  9. #19
    Quote Originally Posted by Chebmaster View Post
    P.S. More elaboration on dropping Win98 support (after investing so much effort, sniff).

    Alas, the said support became an unsustainable effort sink. All for a vanishingly small fraction of hardware that
    1. is compatible with Win98
    2. has Directx9 - class video card
    3. has OpenGL 2.0 drivers for Win98 for said video card

    I should have done this much, much earlier. It was Ok while my target was OpenGL 1.2 or even when I updated that to 1.4. But when I mage my absolute minimum GLES2 and its desktop substitute GL 2.1 it was time to bury the venerated dead.

    The last nail into coffin was my decision to drop support for video cards without NPOT2 support (I have one, GeForce FX5200). Incidentally, FX5200 was the only video card I have that has Win98 OpenGL 2.0 drivers.

    As a result I am free to drop supporting Free Pascal 2.6.4 (hello, generics, I missed you so much)

    Rest assured, I am still supporting WinXP. I cannot find reasons not to.
    Curious: I'm doing exactly the opposite. Too soon to announce though...
    No signature provided yet.

  10. #20
    In the end it all depends on system requirements. When I learned GLSL and realized how much freedom it gives I was firmly set on using it. I also implemented physics in a separate thread so multi-core CPUs became a great bonus if not outright requirement.

    This resulted in my target hardware being a Core 2 Duo + a DirectX9c class video card. That's around 2007. While Windows 98 with drivers available to it barely reaches 2004.

Page 2 of 2 FirstFirst 12

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •