.TH "ALLEGRO_STATE(3alleg5) Allegro reference manual" "" "" "" "" .SH NAME .PP ALLEGRO_STATE \- Allegro 5 API .SH SYNOPSIS .IP .nf \f[C] #include\ typedef\ struct\ ALLEGRO_STATE\ ALLEGRO_STATE; \f[] .fi .SH DESCRIPTION .PP Opaque type which is passed to al_store_state(3alleg5)/al_restore_state(3alleg5). .PP The various state kept internally by Allegro can be displayed like this: .IP .nf \f[C] \ \ global \ \ \ \ \ \ active\ system\ driver \ \ \ \ \ \ \ \ \ \ current\ config \ \ per\ thread \ \ \ \ \ \ new\ bitmap\ params \ \ \ \ \ \ new\ display\ params \ \ \ \ \ \ active\ file\ interface \ \ \ \ \ \ errno \ \ \ \ \ \ current\ blending\ mode \ \ \ \ \ \ current\ display \ \ \ \ \ \ \ \ \ \ deferred\ drawing \ \ \ \ \ \ current\ target\ bitmap \ \ \ \ \ \ \ \ \ \ current\ transformation \ \ \ \ \ \ \ \ \ \ current\ clipping\ rectangle \ \ \ \ \ \ \ \ \ \ bitmap\ locking \f[] .fi .PP In general, the only real global state is the active system driver. All other global state is per\-thread, so if your application has multiple separate threads they never will interfere with each other. (Except if there are objects accessed by multiple threads of course. Usually you want to minimize that though and for the remaining cases use synchronization primitives described in the threads section or events described in the events section to control inter\-thread communication.)