• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By fleissi
      Hey guys!

      I'm new here and I recently started developing my own rendering engine. It's open source, based on OpenGL/DirectX and C++.
      The full source code is hosted on github:
      https://github.com/fleissna/flyEngine

      I would appreciate if people with experience in game development / engine desgin could take a look at my source code. I'm looking for honest, constructive criticism on how to improve the engine.
      I'm currently writing my master's thesis in computer science and in the recent year I've gone through all the basics about graphics programming, learned DirectX and OpenGL, read some articles on Nvidia GPU Gems, read books and integrated some of this stuff step by step into the engine.

      I know about the basics, but I feel like there is some missing link that I didn't get yet to merge all those little pieces together.

      Features I have so far:
      - Dynamic shader generation based on material properties
      - Dynamic sorting of meshes to be renderd based on shader and material
      - Rendering large amounts of static meshes
      - Hierarchical culling (detail + view frustum)
      - Limited support for dynamic (i.e. moving) meshes
      - Normal, Parallax and Relief Mapping implementations
      - Wind animations based on vertex displacement
      - A very basic integration of the Bullet physics engine
      - Procedural Grass generation
      - Some post processing effects (Depth of Field, Light Volumes, Screen Space Reflections, God Rays)
      - Caching mechanisms for textures, shaders, materials and meshes

      Features I would like to have:
      - Global illumination methods
      - Scalable physics
      - Occlusion culling
      - A nice procedural terrain generator
      - Scripting
      - Level Editing
      - Sound system
      - Optimization techniques

      Books I have so far:
      - Real-Time Rendering Third Edition
      - 3D Game Programming with DirectX 11
      - Vulkan Cookbook (not started yet)

      I hope you guys can take a look at my source code and if you're really motivated, feel free to contribute :-)
      There are some videos on youtube that demonstrate some of the features:
      Procedural grass on the GPU
      Procedural Terrain Engine
      Quadtree detail and view frustum culling

      The long term goal is to turn this into a commercial game engine. I'm aware that this is a very ambitious goal, but I'm sure it's possible if you work hard for it.

      Bye,

      Phil
    • By deadless games
      i'm am looking for volunteers with little or no experience to help with music and graphic design.
      i was thinking of making a platformer game by myself to get into programming but struggled to make music and do Character design
      you PC doesn't need to be amazing,need to be willing to spend time doing your role,
      if you are interested please contact me with one of the means below.
      email deadlessgames@gmail.com
      discord xwolf572#6974
       
    • By tj8146
      I have attached my project in a .zip file if you wish to run it for yourself.
      I am making a simple 2d top-down game and I am trying to run my code to see if my window creation is working and to see if my timer is also working with it. Every time I run it though I get errors. And when I fix those errors, more come, then the same errors keep appearing. I end up just going round in circles.  Is there anyone who could help with this? 
       
      Errors when I build my code:
      1>Renderer.cpp 1>c:\users\documents\opengl\game\game\renderer.h(15): error C2039: 'string': is not a member of 'std' 1>c:\program files (x86)\windows kits\10\include\10.0.16299.0\ucrt\stddef.h(18): note: see declaration of 'std' 1>c:\users\documents\opengl\game\game\renderer.h(15): error C2061: syntax error: identifier 'string' 1>c:\users\documents\opengl\game\game\renderer.cpp(28): error C2511: 'bool Game::Rendering::initialize(int,int,bool,std::string)': overloaded member function not found in 'Game::Rendering' 1>c:\users\documents\opengl\game\game\renderer.h(9): note: see declaration of 'Game::Rendering' 1>c:\users\documents\opengl\game\game\renderer.cpp(35): error C2597: illegal reference to non-static member 'Game::Rendering::window' 1>c:\users\documents\opengl\game\game\renderer.cpp(36): error C2597: illegal reference to non-static member 'Game::Rendering::window' 1>c:\users\documents\opengl\game\game\renderer.cpp(43): error C2597: illegal reference to non-static member 'Game::Rendering::window' 1>Done building project "Game.vcxproj" -- FAILED. ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========  
       
      Renderer.cpp
      #include <GL/glew.h> #include <GLFW/glfw3.h> #include "Renderer.h" #include "Timer.h" #include <iostream> namespace Game { GLFWwindow* window; /* Initialize the library */ Rendering::Rendering() { mClock = new Clock; } Rendering::~Rendering() { shutdown(); } bool Rendering::initialize(uint width, uint height, bool fullscreen, std::string window_title) { if (!glfwInit()) { return -1; } /* Create a windowed mode window and its OpenGL context */ window = glfwCreateWindow(640, 480, "Hello World", NULL, NULL); if (!window) { glfwTerminate(); return -1; } /* Make the window's context current */ glfwMakeContextCurrent(window); glViewport(0, 0, (GLsizei)width, (GLsizei)height); glOrtho(0, (GLsizei)width, (GLsizei)height, 0, 1, -1); glMatrixMode(GL_PROJECTION); glLoadIdentity(); glfwSwapInterval(1); glEnable(GL_SMOOTH); glEnable(GL_DEPTH_TEST); glEnable(GL_BLEND); glDepthFunc(GL_LEQUAL); glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST); glEnable(GL_TEXTURE_2D); glLoadIdentity(); return true; } bool Rendering::render() { /* Loop until the user closes the window */ if (!glfwWindowShouldClose(window)) return false; /* Render here */ mClock->reset(); glfwPollEvents(); if (mClock->step()) { glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glfwSwapBuffers(window); mClock->update(); } return true; } void Rendering::shutdown() { glfwDestroyWindow(window); glfwTerminate(); } GLFWwindow* Rendering::getCurrentWindow() { return window; } } Renderer.h
      #pragma once namespace Game { class Clock; class Rendering { public: Rendering(); ~Rendering(); bool initialize(uint width, uint height, bool fullscreen, std::string window_title = "Rendering window"); void shutdown(); bool render(); GLFWwindow* getCurrentWindow(); private: GLFWwindow * window; Clock* mClock; }; } Timer.cpp
      #include <GL/glew.h> #include <GLFW/glfw3.h> #include <time.h> #include "Timer.h" namespace Game { Clock::Clock() : mTicksPerSecond(50), mSkipTics(1000 / mTicksPerSecond), mMaxFrameSkip(10), mLoops(0) { mLastTick = tick(); } Clock::~Clock() { } bool Clock::step() { if (tick() > mLastTick && mLoops < mMaxFrameSkip) return true; return false; } void Clock::reset() { mLoops = 0; } void Clock::update() { mLastTick += mSkipTics; mLoops++; } clock_t Clock::tick() { return clock(); } } TImer.h
      #pragma once #include "Common.h" namespace Game { class Clock { public: Clock(); ~Clock(); void update(); bool step(); void reset(); clock_t tick(); private: uint mTicksPerSecond; ufloat mSkipTics; uint mMaxFrameSkip; uint mLoops; uint mLastTick; }; } Common.h
      #pragma once #include <cstdio> #include <cstdlib> #include <ctime> #include <cstring> #include <cmath> #include <iostream> namespace Game { typedef unsigned char uchar; typedef unsigned short ushort; typedef unsigned int uint; typedef unsigned long ulong; typedef float ufloat; }  
      Game.zip
    • By Old Mohave Games Studio
      Bitcoin Survival! An 1-bit graphics charming game made in 5 days for the 2018's Crypto Game Jam. It's a Roguelike Clicker Game in which you must mine bitcoins to buy and upgrade itens in order to survive as long as you can! All assets original made by me. Come play. And, please, share and rate. Any suggestions for the game are welcome too. (ALSO REPORT ME ANY BUGS FOUND)
      DEVLOG. V. 0.2
      - The game has been extensively polished. Many bugs have been fixed and many features have been added to the game. The difficulty has been balanced once again. Maybe I still have to update some things in the tutorial, but that's easy and I will be doing this in the next days. Hope you enjoy the game at this actual stage. It's almost like a new game.
      - It's mobile compatible!
      IF YOU LIKED THE GAME, PLEASE DON'T FORGET TO SHARE AND RATE IT! That would help me a lot.
      https://www.scirra.com/arcade/strategy-games/bitcoin-survival-28765




    • By Tuner_z

      Name: One Level: Stickman Jailbreak
      Price: Free
      Developer: RTU Studio
      Platform: Android
      Language: C# (Unity3D)
      Google Play: https://play.google.com/store/apps/details?id=com.RTU.OneLevel
       
      Hello!
      I want to show you my game! "One level: Stickman Jailbreak" is a puzzle game with unusual gameplay where you must help the character to escape from prison. You just need to take the key and get out alive. The game has only one level, and there are many ways to complete it. Not everything is as simple as it might seem at first glance, so there are clues in the game.
       
      Short description:
      Nobody escapes from here!
       
      Description:
      Tommy got into trouble again! Our hero is behind bars. But he's not going to stay in jail for a long time and he decides to escape. Tommy steals a key and gets out of the jail cell. But our friend doesn't go free: Tommy suddenly finds himself in the same room from which he just escaped! The conditions for escaping change every time. In order to go free Tommy will have to solve logical puzzles and you can help him in this!
      At first it will be easy, but the tension will increase, and the tasks will become more complicated with each level. You should use your brain for all 100%, but if your skill is not enough, you can use a hint or ask for help from friends!
      You can solve the puzzles alone or with your friends and spend time well!
       
      Features: 
      Features:
      - 48 unique levels;
      - the game is translated into 10 languages: English, French, German, Spanish, Italian, Portuguese, Russian, Japanese, Chinese, Korean;
      - the function of "help from friend";
      - hints;
      - instructions.
       
      Trailer:
       
      Screenshots:





       
  • Advertisement
  • Advertisement
