Giter Club home page Giter Club logo

opengameframework's Introduction

Open Game Framework

Build status License: MIT

Assets

Assets used for the test game are from kenney.nl.

opengameframework's People

Contributors

simon-bourque avatar gabbell avatar jrf27 avatar samratdebroy avatar wai-lau avatar

Stargazers

 avatar  avatar lwj0723 avatar Jérôme Parent-Lévesque avatar  avatar

Watchers

James Cloos avatar  avatar Jérôme Parent-Lévesque avatar  avatar  avatar Ahmad El-Baher avatar

opengameframework's Issues

Add cube map support to engine

TASK

Description:

We need to be able to create and load cube maps. Both the converter and TextureCache need to be updated to support the new texture type. Add the new type the the Target enum in Texture.h and then add the new case the loadTexture function. Base yourself of the implementation of the current texture types. For the converter also base yourself off what is already there.

Motivation:

Need cube map textures for skyboxes. It is currently blocking us from replacing the old texture manager with the new TextureCache for the 3D engine.

Completion Criteria:

  • Cube map type added to Target enum
  • Can load cube maps using the TextureCache
  • You can convert a set of images into a cube map using our converter
  • Cube map should be saved using our current file format

Add coding conventions to repo

TASK

Description:

We need to come up with coding conventions to make sure everyone is on the right page when it comes to naming, style, etc.

Motivation:

Coming up with coding conventions will make the code more readable and consistent.

Completion Criteria:

  • CONTRIBTUTING file added to the repo
  • Coding conventions section added to CONTRIBUTING file
  • Update existing code with new conventions

Refactor current math library and add support for 3D

TASK

Description:

Our current math library is missing implementations for many geometric objects that would be useful in both 2D and 3D environments. At the moment there is only a Rectangle and Point class for shapes and the currently existing matrix and vector classes could use a bit of refactoring. More math constants especially commonly used ones should be added as well. Utilities for floating point comparison should be added as well. All math classes and functions should be in the ogf::math namespace. Test cases should be written as much as possible for all classes and functions

Geometry:

More shapes for 2D and 3D should be added to the library. Rectangle should no longer store the points representing its shape, instead getters should exist to calculate them when needed. The parent class Shape should also be removed since it does not serve a purpose at the moment. All shapes in their respective dimensions should be able to be tested for intersections, it is not necessary for 2D shapes to be tested with 3D shapes.

Matrix, vectors, and quaternions:

Quaternions should be implemented in the library. The 'f' suffix should be removed from all classes since float versions of these classes are the only kinds that exist. Operator overloading should be used as much as possible.

Suggested Shapes (not all shapes need to implemented right away):
  • 2D
    • Axis Aligned Bounding Box (AABB2D)
    • Rectangle (similar to AABB except can be rotated)
    • Circle
    • Ellipse
    • Polygon
    • Line2D
    • Point2D
  • 3D
    • AABB3D
    • Sphere
    • Ellipsoid
    • Capsule
    • ConvexHull
    • Plane
    • Line3D
    • Point3D

Motivation:

When this task is complete we will be able to completely replace glm from the 3D sections of our code which removes an additional 3rdparty dependency. When the test cases are done we will be certain that our math classes and functions will output correct values even after being modified. With our own custom library we can also easily profile performance and memory. In the future we can also use instruction set extensions such as SSE and AVX which can significantly increase performance. With the additional shapes we can increase the complexity of our collision and physics system.

Completion Criteria:

  • Additional constants added
  • Already existing matrix and vector classes revised
  • 'f' suffix removed
  • Quaternion implemented
  • Floating point utilities implemented
  • Old shapes revised
  • Shape parent class removed
  • Additional shapes implemented
  • Intersection algorithms implemented
  • Unimplemented shapes added as tasks for future
  • All math classes and functions in ogf::math namespace
  • Test cases written

Finish implementing asserts

TASK

Description:

The current assert for the engine is incomplete and lacking functionality. At the moment the dialogue that pops up is not very appealing and only displays the name of the file, line number, and a provided message. Additionally, when the break option is chosen the program breaks at the incorrect instruction. It would be nice to also display the stack trace as well as the full path of the file instead of just its name. The programmer should also be able to use printf format strings when providing a message.

Current Dialogue:

image

Motivation:

Asserts are useful and can be used in place of exceptions where errors are caused by the mistakes of a programmer. Having a fully functioning assert system can help locate bugs in existing code. Asserts can easily be removed from final builds using preprocessor directives.

Completion Criteria:

  • #12 is fixed
  • Break, Ignore, and Terminate options are provided and functional
  • Stack trace, file path, line number, and a message are displayed
  • Programmer can provide printf format strings
  • Break option halts at the correct instruction
  • Dialogue is appealing

Create new readme

TASK

Description:

Somebody needs to make a new readme because our current one is no good. Be creative, should have a general description of the engine as well as a list of planned and current features. Also adding a quick summary of how to build and run the sample games. A logo would be nice but not necessary for this task. Readme should still also have the badges for the build status and license. For now we should also have a message explaining that the engine is in heavy development and probably shouldn't be used to develop full games yet.

Motivation:

Self explanatory every repo should have one.

Completion Criteria:

  • Description
  • Planned and current features
  • Instructions for sample games
  • Message explaining the current status of the engine

Implement xml schema and update build tool

TASK

Description:

Implement an xml schema for the currently existing resources. Modify the build tool to parse xml instead of using command line arguments.

Motivation:

Having our resources saved as xml files will allow them to easily be parsable by any future tool we may need to develop. Implementing an xml schema will ensure that the syntax and rules for our files will be consistent everywhere. Having them as xml files will also make them more human readable which will be especially useful when diffing or merging them.

Completion Criteria:

  • Xml files verifiable using xml schema
  • Xml schema should be implemented for the currently used types of textures
  • Convert currently existing resources in the sample games to xml
  • Build tool can convert the xml files into binary files for the engine to load
  • Build tool can take in files or folders as arguments

Create FramebufferCache

TASK

Description:

We need a FramebufferCache inspired from the other caches already made (look at TextureCache). One major difference is that framebuffers are not loaded from a file. Instead, they are generated during runtime. The cache should store and manage framebuffers. Similar to TextureCache, the GLuint representing the Framebuffer ID will be hashed and store in an unordered_map. One feature is that it should react if the window size is changed because all framebuffers will need to be regenerated based on the new window size.

Motivation:

Some CG features (like shadow mapping) require storage and manipulation of framebuffers. Having easy and clear access to them would be an asset.

Completion Criteria:

  • The FramebufferCache stores framebuffers in a clear and concise manner inspired from other caches
  • All framebuffers are regenerated if a window resize event occurs
  • The Framebuffer ID is hashed and stored into a map

Asserts cause a crash for x64 builds

BUG

Description:

When an assert triggers and the code for creating a dialogue executes the game crashes with the following message and stack trace:
image
image

Frequency:

100%

Repro Steps:

  1. Set visual studio configuration to debug and platform to x64
  2. Run any sample game
  3. Trigger any assert

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.