What graphics engine could achieve this ? lazarus / 39-Graphics ---------------------------------------------------------------------- Zath · 2017-06-28 16:16 Hello. I have played a game for years and there's a core of fools that still do ! It was originally written with Delphi back in the day. It uses DirectX and thousands of bmp tiles to create the effect. I wanted to try and create the same with Lazarus but with one of the newer OpenGL type engines. This is my own vid. Basically it shows a player composed of multiple bmps being looped like a flick book. Everything you see is a bmp image/images. Any views ? https://youtu.be/pUSaWeNJ334 ---------------------------------------------------------------------- Handoko · 2017-06-28 16:39 Here is a list of graphics/game engines and libraries: http://wiki.freepascal.org/Game_Engine Castle Game Engine is actively developed and the author is nice and very helpful. GLScene is very powerful too, unfortunately it has texturing bug when running on Linux. SDL is much simple to start with, I saw a newbie - he managed to create a very simple 2D game just in weeks learning it. SDL is capable for 3D too. I ever learned Allegro, although I do not use it, but I should mention it is easy to learn and has 3D feature too. ZenGL is promising, unfortunately the development has stopped since some years ago. All the mentioned names above should able to achieve the similar effects. ---------------------------------------------------------------------- Zath · 2017-06-28 16:46 Thanks as always Handoko  I was looking at the allegro.pas earlier. Seems very interesting. Would it be a case of using multiple tiles like in the video or would the base/main picture be one large image ? ---------------------------------------------------------------------- Handoko · 2017-06-28 17:07 Not really understood what you said. Quote from: Zath on June 28, 2017, 06:16:38 pmBasically it shows a player composed of multiple bmps being looped like a flick book. You're right, is not a real 3D. it just a 2D composed by multiple pre- rendered 3D images. Allegro is capable to do that, if you know how. For example, I ever tried to make walking character using Allegro.pas: http://forum.lazarus.freepascal.org/index.php/topic,35313.msg236058.ht ml#msg236058 Quote from: Zath on June 28, 2017, 06:46:02 pmWould it be a case of using multiple tiles like in the video or would the base/main picture be one large image ? Did you mean using tiles to build a game world? Usually you need to use level/tile editor like DeleD or Tiled Map Editor. ---------------------------------------------------------------------- Zath · 2017-06-28 20:10 Quote from: Handoko on June 28, 2017, 07:07:16 pmNot really understood what you said. Quote from: Zath on June 28, 2017, 06:16:38 pmBasically it shows a player composed of multiple bmps being looped like a flick book. You're right, is not a real 3D. it just a 2D composed by multiple pre- rendered 3D images. Allegro is capable to do that, if you know how. For example, I ever tried to make walking character using Allegro.pas: http://forum.lazarus.freepascal.org/index.php/topic,35313.msg236058.ht ml#msg236058 Quote from: Zath on June 28, 2017, 06:46:02 pmWould it be a case of using multiple tiles like in the video or would the base/main picture be one large image ? Did you mean using tiles to build a game world? Usually you need to use level/tile editor like DeleD or Tiled Map Editor. This is exactly what I am looking for. Brilliant piece of animation. https://postimg.org/image/80qim95ml/ ---------------------------------------------------------------------- User137 · 2017-06-29 02:51 There is a small demo like that for nxPascal, here you see the character in 3 frame texture https://github.com/Zaflis/nxpascal/blob/master/demos/fpc/walker/textur es/walker.png Rest of the source code is right there when browsing the folders. You will always want to have as few pictures as possible for faster drawing speed. Here is another example of sprite sheet: https://s3-us- west-2.amazonaws.com/s.cdpn.io/59506/spritesheet_grant.png Actually i would say any and all graphics engines are capable of doing it. ---------------------------------------------------------------------- Eugene Loza · 2017-06-29 05:21 Yes, you can create such stuff in Castle Game Engine (see example: https://github.com/castle-engine/castle- engine/tree/master/examples/isometric_game) However, you might find FLARE more suitable to your needs. Thou it's not Pascal. ---------------------------------------------------------------------- Handoko · 2017-06-29 08:32 Most game/graphics engines today are capable to show animated character. Some have it as a ready-to-use feature. While the others, you have to manually program the animation. I created the walking animation using Allegro.pas. Still not finished. I will submit that simple demo how to create a game using Allegro.pas to Graphics Contest 2017. There I will include a detailed step-by-step tutorial. I still have 1 month or more right? I am busy at the moment, but I am sure I can finish it before the deadline. Flare is an interesting project. They have professional artists and programmers, and it is open source. But it seems the development has been slowed down or maybe stopped. nxPascal is good too, it caught my attention some years ago unfortunately I could not find tutorial about it. ---------------------------------------------------------------------- Zath · 2017-06-29 09:23 Where did you get the graphics for the walking knight Handoko ? Did you create them from scratch yourself or are they from a resource ? ---------------------------------------------------------------------- Handoko · 2017-06-29 09:25 Here: http://www.reinerstilesets.de/2d-grafiken/2d-humans/ I checked the license, they are free as long as we do not use it to compete the the author. ---------------------------------------------------------------------- Zath · 2017-06-29 09:33 Quote from: Handoko on June 29, 2017, 11:25:44 amHere: http://www.reinerstilesets.de/2d-grafiken/2d-humans/ I checked the license, they are free as long as we do not use it to compete the the author. Thank you very much indeed. ---------------------------------------------------------------------- Paul_ · 2017-06-29 17:49 What I remember, this guy was making similar isometric game in ZenGL: https://www.youtube.com/channel/UCdVJHaO60aoxd-PNizuFE-A ---------------------------------------------------------------------- Handoko · 2017-06-29 18:27 ZenGL was one of the thing in my have to learn list. But some years ago I learned from their forum, the development of ZenGL will be stopped. The author said, he is a perfectionist, Pascal was slow he had to play around with C-code for speed, which is boring, FPC and Lazarus was not as good as he want, Delphi was expensive, Pascal community was almost dead. Sad ---------------------------------------------------------------------- Paul_ · 2017-06-29 19:10 Also keeping multiplatform code was big problem. Anyway, ZenGL code and structure is great source for learning. Without OOP, clear structure. Only gameloop itself is confusing and there are some "hacks". ---------------------------------------------------------------------- turrican · 2017-06-30 08:38 Quote from: PaulG on June 29, 2017, 09:10:28 pmAlso keeping multiplatform code was big problem. Anyway, ZenGL code and structure is great source for learning. Without OOP, clear structure. Only gameloop itself is confusing and there are some "hacks". ZenGL is the best framework to do 2D and MultiArch-MultiOS. The project needs a maintenaince but at this time works ok. I have a framework to simplify and abstract ZenGL called SimpleZenGL . Features are OOP, Scenes, SpriteBatches, Collisions, Events, Input and Sound. ---------------------------------------------------------------------- turrican · 2017-06-30 08:45 Quote from: Handoko on June 29, 2017, 08:27:15 pmZenGL was one of the thing in my have to learn list. But some years ago I learned from their forum, the development of ZenGL will be stopped. The author said, he is a perfectionist, Pascal was slow he had to play around with C-code for speed, which is boring, FPC and Lazarus was not as good as he want, Delphi was expensive, Pascal community was almost dead. Sad Andru, ZenGL author is a great developer. But his words aren't justificated... He lost the interest for this project (dot). W ith Pascal you can do almost everything you can do in C, C++ with a 5% to 20% of speed lose. For 2D games with OpenGL or DX Pascal is more than suficient. People are developing using python. Is python faster than pascal???? NOT. ---------------------------------------------------------------------- Handoko · 2017-06-30 09:19 Quote from: turrican on June 30, 2017, 10:38:39 amI have a framework to simplify and abstract ZenGL called SimpleZenGL . Features are OOP, Scenes, SpriteBatches, Collisions, Events, Input and Sound. I can't find SimpleZenGL on the web. May you share it? Quote from: turrican on June 30, 2017, 10:45:49 amAndru, ZenGL author is a great developer. But his words aren't justificated... He lost the interest for this project (dot). W ith Pascal you can do almost everything you can do in C, C++ with a 5% to 20% of speed lose. For 2D games with OpenGL or DX Pascal is more than suficient. He said that in 2013. Perhaps at that moment, it was the bad time for Pascal. Now, Lazarus and Free Pascal has improved a lot, the community is strong. Delphi Berlin Starter is offered for free with limited commercial usage. Things are better now. BASIC was my first programming language. Soon I found it was too slow. So I spent some time learning Assembly using debug.com. I am glad I found Pascal, it is a good balance between power and performance. ---------------------------------------------------------------------- turrican · 2017-06-30 09:36 QuoteI can't find SimpleZenGL on the web. May you share it? Sorry, I need to upload to GitHub to share it with a working example. This afternoon I will do it. As you said I also started with my old Amstrad CPC 6128 BASIC when I was 6 years old I'm not a fanboy but I found on Pascal most equilibrated programming language for all platforms. I could do everything I need. Easy to learn, hard to master. ---------------------------------------------------------------------- Akira1364 · 2017-07-02 03:30 You could pull off this Diablo clone in a whole lot of different frameworks! If you want specifics, personally I'd recommend the Castle Game Engine as it is actively developed and uses modern functionality. Definitely don't use ZenGL. ---------------------------------------------------------------------- Zath · 2017-07-02 11:54 Quote from: Akira1364 on July 02, 2017, 05:30:31 amYou could pull off this Diablo clone in a whole lot of different frameworks! If you want specifics, personally I'd recommend the Castle Game Engine as it is actively developed and uses modern functionality. Definitely don't use ZenGL. It first came out in 2000/2001 so maybe predates diablo. I did look at the Castle engine but I tend to give up easily if something doesn't work right like an install fail or something else. Thanks for all the input. ---------------------------------------------------------------------- Handoko · 2017-07-02 14:30 My first install of Castle Game Engine was failed too. After weeks later, I managed to install it on my second attempt and the demos run correctly. But because I was busy, I didn't have time to learn more about it. Quote from: Akira1364 on July 02, 2017, 05:30:31 am... Definitely don't use ZenGL. I haven't try it but I already heard a lot of praise about ZenGL. I am open to hear from different point of views, can you please explain more why you do not recommend ZenGL? ---------------------------------------------------------------------- Akira1364 · 2017-07-02 16:27 Quote from: Zath on July 02, 2017, 01:54:13 pmIt first came out in 2000/2001 so maybe predates diablo. The original Diablo came out in 1996. Quote from: Handoko on July 02, 2017, 04:30:45 pmI haven't try it but I already heard a lot of praise about ZenGL. I am open to hear from different point of views, can you please explain more why you do not recommend ZenGL? It's not a bad engine by any means and there have certainly been good games made with it. However, it's an abandoned project (meaning it obviously won't be improved or receive any bug fixes in the future) and it's also built around outdated GL functionality which leaves it with something of a "ceiling" performance-wise. Lastly the overall design of the engine is largely procedural and doesn't fit in particularly well with object-oriented projects. ---------------------------------------------------------------------- Paul_ · 2017-07-02 20:07 Quote from: Akira1364 on July 02, 2017, 06:27:13 pmit's also built around outdated GL functionality which leaves it with something of a "ceiling" performance-wise. Lastly the overall design of the engine is largely procedural and doesn't fit in particularly well with object- oriented projects. What is this new functionality or approach in OpenGL? And because you're talking about performance I also checked Castle engine demos related to 2D graphics 1) PC with AMD RX 480 isometric_game - 180/180 FPS (even with 180 FPS scrolling isn't smooth) 2d_dragon_spine_game - 900/400 FPS  (when I add 100 trees into scene, FPS drop to 100) tiled - 120/120 FPS 2) Old PC, Atom + ATI 6450 isometric_game - 30 FPS 2d_dragon_spine_game - 120 FPS Well, scenes are absolutely not complicated and such 2D rendering performance is really hardly usable.. ZenGL tests: 1) PC with AMD RX 480 Demo 08 sprite engine - 60000 animated sprites ~60 FPS 2) Old PC Demo 08 sprite engine - 2000 animated sprites ~60 FPS Compiled in FPC (-O3). Everyone likes a different style. Anyway how we can see this ZenGL procedural approach in framework is "super" efficient and it is very clear. (There is also ZenGL OOP wrapper MondoZenGL.) Because ZenGL is dead it isn't best choice. For smaller project why not. For something bigger are fine frameworks like SDL2 or SFML. ---------------------------------------------------------------------- kagamma · 2017-07-02 20:31 The reason castle game engine (CGE) has worse performance compare to ZenGL in your test is because it doesnt do any batching under the hood (it was never easy to do batching on 3D engines when a model is always construct from differents parts with different materials, unlike simple 2D sprites, and yes Spine is treated as 3D object in CGE). In order to achieve good performance in CGE you need to implement your own batching and CGE provides necessary tools to help you with the task. Or, wait for Michalis or any contributor to implement proper batching as it is one of the planned features in roadmap. Another reason is CGE is a full-blown game engine with scene manager, AI and many fancy stuff on top of it, unlike ZenGL which is just a simple wrapper around OpenGL. ---------------------------------------------------------------------- Akira1364 · 2017-07-02 22:17 Quote from: PaulG on July 02, 2017, 10:07:48 pmWhat is this new functionality or approach in OpenGL? The most basic approach would be roughly something like the following: First, you'd need to define some kind of interleaved OpenGL data structure, such as what's shown below. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i   TTexCoord = record    U, V: Single;  end;   TFloatColor = record    R, G, B: Single;  end;   TVertex = record    X, Y, Z: Single;  end;   TSpriteVertex = record    T2F: TTexCoord;    C3F: TFloatColor;    V3F: TVertex;  end;   TSpriteTriangle = record    V1, V2, V3: TSpriteVertex;  end;   TSpriteQuad = record    Tri1, Tri2: TSpriteTriangle;  end;   TSpriteQuadArray = array of TSpriteQuad; Then, you would need to define some kind of sprite manager class (or even advanced record) that had its own TSpriteQuadArray as well as a separate array of actual individual sprites (which would each have their own TSpriteQuad, as well as texture ID). Before drawing you'd sort the array of actual sprites by texture ID from low to high, call glBindTexture on the first one, and then loop over the array copying each sprites TSpriteQuad sequentially into the managers TSpriteQuadArray, until the texture ID of the current sprite was different from the previous one. At that point, you'd bind your vertex buffer and use something along the lines of glBufferSubData to upload the data from the TSpriteQuadArray into it, and then set up your "vertex attribute pointers" so that the stride matches your previously defined interleaved data structure. Then you'd call glDrawArrays (in GL_TRIANGLES mode of course), clear the managers TSpriteQuadArray, bind the new texture ID, and return to your initial loop at the index you left off until you hit a different texture ID again. Doing things that way you'd be looking at enormous framerate increases over how ZenGL currently does things, both because you'd be making drastically fewer OpenGL function calls (we're talking hundreds/thousands VS. tens of millions here) and also because all of the data OpenGL needs would be getting uploaded to the GPU in a single array ahead of time, instead of vertex-by-vertex in an endless series of glVertex3Fs and glTexCoord2Fs. As far as your benchmarks, you are certainly comparing apples to oranges. The ZenGL demo is an utterly simplistic "true 2D" loop that just renders the same six textures in a row (thereby "animating" them) over and over again while adjusting their position every so often based on input from a timer. There are no matrix transformations, world space computations, or "game logic" of any kind going on. The Castle Dragon demo on the other hand is loading fully articulated spine models from JSON files and computing the transformations of each joint in real time, while also dealing with 3D matrix computations (since nothing in Castle is ever actually 2D, as demonstrated by the 3D camera mode you can switch to in that demo) as well as rendering the on-screen menu buttons. Most of the same things apply to the isometric demo, other than the use of "rigged" spine models. ---------------------------------------------------------------------- Paul_ · 2017-07-02 23:29 This kind of sprite batching is in LibGDX I think. So you recommend 3D engine for 2D Diablo-like game, when you know that is slow, because there are no 2D sprite routines? And it is unnecessary to notify ZenGL performance in that case, because this "outdated" rendering is maybe 1000x faster.. He only needs simple gameloop, texture manager, timers, fast rendering etc. So everything what ZenGL have. ---------------------------------------------------------------------- Akira1364 · 2017-07-03 00:07 Quote from: PaulG on July 03, 2017, 01:29:53 amThis kind of sprite batching is in LibGDX I think. So you recommend 3D engine for 2D Diablo-like game, when you know that is slow, because there are no 2D sprite routines? And it is unnecessary to notify ZenGL performance in that case, because this "outdated" rendering is maybe 1000x faster.. He only needs simple gameloop, texture manager, timers, fast rendering etc. So everything what ZenGL have. You're being remarkably disingenuous. Notwithstanding what I already pointed out about the flawed comparisons you made, even if they were actually accurate they still wouldn't be 1000x faster or anywhere close. The only reason you were locked at 60FPS is because ZenGL turns on VSync by default when the window is initialized. If you turned on VSync with any Castle demo you'd be locked at 60FPS in the same way. (And again, you were getting more than 60FPS across the board to begin with in the Castle demos, so I'm not entirely sure what your actual complaint even was.) Secondly, he needs a lot more than a "simple gameloop, texture manager, timers, and fast rendering" to do that sort of game. Action RPGs aren't Flappy Bird. The actual graphics backend is only a very small piece of the puzzle, which is why I recommended Castle which can in fact do the rendering just fine while also providing all of the necessary functionality that he'd need for the actual gameplay. ---------------------------------------------------------------------- kagamma · 2017-07-03 01:02 Since some people doubt about Castle Game Engine's performance I decided to make simple tests with the engine (with my own batching method of course ) Specs: Intel core i7 6700HQ 2.6Ghz, 8GB RAM, Intel HD Graphics 530. Compiler: FPC 3.0.2. Target: Win32 with -O3 optimization. 1: demo_tilemap - This test will try to load a huge, ugly tilemap with 2048x2048 tiles, 2 layers, each tile has a size 32x32 pixels. - The program will try to load all resources before render so it will take some time and eat a lot of memory (~1.4GB RAM on my PC). Once the load completed, it will make use of CGE's scene manager to remove all tiles outside viewport from the drawing pipeline. - Use arrow keys to scroll the map. - Result: ~1500 FPS. 2. demo_sprite - This test is basically a crude port of ZenGL's demo 08, with my own implementation of simple sprite batching. - Result: ~60FPS with around 30000 sprites on screen (in comparison, ZenGL renders around 23000 sprites on my PC before drop down to < 60FPS). - Edit: The reason for ZenGL's poor performance compare to CGE, despite all the "bloat" CGE has, is because ZenGL still use OpenGL immediate mode for rendering i.e. by calling hundred thousands of glVertexXX/glTexCoordXX/glColorXX commands per frame. This cause a huge performance impact on the test. - Edit2: In another run on another PC with a nVidia GTX950 graphics card, both programs have almost the same result, so I guess driver/graphics card quality also play an important part in here. Link: https://mega.nz/#!hIRWBKxT!VBIFZNbYWaoYaW1tJQ5pnytwQlgU379EcW2S4DPXb5U ---------------------------------------------------------------------- Paul_ · 2017-07-03 08:58 Quote from: Akira1364 on July 03, 2017, 02:07:22 amNotwithstanding what I already pointed out about the flawed comparisons you made.. I did not test it with VSync, just added objects until game hits 60 FPS. Also there is no default 60 FPS rendering lock in ZenGL. Anyway kagamma's tests looks much better ---------------------------------------------------------------------- turrican · 2017-07-03 12:34 Quote from: kagamma on July 03, 2017, 03:02:39 amSince some people doubt about Castle Game Engine's performance I decided to make simple tests with the engine (with my own batching method of course ) Specs: Intel core i7 6700HQ 2.6Ghz, 8GB RAM, Intel HD Graphics 530. Compiler: FPC 3.0.2. Target: Win32 with -O3 optimization. 1: demo_tilemap - This test will try to load a huge, ugly tilemap with 2048x2048 tiles, 2 layers, each tile has a size 32x32 pixels. - The program will try to load all resources before render so it will take some time and eat a lot of memory (~1.4GB RAM on my PC). Once the load completed, it will make use of CGE's scene manager to remove all tiles outside viewport from the drawing pipeline. - Use arrow keys to scroll the map. - Result: ~1500 FPS. 2. demo_sprite - This test is basically a crude port of ZenGL's demo 08, with my own implementation of simple sprite batching. - Result: ~60FPS with around 30000 sprites on screen (in comparison, ZenGL renders around 23000 sprites on my PC before drop down to < 60FPS). Edit: The reason for ZenGL's poor performance compare to CGE, despite all the "bloat" CGE has, is because ZenGL still use OpenGL immediate mode for rendering i.e. by calling hundred thousands of glVertexXX/glTexCoordXX/glColorXX commands per frame. This cause a huge performance impact on the test. Edit2: In another run on another PC with a nVidia GTX950 graphics card, both programs have almost the same result, so I guess driver/graphics card quality also play an important part in here. Link: https://mega.nz/#!oVBzSYLb!N4JMO25nMrZzAsyxTFvF1Gy6E1LiQwasIvIFrZeZd6E Nice tests... I'm going to check this framework before I move to SDL2. ---------------------------------------------------------------------- Akira1364 · 2017-07-09 22:10 Quote from: kagamma on July 03, 2017, 03:02:39 am- Edit: The reason for ZenGL's poor performance compare to CGE, despite all the "bloat" CGE has, is because ZenGL still use OpenGL immediate mode for rendering i.e. by calling hundred thousands of glVertexXX/glTexCoordXX/glColorXX commands per frame. This cause a huge performance impact on the test. That's exactly what I've been trying to point out the whole time! Nice demos, also. ---------------------------------------------------------------------- turrican · 2017-07-12 13:45 Quote from: Handoko on June 30, 2017, 11:19:11 amQuote from: turrican on June 30, 2017, 10:38:39 amI have a framework to simplify and abstract ZenGL called SimpleZenGL . Features are OOP, Scenes, SpriteBatches, Collisions, Events, Input and Sound. I can't find SimpleZenGL on the web. May you share it? Quote from: turrican on June 30, 2017, 10:45:49 amAndru, ZenGL author is a great developer. But his words aren't justificated... He lost the interest for this project (dot). W ith Pascal you can do almost everything you can do in C, C++ with a 5% to 20% of speed lose. For 2D games with OpenGL or DX Pascal is more than suficient. Here is Hadoko https://github.com/turric4n/SimpleZGL He said that in 2013. Perhaps at that moment, it was the bad time for Pascal. Now, Lazarus and Free Pascal has improved a lot, the community is strong. Delphi Berlin Starter is offered for free with limited commercial usage. Things are better now. BASIC was my first programming language. Soon I found it was too slow. So I spent some time learning Assembly using debug.com. I am glad I found Pascal, it is a good balance between power and performance. ---------------------------------------------------------------------- michalis · 2017-07-14 01:10 Hi everyone, As for automatic batching in Castle Game Engine: Indeed, it is just not yet implemented (yet). It's on the Castle Game Engine roadmap In the meantime, you can indeed do it yourself, with a bit of code. Typically it means you will put multiple geometries inside a single IndexedFaceSet X3D node, instead of creating many IndexedFaceSet X3D nodes. Demo from Kagamma nicely shows this technique, using TCastleSpriteBatchScene in demo_sprite. P.S. Various optimization hints for CGE are mentioned in our manual BTW, @Kagamma, I would happily take your demo_sprite code and add it to the CGE examples directory. It's a very nice example. Are you OK with this? It would mean placing the code under https://castle- engine.sourceforge.io/license.php . (I'm not sure about the license of miku.png image, but if needed replacing it with something else is easy.) ---------------------------------------------------------------------- ykot · 2017-07-14 02:12 Platform eXtended Library supports automatic sprite batching.