Great post Triplefox!
Great post Triplefox!
I have 15 years programming experience with Pascal/Object Pascal (Delphi and FPC), and never seen nothing that cannot do with this language. I made games, multimedia apps, console apps and database apps.
I think pascal needs more community support, new developers don't know the power of Pascal and the power of <T>, but I saw a little improvement since 2016 at tiobe chart. https://www.tiobe.com/tiobe-index/delphi-object-pascal/
I will keep making my engine, not game (chances of success 5%), then will make a proof-of-concept game using assets lifted from OA, then will try making tools (another 15% success chance), then will try making a real game (chances of success 5% again). And only then I will look what could be shared / ported back to community.
I haven't even created a thread in "your projects" yet, it's that hopeless.
I admit I tend to create fixes for severe flaws in FPC RTL... Then not share them back because my fixes are too specialized
Like that one that allows you reach Platinum level of Wine compatibility using fpc 2.6.4 for Win32 Without it you get random crashes on file operations because some crap algorithm seeped into the RTL in the times of Windows 95 and never got fixed in that version (does not free file handles that are less than 5). But why where there's 3.0.2 coming Or the system that solves exception handling in a DLL - but it's too too integrated into my engine and requires the DLL to have a special callback entry point for re-raising Pascal exceptions
Uh, why are you still using FPC 2.6.4? It has a large number of known bugs that have been fixed in 3.0.0 and onwards. (Personally I always just use trunk everything for both FPC and Lazarus... the developers are careful enough that the risk and overall rate of "breakage" is quite low.)
I think we've made good progress so far, I'm interested in discussing how to cater for many skill levels - it'd be nice if everybody that wanted to contribute had something to work on that they are confident with.
But there are parts that only the minority can work on immediately.
But there's no reason why we should wait for the core engine / graphics pipeline to be workable before its dependencies as long as we have substitutes for those dependencies and an abstraction / API that will remain at least fairly constant.
I propose that parts such as a model loading library could be created before the engine design is even finalised and via a temporary abstraction - be able to render (for the purposes of development) using some existing system.
In this example the structure/API of the model lib would be abstracted from the host engine so that it could be dropped in to the PGD engine when functional enough.
Just one idea but anybody have thoughts along these lines? approaches that will let the most number of people start work on something instead of waiting for a minority to develop a framework?
I think it would be beneficial to identify lines to be drawn so that it's multiple projects, PGD_Graphics, PGD_Resources, PGD_Framework etc - just an idea but I think it has merit.
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
Is very stable.
Trunk and 3.0.0 compilers, on the other hand, crash with internal errors trying to build my project (I reported many a bug). It seems that that was fixed in 3.0.2 but I want to be ABSOLUTELY sure when something crashes it's a problem in my mindscrewy code, not in the compiler or RTL.
I had very bad experience of spending several months on difficult debugging and practically had my project die due to my confidence failing -- all because of a faulty tool causing random *unrelated* crashes.
Let's say I would be boasting the first multi-threaded first-person shooter for DOS in human history (made in 1998 ) if not for that faulty piece of excrement. It killed my motivation.
Since then I ONLY use stable tools. So, until the managers of Debian Stable say it's okay by raising its FPC over 2.6.4... Just no.
I carefully prepare my code to move over to 3.0.x and periodically test if it compiles, of course, but not yet.
Chebmaster : having developed cross platform code using FPC for a number of years, I've encountered many bugs, usually OS specific. I'd recommend that you build on at least two operating systems - It helps to identify the source of problems, to eliminate common code etc.
I've found FPC 3.0.x to be very stable, my code is working on all the OSes I currently support and it touches everything you'd expect from a modern engine - I had a few issues with 2.6.x.
There may be some issues that were introduced perhaps but don't dismiss it entirely just in case you spend ages trying to get round a bug that was later fixed - which is a more likely scenario.
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
I'm not dismissing it, I'm waiting for it to mature to the point of usability.
Which, in my estimate, will eventually happen as fpc reaches 3.0.4 or 3.0.6
For example, classes in 3.0.0 are not unicode so I *still* had to create this hackaround:
That wasn't hard. I already have one for 2.6.4:Code:TFileStream = class(classes.THandleStream) Private FFileName : UnicodeString; public constructor Create(const AFileName: UnicodeString; Mode: Word); constructor Create(const AFileName: UnicodeString; Mode: Word; Rights: Cardinal); destructor Destroy; override; property FileName : UnicodeString Read FFilename; end;
P.S. Truly universal code compatible with both 2.6 and 3.0 branches goes like this:Code:{ This is a permanent fix for the broken RTL of FPC 2.6.4 See http://bugs.freepascal.org/view.php?id=27221 This fix is required to get Platinum level of Wine compatibility } {$ifndef windows} {$fatal Windows ONLY} {$endif} type TFileStream = class(classes.TFileStream) public destructor Destroy; override; end; //The rest of the classes are dragged along by the need to base them on the fixed TFileStream TStringList = class(classes.TStringList) public procedure LoadFromFile(const FileName: AnsiString); procedure SaveToFile(const FileName: AnsiString); end; TIniFileKey = class //..... and so on // where destructor TFileStream.Destroy; begin if Handle <= 4 then CloseHandle(Handle); inherited; end;
P.P.S. This is getting far off-topic. Dear mods, please feel free to snip this discussion off.Code:{$if FPC_FULLVERSION>=20700} {$define che_unicode} {$endif} ... {$ifdef che_unicode} {$if FPC_FULLVERSION<30000} {$fatal Impossible to use this compiler version: RTL is not unicode} //The sad truth {$endif} { modeswitch unicodestrings} //is in the main project file {$warn IMPLICIT_STRING_CAST_LOSS Error} {$warn EXPLICIT_STRING_CAST_LOSS Error} { if FPC_FULLVERSION<=40000} //***TODO Replace with version in which it is fixed {$define fix_fpc3_unicode} // Use custom mods of TFileStream, TStringList and TIniFile { endif} AnsiString1251 = type AnsiString(1251); TFileNameString = UnicodeString; PFileNameChar = PUnicodeChar; {$else} //Legacy Free Pascal below 3.0 (2.6.0 to 2.6.4) RawByteString = AnsiString; AnsiString1251 = AnsiString; {$ifdef windows} //no unicode support for file names TFileNameString = AnsiString; PFileNameChar = PAnsiChar; {$else} TFileNameString = Utf8String; PFileNameChar = PAnsiChar; {$endif} {$endif}
Last edited by Chebmaster; 13-08-2017 at 10:38 AM.
Yes there are still problems - you do raise a good point - code you've patched to suit your purposes is effectively more 'advanced' - better the devil you know and all that jazz
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
@Chebmaster: I still don't understand how your filenames could possibly require unicode support. Why would anyone specifically go out of their way to use unicode characters in a filename to begin with? It makes no sense. I've also never encountered a "unicode" situation with FPC that normal "AnsiStrings" couldn't handle. For example, the following code compiles fine and displays correctly:
Also, you do realize the people who maintain Debian are entirely unrelated to the developers of FPC/Lazarus, right?....Code:procedure TForm1.FormShow(Sender: TObject); var MyString: AnsiString; begin MyString := '¶' + '¿' + 'ÆÆÆ' + '®®®®®®' + '¢¢¢¢¢' + 'ȾȾȾȾȾȾȾȾ' + 'ɎɎɎɎɎɎɎɎ' + 'ΏΏΏΏΏΏΏΏΏ' + 'ϼϼϼϼϼ'; ShowMessage(MyString); end;
Last edited by Akira13; 10-09-2017 at 04:54 PM.
Bookmarks