This wiki was in read-only mode for many years, but can now be edited again. A lot of information will need to be updated.

User:Will07c5: Difference between revisions

From BZFlagWiki
Jump to navigation Jump to search
← Older editNewer edit →
Line 27: Line 27:


==Draft Proposal for Modularization of OpenGL code==
==Draft Proposal for Modularization of OpenGL code==
Currently the OpenGL calls in bzflag are scattered across the entire game client. This a problems since it results in the graphics code being difficult to maintain. The goal of this project is find all the calls to OpenGL and move them to one location. A basic API will be constructed to allow the moved code to be accessed and the OpenGL calls will also be refactored into calls to the new API.
Bzflag currently has drawing code all over the code base. This means that maintenance of the drawing code is difficult and plugging in an alternative graphics engine is nearly impossible. The goal of this project is to take all the drawing code and place it in a central location. All the code at this location will be accessible through an API. This is the first step on the road to having the drawing independent of the graphics engine.  


The most important consideration of this project is to make sure that as the code is being replaced it still stays fully functional, since other people will be concurrently working on the code. While this API will be constructed with the thought in mind that eventually the work will be used to support multiple rendering engines, support for multiple rendering engines is beyond the scope of this proposal. This consideration will also never take precedence over not breaking code. To avoid breaking code, the API will minimize the reorganization of drawing code and only reorganize only if it is beneficial to do so. Testing will be performed after each new method is added to the API as well as after each section of code is refactored, this will minimize hard to track down bugs and the breaking of existing code.
The primary requirement of this project is that at no stage can the code base be broken, since bzflag is an active project. To accommodate this requirement, there will be no large stages. The work will be done incrementally. Each section* of code will first be inspected to determine its functionality. The code will then be moved and modified as necessary to accommodate being placed in a separate method in the API. The section will then be refactored to use the new API method(s). Finally the section will be tested thoroughly. This process will be repeated for each and every section of drawing code.
 
<br />
The first stage will be looking through the code and finding functionality that needs to be in the API, this stage will be started before Summer of Code begins. The next stage will be implementing and testing the new API. The final stage will consist of refactoring all the OpenGL calls and testing to make sure nothing is broken. After this some final testing will be done but the vast majority of testing should take place during the moving and refactoring of the code.
<br />
*Section will usually be defined as a single method, unless the method is too large in which case it may be split up into multiple sections. Conversely if there is a small and simple enough class it may be treated as a section.

Revision as of 04:57, 25 March 2009

List of possible improvements to bzworkbench

High priority

  • add support for rotating and scaling objects, with widgets for both functions
  • implement any missing functionality in the menus
  • complete the material editor
  • add snap to grid
  • add grouping and improve selection
  • implement missing object types
  • fix bug where bzwb complains about missing a plugin for obj files whenever an object is added to the map

Medium priority

  • implement undo and redo functionality
  • add an object list so that objects can be selected even if they are obscured
  • numeric input for coordinates

Low priority

  • make it so editor doesn't need to turn off aero to run (vista specific)
  • Remove dependance on outside files for simple models like boxes.
  • make windows scale properly
  • make GUI look nicer
  • Possibly add support for docking toolbars and windows http://fltkdock.sourceforge.net/
  • allow the layout of the GUI to be saved and loaded (important for docking toolbars/windows)
  • Improve grid by adding/removing grid lines as user zooms in and out and scaling the grid
  • move the add object and base buttons to toolbars
  • Add support for multiple viewports

Draft Proposal for Modularization of OpenGL code

Bzflag currently has drawing code all over the code base. This means that maintenance of the drawing code is difficult and plugging in an alternative graphics engine is nearly impossible. The goal of this project is to take all the drawing code and place it in a central location. All the code at this location will be accessible through an API. This is the first step on the road to having the drawing independent of the graphics engine.

The primary requirement of this project is that at no stage can the code base be broken, since bzflag is an active project. To accommodate this requirement, there will be no large stages. The work will be done incrementally. Each section* of code will first be inspected to determine its functionality. The code will then be moved and modified as necessary to accommodate being placed in a separate method in the API. The section will then be refactored to use the new API method(s). Finally the section will be tested thoroughly. This process will be repeated for each and every section of drawing code.

  • Section will usually be defined as a single method, unless the method is too large in which case it may be split up into multiple sections. Conversely if there is a small and simple enough class it may be treated as a section.
Retrieved from "https://wiki.bzflag.org/index.php?title=User:Will07c5&oldid=5623"