RtB/build at f05725438dcfd638b229b784ac87f9da9d10c6db - RtB

History

kts f05725438d Implemented some of the GUI subsystem. Events are first passed through the GUI (should limit this to only particular events) before being sent to the top-most state. Later on, the GUI will be capable of locking the sending of particular events, such as motion or mousemove, if an element is currently focused/held. Basic GuiElement added. Each GuiElement may have children, each of which may have children in turn. The Gui will send getHit requests to the top-most/parent GuiElement, after which that GuiElement will send getHit requests down to its children and their children if need be. If a match is found, a pointer to that element is returned, otherwise NULL. More to be added, but hopefully the GUI system is robust enough - it tries to somewhat decouple from the state, in that elements do not have to have their lower level hit detection processed. There may be some oddities in the design that have yet to be discovered due to there being no visual front end (and the creation of RenderObjects for said visuals).		2015-03-03 03:24:07 -08:00
..
android	Implemented some of the GUI subsystem. Events are first passed through the GUI (should limit this to only particular events) before being sent to the top-most state. Later on, the GUI will be capable of locking the sending of particular events, such as motion or mousemove, if an element is currently focused/held. Basic GuiElement added. Each GuiElement may have children, each of which may have children in turn. The Gui will send getHit requests to the top-most/parent GuiElement, after which that GuiElement will send getHit requests down to its children and their children if need be. If a match is found, a pointer to that element is returned, otherwise NULL. More to be added, but hopefully the GUI system is robust enough - it tries to somewhat decouple from the state, in that elements do not have to have their lower level hit detection processed. There may be some oddities in the design that have yet to be discovered due to there being no visual front end (and the creation of RenderObjects for said visuals).	2015-03-03 03:24:07 -08:00
ios	Implemented some of the GUI subsystem. Events are first passed through the GUI (should limit this to only particular events) before being sent to the top-most state. Later on, the GUI will be capable of locking the sending of particular events, such as motion or mousemove, if an element is currently focused/held. Basic GuiElement added. Each GuiElement may have children, each of which may have children in turn. The Gui will send getHit requests to the top-most/parent GuiElement, after which that GuiElement will send getHit requests down to its children and their children if need be. If a match is found, a pointer to that element is returned, otherwise NULL. More to be added, but hopefully the GUI system is robust enough - it tries to somewhat decouple from the state, in that elements do not have to have their lower level hit detection processed. There may be some oddities in the design that have yet to be discovered due to there being no visual front end (and the creation of RenderObjects for said visuals).	2015-03-03 03:24:07 -08:00
linux	Core now uses a state stack. States may be pushed on the stack with Core::pushState(State*) and popped off with Core::popState(). Pushing a state will trigger the old state's onCede(), push the state onto the stack, then call the new state's onInit(if DID_INIT is not set) then onRise(). Popping a state will trigger the top state's onCede and the previous state(if it exists)'s onRise. Core::doProcess now has a delta tickrate accumulator that ensures the world is processed at Core::tick_rate. Rendering is not capped to this tickrate, as doRender is called outside of the Event handling and state processing. Finally, functionality that was in Core for testing is now in TestState - it pushed onto the stack during Core::initSystem	2015-03-02 19:58:35 -08:00
osx	Implemented some of the GUI subsystem. Events are first passed through the GUI (should limit this to only particular events) before being sent to the top-most state. Later on, the GUI will be capable of locking the sending of particular events, such as motion or mousemove, if an element is currently focused/held. Basic GuiElement added. Each GuiElement may have children, each of which may have children in turn. The Gui will send getHit requests to the top-most/parent GuiElement, after which that GuiElement will send getHit requests down to its children and their children if need be. If a match is found, a pointer to that element is returned, otherwise NULL. More to be added, but hopefully the GUI system is robust enough - it tries to somewhat decouple from the state, in that elements do not have to have their lower level hit detection processed. There may be some oddities in the design that have yet to be discovered due to there being no visual front end (and the creation of RenderObjects for said visuals).	2015-03-03 03:24:07 -08:00
vs	Update VS project - works fine as well.	2015-03-02 20:13:43 -08:00
README	Initial commit of RtB skeleton. ios, osx, and android build environments exist and successfully compile, presuming a fully functional SDL2 build environment. Documentation on getting such an environment set up will be forthcoming.	2015-02-04 15:26:15 -08:00

README

This directory contains build environments for different platforms. The basic object of each build environment is to compile the source files in the root "src/", collect the files in "assets/", and produce a release or build product. This product may be a directory with binaries or an application package/bundle depending on the target platform.

Significant changes to the base source directory, such as the removal or addition of new files, will require updating the build environments to reflect those changes.