Difference between revisions of "Programming"
BloodyCactus (talk | contribs) m (→Sound) |
BloodyCactus (talk | contribs) (→Languages) |
||
Line 1: | Line 1: | ||
== Languages == | == Languages == | ||
− | === Frameworks === | + | Your programming languages are going to be dictated, mostly by your hardware control system. Off the shelf systems such as P-ROC or Fast have a close relationship to PyProcGame and the Mission Pinball Framework as more higher level programming systems. |
+ | |||
+ | Using the more lower level libpinproc library for P-ROC boards, will allow you to bind into other languages and build your own layering by using things like SDL or SFML which gives you access to OpenGL and other fancy graphics api's. | ||
+ | |||
+ | Obviously, if your using custom hardware, you probably have the means for writing your own software however you see fit. | ||
+ | |||
+ | === Pinball Frameworks === | ||
[https://missionpinball.com/framework/ Mission Pinball] | [https://missionpinball.com/framework/ Mission Pinball] | ||
+ | Currently supports both P-ROC and FAST controllers, written in Python | ||
+ | |||
+ | [http://pyprocgame.pindev.org/ PyProcGame] | ||
+ | Developed originally for the P-ROC controllers. Written in Python | ||
+ | |||
+ | [https://github.com/preble/libpinproc libPinPROC] | ||
+ | This is a lower level C library for P-ROC | ||
== Rules == | == Rules == |
Revision as of 02:11, 25 January 2015
Contents
Languages
Your programming languages are going to be dictated, mostly by your hardware control system. Off the shelf systems such as P-ROC or Fast have a close relationship to PyProcGame and the Mission Pinball Framework as more higher level programming systems.
Using the more lower level libpinproc library for P-ROC boards, will allow you to bind into other languages and build your own layering by using things like SDL or SFML which gives you access to OpenGL and other fancy graphics api's.
Obviously, if your using custom hardware, you probably have the means for writing your own software however you see fit.
Pinball Frameworks
Mission Pinball Currently supports both P-ROC and FAST controllers, written in Python
PyProcGame Developed originally for the P-ROC controllers. Written in Python
libPinPROC This is a lower level C library for P-ROC
Rules
Light Shows
Modes
mini-modes - Drop target sets, etc
Settings/Preferences
Scoring
Procedures
Status Report - Holding down a flipper for a status report
Hardware-specific procedures
Sound
With anything that conveys sound as a key to whats going on, you want to have some form of priority. A background sound effect might have a low priority of say 4, but 'Shoot the ram for jackpot' might have a priority of 1. If a priority 1 sound is playing, and the player his a switch that triggers a background sound effect, the system can know now to play the sound effect over the top of the more important jackpot instruction call out. You also do not want to be playing sounds continuously over the top of one another, say you have an explosion sound when a pop bumper is triggered, if the ball is getting a lot of pop bumper action and triggering 3 pops in very fast succession, you do not want to have the sound affect triggered as one long continuous shotgunning whitenoise. You could choose not to play the same sound effect unless N time has passed (say 3 seconds), or never play the same sound affect at the same time.
Too many sound effects playing over each over mutes the affect it should have on the player.
You should also normalise the volume of all the sound effects to the same level so it does not play havoc with the volume control on the machine itself.