So whatever happened to the whole PGDCE thing?

[Akira13]

Looking at the forum, not much since 2014! Just a lack of interest?

[farcodev]

Yep this part is dead for a certain time. At least it was fun while it lasted :)

[phibermon]

I was very excited by the project and some people worked hard on getting it together but there were large disparities in skill level that were I factor I think - the seasoned engine devs difference in opinions aside, there was so much to do and so much to plan and design before it reached a level where there was something for every skill level to contribute to.

It would of been a tiny handful of people working on an engine for ages - a tiny handful who already had engine project of their own.

So the experienced drifted away onto their already working engine projects - the less experienced drifted away because there wasn't much for them to do other than learn how to make game engines - which is what they were doing anyway.

---

I think upon reflection the project needed a working and established engine core to build around, some part of that engine developed enough that there were jobs for people to do at any skill level and somebody to maintain a list of tasks that people could pick up according to size and skill.

In effect we needed gamification of the process of creating a game engine.

[SilverWarior]

I think upon reflection the project needed a working and established engine core to build around, some part of that engine developed enough that there were jobs for people to do at any skill level and somebody to maintain a list of tasks that people could pick up according to size and skill

I strongly disagree with you on this.
You see the main idea of PGDCE was not to take an existing engine and then build upon it but to start creating a new engine from start (that also includes engine core) in order to provide from start to end learning experience for everyone involved.
What PGDCE lacked or should I say is still lacking is a proper design documentation which is written in such way that even those without any prior experience in game engine development would be able to understand it.
But that was never made. The closest that we got were just a few text documents suggesting the basic class structure. Wile design document outlining the basic class structure might be enough for experienced game engine developers to start working on a game engine that definitely isn't enough for people who have no prior experience on game engine development to start any work. Why? Because they probably won't be able to visualize relation of these different classes and therefore understand their role in the game engine as a whole.
That is why (if your remember) I suggested that we instead start making a mind graph which will at the beginning outline all planned modules (the idea was for PGDCE to have modular structure) and which could then later be further extended with more detailed information about each specific module and their mutual relations. But for some reason there was no interest in my idea about creating mind graph as part of documentation.

