User:Will07c5

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

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

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.

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 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.