Page 11 of 12 FirstFirst ... 9101112 LastLast
Results 101 to 110 of 119

Thread: So whatever happened to the whole PGDCE thing?

  1. #101
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    509
    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)
    Last edited by phibermon; 17-06-2017 at 02:34 AM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

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

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

  3. #103
    PGD Community Manager AthenaOfDelphi's Avatar
    Join Date
    Dec 2004
    Location
    South Wales, UK
    Posts
    1,171
    Blog Entries
    2
    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.
    :: AthenaOfDelphi :: My Blog :: My Software ::

  4. #104
    Quote Originally Posted by laggyluk View Post
    I think this can take longer, new gfx cards would still have to backwards compatible I suppose. First time hearing about this btw
    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.

    Quote Originally Posted by laggyluk View Post
    Soft body physics introduce some unique possibilities (Spintires as example) but then I dont know first thing about it
    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.

    Quote Originally Posted by laggyluk View Post
    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.

  5. #105
    Quote Originally Posted by laggyluk View Post
    Anyone has other ideas how this engine could stand out?
    Use Pascal Script as scripting languaje.
    No signature provided yet.

  6. #106
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    509
    Quote Originally Posted by Ñuño Martínez View Post
    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.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  7. #107
    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...

  8. #108
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    509
    Quote Originally Posted by Akira13 View Post
    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
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  9. #109
    Quote Originally Posted by phibermon View Post
    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

  10. #110
    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 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 and the PICO-8 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 - 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.

Page 11 of 12 FirstFirst ... 9101112 LastLast

Bookmarks

Posting Permissions

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