Sign in to follow this  

Tetris Clone Code Review Request

Recommended Posts

Hello! I have made a clone of Tetris using SDL libraries for C++. I would love to get some input as to what I have done right and wrong. Also please tell me if im using Github correctly, it confuses me greatly. (I tried to add a new commit to remove the misplaced header file "DungeonCrawlV4.o" but it doesn't seem to have taken place.)

https://github.com/Starfruit64/Tetris-Clone

Share this post


Link to post
Share on other sites
Advertisement

Quick thoughts (some of which I think I mentioned to you last time we looked at this code):

  • there's no need to have a single, shared SDL_Event for everything to use - it can be a local object inside the function that polls for them.
  • it seems a bit pointless to abstract away the SDL input messages in a program this small, but if you prefer to do this, I'd suggest using enums rather than strings like "a_d" which are more error-prone and also less efficient to pass around. This also allows you to use switch/case instead of the uglier chains of if-elses.
  • I don't recommend wrapping your SDL_PollEvent call inside an input class because SDL events aren't all about player input.
  • Normally, instead of passing a graphics object (e.g. Renderer) to a game logic object (e.g. Board), you do it the other way around. This is because you don't usually want your logic objects to have to worry about details such as how they get rendered.
  • different gamestates are better represented with enums than with integers and comments explaining the integers.
  • you should consider making accessors like 'return_pos' const
  • you should probably add comments in your header files to say what each class does and what each member does
  • explicitly initialise variables when you create them, e.g. to nullptr
  • be consistent with your naming - you seem to use 'tetro' and 'tetri' interchangeably.
  • consider separating your game loop out into clear input/update/render functions. You might need to have some extra mechanism telling you when to render, since (unlike most games) you don't render every frame.

Share this post


Link to post
Share on other sites
1 hour ago, Kylotan said:

Quick thoughts (some of which I think I mentioned to you last time we looked at this code):

  • there's no need to have a single, shared SDL_Event for everything to use - it can be a local object inside the function that polls for them.
  • it seems a bit pointless to abstract away the SDL input messages in a program this small, but if you prefer to do this, I'd suggest using enums rather than strings like "a_d" which are more error-prone and also less efficient to pass around. This also allows you to use switch/case instead of the uglier chains of if-elses.
  • I don't recommend wrapping your SDL_PollEvent call inside an input class because SDL events aren't all about player input.
  • Normally, instead of passing a graphics object (e.g. Renderer) to a game logic object (e.g. Board), you do it the other way around. This is because you don't usually want your logic objects to have to worry about details such as how they get rendered.
  • different gamestates are better represented with enums than with integers and comments explaining the integers.
  • you should consider making accessors like 'return_pos' const
  • you should probably add comments in your header files to say what each class does and what each member does
  • explicitly initialise variables when you create them, e.g. to nullptr
  • be consistent with your naming - you seem to use 'tetro' and 'tetri' interchangeably.
  • consider separating your game loop out into clear input/update/render functions. You might need to have some extra mechanism telling you when to render, since (unlike most games) you don't render every frame.

About events: should I remove the Input class and have all events handles in Main in a function? Or should I have multiple times where I poll for events, one time for input, one time for window events, etc.?

Share this post


Link to post
Share on other sites

I recommend handling all the events in your main loop, and passing them on to whichever subsystem - e.g. Input - can handle them.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Advertisement