User Tools

Site Tools


proton_info

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
proton_info [2010/12/15 06:23] sethproton_info [2011/04/26 22:34] (current) seth
Line 1: Line 1:
 ==== What is Proton SDK? ==== ==== What is Proton SDK? ====
  
-Proton SDK is an all-in-one framework solution optimized for writing games in C++ and deploy them on many platforms.+Proton SDK is an all-in-one framework solution optimized for writing games in C++ and deploying them on many platforms.
  
 [[proton_features|Feature list]] [[proton_features|Feature list]]
Line 8: Line 8:
  
   * Engine is just source files included in the project, no separate libraries to link for debugging ease (not including system libraries like zlib and gles in some cases)   * Engine is just source files included in the project, no separate libraries to link for debugging ease (not including system libraries like zlib and gles in some cases)
-  * "almost zlib" free/open licensed GL/GLES optimized alternative to libraries like SDL - can be used and shared everywhere without worries+  * "near zlib" free/open licensed GL/GLES optimized alternative to libraries like SDL - can be used and shared everywhere without worries
   * Components designed to be modular and loosely linked, should be possible to understand and fix bugs when you find them yourself   * Components designed to be modular and loosely linked, should be possible to understand and fix bugs when you find them yourself
   * Created to be easy to compile on many systems, a single .mak should be all that is required, avoiding the automake/configure tools   * Created to be easy to compile on many systems, a single .mak should be all that is required, avoiding the automake/configure tools
   * Device specifics abstracted out, native UI usage avoided.  Games look and play the same on all devices, but you won't see the standard iOS buttons or dialog boxes in your game for example (with some exceptions, for instance, the native pop-up keyboard is invoked for text entry if needed)   * Device specifics abstracted out, native UI usage avoided.  Games look and play the same on all devices, but you won't see the standard iOS buttons or dialog boxes in your game for example (with some exceptions, for instance, the native pop-up keyboard is invoked for text entry if needed)
-  * Can write raw GL/GLES code and easily import existing C/C++ source you have+  * Can write raw GL/GLES code and use existing C/C++ source you have
   * An (optional) entity/component system that is designed to combat "entity bloat", subclass hell and complexity creep - an entity can be anything, an entire game, a widget, a non-rendering sound that plays every ten seconds or something that detects when the Escape key is hit   * An (optional) entity/component system that is designed to combat "entity bloat", subclass hell and complexity creep - an entity can be anything, an entire game, a widget, a non-rendering sound that plays every ten seconds or something that detects when the Escape key is hit
  
Line 29: Line 29:
   * It can be slow.  It's mostly boost:signals fault.     * It can be slow.  It's mostly boost:signals fault.  
   * If you have 200 entities, you should not be using entities and components for them, you should be using one component that handles all your entities in a faster more logical form.   * If you have 200 entities, you should not be using entities and components for them, you should be using one component that handles all your entities in a faster more logical form.
-  * It's complicated.  If you aren't organized the abiltity to create variables and functions on the fly (and schedule same) can get out of control fast!+  * It's complicated.  If you aren't organized the ability to create variables and functions on the fly (and schedule same) can get out of control fast!
   * The syntax is sucky.  Forcing C++ to approach the features of flexible languages like lua and python just isn't a perfect solution, you'll have to decide if the trade-offs of being able to stay in glorious C++ at all times is worth it.   * The syntax is sucky.  Forcing C++ to approach the features of flexible languages like lua and python just isn't a perfect solution, you'll have to decide if the trade-offs of being able to stay in glorious C++ at all times is worth it.
   * The good news is you don't really have to touch that stuff at all, it's optional.  But especially for GUIs it's very useful.   * The good news is you don't really have to touch that stuff at all, it's optional.  But especially for GUIs it's very useful.
proton_info.1292394180.txt.gz · Last modified: 2010/12/15 06:23 by seth