Jump to content

Pixma

Community Newbie
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

4 Neutral

About Pixma

  • Rank
    Tiro
  • Birthday 08/03/1992

Previous Fields

  • First Name
    Dennis

Profile Information

  • Gender
    Male
  • Location
    Germany
  1. hmm ok, what do you think about the following idea? I create a folder samples inside the graphics project. There is a main function from where I can call the samples which I am creating. For example creating a Triangle, creating a triangle with shader, creating a mesh, ans so on. Finally with these main function, I make the graphics project as Startup Project. edit: hmm, I have noticed now, that this is not possible, because this is a library project. edit 2: ok, now I have another idea, to create this in the pyrogenesis project. So I append this project for command argument --sample in Debugging. And in the main function then I check for this argument.
  2. hi, I have a problem with creating a project for my Graphic Wrapper implementation? I created some Vulkan cpp/h files and adapter files. Now I want to create a Solution/Project where I can test these Vulkan functionality. To test the Vulkan Functionality, I want to create some triangles and polygons. I saw this is done with premake. But I dont't know how I can create an additional Project file in this solution for testing. greeting Pixma
  3. @stanislas69 Thanks @wraitii yes, i think Support for OpenGl is important. I don't know any library which can do this. But I think with the adapter pattern we could implement a low-level renderer. Furthermore we can think of using define statements or variables to switch the Graphi api. The variant with the variable, we could create an entry in an configuration file. The disadvantage of using variables is that all api libraries are needed to built. The idea of implementing an adapter pattern with #ifdef and #elif is shown in my first thread. This could be an example of an adapter pattern with variables: #include <iostream> using namespace std; enum RenderAPI {GL, VULKAN, METAL}; // Configuration File ////////////////////////////////// int renderApi = GL; // Cpp and H File ////////////////////////////////// // Renderer Interface class IRenderer { public: //bool init(); virtual void draw() = 0; }; // Opengl Renderer class GlRenderer : public IRenderer { public: void draw() { cout << "GlRenderer draw method called!" << endl; } }; // Vulkan Renderer class VulkanRenderer : public IRenderer { public: void draw() { cout << "VulkanRenderer draw method called!" << endl; } }; int main() { if (renderApi == GL) { IRenderer *rend = new GlRenderer(); rend->draw(); } else if (renderApi == VULKAN) { IRenderer *rend = new VulkanRenderer(); rend->draw(); } return 0; } Finally, I can research for an GPL library that could allow us this type of implementation.
  4. Hello all together, on february, I will finish my bachelor thesis. Then I want to contribute development content for 0 A.D. I am thinking about to expand the render engine with Vulkan Support. I read in Preparation a lot of threads, like https://wildfiregames.com/forum/index.php?/topic/21256-vulkan-api/&tab=comments#comment-320810 and https://wildfiregames.com/forum/index.php?/topic/24694-0-ad-the-next-steps/&tab=comments#comment-359754. I read out the following requirements: 0 A.D. shall support older hardware, too Vulkan should be GPL Compatible -> I have no idea about this Finally I thought about implementing the functionality as a wrapper (adapter pattern) In addition, I analyzed which classes uses OpenGL Code, which I have attached as a Pdf file. On the basis of the analysis, I found out that a lot of Opengl Code is used in other Solutions like atlas, lowlevel, GUI and so on. Often are these render or draw methods like: GuiRenderer::Draw CminiMap::Draw AtlasViewGame::Render and so on What do you think about encapsulte API Functions in the Graphics Solution? So for example AtlasViewGame::Render calls an render function of the Graphics Solution. Here is an example, how a adapter pattern of the Renderer Component can look like: #include <iostream> using namespace std; // use GL or Vulkan #define _USEGL 1 // Renderer Interface class IRenderer { public: //bool init(); virtual void draw() = 0; }; #ifdef _USEGL // Opengl Renderer class GlRenderer : public IRenderer { public: void draw() { cout << "GlRenderer draw method called!" << endl; } }; #elif _USEVULKAN // Vulkan Renderer class VulkanRenderer : public IRenderer { public: void draw() { cout << "VulkanRenderer draw method called!" << endl; } }; #endif int main() { #ifdef _USEGL IRenderer *rend = new GlRenderer(); rend->draw(); #elif _USEVULKAN IRenderer *rend = new VulkanRenderer(); rend->draw(); #endif return 0; } What do you think about my plan? Do you have any suggestions? Best regards Pixma VulkanImplConcept.pdf
×