Any way the second reason why people lost interest in the creation of PGDCE is that at the time when we were still in the process of creating documentation the Castle Engine was published. So many people would rather go making new games on existing engine rather than making the engine itself.
Also at the time user masonwheeler offered a chance to help him continue development of his own partially made engine named The TURBU engine (http://code.google.com/p/turbu) instead.

[farcodev]

Any way the second reason why people lost interest in the creation of PGDCE is that at the time when we were still in the process of creating documentation the Castle Engine was published. So many people would rather go making new games on existing engine rather than making the engine itself.

That is a strong point, especially by this day and age where game engine like Unity and Unreal exists.
Many people doesn't care anymore about what is under the hood.

I don't advocate for these tools, but it is a reality.

[SilverWarior]

Strong point until you find out that those engines does not support features that your require. At that point you realize that adding needed features to such engine can be a verry hard task.
Not to mention that you might be stuck with some bugs that come with those engines.

[User137]

Engine like Unity may actually have so many more features than we can ever imagine re-creating. On top of that they have Microsoft, Google and others as platform dev partners. Direct support for VR, latest graphics card features and so on. Same project running on Win, Linux, Mac, Android, iPad without code changes... At best the own engine is a thing that helps participants to learn about game engines, but it's like tasking 10 people to build a skyscraper when it comes to engine fitting for modern games.

A while back we released this Unity game https://www.youtube.com/watch?v=_fe2KDt7MYE , which had 1 artist, 1 level designer and 1 other programmer besides me. Physics, animations, graphics with shadows and all were trivial to do compared to how i could even imagine accomplishing on a custom made engine. Even something like making a skeleton explode and bones drop on the ground colliding all over the place. And no, nxPascal i code is nowhere near capable of doing any of those. What i really liked about was the animating that's really powerful. The engine allows you to write your own shaders, but what's even more impressive is the user support of thousands of people whenever you don't know how to do something by yourself. You get answer within minutes in most cases.

[phibermon]

That's the point though - full design documentation requires a design that is at least in it's most primitive form - complete. No matter which way you spin it, be it extensive design documentation or a solid platform on which to build - experienced engine devs are still doing a lot of work for quite some time before anybody that doesn't yet have the experience - can start.

Take the imaginary Jane - Jane loves making games and wants to learn how to create a modern 3D engine so she can realise her dream of a game where you play a Amish assassin taking out scientists at CERN.

Jane has created 2D games/demos and has also started to play around with some OpenGL examples and has started to get a handle on 3D projections and piping data to the graphics card.

With all the will in the world, Jane can't yet sit down and write a shader/material sorting rendering pipeline - she doesn't know enough including why sorting by material is a good idea.

She could sit down and start writing an object orientated scene graph and it would work eventually - however her work wouldn't anticipate the hundreds of quirks and uses that the scene-graph must contend with then lots of people start creating new node/entity types that don't run into issues on their own - then one day it's discovered that feature X needs a different approach to handling the scene graph and BOOM all the dependencies and the graph itself have to be refactored.

Emily bleeds in binary and breathes in triangle strips - she could come along and create a scene graph design that anticipates most of it's usage patterns and major refactoring isn't required.

Emily would have to teach Jane an awful lot of stuff before Jane could come up with an informed design.

So does Emily take the months to teach Jane how to do it, holding up everything and everybody that depends on it - or does Emily just write it herself?

----

Either a base-code, complete design documentation or teaching everybody requires already experienced engine devs - it took me years to know what I know and I'd still be more comfortable consulting other engine devs before I settle on designs.

I think a base-code (it doesn't have to be massive) is the best approach - it ensures a solid design and good practices which will filter down by example to the rest of the engine - anybody that doesn't know about some part that is in the base-code can always learn it and they've got the people that wrote it right there in the team to answer questions - also an existing base-code means that Jane can jump right in and apply what she already knows.

Even in large commercial environments - engines are rarely the product of one or two devs - you have people that specialise in certain things - coders that support artist requirements will be masters with shaders and skinning/animation code, somebody will be a mathematics whizz and they'll be handling more complex things such as BSP processing, optimized culling routines etc

For the project to carry on living - it needs active devs of all levels working on it - 20 devs is great but if only 3 of them can do anything for weeks/months, be it creating design documents, base-code or teaching somebody else how to do those things - then the project is going to fizzle out and die.

With a simple basecode then there's loads of tasks for all skill levels - anybody can choose anything they like - if they want to spend months learning what the experience devs are doing and join them? they can - the source is there, they can ask questions, watch it evolve - but if they just want to contribute and learn *somthing* they can do that too - we need a plugin to load a given model format just as much as we need a scene graph.

[SilverWarior]

@phibermon

I see us two have a different opinion of effective learning process.
I'm guessing you are more oriented toward traditional learning where you are simply told what to do and what it "best" approach to do it.
Well I'm more oriented toward exploratory learning approach where you tell people which approaches doesn't work at all and also show them as many possible approaches that work and let them decide which approach is "best".

You might have noticed that I always write best in double quotes. I do this because in programming there is no best solution that would fit everyone. Best solution actually depends on many things like compatibility with existing code and coding style, current programming level of individual etc.

I'm willing to bet that if us two get into discussion of how base code should look we will both have different ideas for it. Why? Because each of us is probably thinking about different scenarios to use that base code in not to mention that each of us probably have its own preferred coding style.
Only by working together could we design base code that would be most suitable for both mine and yours usage scenarios. Same goes if we want to make this base code to me best suitable for everyone.
That is why I feel we should allow everyone interested (even those with no prior experience of game engine development) to also be part of the base code development even thou they might be just watching it being built.

[AthenaOfDelphi]

Whatever happened to the community engine?

The same thing that happens to the community in general plus it was way to ambitious, I should have listened more to the feedback, there was no clear plan in place before we started which resulted in a lot of discussions about what we should and should not include and why, much of which was very technical meaning understanding it was beyond the capabilities of many of those who may have sought to be involved, including me.

The intentions of the project were good, but implementation/management was bad and that's partly down to me.

However, going back to the first point... the same thing that happens to the community in general...

I wrote a huge response to this thread yesterday but ended up feeling it was a very negative rant so I figured I'd ditch it, sleep on it and have a go this morning, unfortunately it's still going to come across as negative.

Take a look at the articles section of the site... the last thing in there was published in 2014 and it was a tutorial I wrote. We have no quick start guides, we've not had an interview in ages and there have been no tutorials. Why?

Because in my view people are unwilling to set aside a small amount of their time to create content, to give back. It's that simple. Unfortunately, some of those people then complain about a lack of content, which really annoys me and it's not just the current users, this has been an on-going problem almost since the start (I had so many chats with Jason about this and over the years he tried many times to kick start things, just as I have, unfortunately we always end up in the same situation - very little or no user created content). If every regular visitor wrote one article a year (two would be better), we'd have bags of content, but I would say 99% of people have NEVER volunteered to do anything (which is why I'm eternally grateful to the moderators who keep things ticking over while I'm not around, you guys deserve a huge round of applause from everyone).

So how does this tie in with the community engine?

My feeling was that if we could produce an engine for the community it would yield many possibilities for content. Like tutorials on the various elements, what they do, how they work, how they can be optimised for specific scenarios, documentation, examples, hell maybe even a competition based around the engine and all of that content would provide a valuable learning resource for those of us who want to learn and understand the advanced techniques required in a modern 3D engine.

Alas, for the reasons above (I think mainly because it was overly ambitious meaning helping was beyond the capabilities of many users, including me, and we didn't have a clear end goal) it died a death. I think 3 people committed anything to the repository and ultimately it was one person who contributed the most.

In reality what we should have done was fixed some basic goals... 2D, OpenGL, support Delphi and FreePascal, target Android, iOS, MacOSX and Windows (and please don't tell me that this isn't possible from a single codebase because it is), including sound, shader support for effects, a basic GUI library, platform specific helpers and a set of tools for creating top down tile maps, side scroll maps and other utilities. Just imagine how much content we could create around that... tutorials on sound formats, shaders, font packing, collision detection, basic physics, the list goes on. And whilst this is going on, the people capable of more could write articles and tutorials about some of the advanced concepts required for a 3D engine so that those of us who need to learn the basics (I for one have no clue what some of the stuff that was talked about in the community engine forum is, what it does, why it's needed etc.).

Do I think we would complete that project? I honestly don't know. I think we could, but people would have to put aside their egos and desire to prove how tech savvy they are and accept that this would be a less than optimal solution because (a) it's likely to be more generic than building for a specific idea and (b) because it will need to be simpler so those of us who aren't so clued up can understand it. But here's the thing... you could always write a tutorial on optimising a particular element, why the optimisation works and when to apply it.... more content!

I'm happy to facilitate anything like this, the community just needs to let me know what you want and I'll get it sorted (as long as it doesn't cost money). For those of you that don't know, I'm no longer a professional software engineer, I am instead a self-employed electrical contractor because my last job destroyed me (suffice to say, when you have two people, both directors of the company, think they are better than you despite not having as much wider industry experience as you, you are likely to be faced with a never ending torrent of negativity around your work, your ideas, the way you do things and eventually it will destroy you). I haven't written anything of note since the end of 2014 because inside I was (and still am to an extent), devoid of the confidence I once had that I could make sensible decisions about the software I am writing, and so last year I took the plunge and got out of an industry I'd been in for nearly 21 years and honestly, it broke my heart.

The upside is I'm my own boss and consequently I have the benefits that come with that, like a lot more freedom and a lot less stress (yes, believe it or not, I find major electrical work is a lot less stressful than writing software). The downside to this decision is that I have practically no money because I'm just starting out and I don't have a steady stream of work yet. Unfortunately the hosting contract for PGD is up for renewal and I've been asking myself what to do about it. With no major projects, no competitions, no regular flow of content (aside from forum activity), I've been contemplating moving the site to my own server to save money. That will mean slower page serve times and the possibility of bandwidth caps.

So I guess my question to the community is this... would you be happy with that? If the answer is yes, then I guess that means we won't be getting any new content... no competitions, tutorials, interviews, quick start guides, community projects. If the answer is no, you're not happy about that possibility, then what are we, the community, going to do about it?

Now, I'm starting to work on a new game... well actually, it's not new, it is a reboot of our 2006 Annual competition entry... there is scope for a huge amount of content in my view, just from my one project, and I've thought about what articles I might write, and I've had several ideas for articles in the time I've not been around much, but I've never followed through and actually written them. Why? Because I think to myself why should I? Why should I give up more of my time to benefit a community where so few people give back by spending a little of their time generating some content? Why should I do anything more than I do already (host it, keep it running, pay for it) when in over 2 years, there have been no volunteers to do anything, practically no substantial content and no donations?

One article a year from each regular visitor and we could have a nice steady stream of new content. You don't have to write it all yourself, you could work with others and if you're worried that what you're saying is wrong, have someone else proof read it, send them example code to make sure it works... you could do an interview with someone in the industry, you could write a tutorial about something, you could write a quick start guide for getting going with a framework, you could write a post-mortem about a project. Hell, you could even just post links to interesting content (like the couple I posted about the render pipeline breakdowns). There are so many possibilities and yet so little content.

Why? ???

Delphi is enjoying a resurgence in popularity and I want this place to be buzzing, I want this place to be the place to go to for advice and information when it comes to making games with Pascal, but I'll be honest, I'm out of ideas on how to achieve that without help. If I spent all my spare time writing content, how much fun would that be for me? I'd never have any time to work on my own projects, I'd have no time to learn new stuff and ultimately I'd run out of things to write about. And then, we'd be back to square one, the content stream would dry up as it has done on so many previous occasions through the history of the site.

So I'm asking you guys... what do you want? What would you like to see here? What kind of events would you like to see PGD run? Do you want a community project to get involved in? If so, what? What sort of tutorials would you like to see? Who would you like to interview if you could? Would you like to have a PGD team enter say Ludum Dare? And most importantly what are you going to do to help make that a reality? If the answer to the last part is nothing, then that sums up the problem and I see no way things will improve, so if you'd answer that, what would make you do something for the community? And if you don't want to share you views, thoughts etc. publicly, PM me. But really, I need to know what you guys want and what it would take for you to give back to the community, because I just don't know what to do about it?

[Ñuño Martínez]

So I'm asking you guys... what do you want? What would you like to see here? What kind of events would you like to see PGD run? Do you want a community project to get involved in? If so, what? What sort of tutorials would you like to see? Who would you like to interview if you could? Would you like to have a PGD team enter say Ludum Dare? And most importantly what are you going to do to help make that a reality? If the answer to the last part is nothing, then that sums up the problem and I see no way things will improve, so if you'd answer that, what would make you do something for the community? And if you don't want to share you views, thoughts etc. publicly, PM me. But really, I need to know what you guys want and what it would take for you to give back to the community, because I just don't know what to do about it?
What I want is just a window for may projects and a place where I can ask about game programming with Pascal.

Actually I would like to write some articles about Allegro.pas but I have no time right now (or I should say I don't find it now). :(

A LudumDare team would be cool.

[SilverWarior]

The downside to this decision is that I have practically no money because I'm just starting out and I don't have a steady stream of work yet. Unfortunately the hosting contract for PGD is up for renewal and I've been asking myself what to do about it. With no major projects, no competitions, no regular flow of content (aside from forum activity), I've been contemplating moving the site to my own server to save money. That will mean slower page serve times and the possibility of bandwidth caps.

Hey Christina if the hosting expenses are a big problem for you then this is where I can and I'm prepared to help immediately. Initially I was planning to use that money to buy Mobile Add-on pack for Delphi for developing a mobile application for my employer but since my employer isn't showing a big interest in this I have no need for buying the Mobile Add-on pack at this time. So feel free to share more information on how can I help you in this matter.

As far as content creation goes I must shamefully admit that my extensive tutorial about working with classes in Object Pascal that I started several years ago (I'm actually afraid to look when :() hasn't seem much progress lately.
The main reason for this is that my current job is draining almost all of my energy from me. Man I miss my old job where sometimes I even had time do to some programming during work time (don't tell my old boss about this ;D).

PS: If you need an idea about the theme for next PGD competition I got two words for you: Deterministic Simulation :)

[Super Vegeta]

Unfortunately the hosting contract for PGD is up for renewal and I've been asking myself what to do about it. With no major projects, no competitions, no regular flow of content (aside from forum activity), I've been contemplating moving the site to my own server to save money. That will mean slower page serve times and the possibility of bandwidth caps.
I guess I could conjure a few shekels. What are the running costs, currently? Also, can you give some numbers on the site's disk & bandwidth usage? We could look at what the various hosting providers are offering and maybe choose something less taxing.


If every regular visitor wrote one article a year (two would be better), we'd have bags of content
Sure. What kind of content would you like to see, though? I don't think another "Pascal from square one" tutorial would be very useful, as there's a ton of those on the internet. "Any" content isn't the way - quality content is. Although yeah, often bad content is better than no content.
Sorry if this sounds condescending, but it's a serious question. The primary reason I don't have a blog is I don't really think of anything I do as particularly interesting nor challenging, thus there's no incentive to write about it.


Would you like to have a PGD team enter say Ludum Dare?
Instead of a PGD team, just have people join Ludum Dare individually and then we can have a mini-competition for the best LD game by a PGD visitor.


Do you want a community project to get involved in? If so, what?
An engine is a really broad subject; maybe have something more focused? Like "let's make a platformer". Try to agree on basic design principles, and then collaborate via Bitbucket / GitHub. The code will probably be far from an architectural masterpiece, with individual fragments being added on-the-go and glued together - but I'd say an approach like this has a way bigger chance of shipping. Less focus on getting the design 100% right, more focus on making stuff work and shipping.

[de_jean_7777]

I can pitch in with a donation to help the costs, once my next paycheck is here :D Thinking about posting my code onto github, and some parts of it can be used for an engine as I develop my own. I do admit I've wanted to help with PGDCE but I've set aside everything for my personal projects, and I don't get much time around with that either. I also agree that Ludum Dare should be used instead of our own competitions, as there's not enough people to make a competition.

[phibermon]

I'm also more than willing to contribute what I can to running costs - you do us all a great service in taking responsibility for the site Athena and it *is* appreciated - I promise you that.

I'm going to do some work towards a finished article now.

I hope you're all well - I'd like to try and keep the ball rolling and I've 'known' you all for a long time so anybody that would like to add me on FB or just message for chat please do so - build a rapport, reify each others mutual existence etc - I find that progress is greatly aided with more real-time communication and I'm always connected to FB if I'm awake.

[SilverWarior]

so anybody that would like to add me on FB or just message for chat please do so - build a rapport, reify each others mutual existence etc - I find that progress is greatly aided with more real-time communication and I'm always connected to FB if I'm awake.

I myself am not a FB fan. In fact I must admit that I'm beginning to hate it. The only reason that I haven't terminated my FB account is the fact that I occasionally still use to check on my relatives that live across the world.
So I personally prefer using Skype as instant messaging communication but I'm not always online so it is best that we synchronize out timings here through PGD forums as I come here at least once a day.

[SilverWarior]

I also agree that Ludum Dare should be used instead of our own competitions, as there's not enough people to make a competition.

I don't agree with this. Well I admit that due to low recent activity there probably won't be so many participants in PGD competition as they were in previous years but still I'm sure we can pull it of.
Now don't get me wrong I don't say that participating in Ludum Dare or any other competition is bad but the truth is that when you are participating in Ludum dare you are basically only promoting yourself.
The main goal of PGD competitions was not to just promote individual developers but to promote us all as a community. And that is one of the things that can bring new people in.

Here is another wild idea that might boost our promotion. Why don't we personally challenge Eli M. from Delphi boot camp to participate in our next PGD challenge ;)
https://community.embarcadero.com/blogs/entry/delphi-boot-camp-day-4
I guess that for a man who developed over 300 mobile based games (many of them with Delphi and FMX) he should have no problem in participating. Also his participation could also bring some other Delphi developers to give it a try.

[AthenaOfDelphi]

To answer the question which has been asked about hosting costs for PGD, they are about £135 per year.

To add some context to what I said about regular visitors and 1 article each per year... so far this year, 50 unique users (nearly all with well over 10+ posts) have visited the site. 1 article each = 4 items of new content every month for the next 12 months. And if you consider the costs, if everyone who visits regularly donated £2, the costs would be mainly covered. I'd rather not go down the route of having a subscription which say removes ads, but if we want to do some stuff, like get good prizes, being able to buy them from community money would be a good plan... if you've never tried to secure prizes for one of our competitions, trust me when I say it's hard work and it always feels a little like begging.

I absolutely agree with the comment about quantity vs quality, content is not about quantity, quality is important.

My view on the competition front is that I'd like a mixture of both... involvement under a PGD banner/team in the likes of Ludum Dare and the chance to run our own. If I actually sit down and finished the site I was writing to run them, running them won't be an issue (most of it is done, it's that illusive last 10%).

And I don't want anyone else posting apologies etc. or implying that they haven't done enough. What I'm after is honest feedback from every regular visitor about what they would like to see. Do you want tutorials about things? If so, what? Should they be geared to a particular platform, be entirely theoretical, what? Interviews... if you could interview anyone in the industries related to the site (game development, marketing, language development etc. etc.) who would you want to interview? What would you want to ask them?

Engine devs... can people help these guys out by writing documentation, quick starts, tutorials for their engines?

I guess what I'm wanting is information about the future... what the site needs to do to be more appealing, and if possible get a firm commitment from as many people as possible that they will do something to help. Does anyone want to volunteer to post news? Anyone want to volunteer to go hunting out projects developed in Pascal and write articles about them, interview the devs about stuff?

[phibermon]

I myself am not a FB fan. In fact I must admit that I'm beginning to hate it. The only reason that I haven't terminated my FB account is the fact that I occasionally still use to check on my relatives that live across the world.
So I personally prefer using Skype as instant messaging communication but I'm not always online so it is best that we synchronize out timings here through PGD forums as I come here at least once a day.

ok.

[phibermon]

And I don't want anyone else posting apologies etc. or implying that they haven't done enough. What I'm after is honest feedback from every regular visitor about what they would like to see. Do you want tutorials about things? If so, what? Should they be geared to a particular platform, be entirely theoretical, what? Interviews... if you could interview anyone in the industries related to the site (game development, marketing, language development etc. etc.) who would you want to interview? What would you want to ask them?

I'd like to see a series of step by step tutorials that produce a visble, working output at the end.

Each successive tutorial building on the previous tutorials code.

Each tutorial coming with complete working source code available to download.

They should target Lazarus - it's free, available on all platforms and would require the bare minimum if at all covering platform specifics (up to a certain point at least)

They should target OpenGL 3.0+ style contexts, firstly focusing on 2D (but very briefly) then bringing in 3D. Any tutorials on old immediate mode GL are just teaching bad practices - GL3 is *easier* - there's just less information around for learners.

Tutorials should be pushing people towards 3D. People should get into 3D straight away instead of seeing it as this distant target that they have to be a master of 2D before they move on to. I've always found this mildly aggravating and to the determent of people's progress - nobody insists on learning to ride a motorbike before they get in a car because they want to master 2 wheels before they move onto 4. It's not 'the next level up' and learning 2D first only spawns naive notions about working in 3D. There should be absolute emphasis on the fact that 2D and 3D approaches are vastly different and the former is NOT a precursor to the latter.

Basically exactly like the famous NEHE OpenGL tutorials (http://nehe.gamedev.net/) but specifically for Pascal/Object Pascal and the standard GL3+ way of doing things.

[SilverWarior]

They should target OpenGL 3.0+ style contexts, firstly focusing on 2D (but very briefly) then bringing in 3D. Any tutorials on old immediate mode GL are just teaching bad practices - GL3 is *easier* - there's just less information around for learners.

I think that making tutorials about specific graphic API is a bad choice. Why?
Correct me if I'm wrong but isn't the purpose of graphic API to provide a uniform way of using graphic hardware regardless of which programming language is used for the application/game development? Or in order words if you want to create same graphic scene in let us say Object Pascal, C++, C#, .NET, Python or JAVA you would in the end always end up calling same graphical API functions. Right?
If I'm right then it would be possible to go and learn about specific graphic API even by checking tutorials that are written for other programming languages. Sure it would be hared but still possible.
Also graphic API's keep changing. So we could start teaching OpenGL 4.5 but what if by the time our members get to master it OpenGL 4.5 is no longer the dominant graphic API? Excellent first impressions about Vulkan are definitely opening this possibility. That could mean that we invested a lot of time writing tutorials for something that is no longer useful for game developers at that time.

I think we should more focus on making tutorials about various game mechanics like:


managing game states
working/managing with in-game entities
path finding algorithms
AI
procedural assets creation
physics
and so on


The main advantage of these topics is that they will stay relevant in 10 or 20 years as much as they are today. Also none of them depends on certain existing libraries or API-s. So no fear that you will have to relearn them because certain library or API became obsolete.

Also why should we bother people with learning about graphic basics when there are several quite capable graphical libraries out there which make the whole process about working with graphics a lot easier?

To be honest I'm pretty disappointed with game industry (especially big AAA companies) because they are spending too much focus on graphics and not enough on gameplay and game mechanics.
You see a great looking game with poor gameplay will still be a poor game. But a poorly looking game with great gameplay will still a great game.

[Akira13]

So we could start teaching OpenGL 4.5 but what if by the time our members get to master it OpenGL 4.5 is no longer the dominant graphic API? Excellent first impressions about Vulkan are definitely opening this possibility. That could mean that we invested a lot of time writing tutorials for something that is no longer useful for game developers at that time.

I believe Khronos has explicitly stated that they have no plans to move away from OpenGL, and it's also unlikely that the basic structure of the OpenGL API is going to change much more going forwards... everything after version 3.0 is just an "add-on", essentially. Vulkan is also not even really meant to be a replacement for OpenGL... it's pretty much specifically oriented towards seasoned industry professionals (we're talking 10+ years of experience) who need extremely high levels of performance 100% of the time (as it is much lower-level than OpenGL with more optimization potential, but also a significantly higher learning curve.) It's far more likely to gain traction in the film industry than it is the gaming industry, in my opinion.

[phibermon]

I think that making tutorials about specific graphic API is a bad choice. Why?
Correct me if I'm wrong but isn't the purpose of graphic API to provide a uniform way of using graphic hardware regardless of which programming language is used for the application/game development? Or in order words if you want to create same graphic scene in let us say Object Pascal, C++, C#, .NET, Python or JAVA you would in the end always end up calling same graphical API functions. Right?

Hey man I agree with you but where do you draw the line? do write all our examples in pseudo code because we can't garuntee the future of pascal? do we not talk about games because people can learn general programming elsewhere and apply those principals to game development?

Yeah somebody can go learn OpenGL anywhere - they can also go learn programming anywhere. Is not teaching them Object Pascal because they can learn general programming and apply the principals to Object Pascal - exactly the same as not teaching them GL because they can go and learn general GL and then figure out on their own how to apply it to Pascal?


Also why should we bother people with learning about graphic basics when there are several quite capable graphical libraries out there which make the whole process about working with graphics a lot easier?

You literally just dismissed OpenGL because it might not be relevent in 10 years and then you suggest they invest the entire future of their project on an even smaller and less supported graphics library?

Why bother teaching game programming or indeed programming at all because they'll be irrelevant when we have holodecks and the computer interprets our requirements?

In fact why do anything whatsoever because the universe is going to end rendering everything ultimately pointless?

You have to start somewhere - you have to make some assumptions - believe me - there's *plenty* of 3D specifics that your highly generic categories will not cover, there's entire designs that are specific to 3D hardware - compute hardware.

Like it or not hardware accelerated 3D is a massive part of gaming and has been for nearly 2 decades and there's far more complexity, far more to learn in the 3D realm (NOT just graphics) than in a thousand collections of generic 'timeless' catch all principals.

Definitely what you say is a good idea, I'm all for general principals and good coding practices - give a man a fish and he'll eat for a day but give him the means to catch his own fish and he'll eat for a whole lifetime.

Totally agree - but by the same token teaching him to fish isn't going to let him build a spaceship.

A game with great gameplay running in software at 2fps is a game with bad gameplay

[SilverWarior]

@phibermon
I'm afraid you misunderstood me. I'm not saying we should abolish using any modern graphics. Heck most game ideas that I have revolve around 3D graphics (even have one or two VR ideas).
What I was trying to say is why teaching people of how to initialize OpenGL rendering pipeline, why teaching them how to store textures in video memory, how to apply transformations onto 3D models, applying lighting and shaders, and so on low level if there are already available graphics engines that can do all this for them.
If we go and start teaching this do we also expect that each one of them will be using this knowledge to create his own graphical engine. I guess I don't have to be telling you on how much work is required in order to make your own graphical engine as you already have experience in this area.

Any way if you decide to start writing articles about using of OpenGL 3+ is won't say you shouldn't . In fact your rich experience in graphics and game engine creation is probably making you perfect candidates fur this topic. And it is quite high possibility that I will read through them.

I just think that it would be more beneficial for PGD as community if we focus more on the topics mentioned in my previous post. Why? Because you can find a graphical engine that potentially allows you to create a game without any knowledge of OpenGL or any other graphic API for that matter.
But you won't find a library that would allow you to make a game without knowing at least some of the topics that I mentioned in my previous post. At leas in the past 7 or 8 years since I focused my learning on game development I have never found one.

[laggyluk]

@phibermon
What I was trying to say is why teaching people of how to initialize OpenGL rendering pipeline, why teaching them how to store textures in video memory, how to apply transformations onto 3D models, applying lighting and shaders, and so on low level if there are already available graphics engines that can do all this for them.
If we go and start teaching this do we also expect that each one of them will be using this knowledge to create his own graphical engine.
Yeah but when someone looks for OpenGL tutorials and all he/she can find are for c++/c# then why would even bother with doing it in pascal?

Dev forums are dying thanks to stackoverflow and this one is no different.

Pascal is obscure choice for making games considering lack of learning resources/user base and imo this can only change if some big company picks it up for their next big publicly accessible game engine. But then, why would anybody do that same reasons considered?

[Rickmeister]

Yeah but when someone looks for OpenGL tutorials and all he/she can find are for c++/c# then why would even bother with doing it in pascal?

Dev forums are dying thanks to stackoverflow and this one is no different.

Pascal is obscure choice for making games considering lack of learning resources/user base and imo this can only change if some big company picks it up for their next big publicly accessible game engine. But then, why would anybody do that same reasons considered?

A quick way to get more 'meat' on this site would be to ask the people over at DelphiGL for permission to translate some of their GL tutorials and move them here?? Or link to them? I don't speak german, and google translate is just awful :( Not much use to do the good old 'divide and conquer' dance, and they seem to be quite active, at least by the looks of their forums. It would be much easier if you all spoke Swedish, it's way more easy to understand...

[dazappa]

I haven't been here in forever. For me it is all about language and tool popularity. First, where do we go to find news in the first place that we can post on this site? The only other thing really is working on custom projects and posting about them.

I stopped using Pascal for games probably 5 years ago. The tools are weak. The libraries are unmaintained. It just feels like Pascal as a language for game development has faded out of existence. I still like Pascal, and I still use it with Lazarus to create some desktop software. Without any decent momentum behind a project though I find it hard to work with. I would rather make games than engines. At this point, I am more interested in 3d games than 2d games. That's not easy to do with Pascal, especially if you want all these cool new features like PBR and VR (if you guys haven't tried a Vive, you should they're so much fun).

Quick edit: We have amazing tools available as free to use now. Unity 3d and Unreal Engine 4 are stellar. Has anyone tried to make a comparable game in Pascal and compared how long it can take? These large game engines are dominating the game dev scene for a reason. I got tired of dealing with issues, missing features, and lackluster tools.

Anyway. I through you a couple of dollars for hosting Athena. It's not much but hopefully others can chip in as well.

FYI there is a small Linux game jam happening. No prizes or incentive to "win" just for fun. Might be worth entering if anyone uses Lazarus: https://itch.io/jam/linux-jam-2017

[phibermon]

@SilverWarrior - Yes I do see what you mean but Pascal engines currently available as good as many of them are still don't come close to the ease of use and rapid development capable with some of large and free engines that are available in other languages - you're totally right - it's game development, not graphics engine development but due to what's available? if a game developer working in Pascal right now wanted to produce even half of what unreal engine 4 is capable of - they need to write it themselves.

which leads onto :


Quick edit: We have amazing tools available as free to use now. Unity 3d and Unreal Engine 4 are stellar. Has anyone tried to make a comparable game in Pascal and compared how long it can take? These large game engines are dominating the game dev scene for a reason. I got tired of dealing with issues, missing features, and lackluster tools.

A view probably shared by many - certainly anybody looking to choose between Pascal and another language. Many of us have been working hard for a number of years on better and more capable engines but compared to the dozens/hundreds of developers that contribute to something like Ogre3D, unity etc - progress is slow.

Things are changing though and there's some very capable engines out there. There's certainly a lot more capability than people seem to be making use of

[SilverWarior]

@SilverWarrior - Yes I do see what you mean but Pascal engines currently available as good as many of them are still don't come close to the ease of use and rapid development capable with some of large and free engines that are available in other languages

Yes I perfectly agree with you on that. But why is that? Is it because Pascal as a language is not suitable for game development? Or is it because none of the "weaker" Pascal based game engines never remained in development for so long as development of those powerful game engines that were developed in other programming languages have?
Below you are mentioning Unreal 4 game engine. Do you even know how long was Unreal 4 game engine in development? Development of the Unreal 4 engine started in 2003 and it was published in 2012. That is 9 years of development done by experienced team before publishing but its development still hasn't stopped. But we should not forget about Unreal 4 game engine predecessors as they also affected the Unreal 4 game engine development in a way.
First unreal game engine was published in 1998 which is 18 years ago. So this in a way means that there is almost 20 years of development behind Unreal 4 game engine.

So how many Pascal based game engines have seen so long development time? I could come up with only three potential candidates


Your unpublished JINK game engine that as you have said has been in development for over 8 years
Platform extended which is successor to several popular Asphyre game libraries where the oldest one was releast back in 2007
Castle game engine for which I don't have release date of its first iteration



if a game developer working in Pascal right now wanted to produce even half of what unreal engine 4 is capable of - they need to write it themselves.

That is true. But what would be better? For them to start from scratch (all the way from writing OpenGL basics)? Or perhaps by extending one of the above mentioned game engines?
I think that the latter would be better.


Many of us have been working hard for a number of years on better and more capable engines but compared to the dozens/hundreds of developers that contribute to something like Ogre3D, unity etc - progress is slow.

But why is progress so slow?
I guess main reason for this might be the fact that each of the above mentioned game engines is basically being developed by single developers or very small team.
Now you may argue that in the past you offered others to join development of your game engine but there wasn't interest in that. I'm willing to bet that main reason for that is the fact that since you still hasn't published your game engine no one had a chance to see its capabilities and with that also its potential for improvement.
But then looking back at my last sentence I think that the main reason for lack of decent progress with Pascal based game engines is not due the lack of developers but instead lack of users.

So how can we bring more users to these engines?
Is it by teaching them basics of OpenGL which would potentially allow them to start creating one of their own game engines?
Or by teaching them topics that I recommended which would allow them to use one of the existing engines and actually start making games with it and maybe even join developers of these existing game engines with goal of adding additional features to them in order to bring them closer to Unity or Unreal 4 game engines?

I personally think that later choice is much better. That is why I'm so adamant about it.

[phibermon]

Yes I perfectly agree with you on that. But why is that? Is it because Pascal as a language is not suitable for game development? Or is it because none of the "weaker" Pascal based game engines never remained in development for so long as development of those powerful game engines that were developed in other programming languages have?
Below you are mentioning Unreal 4 game engine. Do you even know how long was Unreal 4 game engine in development? Development of the Unreal 4 engine started in 2003 and it was published in 2012. That is 9 years of development done by experienced team before publishing but its development still hasn't stopped. But we should not forget about Unreal 4 game engine predecessors as they also affected the Unreal 4 game engine development in a way.
First unreal game engine was published in 1998 which is 18 years ago. So this in a way means that there is almost 20 years of development behind Unreal 4 game engine.

So how many Pascal based game engines have seen so long development time? I could come up with only three potential candidates


Your unpublished JINK game engine that as you have said has been in development for over 8 years
Platform extended which is successor to several popular Asphyre game libraries where the oldest one was releast back in 2007
Castle game engine for which I don't have release date of its first iteration



Yes I'd agree with you on that too - there's been numerous engines over the years that seemed to die off - another notable mention for your list would be GLScene - while not an engine in itself? it's still in development and is very capable if you know how to use it. GLScene, Jink, Platform extended/Asphyre and Castle are probably the most advanced pascal frameworks/engines that are actively developed, Cast II is noteworthy too although I've not seen updates for quite some time.



But why is progress so slow?
I guess main reason for this might be the fact that each of the above mentioned game engines is basically being developed by single developers or very small team.
Now you may argue that in the past you offered others to join development of your game engine but there wasn't interest in that. I'm willing to bet that main reason for that is the fact that since you still hasn't published your game engine no one had a chance to see its capabilities and with that also its potential for improvement.
But then looking back at my last sentence I think that the main reason for lack of decent progress with Pascal based game engines is not due the lack of developers but instead lack of users.

Agree again - lack of users - something I'm very much aware of! but it's certainly not a lack of potential users. To my mind the two biggest barriers to 3D development are :

1. Lack of knowledge in the 3D realm
2. Lack of 3D resources to use in games or the skills to make them cheaply

The first I think is still underestimated. We've had GLScene for years and it's very capable - so why isn't there a dozen, large 3D game projects making use of GLScene? well it's mainly number one - it's not good enough to say "here's a model loaded and rendered to the screen" and "here's a particle system with a fire preset" if you want an amateur to create a game using your engine - it has to be, as we've often said, a game engine and a game engine to my mind should be something like Quake or the engine used in Fallout/Oblivion/Skyrim etc

You should be able to load some resources, allocate some defaults - assign a few events and have a 'working game'.

If a great set of useful components were going to take the Pascal Gaming world by storm? it already would of done.

All engines so far, have stop too short in terms capability, to gain a meaningful user-base, given the already small number of potential users.

The second is an issue for game development in general and not just specific to Pascal but it effects all game developers and in terms of the adoption of Pascal 3D engines - I believe it's a factor.


So how can we bring more users to these engines?
Is it by teaching them basics of OpenGL which would potentially allow them to start creating one of their own game engines?
Or by teaching them topics that I recommended which would allow them to use one of the existing engines and actually start making games with it and maybe even join developers of these existing game engines with goal of adding additional features to them in order to bring them closer to Unity or Unreal 4 game engines?

I personally think that later choice is much better. That is why I'm so adamant about it.

Again I agree - perhaps then a tutorial that shows how to do the same basic thing in three different engines?

[SilverWarior]

Agree again - lack of users - something I'm very much aware of! but it's certainly not a lack of potential users. To my mind the two biggest barriers to 3D development are :

1. Lack of knowledge in the 3D realm
2. Lack of 3D resources to use in games or the skills to make them cheaply

Why are you so convinced that in order for a game nowadays to become popular it needs to have 3D graphics? You know there are many popular 2D based games out there?
Here is a list of 6 2D based games (that I know of who) are amongst top 100 most currently popular Steam games (http://steamcharts.com/top):


Terraria at 20th place: http://steamcharts.com/app/105600
Stardew Valley at 29th place: http://steamcharts.com/app/413150
RimWorld at 50th place: http://steamcharts.com/app/294100
Factorio at 54th place: http://steamcharts.com/app/427520
Oxygen Not Included at 67th place: http://steamcharts.com/app/457140
Starbound at 75th place: http://steamcharts.com/app/211820



All engines so far, have stop too short in terms capability, to gain a meaningful user-base, given the already small number of potential users.

Have you ever asked why did this happen? I did and I believe that the main cause for this is too low user base which is killing the motivation for engine developers to continue their work on them.


Again I agree - perhaps then a tutorial that shows how to do the same basic thing in three different engines?

I was more thinking about tutorials about game development parts that are not dependent on game engines but sure when you need to visually show something we could make examples that would work with different existing game engines.

[phibermon]

Why are you so convinced that in order for a game nowadays to become popular it needs to have 3D graphics? You know there are many popular 2D based games out there?
Here is a list of 6 2D based games (that I know of who) are amongst top 100 most currently popular Steam games (http://steamcharts.com/top):


Terraria at 20th place: http://steamcharts.com/app/105600
Stardew Valley at 29th place: http://steamcharts.com/app/413150
RimWorld at 50th place: http://steamcharts.com/app/294100
Factorio at 54th place: http://steamcharts.com/app/427520
Oxygen Not Included at 67th place: http://steamcharts.com/app/457140
Starbound at 75th place: http://steamcharts.com/app/211820



Yes I do know more or less, do you know how many popular 3D based games there are out there?

It doesn't need to have 3D graphics no but certain game styles only work in 3D (same for some 2D styles) and out of that top 100 how many are 3D? 70? 80?

Some people want to create 3D games - you might not want to and there's nothing wrong with that but it's not about what we want - if we're going off figures? how many games of a given type there are and what API's/hardware they use? we can't ignore 3D hardware and techniques - it's a games programming website and such games are the vast, overwhelming majority :\

And as far as generic tutorials are concerned - as I've already stated, you could have a thousand of the most perfectly written generic tutorials that aren't dependent on any API's or engines - that aren't dependant on 3D or 2D. And after reading them all? someone still can't make a game.

Like it or not you can teach gamification, state machines, AI and whatever else all day long - sooner or later they'll need to draw something to the screen, play some audio, send data across a network.

We have to teach people how to do the specifics in pascal too - we can't just cover generic topics and tell people if that want to actually draw anything to the screen then head over to a C++ tutorial site or to use Engine XYZ and not to worry their pretty little heads about how it actually works or even if Engine XYZ will still be supported next year.

I mean I think it's a good idea to provide source code to examples - you'd likely agree - so how are our examples going to draw things? or are we not going to have any examples that look like games on a games programming website?

Are they going to render in 2D using somebody's engine? whose engine? we have to be impartial, if we started using somebody's engine for the tutorials what will that do to other engines?

So we use the underlying API's? which one? GDI+? windows only? ok we'll add Quartz and X11 rendering - now we need an abstraction so our examples will compile across the board - oh whoops we've written a 2D graphics library.

Definitely I'll help write generic tutorials with you or anything you think is a good idea but you've got to meet me half way here, we need to cover 3D hardware and for that we need to use an API and is there a better choice than OpenGL when it come to cross platform and future proof 3D? No it might not last forever but OpenGL 1.2 still works just fine on Windows 10 with a DirectX12 graphics card - I think OpenGL 4.5 is safe for at least as long - which has been well over 10 years now.

And finally one thing you've not realised is that nearly every game you just listed - renders using 3D hardware and that their scale and even aspects of their game-play are only possible due to 3D hardware.

When somebody is frantically scanning back and forwards through our generic, API agnostic tutorials as to why their Terraria clone is only running a 3fps then you can be the one to tell them that we skipped 90% of what they needed to know because you decided they didn't need to know it.

Come on dude - you know I'm right, agreed - generic things first, general techniques - good practices, good designs - but you can't escape 3D hardware - it will find you.

[SilverWarior]

Are they going to render in 2D using somebody's engine? whose engine? we have to be impartial, if we started using somebody's engine for the tutorials what will that do to other engines?

So we use the underlying API's? which one? GDI+? windows only? ok we'll add Quartz and X11 rendering - now we need an abstraction so our examples will compile across the board - oh whoops we've written a 2D graphics library.

And if we use OpenGL as an underlying API as you are suggesting aren't we also creating a 3D graphics library/engine?

Any way unless we are talking about graphics specific tutorials having discussion about which engine or graphic API to use is just pointless. Why? Because if we start limiting which engine or graphic API should tutorials use for their representation all we are doing is driving people away from writing any tutorials in the first place. Why? Because most of them won't be prepared to learn about specific engine or graphical API prior writing the tutorial. But they would be much more motivated to write a tutorial if they could use the engine or graphical API that they are used to work with.
Now you are surely thinking: "But that would be favoring one engine over other". Yes that is true. But you could always have other members porting the tutorial examples to work with other engines or graphical API's.
You see there is no rule saying that tutorials should be made by single person. They could always be made by groups of people or community as a whole. In fact having them made by group of people would surely lead to together quality of those tutorials.


but you can't escape 3D hardware - it will find you.

Really? How about all those old games (many still popular even today) that even predate 3D hardware. Games which had to run on computers that had far less processing power than even those non-smart phones that are out there.


And finally one thing you've not realised is that nearly every game you just listed - renders using 3D hardware

Not nearly every game but every game. But that is not due to game requiring 3D hardware but the sheer fact that every modern graphics card process all of the graphics in 3D. Even 2D graphics are processed as 3D with fixed Z orientation.


and that their scale and even aspects of their game-play are only possible due to 3D hardware.

I disagree with that. Why? Because none of the games that are on that list does suffer performance issues due to graphics cards not keeping up but instead due the CPU's not keeping up.

[Akira13]

IMO there's literally nothing else you could use other than OpenGL or DirectX to write a reasonably well-performing game nowadays (whether in 2D or 3D.) I mean, you could build it around a general-purpose graphics library like BGRABitmap or Graphics32, but that's still ultimately going to be significantly slower than any hardware accelerated solution. There's no advantages to ever using a software renderer unless you have no other choice...

Also, in regards to:
Have you ever asked why did this happen? I did and I believe that the main cause for this is too low user base which is killing the motivation for engine developers to continue their work on them.

I personally think the real reason is because 80-90% of the "engines" people have written in Pascal are useless to begin with. Namely, a huge portion of them use immediate-mode OpenGL, which is about as slow as you can possibly get. It's honestly even slower than a well-optimized software renderer in certain cases. Yet for some reason the Pascal community has continued to use it well into the 2000s (and still does in many cases). Why? I don't know. Maybe because people think "stuff that reminds them of C or C++ is scary" (which is another huge problem honestly. If you think C++ is scary you should quit trying to develop games right now, as you will never make it anywhere.) As far as I'm concerned, there is no logical reason for anyone to have used glBegin/glEnd or anything of that sort any later than 2001 or so. Anything after that is just laziness on the part of the developer. Even if you don't use shaders or vertex buffers, you can at least use glDrawArrays with client-side arrays! Sorry if any of this sounds abrasive, that honestly wasn't my intent... and it is worth pointing out that things ARE finally starting to get better in this regard. The Castle Game Engine for example, has a well optimized modern OpenGL renderer that doesn't use any immediate mode at all, as far as I can tell.

[Carver413]

IMO there's literally nothing else you could use other than OpenGL or DirectX to write a reasonably well-performing game nowadays (whether in 2D or 3D.) I mean, you could build it around a general-purpose graphics library like BGRABitmap or Graphics32, but that's still ultimately going to be significantly slower than any hardware accelerated solution. There's no advantages to ever using a software renderer unless you have no other choice... Also, in regards to: I personally think the real reason is because 80-90% of the "engines" people have written in Pascal are useless to begin with. Namely, a huge portion of them use immediate-mode OpenGL, which is about as slow as you can possibly get. It's honestly even slower than a well-optimized software renderer in certain cases. Yet for some reason the Pascal community has continued to use it well into the 2000s (and still does in many cases). Why? I don't know. Maybe because people think "stuff that reminds them of C or C++ is scary" (which is another huge problem honestly. If you think C++ is scary you should quit trying to develop games right now, as you will never make it anywhere.) As far as I'm concerned, there is no logical reason for anyone to have used glBegin/glEnd or anything of that sort any later than 2001 or so. Anything after that is just laziness on the part of the developer. Even if you don't use shaders or vertex buffers, you can at least use glDrawArrays with client-side arrays! Sorry if any of this sounds abrasive, that honestly wasn't my intent... and it is worth pointing out that things ARE finally starting to get better in this regard. The Castle Game Engine for example, has a well optimized modern OpenGL renderer that doesn't use any immediate mode at all, as far as I can tell. I dont think that there is really anything out there that is still in production that uses legacy opengl.

[Akira13]

There definitely is..... GLScene for example is like 90% immediate mode. Even most of the shader components it includes are written in the deprecated "ARB Assembly Language" and not GLSL.

[Carver413]

There definitely is..... GLScene for example is like 90% immediate mode. Even most of the shader components it includes are written in the deprecated "ARB Assembly Language" and not GLSL. Glscene hasn't had any focused development in years, just a bunch random coders going in and changing this or that to there liking and moving on when they get bored.

[phibermon]

And if we use OpenGL as an underlying API as you are suggesting aren't we also creating a 3D graphics library/engine?

No because you can render in 2D just fine with OpenGL - pixel perfect in fact if you offset for the center of pixels. You've got to use something. why *not* OpenGL? no matter what you use you're still teaching API specifics if you want to include source with your examples.



Now you are surely thinking: "But that would be favoring one engine over other". Yes that is true. But you could always have other members porting the tutorial examples to work with other engines or graphical API's.
You see there is no rule saying that tutorials should be made by single person. They could always be made by groups of people or community as a whole. In fact having them made by group of people would surely lead to together quality of those tutorials.

That's a good idea, have fun porting my OpenGL tesselation tutorials to VESA under DOS.


Really? How about all those old games (many still popular even today) that even predate 3D hardware. Games which had to run on computers that had far less processing power than even those non-smart phones that are out there.

You mean those games that ran at 320x240, 640x480 using spites?


Not nearly every game but every game. But that is not due to game requiring 3D hardware but the sheer fact that every modern graphics card process all of the graphics in 3D. Even 2D graphics are processed as 3D with fixed Z orientation.

Yes I know - this was my point which you've just proven - "every modern graphics card processes all of the graphics in 3D" while not strictly true is true enough that teaching something like OpenGL is *essential* - yeah use an existing engine that in turn uses OpenGL if you like - different versions of the tutorials for different engines would be ideal but even if you use an existing engine you'll still find yourself talking about the hardware and how to use it unless you want somebody to end up replicating immediate mode on top of a buffered API because they don't know any better.

Following your logic we shouldn't assume they're on a modern computer at all and write all our tutorials for a hypothetical Turing machine and describe hypothetical ways that graphics might one day be printed out.



I disagree with that. Why? Because none of the games that are on that list does suffer performance issues due to graphics cards not keeping up but instead due the CPU's not keeping up.

Well I disagree with that - the scaling and vast number of sprites used in games such as Terraria or Starbound would be unfeasible to process in software. The reason the games don't suffer from the 'graphics cards not keeping up' is *because* they use hardware acceleration. Swtich to software rendering then the biggest overwhelming bottleneck will be graphics - because it's not really the graphics card keeping up - then it's the CPU doing everything except moving the final graphics to video memory.

[Akira13]

Glscene hasn't had any focused development in years, just a bunch random coders going in and changing this or that to there liking and moving on when they get bored.

I'm not sure that's true. I'm aware they kind of dropped off for a while around 2010 or so, but for the past few years they seem to have resumed a pretty organized development process with regular releases. And the coding team isn't really random.... seems to be the same 5 or 6 people all the time, headed up by someone named Pavel Vassiliev.

[Carver413]

I'm not sure that's true. I'm aware they kind of dropped off for a while around 2010 or so, but for the past few years they seem to have resumed a pretty organized development process with regular releases. And the coding team isn't really random.... seems to be the same 5 or 6 people all the time, headed up by someone named Pavel Vassiliev. well maybe there is still hope for it then.

[Akira13]

well maybe there is still hope for it then.

Only if they start to focus on modernizing the rendering code. No amount of features will make up for an underlying engine that simply doesn't perform well....

[phibermon]

Only if they start to focus on modernizing the rendering code. No amount of features will make up for an underlying engine that simply doesn't perform well....

EDIT : in the branches of their revision server there's a Vulkan branch - so no I don't see any modern OpenGL code but it looks like they're not idle on the technology front.

However I hope the developers have been engaged in some hardcore work behind the scenes - Vulkan is hardly a drop in replacement for OpenGL - you really need to know what you're doing and going from an immediate mode GL design to a low level Vulkan design without extensive experience in the upper echelons of OpenGL could become quite the nightmare for them - Vulkan is very unforgiving of errors and it doesn't hold your hand.

[Akira13]

EDIT : in the branches of their revision server there's a Vulkan branch - so no I don't see any modern OpenGL code but it looks like they're not idle on the technology front.

However I hope the developers have been engaged in some hardcore work behind the scenes - Vulkan is hardly a drop in replacement for OpenGL - you really need to know what you're doing and going from an immediate mode GL design to a low level Vulkan design without extensive experience in the upper echelons of OpenGL could become quite the nightmare for them - Vulkan is very unforgiving of errors and it doesn't hold your hand.

Yes, I'm aware. I think it would make far more sense for them to move to OpenGL 4+ than Vulkan, though... OpenGL 4 would give them all the performance they'd ever need while still remaining somewhat accessible to the sort of user who wants to add their own rendering code to an application. Almost nobody "needs" Vulkan, and the learning curve for Vulkan has proven itself to be steep enough that even professional studios staffed with industry veterans are making mistakes with their initial Vulkan ports (IE: almost nobody knows HOW to use Vulkan.)

By the way, as a general note regarding Pascal-based game development tools, I've been working on fixing (and later improving) the Lazarus port of DeleD since this past June... currently in the process of rewriting all the rendering code. (There's a post on the Lazarus forums I made that goes into more details, if anyone's interested.) Here's a couple screenshots of what it's looking like so far. Keep an eye out!

https://i.imgur.com/7iVT1Pw.png (http://i.imgur.com/7iVT1Pw.png)
https://i.imgur.com/7GEjy1B.png

[phibermon]

Yes, I'm aware. I think it would make far more sense for them to move to OpenGL 4+ than Vulkan, though... OpenGL 4 would give them all the performance they'd ever need while still remaining somewhat accessible to the sort of user who wants to add their own rendering code to an application. Almost nobody "needs" Vulkan, and the learning curve for Vulkan has proven itself to be steep enough that even professional studios staffed with industry veterans are making mistakes with their initial Vulkan ports (IE: almost nobody knows HOW to use Vulkan.)

By the way, as a general note regarding Pascal-based game development tools, I've been working on fixing (and later improving) the Lazarus port of DeleD since this past June... currently in the process of rewriting all the rendering code. (There's a post on the Lazarus forums I made that goes into more details, if anyone's interested.) Here's a couple screenshots of what it's looking like so far. Keep an eye out!

https://i.imgur.com/7iVT1Pw.png (http://i.imgur.com/7iVT1Pw.png)
https://i.imgur.com/7GEjy1B.png


I think GL4 would be a more useful target too - there will likely never be vulkan support on OSX (Apple have their own API - Metal) and there's no indication that we'll see Vulkan on mobile devices in its current form or a 'cut down' version like GLES is to OpenGL. The general setup of Vulkan is like GL4 but designed around low level access to memory and the GPU - specifically when it comes to asynchronous access from multiple threads - IE with DirectX12 / Vulkan / Metal you can set it up to be handling some shader heavy transform feedback functionality while doing fixed pipeline heavy stuff like rendering shadow maps - you need a very specific and sophisticated design to even be able to take advantage of this - GLScene is NOT that - Vulkan is only faster if you make use of such things - if you don't? it's just a more difficult OpenGL4.5.

Vulkan doesn't replace OpenGL either - there will be new OpenGL versions etc - I myself have been planning around Vulkan since I learned some use cases and there's some areas where I *can* take advantage of it but not many - maybe in a year or two when it's better understood and professionals open up more about usage patterns I'll be able to identify more areas I can use it and it'll become beneficial to implement.

For now I'm all about optimizations involving OpenCL compute - that'll keep me more than busy enough lol

--

Good! DeleD was a promising project and I was really surprised that development seemed to stop - it's looking great and I look forward to seeing new developments!

[Dan]

Vulkan is very unforgiving of errors and it doesn't hold your hand
yet it has an extremely useful feature - validation layers. if you enable parameter validation layer for example it will tell you every time you pass in an invalid parameter to a function. but it is extremely low level and I am now at about 100 KB of code just to get Vulkan to initialize and start rendering. This is off topic of course, but I have been researching Vulkan for the last 6 months, it is very promising. Bero, has done some amazing work to make Vulkan available for pascal developers here https://github.com/BeRo1985/pasvulkan.

[phibermon]

yet it has an extremely useful feature - validation layers. if you enable parameter validation layer for example it will tell you every time you pass in an invalid parameter to a function. but it is extremely low level and I am now at about 100 KB of code just to get Vulkan to initialize and start rendering. This is off topic of course, but I have been researching Vulkan for the last 6 months, it is very promising. Bero, has done some amazing work to make Vulkan available for pascal developers here https://github.com/BeRo1985/pasvulkan.

I wasn't aware that Bero was working on it, that's absolutely fantastic news - thanks Dan!

You clearly know more than I do (which is very little so far) these validation layers make coding for Vulkan a far more appealing prospect by the sounds of it however you're a very experienced developer and 100KB of code just for init indicates an awful lot of work and learning will be required to reach the same stage - the potential performance benefits are very tempting. We're really lucky that Bero is working on this and releasing code that we can use - he's a true guru and far more capable than me - hopefully I'll be able to put his work to use in my projects eventually.

I'd be interested in hearing more about your experiences with the API one of the days if you have the time to discuss - it would be useful to put together a small article for prospective pascal Vulkan developers so they know what to expect and can plan accordingly.

Thanks for the heads up!

--

EDIT : I just wanted to add for those reading that Vulkan actually is available on Android so that does make it a far more tempting target. Unfortunately however it is not and will not be available on OSX/IOS - such a shame that Apple have got the propitiatory bug (so to speak) - so much extra work for everybody.

Given the time it takes to develop engines, if work on PGDCE should resume? it may pay for us to design with Vulkan in mind - if learning is the main aim of the game? we all have something to learn there.

[AthenaOfDelphi]

So we've heard quite a bit from regulars.... what about everyone else???

Everyone who is lurking around posting just when they have a question... in the words of Mr. Morden.... What do you want?

I want to hear from as many of you as possible, so get posting!

[Rodrigo Robles]

Sorry for the late response, I can't read all the messages from all the forum sections, even a small amount that we have today requires more time than I can get. But I assume that is a reality that we should face as a natural things nowadays, with a lot of social networks and infinite messages.

First about the community engine: I never offered my help to the engine because my OpenGL knowledge is about 1.0 version, and for me OpenGL still is the API of preference. I could help more as a user or tester when the first versions come out.

For the guys that pointed that the homemade engines can't face the big commercial ones. Nowadays I believe it's true. But free software tends to overcame commercial software sooner or later, and we are plenty of examples like Linux overcoming windows (now in all arenas except desktop), Firefox/Chromium/Chrome overcoming IE and so on. In the game engine arena OGRE can be still weaker than Unity, but the history shows that some free software can overcome the proprietary software sooner or later.

SilverWarrior said "my current job is draining almost all of my energy from me". Welcome to the capitalism, my friend! I don't want to divert the conversation for economical or political models, but it is a valuable pointed. Athena pointed something similar, and I can say the same. Our actual political/economical model is built do extract the most of the energy from us to continue enrich that 1% of guys that keep the capital. So we work like slaves and have few time to do any kind of community work.

I'm participating of several communities, including techies like PGD and Free Software and others less techie and more local. In all the communities we are facing the problem of low contribution and people sucked for the work. And we aren't even talking about all that people that is just alienated that not realize how communities are important to the society.

And the bad news is I can see nowhere providing an easy solution for this problem. The solution we are working in many communities is to share knowledge about how communities are important to the society and how people can work together to build a better life. But is a long-term solution. There is no short-term solution.

I believe that being a member of a community is a two-hand way, every people contribute with something that builts into a larger whole. What I expect from the community is to exchange knowlege with others. I like to talk about technical questions and to read about the game projects.

At last I want to say that I really respect the efforts of Athena to keep up the community. The real heroes are the people that fight for their people, not vain people of industry that fight for profits and fame. When you need help funding for the hosting or any other thing please call me.

You're right to feel bad in the corporative workspace. I feel like that. Many corporations (not all, but the majority) can't manage their workers correcty, building a toxic environment of stress and harassment.

[AthenaOfDelphi]

Well, from a stress perspective I'm much better these days. I've just spent 5 days house bashing, rewiring a kitchen ready for the installation of the accessories once the kitchen is fitted, later in the week I'll be moving some more light switches and a socket outlet in the same property :) Far more satisfying than being sat at a desk all day :D

[Akira13]

Kinda reviving this thread here, but I've spent some serious time browsing through the PGDCE sources over the last couple of days and man, it sure seems like it's basically just Cast Engine 3.0. Was there any particular reason why George/Mirage had such a relatively "heavier" influence on the engine than everyone else? It's not a bad codebase overall at all, though. Certainly could be continued/improved upon/picked up from where it was left off pretty easily, I'd say. One thing I would definitely do immediately (if it was up to me) is completely scrap all use of that nightmarish fake-generics "template" library. Talk about include-file hell! There is no logical reason for anyone to be using anything other than Generics.Collections for their container classes these days, whether on Delphi or FPC/Lazarus. (The FPC version is actually better, BTW.)

[AthenaOfDelphi]

The reason it was heavily influenced by Mirage is because he was the only one who really contributed any code.

What's really come out of this is that the vast majority of the site users don't have much to say about the site and seem to have even less interest in generating useful content and such like. I've received a small handful of offers of help, one of which I still have to review, but other than that... nothing.

Which does beg the question, why bother?

Well because looking at the forums there is a steady flow of new posts, but it is really quite depressing that so few people are willing to give a little bit of their time back to help improve the community they probably benefit from. I have no idea how to change that.

[Akira13]

I posted a project in the tutorial forum just a couple of days ago, if that's any consolation!

[AthenaOfDelphi]

Thanks

And do you mind me asking how long it took to put it together and get it posted? What I'm getting at is they don't have to be epic monsters, just useful :)

[Akira13]

Thanks

And do you mind me asking how long it took to put it together and get it posted? What I'm getting at is they don't have to be epic monsters, just useful :)

Only around three hours or so

[AthenaOfDelphi]

As I've said before, if everyone who is a regular visitor took a small amount of time to write some content for the site... once every year, we'd be brimming with new, regularly updated content.

[pitfiend]

...One thing I would definitely do immediately (if it was up to me) is completely scrap all use of that nightmarish fake-generics "template" library. Talk about include-file hell! There is no logical reason for anyone to be using anything other than Generics.Collections for their container classes these days, whether on Delphi or FPC/Lazarus. (The FPC version is actually better, BTW.)

This was a topic of very deep debate, we decided to drop generics, because there are differences between Delphi and FPC on how they tackle them. So, as we wanted to provide an engine for everybody, there are some sacrifices to do and some requirements to meet.

[Akira13]

This was a topic of very deep debate, we decided to drop generics, because there are differences between Delphi and FPC on how they tackle them. So, as we wanted to provide an engine for everybody, there are some sacrifices to do and some requirements to meet.

FPC is 100% compatible with Delphi-style generics when you use the {$mode Delphi} define though, which you guys did in fact have set for FPC in "PGDCE.inc". So you could have just used the Delphi syntax and not had any issues on either compiler.

[pitfiend]

FPC is 100% compatible with Delphi-style generics when you use the {$mode Delphi} define though, which you guys did in fact have set for FPC in "PGDCE.inc". So you could have just used the Delphi syntax and not had any issues on either compiler.

we decided to drop generics because we planned to bring the engine to developers on older delphi with no generics.

[JC_]

People are talking here about APIs.. it's unnecessary debate :) If is somebody making 3D game so it's clear that he will use Unity, Unreal Engine or something like that.
Using something else is 100% nonsense. For 2D no matter if you have OpenGL 1 or 4.5 and it's question about framework. Simply use something which have living community like SDL or SFML
because all Pascal engines/frameworks are dead, it's one man show, looks prehistoric or they are super slow - anyway no one is using them.

If there was anything usable so it was ZenGL, but today it's useless also, unfortunately.



I think we should more focus on making tutorials about various game mechanics like:


managing game states
working/managing with in-game entities
path finding algorithms
AI
procedural assets creation
physics
and so on



This is good idea, but instead of tutorials we can create a community which share and improve code and where people can learn something.
The code should be optimized and easy to use. It has some perspective. I saw interesting things around like Coolsprite (something like Spine 2D) etc, also everyone need particle engine,
sound manager..

[SilverWarior]

If is somebody making 3D game so it's clear that he will use Unity, Unreal Engine or something like that.
Using something else is 100% nonsense.

Why do you say using something else is nonsense?
Tell me what would prefer more? Using Unity or Unreal Engine and with it being forced to do most of the programming in some other programming language than Pascal? Or seeing that comparable pascal based game engine is being built so you could do all of the programming in Pascal?
Well the idea of PGDCE is to make the later option a reality. But off course such task isn't trivial and I fear many of PGD members are afraid and insecure in their knowledge in order to participate in such project.


For 2D no matter if you have OpenGL 1 or 4.5 and it's question about framework.

I strongly disagree with you on this. Even when rendering 2D graphics you could greatly benefit from features available in newer API's.


Simply use something which have living community like SDL or SFML because all Pascal engines/frameworks are dead, it's one man show, looks prehistoric or they are super slow - anyway no one is using them.

Why do you think all Pascal engines/frameworks are dead? Because there weren't enough interest in using them. And why weren't enough interest from people in using them? One of the reasons is people always saying of how much they suck instead of trying to help improving them. Pretty much like you now.
The hard truth is that if we don't get together and start working on them nobody will.


This is good idea, but instead of tutorials we can create a community which share and improve code and where people can learn something.
The code should be optimized and easy to use.

Why should the posted code be optimized? So that you can only copy and paste it into your project? This way you won't learn much especially because heavily optimized code is often much harder to understand.
I would recommend that instead of worrying about the posted code being optimized we provide as many possible approaches in solving specific problems. This way we allow people to chose the approach which suites them the most. And that largely depends on their coding style and the rest of the project code.
Also once people truly understand some gane concepts they will be able to optimize the code on their own. And yes optimizing code for some game concept also heavily depends on the rest of the project code.

And no I'm not one of those people who say "Best optimization is no optimization at all". I myself like to have nicely optimized code but I try to avoid doing any premature optimizations but I still sometimes get carried away with premature optimization. Well nobody is perfect.

[turrican]

Hi,

Most of the time Object Pascal compiled code is near fast as C++ code. I develop applications and games with Delphi/FPC (production enviorment) and never have perfomance problems. Every language developer can do good programs and bad programs. The important thing is the developer and the spirit.

I use ZenGL to make games for Android, Windows and Linux, and all the games I developed runs at 60fps at most systems with FULLHD graphics, more FPS than crap Android Java SDK based games. Also I'm trying to port Ñuño's AllegroPAS to Android.

I think the developer is the whole think and programming language is a secondary stuff.

[turrican]

If there was anything usable so it was ZenGL, but today it's useless also, unfortunately.



You are wrong... Today is still usable and stable. But need developers to mantain it! I think we need to focus on this framework because is simple and very strong.

[Akira13]

we decided to drop generics because we planned to bring the engine to developers on older delphi with no generics.

I see. Personally I wouldn't have bothered with trying to support versions that old, but that's just me. I mean, if you can't afford a newer Delphi version, why wouldn't you just use FPC/Lazarus instead? I'd rather quit programming forever than have to use Delphi 7 in this day and age...


You are wrong... Today is still usable and stable. But need developers to mantain it! I think we need to focus on this framework because is simple and very strong.

It's an abandoned project (the developer seems to have just vanished) built ENTIRELY around outdated OpenGL functionality. I don't doubt you get 60 FPS in what are probably relatively simple 2D sprite games, but that's just your CPU brute-forcing the immediate-mode rendering. If you tried to scale ZenGL up to anything relatively complex you would hit a brick wall, trust me.

[turrican]

It's an abandoned project (the developer seems to have just vanished) built ENTIRELY around outdated OpenGL functionality. I don't doubt you get 60 FPS in what are probably relatively simple 2D sprite games, but that's just your CPU brute-forcing the immediate-mode rendering. If you tried to scale ZenGL up to anything relatively complex you would hit a brick wall, trust me.


Yes, simple 2D games are my focus now. No CPU usage at all (2%) with more than 800 sprites at screen. What modern framework do you recommend me to have the same functionity?

[JC_]

Why do you say using something else is nonsense?
If you're making a real 3D game so you need complex and standardized tools with some continuity and with good visual/graphics possibilities (in case that you are not John Carmack).
It's not only about people but also about time and money. There are some good non-commercial 3D engines? Or exists more commercial engines which can compete Unity, UE, CryEngine?
I like games like Legend of Grimrock with own 3D engine which have benefits from optimalization etc., but this is another case. They have team of people making engine directly for the game
not not kind of universal thing. Secondly, I have not seen such game with own 3D engine done in Pascal or in Java etc. => if somebody want 100% performance logically he uses the language that will allow it.


I strongly disagree with you on this. Even when rendering 2D graphics you could greatly benefit from features available in newer API's.
Can you specify which benefits and features? OpenGL have shader support since 2004, which was maybe most important thing for 2D graphics rendering?


Why do you think all Pascal engines/frameworks are dead? Because there weren't enough interest in using them. And why weren't enough interest from people in using them? One of the reasons is people always saying of how much they suck instead of trying to help improving them. Pretty much like you now.
If you need more real reason: 90% of them were not usable just some start-up projects. Working systematically is challenging. In second case, capable author(s) lost interest ( own life, no time, growing complexity, limitations of Pascal language..).
You can use same concept again and it will probably fail again. I do not know how you, but I preferred the solution which survived such natural selection and are universal like SDL or SFML..
This increases the chances to finish game in 1 person lifetime.


Why should the posted code be optimized? So that you can only copy and paste it into your project? This way you won't learn much especially because heavily optimized code is often much harder to understand.
I would recommend that instead of worrying about the posted code being optimized we provide as many possible approaches in solving specific problems. This way we allow people to chose the approach which suites them the most. And that largely depends on their coding style and the rest of the project code.
I do not understand much here, eg. ZenGL code is well optimized and very easy understandable and modifiable. On other hand there is ZenGL Particle editor from different author who did great job but it's pure chaos.
Chaos is not optimized in that sense :)

[JC_]

It's an abandoned project (the developer seems to have just vanished) built ENTIRELY around outdated OpenGL functionality. I don't doubt you get 60 FPS in what are probably relatively simple 2D sprite games, but that's just your CPU brute-forcing the immediate-mode rendering. If you tried to scale ZenGL up to anything relatively complex you would hit a brick wall, trust me.

With ZenGL you can render >10 000 animated sprites with transformations on 10y old hardware without any problems, it uses sprite batching etc. If there is any bottleneck so it's management or structure of game objects and their dynamics adding and removing - so rather Pascal language performance problems. Also internal ZenGL gameloop have some gaps in performance and it does a lot.

[AthenaOfDelphi]

Edited:-

If you are experiencing performance issues with Pascal, I would suggest that the problem is perhaps yours and not the language. Achieving maximum performance takes skill in the form of a thorough understanding of what's slow, what's fast and what's going on when your code is actually executed. It also requires patience. I spent 12 months optimising the server for my first publicly released game and it showed because performance wise it blew away a lot of the competition and included the capability to scale to handle lots of users. I learned a lot doing it and have since applied that learning to more commercial products for some past employers and I have frequently been able to beat 'the best tools for the job' using Delphi.

Engines are ultimately written for a purpose. I'm in the process of starting a new game development project. Am I going to use an engine that already exists? No, because the ones that are out there won't do what I want in the way I want them to so I'm planning on rolling my own. There is one engine out there that would do what I want, but the chances of me getting my hands on it are nil! If it takes me a couple of years, so be it, if it takes me longer, again so be it. Along the way, I'll learn some neat stuff, have fun and be a better developer at the end of it.

Now my original post was driven by some of the posts before it are simply rubbishing our attempts to try and create something for the community. Part of the problem with a lot of the frameworks that exist currently is that they are written by one person! Life gets in the way and the project dies a death and then people complain. Well here's a radical idea... you want to know why good shit exists for other languages??? Because lots of people come together to work on them! It's that simple! One of the key problems this site has experienced through out it's life is this unwillingness of the community to get in there and help out and give back. Now if you've volunteered your services in response to some of my rantings on this subject, thank you it is much appreciated... I know I have one article to review that I've just been a bit busy to get around to (and if you think this is a cop out, screw you, I'm busy trying to build a business from the ground up in an area where I have no commercial contacts or pre-existing customers and it's hard going).

Maybe, just maybe, if the community had volunteered to help some of these earlier projects they wouldn't have died a death. Maybe, just maybe.

I keep banging on about this, and I'm going to continue until either everyone that does this leaves or people stop complaining about what exists for this language. The reason it doesn't exist is because people don't give up their time for the benefit of others and those that do are normally called out because 'this is wrong with the engine', 'the documentation sucks', 'there's no examples'. If you're that kind of person, keep your negative comments to yourself about the endeavours of people who have genuinely tried to help this community by trying to bring tools to it that enable the vast majority to do what this site is about... make games.

My original post was a far more personal attack and I'm sorry about that but the last few posts pushed me over the edge.

Pascal is an amazing language and simply lacks the community support that exists for other languages. You want more for the language you (we) need to do more, to create more, to share more.

[Akira13]

I honestly have no idea how we got onto this particular tangent about APIs/ZenGL/C++/e.t.c to begin with, but I certainly agree with what AthenaOfDelphi said above. Also, on a more general note, there are two specific things I've noticed in the sources of various dead Pascal game engines I've browsed through that seem to crop up consistently and are likely part of what contributed to the death of the engines in question, that I thought I'd outline here as "things to be avoided" for any future Pascal game engine devs:

1) They all try to "reinvent the wheel" when there's absolutely no reason for them to do so.

By this, I mean: they have their own "System" or "Core" or some similar name units where they redefine all of their own keyboard codes/mousebutton codes/e.t.c, and re-implement already-existing basic things like string handling functions, file system handling functions, and so on and so forth. 99% of the time these functions are objectively worse/slower/buggier than the Delphi RTL or FPC RTL equivalent. The overall point being: Design your engine around the existing, established "Object Pascal" RTL core shared by Delphi/FPC. I promise you that your handwritten string routines aren't as good as you think they are. Also, your redefinition of all the keyboard codes is both utterly pointless and incredibly inconvenient. Just use the "VKs"!

2) They attempt to implement their own image loading/handling code instead of using established image libraries that actually work.

I cannot count the number of times I've encountered some utterly broken low-level behemoth of an OpenGL texture loading routine, full of pointers getting typecasted to integers and other stupidity that won't even come close to working in anything other than 32-bit applications compiled in ancient products like Delphi 6 or 7. Every time I encounter methods like this I just replace them with the same less-than-twenty-line BGRABitmap-based loading routine I use in every project, and immediately everything works perfectly! The overall point, for this one, being: if you were the sort of developer who wrote useful, high-quality image-related code, you would already know it. The rest of us should just pull the libraries written by those people into our own projects!

[AthenaOfDelphi]

And I absolutely agree with those two points.

[LP]

The problem is that you should Write Games, Not Engines (https://geometrian.com/programming/tutorials/write-games-not-engines/) (bold intended). Even if a hobby developer(s) have the appropriate software engineering background with an actual work experience (many of developers of hobby engines don't) to be able to come up with a "not so horrible" architectural design eventually, without any well-thought objectives and reasons behind the developed engine in question, it still won't be very useful even for original developer itself.

So my suggestion would be, just stop making any new engines - not for your own projects, not even as a learning experience. If you want to learn, just make an actual game, maybe a very simple one, you don't need an engine for that: just a TCanvas, TBitmap and its magical Scanline property are the only ones you would need. If you want to learn an API like OpenGL, then just learn it, but without any helpers such as SDL, GLFW or similar, which distract you from learning what's actually happening behind the scenes. Just my two cents...

[Carver413]

I honestly have no idea how we got onto this particular tangent about APIs/ZenGL/C++/e.t.c to begin with, but I certainly agree with what AthenaOfDelphi Also, your redefinition of all the keyboard codes is both utterly pointless and incredibly inconvenient. Just use the "VKs"!
written by those people into our own projects!
I like Being able to use a single case statement for keyboard or mouse input but I don't believe that is possible with VKs


case vMessage.Input.CombineButton of
CK_CONTROL or CK_MOUSE1 :begin
end;
CK_CONTROL or CK_Alt or CK_MOUSE1:begin
end;
CK_MOUSE2 :begin
end;
end;



case vMessage.Input.CombineKey of
CK_Alt or CK_S :begin
end;
CK_Shift or CK_S :begin
end;
end;

also BGRABitmap is one of those reinvented wheels that you so greatly discourage. and kind of a bulky solution just to get a texture into video memory

[AthenaOfDelphi]

The problem is that you should Write Games, Not Engines (https://geometrian.com/programming/tutorials/write-games-not-engines/) (bold intended). Even if a hobby developer(s) have the appropriate software engineering background with an actual work experience (many of developers of hobby engines don't) to be able to come up with a "not so horrible" architectural design eventually, without any well-thought objectives and reasons behind the developed engine in question, it still won't be very useful even for original developer itself.

So my suggestion would be, just stop making any new engines - not for your own projects, not even as a learning experience. If you want to learn, just make an actual game, maybe a very simple one, you don't need an engine for that: just a TCanvas, TBitmap and its magical Scanline property are the only ones you would need. If you want to learn an API like OpenGL, then just learn it, but without any helpers such as SDL, GLFW or similar, which distract you from learning what's actually happening behind the scenes. Just my two cents...

Performance wise, it's not going to be great using TCanvas and TBitmap etc. And as for learning OpenGL, if you're just starting out, it can be a bit daunting.

When I first joined this site there were quite a few nice little frameworks that worked out of the box and allowed people to make games easily. Many of these are not developed anymore and as a consequence there is a lack of some basic functionality that allows people to create games with decent graphical performance.

So whilst I fundamentally agree, writing games is the ultimate goal, for those that have a great idea in terms of gameplay but lack some of the finer technical skills to make it work when it comes to the graphics etc. what can they do? Some people may simply never be able to develop the skills required to build even the basics because it's beyond them, but give them a tool chain that facilitates their ideas and hey presto, they may be able to make a game. There are enough skilled people on this site to be able to do this, I'd like to see a well documented engine focusing on say 2D for now, created and maintained by the community for the community so that those people who simply want to make games without having to focus on the technical aspects of OpenGL etc. can do so.

[laggyluk]

When I first joined this site there were quite a few nice little frameworks that worked out of the box and allowed people to make games easily. Many of these are not developed anymore and as a consequence there is a lack of some basic functionality that allows people to create games with decent graphical performance.

So whilst I fundamentally agree, writing games is the ultimate goal, for those that have a great idea in terms of gameplay but lack some of the finer technical skills to make it work when it comes to the graphics etc. what can they do?
Pick up any other existing engine? There's no reason to stick with pascal if someone wants to make a game, on the contrary. And if someone wants to make a pascal engine he should first make couple of games in other engines to see how it's done anyways.

For example people arguing over using VK key codes in previous posts might discover that in proper engine it's necessary to define input actions and map them to keys instead of using key codes directly.

[Akira13]

I like Being able to use a single case statement for keyboard or mouse input but I don't believe that is possible with VKs


case vMessage.Input.CombineButton of
CK_CONTROL or CK_MOUSE1 :begin
end;
CK_CONTROL or CK_Alt or CK_MOUSE1:begin
end;
CK_MOUSE2 :begin
end;
end;



case vMessage.Input.CombineKey of
CK_Alt or CK_S :begin
end;
CK_Shift or CK_S :begin
end;
end;

also BGRABitmap is one of those reinvented wheels that you so greatly discourage. and kind of a bulky solution just to get a texture into video memory

You can definitely use VKs with case statements. Not sure why you would think otherwise.


procedure TForm1.FormKeyUp(Sender: TObject; var Key: Word; Shift: TShiftState);
begin
case Key of
VK_UP:
ShowMessage('Up!');
VK_DOWN:
ShowMessage('Down!');
VK_LEFT:
ShowMessage('Left!');
VK_RIGHT:
ShowMessage('Right!');
end;
end;

Also BGRABitmap is not what I would call a "reinvented wheel", nor is it a game engine. It's also written by someone who actually knows what they're doing! I'd much rather use it and be able to handle all major image formats in a single short method than have to write my own thousand-plus line unit with a separate BMP loading routine, PNG loading routine, TGA loading routine, e.t.c.

[Carver413]

You can definitely use VKs with case statements. Not sure why you would think otherwise.
procedure TForm1.FormKeyUp(Sender: TObject; var Key: Word; Shift: TShiftState);begin case Key of VK_UP: ShowMessage('Up!'); VK_DOWN: ShowMessage('Down!'); VK_LEFT: ShowMessage('Left!'); VK_RIGHT: ShowMessage('Right!'); end; end; Also BGRABitmap is not what I would call a "reinvented wheel", nor is it a game engine. It's also written by someone who actually knows what they're doing! I'd much rather use it and be able to handle all major image formats in a single short method than have to write my own thousand-plus line unit with a separate Bitmap loading routine, PNG loading routine, TGA loading routine, e.t.c. those are only single key not combo's

[Akira13]

Well, my example is obviously restricted to the capabilities of the VCL/LCL event handling system. I think you may have missed my point though: I wasn't saying you should only use built-in key handling methods, I was just saying you should use the actual keycodes that already exist instead of defining your own. For example, VK_A is defined as $41. If you go and define MYENGINEK_A as $58, you're just making the engine less compatible with everything for no reason.

[JC_]

Please do not take it personally or emotionally as in previous case, but it's little bit out of reality. Form/VK/BGRABitmap.. Minesweeper 2?
BGRA is great stuff when you're making editors for game or such things.

There is no good choice in pure Pascal game library/framework right now, if someone wanted to make a commercial product.
I remember only one ZenGL game which was in Steam Greenlight and thats all.

[Akira13]

Please do not take it personally or emotionally as in previous case, but it's little bit out of reality. Form/VK/BGRABitmap.. Minesweeper 2?
BGRA is great stuff when you're making editors for game or such things.

There is no good choice in pure Pascal game library/framework right now, if someone wanted to make a commercial product.
I remember only one ZenGL game which was in Steam Greenlight and thats all.

No offense taken, but you've definitely completely missed my point. (Also, when did I take anything "emotionally" or personally? Do you have me confused with someone else?) I use BGRABitmap to load images for use as OpenGL textures/to perform blending/e.t.c. and that's it. I've certainly never used TForms in any game or game engine related project I've ever written. Finally, once again, my point about the VKs was just that you should simply use the existing VK codes instead of defining your own. (Because, as I'm sure you know, they're just numerical constants, and nothing more!) Not sure where you got the idea that I'm suggesting people should write BGRABitmap-enhanced VCL/LCL-based game engines....

[AthenaOfDelphi]

Let's get this thread back on track.

First up, to those suggesting we might like to use other languages and tools.... this is a site about developing games with Pascal. I don't want to use Unity, C#, Game Maker etc. etc. etc. I want to use Pascal, just like many of the other visitors here. Suggesting we're wrong for this (and with some of the comments, intimating we're somehow mentally deficient because of this) is wrong. There are no technical reasons why you can't use Pascal to make games. Performance wise it's right up there, learning it is pretty straight forward and there is a good range of tools.

The project failed because people couldn't agree, it was overly ambitious and ultimately only one person contributed any sizeable amount of code.

There are posts that suggest we should make games not engines, and having read the post by Ian Mallett I generally agree... but what are you going to use to make a game? What's out there that is well documented, under active development and isn't reliant on a single developer?

This is the hole I was hoping we might, as a community, be able to fill.

[laggyluk]

What I was trying to say was that technology is secondary choice in making a game once you decide to do it. You should judge features and pick whichever engine fits your game idea best. Trying to do it in non mainstream tech basing on sentiment is wasting resources.

On other hand If you want to make game engines then pascal is perfectly fine choice.

[LP]

The project failed because people couldn't agree, it was overly ambitious and ultimately only one person contributed any sizeable amount of code.
No, the project failed because it was doomed since beginning - the article "Write Games Not Engines" that I've linked explains why.


What's out there that is well documented, under active development and isn't reliant on a single developer?
Maybe you could actually state why do you feel that existing engines/frameworks do not suit YOUR needs? That is, name a specific framework/engine name and the problems that you have with it. There are authors of frameworks/engines participating on these forums, myself included, so we'll likely be able to answer for ourselves and address the issues that you may have.

Granted, there are some engines like ZenGL that were officially discontinued (and it's sad as Andrey is a very talented developer, I hope he's alright and going strong), but please, there are plenty more that are recent and active.


This is the hole I was hoping we might, as a community, be able to fill.
I think this is where you are wrong - in fact, I think, there is a market saturation, so there are TOO MANY framework/engines to choose from, it'll be quite hard to find any hole to fill. I can't say for anyone else, but at least in my case, the framework that I've published and have been maintaining since 1999 (for almost 18 years already) is just part of the common code that is shared among my own projects, and it is a part of my business plan (consulting), it wasn't made just for the fun of it, but it came as side-effect (result) of developing other products. In addition to helping anyone else, I actually make good money with it.

[AthenaOfDelphi]

As much of what I'm saying is clearly wrong, educate me.

Assume I'm a beginner (I can code Pascal well, but in terms of graphics APIs I'm a newbie), I want to use OpenGL because I want cross platform (I'm using Delphi and I'm planning on targetting Windows, MacOSX and Android). I have a game idea that is 2D tile/sprite based (run jump platformer with some top down world exploration).

Which engine/framework should I use and why?

The selection criteria are:-



Must be actively maintained and up to date in terms of API implementations
Must be maintained by more than one person (I don't want to be waiting for bug fixes, when the only dev needs a break for his/her honeymoon for example)
Must be well documented (for beginners)
Must have a good suite of examples (for beginners)


So point me in the right direction.

[laggyluk]

Firemonkey? sad.

[LP]

Must be maintained by more than one person (I don't want to be waiting for bug fixes, when the only dev needs a break for his/her honeymoon for example)

Unless the framework is provided by a large corporation such as Intel or Microsoft (and even in case of those companies, the following could apply), you might be very surprised to find out that a certain portion of an important framework or section, a single person is typically responsible of, and many times is the only fully qualified to do the appropriate maintenance. At least in the companies I've worked in, a senior developer responsible of large portion of specialized code, in the area of 2D/3D graphics, is difficult to find and/or replace (so naturally, it is typically a well paid, important position). And now, with introduction of new, complicated APIs such as Vulkan and Direct3D 12, a senior engineer for such position, that also happens to know Delphi, is even more rare, practically nonexistent. Therefore, I think that the quoted criteria point is unrealistic, sorry.

[SilverWarior]

Firemonkey? sad.

You are suggesting Firemonkey. Seriously? It doesen't ment any criteria that AthenaOfDelphi specified.


Yes it is actively maintained but the problem is that FMX is not focusing on game development but instead of standard desktop/mobile application development. Also FMX isn't up to date with latest API's. And since we are talking about API's the main problem of FMX is that on windows it uses DirectX and on other platforms OpenGL, meaning that there is no guarantee that applications developed with FMX will handle the same way on all supported platforms.
While FMX is maintained by multiple developers the problem is that their response time to bug reports is quite slow. Just check Embarcadero Quality Portal for many FMX based bug reports where some of them are even more than a year old.
As for FMX documentation. I'm afraid to tell you that it is terrible. I mean how can you say that certain documentation is good if checking documentation for some component properties actually shows you documentation similar property of one of the parent components. Or even worse when you get "Embarcadero does not have any additional information on this subject"
As for examples goes. Those that are available are again not focused on game development but on standard application development.


And main reason why I personally would not recommend FMX for game development to anyone. It is its rather poor performance.
Wanna see how poor performance it has? Create a new FMX project, place 100 panels on the form, compile, run and while running just do some rapid mouse movements across the form and observe the CPU usage.
On my 7 years laptop with 2 GHz AMD Turion X2 CPU and ATI Mobility Radeon HD 3650 graphic card having 100 panels on FMX form and doing rapid mouse movements I can cause full usage of one of the cores and FPS drops below 20. Now imagine what FPS drops I would be encountering in actual game where I would have to do a lot of other processing. And before you start saying that this is just because my laptop is worth s*** I should mention that on this laptop I can play Far Cry 3 on medium settings with average of 40 to 50 FPS .

[AthenaOfDelphi]

Granted, I was responsible for a big chunk of my teams product line up at my former employers, and I had little to do with other sections, but we were all capable of picking up the others portions (as demonstrated by the fact I handed over that huge chunk of work - 7 years worth - to another member of the team when I left). People are not irreplaceable, the people who think they are make themselves more replaceable.

I'm talking about the framework/engine as a whole... just like lots of other open source projects out there.

So with all that in mind, sounds like an excuse not to give me a good candidate for an engine I could use as a newbie. But, as I'm feeling generous, if you can't meet that criteria, lets discount it and instead go for a 75% requirements fit.

Any takers?

[SilverWarior]

If you can compromise for meeting 75% percent criteria I think you should check Platform eXtended Library. It supports multiple platforms, multiple API's through multiple providers (DirectX 7, 9, 11, OpenGL, OpenGL ES). It works both with Delphi and FMX. Supports both 2D and 3D rendering. And finally it is open-source project so anybody can contribute.
If you chose to use this one I might be able to help you get started since I have some experience with its predecessor Asphyre Sphinx 3.

Another option that you could chose is Castle game engine or nxPascal (might need a bit work to compile with modern Delphi).

[laggyluk]

You are suggesting Firemonkey. Seriously? Seriously no but it looks like only one meeting the criteria and performance was not one of them :P

[LP]

People are not irreplaceable, the people who think they are make themselves more replaceable.
As much as I would like this to be true, in case of Delphi/Pascal jobs, unfortunately this is not the case anymore, especially in very specialized, highly technical areas, so when a person leaves, you have pretty much to rethink some of the priorities. Granted, as long as the project is well designed, written and documented (which is rarely the case), it is easy to just keep maintaining, but that usually doesn't go beyond changing comments, adjusting code formatting or doing some other "esthetic" changes - for an actual development you really have to have the same expertise as the other person and know the project well, where in case of large projects it could be increasingly difficult.



So with all that in mind, sounds like an excuse not to give me a good candidate for an engine I could use as a newbie. But, as I'm feeling generous, if you can't meet that criteria, lets discount it and instead go for a 75% requirements fit.
The problem is that you've actually defined conflicting, self-excluding requirements, so either all frameworks fall into your criterias or none.

If you are a total beginner, then none of the existing Pascal engines would suit you because... in 99% of cases, you'll end up using JavaScript with WebGL instead of Pascal, or one of other attractive options such as C#, Java or Swift, depending on your needs.

If you are aiming at native development and for some crazy reason can't use C++, aiming for Pascal, then it likely you are a mid-aged person or even someone who has already retired, to pursue a favorite language of your youth. In this case, wasting 10 years to master OpenGL is definitely undesired, so you can use any of the engines/frameworks from one of existing lists (https://github.com/Fr0sT-Brutal/awesome-delphi), that people enjoy making (http://www.pascalgamedevelopment.com/showthread.php?32587-Index-of-acronyms). Most of them are cross-platform and suit all your criterias.

As an alternative, since you mentioned that existing engines/frameworks have deficiencies in your point of view, why not helping to improve them instead? Why not promoting Pascal itself by making events, LAN parties, conferences and so on, writing tutorials for existing frameworks, making new examples, etc.

[AthenaOfDelphi]

As much as I would like this to be true, in case of Delphi/Pascal jobs, unfortunately this is not the case anymore, especially in very specialized, highly technical areas, so when a person leaves, you have pretty much to rethink some of the priorities. Granted, as long as the project is well designed, written and documented (which is rarely the case), it is easy to just keep maintaining, but that usually doesn't go beyond changing comments, adjusting code formatting or doing some other "esthetic" changes - for an actual development you really have to have the same expertise as the other person and know the project well, where in case of large projects it could be increasingly difficult.

I've been in the industry long enough to know the problems caused when a key member of staff leaves and I also know it's part of the reason teams are better than individuals when it comes to large projects. Not to be too morbid, but what would happen to PXL if you ended up dead tomorrow? And it's a sad reflection of the times in which we live, but that's not a threat, it's an honest question... a question I've actually asked several members of my teams over the years.



The problem is that you've actually defined conflicting, self-excluding requirements, so either all frameworks fall into your criterias or none.

I struggle to see how being maintained by a team, well maintained to use the latest compiler/APIs, well documented with good examples are conflicting requirements. So please, enlighten me.


If you are a total beginner, then none of the existing Pascal engines would suit you because... in 99% of cases, you'll end up using JavaScript with WebGL instead of Pascal, or one of other attractive options such as C#, Java or Swift, depending on your needs.

Seems like you've just made my point for me... none of the existing Pascal engines would suit you. Isn't that what I've been trying to say? Isn't that a good reason to consider building one as a community? A community of people with varying degrees of technical capabilities... where the beginners can contribute and guide the experts in terms of what beginners need (because so often, experts forget they were beginners once and loose sight of the things that make it easy for beginners), learn from the experts so that the community benefits as a whole.


If you are aiming at native development and for some crazy reason can't use C++, aiming for Pascal, then it likely you are a mid-aged person or even someone who has already retired, to pursue a favorite language of your youth. In this case, wasting 10 years to master OpenGL is definitely undesired, so you can use any of the engines/frameworks from one of existing lists (https://github.com/Fr0sT-Brutal/awesome-delphi), that people enjoy making (http://www.pascalgamedevelopment.com/showthread.php?32587-Index-of-acronyms). Most of them are cross-platform and suit all your criterias.

Over the years, I have used numerous languages including C and C++. For some reason which I can't really explain my preference is Pascal. So when I want to write a game, it's logical to use the tool with which I am most familiar and feel able to achieve the most. Pascal it is. If I wanted to write games in C++ I wouldn't be here would I?


As an alternative, since you mentioned that existing engines/frameworks have deficiencies in your point of view, why not helping to improve them instead? Why not promoting Pascal itself by making events, LAN parties, conferences and so on, writing tutorials for existing frameworks, making new examples, etc.

1. I don't consider myself technically competent enough to contribute to existing projects, especially as they lack much in terms of documentation already (a fact I've stated clearly on numerous occasions... I consider myself a beginner who needs some help), the same reason I don't feel confident writing new examples or tutorials
2. My work/life balance has for the last 8 years been somewhat off. So much so that it has cost me a chance to get a maths degree, my ability to write code confidently, my mental and physical health have suffered. And in terms of this community, the fact is, the site is generally on-line and available.... do you think that happens by magic?
3. Conferences and LAN parties require money. Where do you think I'd be able to get the money together to do that based on the fact PGD is free, there is no advertising.
4. Previous community organised events have been, how shall I put this... less than well attended.
5. In essence what you're saying is that promoting Pascal, creating content etc. should be entirely on me? Why?

All I'm trying to do is figure out how to improve things, to breath new life into the community, to make things easier for beginners with good resources, good examples etc. That's it. In reality, I could drop the site tomorrow, simply suspend it's hosting and walk away because it (whether you see it or not) consumes my time and my resources. Either we do something as a community to improve things or we continue to loose people to other languages and tools. I'd like us to do something so other people can have the pleasure that many of use have experienced... the pleasure you get when people are playing your games, games you've developed with your chosen language.... Pascal. What's wrong with that vision?

[LP]

Not to be too morbid, but what would happen to PXL if you ended up dead tomorrow? And it's a sad reflection of the times in which we live, but that's not a threat, it's an honest question...
Yes, the Bus Factor (https://en.wikipedia.org/wiki/Bus_factor). That's the beauty of open-source: the entire source code is documented and a lot of effort was spent into making it as didactic as possible, so if anything happens, you can continue use it and someone eventually make take it over. For instance, Ultibo developers ported PXL to their platform (https://ultibo.org/asphyre-pxl-on-ultibo/) without my intervention. In fact, I'm planning on liberating it on a more liberal license such as Apache, which would give even more freedom for the development.

Remember AGG (https://en.wikipedia.org/wiki/Anti-Grain_Geometry)? That's exactly what happened there, the author passed away. The project is still alive last time I checked as people forked version before it was GPLed.




Seems like you've just made my point for me... none of the existing Pascal engines would suit you. Isn't that what I've been trying to say? Isn't that a good reason to consider building one as a community?
No, no no, of course not. :) What is mean is quite the contrary - there are very few newcomers to Delphi/Pascal world anyway and with current availability of libraries, making yet another engine is the least thing that is needed right now, IMHO.



In essence what you're saying is that promoting Pascal, creating content etc. should be entirely on me? Why?
No, of course not, I'm not referring to you personally, but in general. I know any activities like LAN parties, conferences and so on cost money, but maybe this is something that we could actually organize together. Instead of building a framework/engine that no one needs, do something together than would be more meaningful, with higher impact.

[Thyandyr]

At least for me (and perhaps others if the goal is to lure new people) a collection of reasonably well documented example projects (preferably concentrating on one thing only) or source to existing (non-engine-utilizing) game project is worth more than extensive engine or framework (even if it includes examples). I'm usually after one thing at a time and I prefer to make it myself at the lowest level so I know what is going on. In most areas I'm not so fluent I would automatically know how to do things, I first need to see what other people did. Understanding what and why and how, are things one needs to tackle first before even thinking about things like performance and portability. In this context (learning) a library or engine project with 100's of functions or features may be exhausting to crawl through. When I go look at one method, it leads to several new ones, header files to bunch of dlls, dependency injections and interfaces. A project doing one thing or limited set of things would be more useful.

In my books the E in PGDCE should stand for effort and not for engine. Whatever you do, comment it with extra effort and share it. It will strengthen the community and bear fruit in the long term.

[SilverWarior]

No, no no, of course not. :) What is mean is quite the contrary - there are very few newcomers to Delphi/Pascal world anyway

And why is that? I see two main reasons:


The fact that there aren't as many useful resources (game engines, libraries, tutorials) available for Pascal as they are for other programming languages.
People who keep bitching that there are not enough suitable resources available, like you are doing lately, instead of helping with creation of such resources.


I wish I would have at least half as much experience in game development as you do because that way I would not have much problem writing some tutorials on this topic. But I don't.
And yet this is not stopping me in very slowly writing quite extensive (perhaps too extensive) tutorial about using classes in game development. So why I'm progressing so slow with this tutorial of mine?

I no longer have as much available free time and energy as I used to when I started it. If I would be starting to write it today I definitely would go for less extensive one.
I'm still learning about game development during the whole process. And that I think might actually make the whole tutorial more interesting as I might also show some bad practices that I come up with providing good explanation of why they are bad practices and with which practices they could be replaced.

Any way I'm trying to contribute to Pascal Game Development community as best as I can.


I know any activities like LAN parties, conferences and so on cost money, but maybe this is something that we could actually organize together.

While money is one problem another big problem is great demographic diversity of PGD members. You see PGD has members from all around the world so it is quite difficult to even get in live chat with other members.


Instead of building a framework/engine that no one needs, do something together than would be more meaningful, with higher impact.

If no one needs such framework/engine then where did the idea for it come from? Why are people inquiring about what happened with it?
Also what in your opinion would be more meaningful and have higher impact to Pascal Development Game community?

[LP]

The fact that there aren't as many useful resources (game engines, libraries, tutorials) available for Pascal as they are for other programming languages.
I don't think this is the case.



People who keep bitching that there are not enough suitable resources available, like you are doing lately, instead of helping with creation of such resources.

Please don't jump to conclusions. In real life I have done my part of homework. For instance, when offered to give an introductory course to game development, instead of Unity, I've insisted to go with FPC/Lazarus as basic toolset and usually have tried to promote Pascal/Delphi tools during development as much as possible. However, one would be very naive or stupid not to realize that Pascal popularity is not as it once was and since I, among other tools, use Delphi for work and maintain Delphi/Pascal framework, am generally concerned with it.

However, I do see a couple of issues myself, but they are not technical problems. It's not lack of game engines, online tutorials or Pascal resources - for Delphi and Pascal I think there are many resources for almost everything - graphics, networking, security, databases, etc. However, I think it's general blindness on purpose and ignorance for identifying issues that Delphi/Pascal developers tend to have. Spelling out issues is discarded as bitching (as you've just called it) and in overall is received with hostility and rose-tinted glasses.



While money is one problem another big problem is great demographic diversity of PGD members. You see PGD has members from all around the world so it is quite difficult to even get in live chat with other members.
I can't help with demography problem, but I could help organizing an event by participating myself, giving a course, tutorial or a seminar, or even shed some budget for it provided that it would have an appropriate invoice.



If no one needs such framework/engine then where did the idea for it come from? Why are people inquiring about what happened with it?
Because it is a general problem - for an unexperienced developer to start and work on an engine instead of actual game. Except that, this time, this activity that should generally be avoided, was explicitly organized by PGD and performed by multiple developers, only to fail miserably as it always does, because, again, you should be doing games, not engines (https://geometrian.com/programming/tutorials/write-games-not-engines/).



Also what in your opinion would be more meaningful and have higher impact to Pascal Development Game community?
At least in the universities that I've visited, whenever a programming or game development course is given, what I usually see is Java, Unity, C#, etc. When I try to convince the administration to consider Pascal, it is usually met with some eyebrown lifting. I think this is something, addressing which would be more meaningful. How? Well, I think it does require some community involvement, so it means spending (or more accurately, wasting) time on unimportant things... like making yet a new damn engine!

[phibermon]

We do need a modern game engine for pascal - there are a number of people working on the next generation of game engines for our preferred language - Castle for example has matured into an excellent engine and it's getting better all the time. We don't yet have an Ogre3D or a Unity but we're closer now than we ever have been.

But that's not the main reason for a community engine - at least not for me. I wanted to see the community come together and pool its collective knowledge on a large project. Something we can all be proud of, spawn new collaborations. Something that people can learn from and even use in their own projects. It doesn't have to be Ogre3D, there's engines in development right now such as Castle that are tackling the high end - it's not for commercial success or making money - it's to have fun, together.

"Make games, not engines" is fine if you're making small games but isn't going to cut it for large games. I'd love for someone to be able to pick a modern pascal game engine off the shelf and write a modern game but we're not there yet.

I'm personally not interested in making games, I'm interested in making engines, developing new techniques and systems to abstract the game development process. I'm fully aware that engines are massive project and I'm fully aware that many engines fail - I'm not some kid dreaming of making the next quake! I'm a professional developer that's taken on a massive task in his spare time because it's fun to me :)

But at the same time, "make games, not engines" is the realm of the hobby coder making small indie titles that have access to things such as Unreal and Unity. People still need to render 3D objects, use shaders, utilise collision detection, path finding, steering etc etc

There's still an engine inside every game even if that engine is a one off specifically tailored for the job - there's a clear line between code related to gameplay and the code it calls as an abstraction to get the job done.

I understand the core mentality that the article is trying to get across - if somebody wants to make a game they should focus on making the game as it'll be more productive towards that end goal. It's trying to dissuade hobby coders from reinventing the wheel or writing code that they can't or won't use. It's written assuming people will be writing games in C++, javascript or any other far more popular language where all the tools already exist.

"make operating systems, not compilers" only makes sense if there's already a modern tool chain you can use. Making a modern 3D game in pascal right now, given its available engine/game related resources is like writing Linux in Cobol from scratch - yeah you can do it but the job would be way easier with the latest GNU C++ tool chain.

Almost everybody shouldn't be writing engines - it's bloody difficult and most want to make games so "make games, not engines" applies to them. But *somebody* has to write the engines, develop modern examples with Vulkan, GL4.x, write steering libraries, skinning libraries, asset trees so that people *can* make modern 3D games. Without a Unity, Unreal, Ogre3D etc to start from - that task is monumentally difficult.

Yeah you *could* of released Skyrim using the morrowwind engine and it would of been a good game but not as good as what they did release. We're moving forward, not backwards.

Can we please get back on topic and try an analyse what went wrong with the project so if there is another effort, we can make it work this time.

[laggyluk]

In my case I got side tracked and when came back it was kind of game over already. Also task that I chose (network) wasn't much fun to work on, ended up wrapping up 3rd party library with some higher level logic but then what's the point of network code that is not tightly integrated into the engine? And it was going that way (my lack of knowledge and other devs not considering multiplayer being core engine feature).

If there's going to be another try some time then I think there should be an online road map with general features to implement and detailed task lists people can pick off from. Trello/google docs. Completing small steps gives a feeling of progress and maybe more people would participate.
Of course some big head needs to be able to think things through before such tasks list can be created. Are our heads big enough?

Btw maybe this legendary pascal engine could have some feature others don't have to draw interest? Like built in soft body physics or true voxelness (boxes<>voxels). Of course there is a good reason popular engines share more or less common feature set - probably not enough demand for other stuff ;)

[Thyandyr]

If there's going to be another try some time then I think there should be an online road map with general features to implement and detailed task lists people can pick off from. Trello/google docs. Completing small steps gives a feeling of progress and maybe more people would participate.

This thread is 10 pages long so clearly there is interest. Starting sketching up a roadmap sounds like a great way to start. And instead of listing everything what a perfect engine should have, people could just add what parts they are willing to contribute to and what they wish to see. That way we get easy overview.

I'll start: I have unused domain and webhotel in case hosting is required. Would love voxel related stuff. Can do random name generation unit/voxel stuff.

[Ñuño Martínez]

(...) Would love voxel related stuff. Can do random name generation unit/voxel stuff.
I would like to see something like Ken Silverman's VoxLap engine (http://www.advsys.net/ken/voxlap/voxlap05.htm). I know that nowadays voxel has lost its initial meaning (volumetric picture element) thanks to Minecraft and maybe also Unity and Unreal. I really like that "pixelated" feeling of such engine.

I did a voxlap-style try a lot of time ago in C named VoxRend (http://voxrend.sourceforge.net/screenshots.html). I have some success but I avandoned because I messed with maths and I didn't know how to fix it (not long ago I discovered I used different axis and projection for camera, scenary and objects ::)). I still think I should resume the development (in Pascal, of course) some day.

[Thyandyr]

Voxelwise I'd aim for https://www.youtube.com/watch?v=2vnTtiLrV1w / https://github.com/nothings/stb/blob/master/stb_voxel_render.h

[laggyluk]

I would like to see something like Ken Silverman's VoxLap engine (http://www.advsys.net/ken/voxlap/voxlap05.htm). I know that nowadays voxel has lost its initial meaning (volumetric picture element) thanks to Minecraft and maybe also Unity and Unreal. I really like that "pixelated" feeling of such engine.

I did a voxlap-style try a lot of time ago in C named VoxRend (http://voxrend.sourceforge.net/screenshots.html). I have some success but I avandoned because I messed with maths and I didn't know how to fix it (not long ago I discovered I used different axis and projection for camera, scenary and objects ::)). I still think I should resume the development (in Pascal, of course) some day.
Yeah I meant something like that. There are attempts at this subject from time to time but so far nothing 'successfull' so I suppose it might not be the best idea to try;)
https://www.youtube.com/channel/UClzSvcwdGx9v66YRza5u_Mg

[phibermon]

I think it's too late to start work on a voxel engine now. The future of 3D hardware is essentially an on-chip voxel engine allowing for real-time ray-tracing. Such hardware is already in development by Intel, Nvidia and AMD.

When such hardware is with us, groups of voxels will be fundamental graphics primatives and the way an engine that makes use of such hardware works, will be quite different from current approaches.

We can expect to see the dawn of such devices in around 2 to 4 years and with them we'll see the next generation of consoles making use of them too.

So spending a few years coming up with the fastest way to handle voxels on hardware poorly suited to the task will be made defunct as all the hard work is swallowed up by the hardware and the low level APIs.

True volumetric assets are much harder to create than traditional polygonal geometry - techniques that project and merge surface textures from inputted meshes to define the properties of internal voxels notwithstanding - there's animation and deformation to content with - which is the current showstopping bottleneck of voxel engines. Hardware will have some form of direct support for such operations.

The days of traditional 3D engines are numbered yes but not as much as the days for the current approaches to voxel engines.

It'll be the death of geo clip mapping due to tessellation hardware all over again.

Traditional engines will have slightly more shelf-life - running on older hardware, requiring far less time spent creating resources and potentially being faster on newer hardware for certain types of games (can't see entire planets made of voxels (with voxels smaller than pixels) being feasible for at least another 5 to 10 years)

[laggyluk]

I think this can take longer, new gfx cards would still have to backwards compatible I suppose. First time hearing about this btw :p
Soft body physics introduce some unique possibilities (Spintires as example) but then I dont know first thing about it :p

Anyone has other ideas how this engine could stand out? Or it's not really important?

[AthenaOfDelphi]

This is more like it :)

Sorry I've not been around the last few days, did a job for a plumber last Monday and they've had work for me for several days running since, along with other customer jobs, the only day I've had off was yesterday when I spent 6 hours in the car with Spirit (my game development partner in crime) and Tia (the dog) going to visit my parents. Was a nightmare journey in the heat.

[SilverWarior]

I think this can take longer, new gfx cards would still have to backwards compatible I suppose. First time hearing about this btw :p

I don't think this would take much long. Why? Because in order to support hardware accelerated Voxel support all you need is a lot of GPU processing power. So if you take into account that today's GPU's are over ten times more powerful than they were about 10 years ago it is just the matter of time.
I have hard about hardware accelerated Voxel support for the first time about five years ago. At that time you required special hardware with insane price tag for it to work. But based on the computational power of today's GPU's I wouldn't be surprised if some of them are already powerful enough for this.
I believe that such technology just hasn't become main-stream yet. And I dare to say that one of the reasons for this are gaming consoles because their hardware development isn't progressing so quickly as PC hardware is. And the worst thing is that most AAA game developers are primarily focusing on game consoles.


Soft body physics introduce some unique possibilities (Spintires as example) but then I dont know first thing about it :p

Yes soft body physics do introduce lots of possibilities. This is technology that does interests me a lot since I had idea about general concept of soft body physics about 20 years ago after playing the original (DOS based) Bridge Builder for the first time. But at that time I still didn't know anything about programming.
Any way I forgot about that until I found a game called Rigs of Rods which is entirely based on soft body physics. That rose both sad and joyful feelings in me.
Sad feelings because someone else come up with the same idea than me and implement it in practice Would be nice if I would have done this first. ;)
And as many of you can imagine the reasons for me to feel joyful feelings was because at that time I know that I'm capable of coming up with new and unique ideas. And that is still driving me today when I'm looking and searching for new ways and new ideas.


Anyone has other ideas how this engine could stand out? Or it's not really important?

First we should make it useful for widest audience. And then we could work out on more advanced features that would make it stand out from the others. That is why the idea was to make PGDCE to be modular. So if someone found out that PGDCE does not offer him all the features he desires he could go and create a new module with those features and them perhaps also make that module available for others to use.

[Ñuño Martínez]

Anyone has other ideas how this engine could stand out?
Use Pascal Script as scripting languaje. ;)

[phibermon]

Use Pascal Script as scripting languaje. ;)

I love pascal script too - although I had issues with it in 64bit mode on FPC (possibly only on Linux) a year back. I'm not sure if that's been resolved yet.

DWS (or at least some recent fork) claims better performance and to the best of my knowledge supports the same feature set - however if memory serves they don't test or officially support FPC.

---

Just to state :

I think we could learn a lot from BeRo - he's an absolute genius coder with his finger on the pulse. He knows more about DSP and audio synthesis techniques than most of us know about all topics - let alone his work on Vulkan and pretty much every other topic under the sun that leads to at least an effective and modern 3D graphics pipeline.

We'd be wise to make use of his excellent code - for example his multi-threading library contains some excellent lock free primatives (although I have found other such libraries by authors and have not exhaustively compared performance)

He's also provided us with a 3D aware tessellation unit which I've found to be an excellent replacement for the GLU tesselator thus removing the dependency on GLU.

---

As I've stated in other posts I strongly believe that engine and content tools really make an engine stand out while also providing a framework and context in which to develop an engine.

With such a tool, preferably with a modular design, you can test every single part of the engine as you develop it - easily setting up complex tests for specific features and combinations thereof just by loading the scene into the editor.

My engine has a real-time editor that synchronises resources, the scene graph and events across multiple clients allowing for not only collaborative editing but it's also the same mechanism by which games have automatic server/client network support.

It's unit tests, engine content tool and a context for debugging all in one - plus it provides some good old fashioned application development that will be accessible to all skill levels in such a project (IE there's tons of stuff you can define in a todo list ahead of time that can be worked on without having to wait for the engine to reach a certain stage)

For my part in recommendation I believe an approach that is developed in tandem with a real-time 'scene' editor of a similar nature is a great idea.

[Akira13]

Haha yeah, I honestly think BeRo might be the best Pascal coder in the world. Who else would it be? No idea how that guy manages to write such massive yet largely bug-free libraries so quickly...

[phibermon]

Haha yeah, I honestly think BeRo might be the best Pascal coder in the world. Who else would it be? No idea how that guy manages to write such massive yet largely bug-free libraries so quickly...

I think he might be too - with great care and time I can produce good code - he could write it three times as fast with one hand while juggling with the other. I doubt he's even seen a compiler warning for years lol

[SilverWarior]

I doubt he's even seen a compiler warning for years lol

I bet otherwise ;)
The thing is that he just know how to properly handle/fix such scenarios unlike some of us who get lost sometimes because of them :(

[Triplefox]

I'm looking at this thread with interest. After spending a lot of time on web games I wanted to do something in native code again, and shopped around newer languages(Rust, Go, Nim, D) but ultimately decided that these factors were important to me:



Fast compile times
No, or opt-in, garbage collection(some reference counting is OK)
Smaller, rational language design
Good existing tooling and libraries


And FPC's Pascal fits all of these neatly. It's always beat C and C++ handily on compilation speed and ergonomics. There are "nice to haves" that are in newer languages, there are examples of stronger tooling elsewhere, and there's plenty of old cruft in the landscape, but the legacy of Delphi + FPC has actually been very good to the language since it's enabled a strong focus without much fragmentation. In comparison, if I want to do something in Rust, a lot would still have to be done "from scratch" - few or no projects to sample code from, rough libraries, a lot of stuff still being bindings to a C library.

I'm mostly agnostic now to the idea of "all Pascal everywhere", or building a top-notch engine from scratch, or other grand designs. They aren't motivating projects, to me. I think the language is a good choice for the same reasons it was originally good(small, structured, logically organized, easy to compile, some common conveniences and protections). What I mainly want to champion in this thread is the idea that you can make very cool, hip gaming software without chasing after AAA-scale projects.

My own plan for right now is to do some "Crt-only" stuff. Textmode gaming has a perennial fanbase and I can probably build up some libraries out of that. I want to produce libraries in the stb libs (https://github.com/nothings/stb) fashion: One file, you drop it in the project, and it works. This is actually way more straightforward with Pascal units, but the fact that this has become a trendy idea in C, an environment that is hostile to the concept, speaks to its appeal.

Then I would progress to graphics systems that are API-independent. The trick to that is, the application can address graphics with a high-level custom state machine. That state machine pushes commands on a stack or sets registers, and then outputs lower level API calls to your GL, DX, Vulkan, etc. This is exactly how old-school immediate mode GL talked to the graphics driver, and why it remains so convenient. It's totally valid to build that abstraction yourself when you have a design in mind and you're aiming towards a purposeful method of rendering("make games not engines").

And you can have a series of such state machines that translate a very high level source representation. Think of how canvas graphics APIs often provide a "Pen" or similar kind of state-driven drawing method: You can build your own pen and make it capable of whatever conveniences you want for whatever type of scene you want to draw. You can feed the results of that into a second system and have it process the results, and emit that to the low-level API.

If you extrapolate from this strategy, you can also take the approach of targeting an existing engine with a DLL, and then gradually strangle all the features out of it by moving more and more of them into your own code and eliminating the dependencies. The abstractions you make might not always be the nuts and bolts, but they are great seasoning, and go with anything.

Building up from prototypes is also feasible. This is why I'm starting with the "Crt-only" approach: it will get me to feedback quickly. Feedback is crucial to making progress with anything big, and it's easier to get feedback when you don't take on too much.

Lastly, I'm drawing on examples from other communities. There's the examples of Handmade Network (https://handmade.network/) and the PICO-8 (https://www.lexaloffle.com/pico-8.php) community. This former is a dev community that's very focused on "back to basics" coding for efficiency - mostly in C, but not particularly language-focused. The second is about a "fantasy console" with an intentionally retro aesthetic and harsh limits on resources, programmable in Lua, and it's been promoted as a learning tool. I'm also very inspired by analog hardware projects such as the special stage systems Ming Mecca (http://www.specialstagesystems.com/system-overview/) - game-like qualities taken out of the packaging of gaming and turned into a synthesizer instrument programmed with patch cables. These qualities deviate strongly from the accepted norms of what coding - game coding or otherwise - is or should be, and should be taken as examples of the possibility space.

There is lots of potential for "can-do". It's just a matter of finding a good leverage point and leaning on it.

[Thyandyr]

Great post Triplefox!

[turrican]

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/

[Chebmaster]

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 :(

[Akira13]

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

[phibermon]

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.

[Chebmaster]

Uh, why are you still using FPC 2.6.4?
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.

[phibermon]

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.

[Chebmaster]

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:


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;

That wasn't hard. I already have one for 2.6.4:


{
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.S. Truly universal code compatible with both 2.6 and 3.0 branches goes like this:

{$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}

P.P.S. This is getting far off-topic. Dear mods, please feel free to snip this discussion off.

[phibermon]

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

[Akira13]

@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:


procedure TForm1.FormShow(Sender: TObject);
var
MyString: AnsiString;
begin
MyString := '¶' + '¿' + 'ÆÆÆ' + '®®®®®®' + '¢¢¢¢¢' + 'ȾȾȾȾȾȾȾȾ' + 'ɎɎɎɎɎɎɎɎ' + 'ΏΏΏΏΏΏΏΏΏ' + 'ϼϼϼϼϼ';
ShowMessage(MyString);
end;

Also, you do realize the people who maintain Debian are entirely unrelated to the developers of FPC/Lazarus, right?....

[SilverWarior]

@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?

Why do you think they would "go out of their way" in order to use Unicode characters in the file name? You do realize there are bunch of languages in the world that actually can't write without the use of Unicode characters or at least customized Charset?
So what seems for you to "go out of their way" in order to use Unicode characters it seems perfectly normal to them. In fact to them using only ANSI characters seems "to go our of their way" big time.

Also you need to realize that since newer versions of Windows support using Unicode characters in user names. This also means that any username based paths like "C:\Users\%Username%\..." could already contain Unicode characters in it so not having Unicode support in your application file handling means you have a large possibility that your application won't work on such system. Especially since based on windows guidelines most of the settings should be stored in one of the sub-folders of the above mentioned user folder.

[Akira13]

Why do you think they would "go out of their way" in order to use Unicode characters in the file name? You do realize there are bunch of languages in the world that actually can't write without the use of Unicode characters or at least customized Charset?
So what seems for you to "go out of their way" in order to use Unicode characters it seems perfectly normal to them. In fact to them using only ANSI characters seems "to go our of their way" big time.

Also you need to realize that since newer versions of Windows support using Unicode characters in user names. This also means that any username based paths like "C:\Users\%Username%\..." could already contain Unicode characters in it so not having Unicode support in your application file handling means you have a large possibility that your application won't work on such system. Especially since based on windows guidelines most of the settings should be stored in one of the sub-folders of the above mentioned user folder.

I'm very aware of all of that. I was really just questioning whether or not he realizes that things such as the code sample in my last post work perfectly as written in current FPC versions. Here's another sample explicitly declaring an "AnsiString" yet happily using Unicode characters:


procedure TForm1.FormShow(Sender: TObject);
var
AFileNameConsistingEntirelyOfUnicodeCharacters: AnsiString;
begin
AFileNameConsistingEntirelyOfUnicodeCharacters := '௵௵௵௵實實實電電電電參參參ݠݠݼݼݼݼݼਈਈਈ.txt';
if FileExists('C:\Test\' + AFileNameConsistingEntirelyOfUnicodeCharacters) = True then
ShowMessage('It exists!');
end;

If that file does indeed exist, the code will properly return true.

[Chebmaster]

how your filenames could possibly require unicode support.
Simple. Assume a Windows XP user who chose user name like "／人◕‿‿◕人＼". Windows creates his Application data folder with that string as part of the path. Non-Unicode applications fail.
I tested it and proved it.
Of course that user is an idiot noob, but still.


the following code compiles fine and displays correctly:
Do you realize your example is invalid because it uses Lazarus? Lazarus includes tons of hacks and custom RTL patching to make UTF-8 work on Windows as if it was default.
I write in pure FPC. The FPC RTL doesn't have the Lazarus hacks. If I try accessing TFileStream.Create('c:\Users\／人◕‿‿◕人＼\Application Data\chentrah\chentrah.ini', fmOpenRead); it will fail even with the file in place.
Fpc 3.x does have much better support for Unicode paths and only requires minor patching. sadly, it is not ready yet.



you do realize the people who maintain Debian are entirely unrelated to the developers of FPC/Lazarus
I do indeed. The Debian maintainers are much more thorough in their approach to stability and they deem fpc 3.x not ready. I agree with them.

[Akira13]

Do you realize your example is invalid because it uses Lazarus? Lazarus includes tons of hacks and custom RTL patching to make UTF-8 work on Windows as if it was default.
I write in pure FPC. The FPC RTL doesn't have the Lazarus hacks. If I try accessing TFileStream.Create('c:\Users\／人◕‿‿◕人＼\Application Data\chentrah\chentrah.ini', fmOpenRead); it will fail even with the file in place.
Fpc 3.x does have much better support for Unicode paths and only requires minor patching. sadly, it is not ready yet.


Uh, what are you talking about?


program Test;

uses
SysUtils;

var
AFileNameConsistingEntirelyOfUnicodeCharacters: AnsiString;
begin
AFileNameConsistingEntirelyOfUnicodeCharacters := '௵௵௵௵實實實電電電電參參參ݠݠݼݼݼݼݼਈਈਈ.txt';
if FileExists('C:\Test\' + AFileNameConsistingEntirelyOfUnicodeCharacters) = True then
WriteLn('It exists!');
end.

There's the command line version of my example, which I just compiled and ran without issues using the FPC binary directly. I'm also unsure as to how you think Lazarus could "hack" or "patch" the RTL at compile time, considering that you cannot build it without an entirely pre-built FPC to link against.



I do indeed. The Debian maintainers are much more thorough in their approach to stability and they deem fpc 3.x not ready. I agree with them.


lol. I think the vastly more realistic scenario is "the people who maintain Debian are Linux power-users who don't remotely care about anything to do with Pascal and may even look down on the language as something for simpletons, and have just forgotten to update it for a really long time." I'd imagine the only reason it was ever added as a standard Debian package in the first place was because like one specific guy who just happened to use it on Linux and was also a Debian maintainer took the time to do it himself.

FPC/Lazurus is far more stable than most of what's out there. I've used nothing but the trunk of both of them for several years and have almost never experienced a situation where one of them conflicted with the other. And any time there was an issue it was either something I could easily work around myself, or it was just fixed in the actual codebase within a day or so.

[Chebmaster]

There's the command line version of my example,
Does NOT work when I compile this using fpc 2.6.4 => non-unicode executable
While fpc 3.x was crashing last time I tried building my project using it => no executable at all

Which one would you prefer? One that works badly or one that does not work at all?
That is the difference between fpc 2.6.4 (lame but stable) and fpc 3.x (supposedly better but chokes on internal errors).

P.S. And fpc 3.0.2 IS STILL INCOMPLETE:
See this example:

{$codepage utf-8}
{$mode objfpc}
program Test;
uses
SysUtils, classes;

var
AFileNameConsistingEntirelyOfUnicodeCharacters: AnsiString;
s: TFileStream;
begin
AFileNameConsistingEntirelyOfUnicodeCharacters := '௵௵௵௵實實實電電電電參參參ݠݠݼݼݼݼݼਈਈਈ.txt';
if FileExists('d:\tmp\test\' + AFileNameConsistingEntirelyOfUnicodeCharacters) = True then
WriteLn('It exists!')
else WriteLn('false.');
try
s:= TFileStream.Create('d:\tmp\test\' + AFileNameConsistingEntirelyOfUnicodeCharacters, fmOpenRead);
s.Free;
except
WriteLn((ExceptObject as Exception).Message);
end;
readln;
end.

Now see it FAIL to open a stream:

It exists!
Unable to open file "d:\tmp\test\????????????????????????.txt"
That's it folks. The RTL may be Unicode now (FileExists & friends) but CLASSES ARE NOT!

P.S. That's why I have a hack in my engine to be used with FPC 3, containing modified versions of TFileStream, TIniFile and TStrings.
I hope it will not be needed someday.
But as it is, FPC 3 was rolled out prematurely. It should've stayed 2.9.x for a while longer.

P.P.S. I was planning to make a similar patch for fpc 2.6.4 with Unicode FileExists & friends, but I decided: why bother when fpc 3 would be there soon. Yeah. That 'soon' proved to be relative :D

[Ñuño Martínez]

I think this thread has degenerated a lot, hasn't it? ::)

[phibermon]

I think this thread has degenerated a lot, hasn't it? ::)


I hope you typed that in unicode

[Akira13]

I hope you typed that in unicode

Hahaha.

Honestly though, I'm still unsure why exactly Chebmaster has issues with that code even compiled under FPC 3.0+... maybe it's a Linux thing?

Wasn't trying to start a war... I'm just generally very skeptical anytime someone says "Yeah, I'm using [insanely old version of something], for [XYZ reason]."

XYZ reason is, 90% of the time, completely avoidable/preventable...

[Chebmaster]

maybe it's a Linux thing?
No, it's a Windows-only problem.

Long ago, when going unicode, Linux did the sensible thing by adopting utf-8. Microsoft though they know better, plus they had to uphold backward compatibility. Thus, all the *A/*W fuss and stuff. And this is the roor of Free Pascal's problems. While Linux making AnsiString encoding-aware was pretty enough, in Windows you have to switch all classes to using UnicodeString because that's what Windows uses natively.


90% of the time, completely avoidable/preventable...
This case falls into these pesky 10%.
Free Pascal's class library is *horribly* out of date with regards to Unicode file names on the Windows platform. If you develop a Windows application in pure FP, without using Lazarus-specific fixes, your application will be stomped by competition because it could fail where any sensible Windows applications have no problems since 15 years ago.
And while fpc 3 *did* fix the RTL, it *DID NOT* fix the classes. So good luck if you are using TStream *or* any third-party library that uses streams to read from files.
It's a glaring flaw that should have been addressed a decade ago.

P.S. So I have to use hacks in fpc 3 to make my application Unicode.
And I am *lucky* I don't have to deal with third-party libraries because they have no such hack...
Oh, wait, I do. I use Vampyre Imaging and I cannou use its functions of loading image from file. I have to load files into memory buffer myself then call vampyre function that loads images from memory. I'm lucky Vampyre *does* have such functions.


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;
...
constructor TFileStream.Create(const AFileName: UnicodeString; Mode: Word);
begin
Create(AFileName, Mode, 438);
end;


constructor TFileStream.Create(const AFileName: UnicodeString; Mode: Word; Rights: Cardinal);
var
h: THandle;
begin
FFileName:= AFileName;
If (Mode and fmCreate) > 0 then
h:= FileCreate(AFileName,Mode,Rights) // it IS already unicode in 3.0.0
else
h:= FileOpen(AFileName,Mode);

If (h = feInvalidHandle) then
If Mode = fmcreate then
Die(RuEn('Не удалось создать файл "%0"','Failed to create file "%0"'),[AFileName])
else
Die(RuEn('Не удалось открыть файл "%0"','Failed to open file "%0"'),[AFileName]);
inherited Create(h);
end;

destructor TFileStream.Destroy;
begin
FileClose(Handle);
end;


P.P.S. I'd call it "dick move" if didn't know the devs are mostly focused on Linux. This probably slipped their mind. And that Lazarus patch and everyone using it probably didn't help as it negated the problem somehow.
Still, this one great pitfall marginalizes Free Pascal by making it harder to write serious business applications for Windows.

P.P.P.S Worst case scenario: you write an application, going to great pains to make 100% sure it works. Like 90% people out there you are unaware that fpc is not unicode.
Finally it's time to show it to your boss. You launch it on his machine... Which coincidentally has user name like "фañ"... And your application flops with a weird error. Why? What? You lost your face.
You try fixing the problem ASAP pulling all-nighter to be ready try the next day, but... The problem is not easily fixable, you miss some instances of non-unicodeness in your tired state. Your application flops again in the face of your boss.
"What it is written in?" he asks. "Free Pascal...? Forget that crap and learn proper coding tools. You're fired."

[Ñuño Martínez]

I think this thread has degenerated a lot, hasn't it? ::)I hope you typed that in unicode
I know this is a sort of joke, but I don't get it. ???

[phibermon]

I know this is a sort of joke, but I don't get it. ???

You were being mature, trying to get back onto topic and in recognition of that I was being ironically petty :)

This isn't over! delegation is the answer. Me and Silver are both planning our tutorials so I think a small tutorial framework in a similar vein as the NeHe OpenGL tutorials would be a nice place to start devising ways to collaborate.

[Ñuño Martínez]

You were being mature, trying to get back onto topic and in recognition of that I was being ironically petty :)

This isn't over! delegation is the answer. Me and Silver are both planning our tutorials so I think a small tutorial framework in a similar vein as the NeHe OpenGL tutorials would be a nice place to start devising ways to collaborate.
I'm always planning a tutorial of Allegro.pas but never did it. I started one at FreePascal's Wiki (http://wiki.freepascal.org/Allegro.pas_tutorial_0) but it is incomplete and useless. I plan to make a beta release soon (Yay!) so may be I should do it.

[phibermon]

Sorry for the late reply - yes definitely finish your tutorial :)

Some ideas for tutorials on this site are being thrown back and forth at the moment - I've got tutorials I've been working on and I know silver has been putting a lot of thought into things as well - if a suitable way to present and post such things emerges? then maybe put it on here too or write more :)