If this is your first visit, be sure to check out the FAQ by clicking the link above. You have to register before you can post.

If you have recently signed up, please make sure you log in so that your activity is registered. This is required for automatic promotions to work and to ensure your account is not deleted during the registration process.

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.

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!

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!

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!

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.

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.

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.

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

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