Page 4 of 14 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 133

Thread: So whatever happened to the whole PGDCE thing?

  1. #31
    Quote Originally Posted by phibermon View Post
    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):

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


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

    Quote Originally Posted by phibermon View Post
    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.
    Last edited by SilverWarior; 18-03-2017 at 02:44 AM.

  2. #32
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    Quote Originally Posted by SilverWarior View Post
    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):

    1. Terraria at 20th place: http://steamcharts.com/app/105600
    2. Stardew Valley at 29th place: http://steamcharts.com/app/413150
    3. RimWorld at 50th place: http://steamcharts.com/app/294100
    4. Factorio at 54th place: http://steamcharts.com/app/427520
    5. Oxygen Not Included at 67th place: http://steamcharts.com/app/457140
    6. 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.
    Last edited by phibermon; 18-03-2017 at 05:19 AM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

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

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

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

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

  4. #34
    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:
    Quote Originally Posted by SilverWarior View Post
    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.
    Last edited by Akira13; 19-03-2017 at 12:37 AM.

  5. #35
    PGDCE Developer Carver413's Avatar
    Join Date
    Jun 2010
    Location
    Spokane,WA,Usa
    Posts
    206
    Quote Originally Posted by Akira13 View Post
    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.

  6. #36
    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.

  7. #37
    PGDCE Developer Carver413's Avatar
    Join Date
    Jun 2010
    Location
    Spokane,WA,Usa
    Posts
    206
    Quote Originally Posted by Akira13 View Post
    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.

  8. #38
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    Quote Originally Posted by SilverWarior View Post
    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.


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

    Quote Originally Posted by SilverWarior View Post
    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?

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


    Quote Originally Posted by SilverWarior View Post
    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.
    Last edited by phibermon; 19-03-2017 at 06:26 PM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

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

  10. #40
    PGDCE Developer Carver413's Avatar
    Join Date
    Jun 2010
    Location
    Spokane,WA,Usa
    Posts
    206
    Quote Originally Posted by Akira13 View Post
    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.

Page 4 of 14 FirstFirst ... 23456 ... 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
  •