DOCSLIB.ORG

Input File Viennaipd Application

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Input File Viennaipd Application ViennaIPD - An Input Control Language for Scientific Computing Josef Weinbub Karl Rupp Siegfried Selberherr Institute for Microelectronics, Technische Universit¨atWien Gußhausstraße 27-29 / E360 A-1040 Vienna, Austria E-mail: {weinbub|rupp|selberherr}@iue.tuwien.ac.at ABSTRACT #include "ipdP.h" A powerful control language, named ViennaIPD, has int main(int argc, char** argv) { been developed. The library based software is capable ipdChar *s; // Read a ViennaIPD input file of reading complex input datasets which can be accessed ipdReadInputDeck(argv[1]); 1. // Access data from C/C++ applications by a programming interface. 3. ipdGetStringByName("~a", &s); ViennaIPD supports a convenient C-like input file lan- printf("Value of ~a: %s\n", s); // Manipulate data 4. guage, object oriented structuring of datasets, powerful ipdSetIntegerByName("~SecA.a", 2); a inheritance mechanisms and a unit system. The input printf("Value of ~SecA.a set to: %d\n", 2); return 0; b file language as well as the programming interface is dis- } cussed in detail. Application SecA a d INTRODUCTION SecB a Applications for scientific computing require a power- 2. d a = "A short text"; ful control language to satisfy the need of control pa- SubSecC c b = 2.2; rameters, e.g. material properties, models to take into SecA { account, model parameters, process definitions, simu- ext a = 1; d = 2 * a; lation modes, iteration schemes, and numerical behav- } ViennaIPD ior [1, 2, 3, 4]. As a result, control files grow in size, SecB : SecA { which results in decreased maintainability. Therefore a d = 3 * a; SubSecC powerful control language has been developed as part of { c = 1; } the MINIMOS-NT simulation software package [5, 6]. } To enlarge the field of application the control language has been extracted, revisited, and packaged to be dis- Input File tributable as a standalone control language named Vi- ennaIPD. ViennaIPD offers a powerful inheritance con- Figure 1: ViennaIPD workflow. The application passes the cept, unit conversion capabilities and the ability to di- filename of the input file to ViennaIPD (1.). The input file rectly access existing input files. The latter is especially is used to populate the tree based datastructure (2.). The of interest for reasons of post-processing simulation re- data can be accessed (3.) and manipulated (4.) by the sults. Figure 1 depicts a comprehensible overview how application. ViennaIPD is used. ViennaIPD provides a powerful input file language which aims to deal with the manifold parameter de- mands of simulation software. The library itself is writ- Therefore any kind of data set hierarchy can be built. ten in C, however, applications can be based on either In this context, inheritance of sections is supported to C or C++. The most fundamental element is a vari- enable, for example, reusability of section elements. Fi- able. To describe dependencies to other variables, a nally a large set of functions is provided to enable math- variable contains an expression, that is evaluated at run- ematical computations within the input files. time. Different variable types are supported as well as The paper is organized as follows: The first section pro- accessibility control. Furthermore, a section provides vides an overview of the ViennaIPD control language, a means of structuring variables to enable associative whereas the second section outlines the programming variable definitions. A section holds an arbitrary set of interface. Furthermore, the third section depicts a use variables and subsections. case example. Finally, the fourth section compares Vi- ennaIPD to various other input control approaches. 34 INPUT FILE SPECIFICATION However, this variable type can be used to temporarily The input file specification is based on a comprehensible store data, for example the result of a computation. language. The usage is similar to common programming Sections languages, e.g. C. Additionally, object oriented features ViennaIPD supports structures of variables, so called are provided to enable structuring of large data sets, sections, to manage large input files. A section is defined i.e. inheritance mechanisms. Furthermore, a powerful with unit system is provided which supports the validity of computations based on quantities. 1 <section name> { ... } Variables The following snippet depicts a section named Solve An arbitrary number of variables can be defined. The with a read-only keyword variable. general definition of a variable is 1 Solve { maxStepSize = 1e30; } 1 <type> <variable name > = <e x p r e s s i o n >; Sections can be nested to arbitrary depth <type> must be a valid variable type. The available variable types are listed in Table 1. Note that if no 1 BaseSection { 2 SubSection { <type> is mentioned, the default key type is used. 3 SubSubSection {} <variable name> can be of any length, can contain 4 } capital and small letters, an underscore, and numbers. 5 } <type> Description ViennaIPD enables also inheritance of sections. ext external variable - read- and writeable 1 BaseSection { x1 = −3; } key keyword variable - read-only (default) 2 DerivedSection : BaseSection; aux auxiliary variable - hidden DerivedSection is inherited from BaseSection. Con- Table 1: Types of Variables sequently, DerivedSection contains all elements (vari- ables and subsections) of BaseSection. However, the name must not begin with a number. An Note, that the variables of BaseSection transparently expression can be assigned to a variable by using the exist in DerivedSection. Hence, if a variable in assignment operator = and a valid data-type (Table 2). BaseSection changes, it changes in DerivedSection too. Type Example Furthermore, multiple inheritance is supported. Boolean a = true; 1 BaseSection1 { a = 1 ; } Integer a = 3; 2 BaseSection2 { b = 3 ; } Real a = 3.1415; 3 DerivedSection : BaseSection1 , BaseSection2; Complex a = 4.3 + 3.1 j; DerivedSection a b Quantity a = 3.1415 "m/s"; consists of two variables and in- BaseSection1 BaseSection2 String a = "This is a string"; herited from and , respec- Array a = [1, "pi", 3 A]; tively. Additionally, conditional inheritance enables to inherit Table 2: Types of Data from sections based on specific conditions. 1 Section : BaseSection1 ? expression1 , The following snippet depicts a few examples which 2 BaseSection1 ? expression2 , make use of the available variable types. 3 ... {} 1 s o m e f l o a t = 3 . 3 ; Conditional inheritance is an extension to multiple in- 2 key some text = ”some Text”; heritance. Several base sections can be specified for in- 3 ext x = 3 2 ; 4 ext y = 4 ; heritance, an expression can be assigned to each one. 5 aux a = s q r t ( x ∗ x + y ∗ y ) ; The following snippet depicts the usage. 6 ex = x / a ; 1 7 ey = y / a ; Switch = 0 ; 2 D e r ivedSection : BaseSection1 , 3 > Lines 1,2,6,7 depict keyword variables. Hence, the as- BaseSection2 ? (Switch −1) , 4 BaseSection3 ? (Switch < 1) signed data can be accessed only, not altered. Lines 3,4 5 {} depict external variables, for which data can be accessed and altered. Line 5 outlines an application case for the DerivedSection is always inherited from auxiliary variable. This variable cannot be accessed by BaseSection1. As Switch is 0, the conditions for the programming interface, it is hidden. BaseSection2 and BaseSection3 both hold. 35 Therefore, DerivedSection is additionally inherited 1 from BaseSection2 and BaseSection3. If Switch Q1 = 3 ”A” ; 2 Q2 = 2 ”m” ; is set to 2, DerivedSection is solely inherited from 3 Q3 = Q1 ∗ Q2 ; //OK BaseSection1 and BaseSection2. 4 Q4 = Q1 + Q2 ; // Error Elements of inherited sections can be locally modified. 1 BaseSection { PROGRAMMING INTERFACE 2 x = 1 ; The ViennaIPD Programming Interface is based on the 3 y = 2 ; 4 } C programming language. It provides an interface to the 5 DerivedSection : BaseSection { y = 4 ; } internal tree-based datastructures of ViennaIPD. Data can be traversed and accessed. DerivedSection consists of the two variables x and y, where the variable x is inherited from BaseSection Interface Setup and the variable y is locally modified. So the vari- To be able to use the interface the ViennaIPD header able DerivedSection.x equals 1 and the variable file has to be included. DerivedSection.y equals 4. 1 #include ”ipd.h” Functions The following code snippet depicts the initialization and ViennaIPD enables the use of functions within input the population of the datastructure from an input file. files. Functions can be used in expressions which are stored in variables. 1 // basic initialization 2 i p d I n i t (NULL, NULL) ; 1 < > < > < > type variable name = function (parameters ); 3 // create a new database 4 ipdCreateBase(”NameOfTheDatabase” , 0); An arbitrary number of parameters is supported. 5 // read the inputfile 6 ipdReadInputDeck(argv [1]); 1 a1 = func1(); // 0 Parameter 2 a2 = func2(1 + 2); // 1 Parameter 3 a3 = func3(”hello”, a1); // 2 Parameter Accessing Data ViennaIPD provides built-in functions, for example Specialized getter and setter functions are provided to a large set of mathematical functions, e.g. sin(), access and alter specific data types. The following code pow(), sqrt(), to list a few of them. The following snippet depicts the reading and writing process based snippet depicts the computation of the sine of a com- on these functions. plex number. 1 // declare a variable of type long 2 1 a = sin(4.42 + j ∗ 5 . 9 ); ipdLong i ; 3 // get the "c" integer value Furthermore support functions are provided, e.g. if() 4 ipdGetIntegerByName(”∼c ” , &i ) ; 5 // set the "c" integer value statement, conversion functions, array sizes, random 6 ipdSetIntegerByName(”∼c ” , 2 ) ; number generator, to name a few. Note the ∼ prefix, which indicates the root level of the Units datastructure hierarchy. Therefore variables can be ac- ViennaIPD provides a powerful unit system. A unit is cessed by absolute path addressing. For example access- used in combination with the quantity datatype (Table ing an integer variable named a within a section named 2) and consists of a valid unit name, of which many are BaseSection would be implemented by the following: provided.
Load more

Recommended publications
  • Scripting Engine for Execution of Experimental Scripts on Ttü Nanosatellite
    TALLINN UNIVERSITY OF TECHNOLOGY School of Information Technologies Department of Software Science Sander Aasaväli 142757IAPB SCRIPTING ENGINE FOR EXECUTION OF EXPERIMENTAL SCRIPTS ON TTÜ NANOSATELLITE Bachelor’s thesis Supervisor: Martin Rebane MSc Lecturer Co-Supervisor: Peeter Org Tallinn 2017 TALLINNA TEHNIKAÜLIKOOL Infotehnoloogia teaduskond Tarkvarateaduse instituut Sander Aasaväli 142757IAPB INTERPRETAATOR TTÜ NANOSATELLIIDIL EKSPERIMENTAALSETE SKRIPTIDE KÄIVITAMISEKS Bakalaureusetöö Juhendaja: Martin Rebane MSc Lektor Kaasjuhendaja: Peeter Org Tallinn 2017 Author’s declaration of originality I hereby certify that I am the sole author of this thesis. All the used materials, references to the literature and the work of others have been referred to. This thesis has not been presented for examination anywhere else. Author: Sander Aasaväli 22.05.2017 3 Abstract Main subject for this thesis is choosing a scripting engine for TTÜ (Tallinna Tehnikaülikool) nanosatellite. The scripting engine must provide functionality, like logging, system debugging, determination, and perform certain tasks, like communicating with the bus, file writing and reading. The engine’s language must be powerful enough to fill our needs, yet small and simple enough to have as small flash and RAM (Random Access Memory) footprint as possible. The scripting engine should also be implemented on an external board (STM32f3discovery). This way the engine’s flash footprint, RAM footprint and performance can be tested in our conditions. The outcome was that, both Pawn and My-Basic were implemented on the external board. The flash and RAM footprint tests along with performance tests were executed and results were analysed. This thesis is written in English and is 38 pages long, including 5 chapters, 6 figures and 2 tables.
    [Show full text]
  • Tomasz Dąbrowski / Rockhard GIC 2016 Poznań WHAT DO WE WANT? WHAT DO WE WANT?
    WHY (M)RUBY SHOULD BE YOUR NEXT SCRIPTING LANGUAGE? Tomasz Dąbrowski / Rockhard GIC 2016 Poznań WHAT DO WE WANT? WHAT DO WE WANT? • fast iteration times • easy modelling of complex gameplay logic & UI • not reinventing the wheel • mature tools • easy to integrate WHAT DO WE HAVE? MY PREVIOUS SETUP • Lua • not very popular outside gamedev (used to be general scripting language, but now most applications seem to use python instead) • even after many years I haven’t gotten used to its weird syntax (counting from one, global variables by default, etc) • no common standard - everybody uses Lua differently • standard library doesn’t include many common functions (ie. string.split) WHAT DO WE HAVE? • as of 2016, Lua is still a gold standard of general game scripting languages • C# (though not scripting) is probably even more popular because of the Unity • Unreal uses proprietary methods of scripting (UScript, Blueprints) • Squirrel is also quite popular (though nowhere near Lua) • AngelScript, Javascript (V8), Python… are possible yet very unpopular choices • and you can always just use C++ MY CRITERIA POPULARITY • popularity is not everything • but using a popular language has many advantages • most problems you will encounter have already been solved (many times) • more production-grade tools • more documentation, tutorials, books, etc • most problems you will encounter have already been solved (many times) • this literally means, that you will be able to have first prototype of anything in seconds by just copying and pasting code • (you can
    [Show full text]
  • Ultimate++ Forum
    Subject: AngelScript - AngelCode Scripting Library Posted by Sender Ghost on Fri, 18 Nov 2011 09:37:26 GMT View Forum Message <> Reply to Message Homepage: http://www.angelcode.com/angelscript/ License: zlib Version: 2.30.0 (February 22nd, 2015) Description: The AngelCode Scripting Library, or AngelScript as it is also known, is an extremely flexible cross-platform scripting library designed to allow applications to extend their functionality through external scripts. It has been designed from the beginning to be an easy to use component, both for the application programmer and the script writer. Efforts have been made to let it call standard C functions and C++ methods with little to no need for proxy functions. The application simply registers the functions, objects, and methods that the scripts should be able to work with and nothing more has to be done with your code. The same functions used by the application internally can also be used by the scripting engine, which eliminates the need to duplicate functionality. For the script writer the scripting language follows the widely known syntax of C/C++, but without the need to worry about pointers and memory leaks. Contrary to most scripting languages, AngelScript uses the common C/C++ datatypes for more efficient communication with the host application. Documentation: http://www.angelcode.com/angelscript/documentation.html In the attachments you could find AngelScript source code, add-ons, samples, converted to U++ packages and documentation. To note: There were minor changes for include files for original sources to adapt for U++ package structure. Edit: Updated to 2.30.0 version.
    [Show full text]
  • 1. with Examples of Different Programming Languages Show How Programming Languages Are Organized Along the Given Rubrics: I
    AGBOOLA ABIOLA CSC302 17/SCI01/007 COMPUTER SCIENCE ASSIGNMENT ​ 1. With examples of different programming languages show how programming languages are organized along the given rubrics: i. Unstructured, structured, modular, object oriented, aspect oriented, activity oriented and event oriented programming requirement. ii. Based on domain requirements. iii. Based on requirements i and ii above. 2. Give brief preview of the evolution of programming languages in a chronological order. 3. Vividly distinguish between modular programming paradigm and object oriented programming paradigm. Answer 1i). UNSTRUCTURED LANGUAGE DEVELOPER DATE Assembly Language 1949 FORTRAN John Backus 1957 COBOL CODASYL, ANSI, ISO 1959 JOSS Cliff Shaw, RAND 1963 BASIC John G. Kemeny, Thomas E. Kurtz 1964 TELCOMP BBN 1965 MUMPS Neil Pappalardo 1966 FOCAL Richard Merrill, DEC 1968 STRUCTURED LANGUAGE DEVELOPER DATE ALGOL 58 Friedrich L. Bauer, and co. 1958 ALGOL 60 Backus, Bauer and co. 1960 ABC CWI 1980 Ada United States Department of Defence 1980 Accent R NIS 1980 Action! Optimized Systems Software 1983 Alef Phil Winterbottom 1992 DASL Sun Micro-systems Laboratories 1999-2003 MODULAR LANGUAGE DEVELOPER DATE ALGOL W Niklaus Wirth, Tony Hoare 1966 APL Larry Breed, Dick Lathwell and co. 1966 ALGOL 68 A. Van Wijngaarden and co. 1968 AMOS BASIC FranÇois Lionet anConstantin Stiropoulos 1990 Alice ML Saarland University 2000 Agda Ulf Norell;Catarina coquand(1.0) 2007 Arc Paul Graham, Robert Morris and co. 2008 Bosque Mark Marron 2019 OBJECT-ORIENTED LANGUAGE DEVELOPER DATE C* Thinking Machine 1987 Actor Charles Duff 1988 Aldor Thomas J. Watson Research Center 1990 Amiga E Wouter van Oortmerssen 1993 Action Script Macromedia 1998 BeanShell JCP 1999 AngelScript Andreas Jönsson 2003 Boo Rodrigo B.
    [Show full text]
  • A Classification of Scripting Systems for Entertainment and Serious
    Published in Proceedings of VS-GAMES 2011: 3rd International Conference on Games and Virtual Worlds for Serious Applications, pages 47-54; definitive version available from http://dx.doi.org/10.1109/VS-GAMES.2011.13 A Classification of Scripting Systems for Entertainment and Serious Computer Games Eike Falk Anderson Interactive Worlds ARG Coventry University Coventry, UK [email protected] Abstract—The technology base for modern computer games is usually provided by a game engine. Many game engines have built-in dedicated scripting languages that allow the development of complete games that are built using those engines, as well as extensive modification of existing games through scripting alone. While some of these game engines implement propri- etary languages, others use existing scripting systems that have been modified according to the game engine’s requirements. Scripting languages generally provide a very high level of abstraction method for syntactically controlling the behaviour of their host applications and different types of scripting system allow different types of modification of their underlying host application. In this paper we propose a simple classification for scripting systems used in computer games for entertainment and serious purposes. Index Terms—Data-Driven Game Development, Scripting Language Classification. Fig. 1. A typical game engine. If the engine core includes a scripting system, then application specific scripts are loaded as external game assets and there I. INTRODUCTION may be no other application specific code. The computer games industry is still a young industry which continues to have a lot of potential for growth. This is especially so, since games have broken out of the domain Consequently it is no surprise that scripting systems are of pure entertainment and are now used in a wide variety of considered one of the most important developer tools that are different situations.
    [Show full text]
  • Overload Journal 95
    OVERLOAD CONTENTS OVERLOAD 95 February 2010 Overload is a publication of ACCU ISSN 1354-3172 For details of ACCU, our publications Editor Ric Parkin and activities, visit the ACCU website: [email protected] www.accu.org Advisors Richard Blundell [email protected] Matthew Jones [email protected] 4 One Approach to Using Hardware Registers Alistair McDonald in C++ [email protected] Martin Moene encapsulates low level register access Roger Orr for testing. [email protected] Simon Sebright 12 The Model Student: A Game of Six Integers [email protected] (Part 1) Anthony Williams [email protected] Richard Harris analyses a popular game show. Advertising enquiries 19 Simplifying the C++/Angelscript Binding [email protected] Process Stuart Golodetz hooks in a scripting language. Cover art and design Pete Goodliffe 24 Quality Matters: Diagnostic Measures [email protected] Matthew Wilson investigates the recls library. Copy deadlines All articles intended for publication in Overload 96 should be submitted by 1st March 2010 and for Overload 97 by 1st May 2010. ACCU Copyrights and Trade Marks ACCU is an organisation of programmers Some articles and other contributions use terms that are either registered trade marks or claimed who care about professionalism in as such. The use of such terms is not intended to support nor disparage any trade mark claim. programming. That is, we care about On request we will withdraw all references to a specific trade mark and its owner. writing good code, and about writing it in By default, the copyright of all material published by ACCU is the exclusive property of the author.
    [Show full text]
  • C++ Best Practices
    C++ Best Practices Table of Contents Preface 0 Use the Tools Available 1 Style 2 Considering Safety 3 Considering Maintainability 4 Considering Portability 5 Considering Threadability 6 Considering Performance 7 Enable Scripting 8 Further Reading 9 Final Thoughts 10 2 C++ Best Practices Preface C++ Best Practices: A Forkable Coding Standards Document This document is meant to be a collaborative discussion of the best practices in C++. It complements books such as Effective C++ (Meyers) and C++ Coding Standards (Alexandrescu, Sutter). We fill in some of the lower level details that they don't discuss and provide specific stylistic recommendations while also discussing how to ensure overall code quality. In all cases brevity and succinctness is preferred. Examples are preferred for making the case for why one option is preferred over another. If necessary, words will be used. C++ Best Practices by Jason Turner is licensed under a Creative Commons Attribution- NonCommercial 4.0 International License. Disclaimer This document is based on my personal experiences. You are not supposed to agree with it 100%. It exists as a book on GitHub so that you can fork it for your own uses or submit back proposed changes for everyone to share. Preface 3 C++ Best Practices Use The Tools Available An automated framework for executing these tools should be established very early in the development process. It should not take more than 2-3 commands to checkout the source code, build, and execute the tests. Once the tests are done executing, you should have an almost complete picture of the state and quality of the code.
    [Show full text]
  • Quality Goal Oriented Architectural Design and Traceability for Evolvable Software Systems
    Quality Goal Oriented Architectural Design and Traceability for Evolvable Software Systems Dissertation zur Erlangung des akademischen Grades Doktor-Ingenieur (Dr.-Ing.) vorgelegt der Fakultät für Informatik und Automatisierung der Technischen Universität Ilmenau von Dipl.-Inf. Stephan Bode geboren am 5. Februar 1983 in Mühlhausen/Thüringen, Deutschland 1. Gutachter: PD Dr.-Ing. habil. Matthias Riebisch, TU Ilmenau 2. Gutachter: Prof. Dr.-Ing. Detlef Streitferdt (JP), TU Ilmenau 3. Gutachter: Prof. Dr. Wilhelm Hasselbring, Universität zu Kiel Datum der Einreichung: 2011/04/20 Datum der Verteidigung: 2011/09/22 urn:nbn:de:gbv:ilm1-2011000313 Zusammenfassung Softwaresysteme werden heute z. B. aufgrund sich ändernder Geschäftsprozesse oder Technologien mit häufigen Veränderungen konfrontiert. Die Software und speziell ihre Architektur muss diese Änderungen zur dauerhaften Nutzbarkeit ermöglichen. Während der Software-Evolution können Änderungen zu einer Verschlechterung der Architektur führen, der Architekturerosion. Dies erschwert oder verhindert wei- tere Änderungen wegen Inkonsistenz oder fehlendem Programmverstehen. Zur Ero- sionsvermeidung müssen Qualitätsziele wie Weiterentwickelbarkeit, Performanz oder Usability sowie die Nachvollziehbarkeit von Architekturentwurfsentscheidungen be- rücksichtigt werden. Dies wird jedoch oft vernachlässigt. Existierende Entwurfsmethoden unterstützen den Übergang von Qualitätzielen zu geeigneten Architekturlösungen nur unzureichend aufgrund einer Lücke zwischen Methoden des Requirements Engineering und
    [Show full text]
  • Programování Počítačových Her
    Inovace přednášky byla podpořena v rámci projektu OPPA CZ.2.17/3.1.00/33274 financovaného Evropským sociálním fondem a rozpočtem hlavního města Prahy. Praha & EU: investujeme do Vaší budoucnosti Programování počítačových her Práce v týmu, rozdělení rolí, práce na větším projektu Obsah • Kdo je to programátor? • Nástroje pro týmovou práci • Specifika většího projektu • Programování v praxi • Middleware • Skriptovací jazyky Kdo je to programátor? aneb Není to jen o renderování. Role • Vedoucí • Architekt • Senior • Junior • Programátor vs. Kodér Specifika • Rozmanitost • Složitost • Matematika • Datové struktury • Algoritmy • Důraz na bezpečnost a rychlost kódu Náplň práce • Návrh řešení problémů . Analýza • Implementace . Vlastní psaní kódu • Code review . Nikdo není neomylný • Opravy chyb / Optimalizace . Debugging Oblasti práce • Jádro . Každý chce pracovat na grafice. • Simulace . Skoro každý chce pracovat na fyzice. • Gameplay . Nikdo nechce dělat práci designéra. • Nástroje . Je to vůbec ještě o hrách? Výsledek práce • Renderer • Datové struktury . interakce • Playground pro designéry • Nástroje pro grafiky • Kdo má poslední slovo? . Programátor vs. Designér Nástroje pro týmový vývoj Co používají profesionální týmy Nástroje • IDE • Compiler a linker • Profiler • Správa verzí (Version control)‏ • Správa dat (Asset management)‏ • Bugtracker • Správa úkolů • Dokumentace/Wiki IDE • Editor, compiler, debugger • MS Visual Studio . nejrozšířenější . užitečné pluginy . nejlepší debugger . používá se i pro Xbox i pro PS3 . na druhou stranu podporuje závislost na kompilaci • Linuxové editory • Ostatní (Eclipse, Bloodshed Dev-C++)‏ Profiling a tuning • Měření rychlosti • Kontrola paměti • Komerční projekty . VTune, Gprof, Telemetry . Memory Validator, BoundsChecker, Valgrind • Nejlepší je vlastní . Profiler: Sean Barrett, Game Developer 08/04 . Vlastní memory manager Správa verzí • Řešení . CVS, SVN, git, Mercurial, SourceSafe • Aspekty . zamykání souborů (check in/out)‏ .
    [Show full text]
  • 'Game' Portability
    A Survey of ‘Game’ Portability Ahmed BinSubaih, Steve Maddock, and Daniela Romano Department of Computer Science University of Sheffield Regent Court, 211 Portobello Street, Sheffield, U.K. +44(0) 114 2221800 {A.BinSubaih, S.Maddock, D.Romano}@dcs.shef.ac.uk Abstract. Many games today are developed using game engines. This development approach supports various aspects of portability. For example games can be ported from one platform to another and assets can be imported into different engines. The portability aspect that requires further examination is the complexity involved in porting a 'game' between game engines. The game elements that need to be made portable are the game logic, the object model, and the game state, which together represent the game's brain. We collectively refer to these as the game factor, or G-factor. This work presents the findings of a survey of 40 game engines to show the techniques they provide for creating the G-factor elements and discusses how these techniques affect G-factor portability. We also present a survey of 30 projects that have used game engines to show how they set the G-factor. Keywords: game development, portability, game engines. 1 Introduction The shift in game development from developing games from scratch to using game engines was first introduced by Quake and marked the advent of the game- independent game engine development approach (Lewis & Jacobson, 2002). In this approach the game engine became “the collection of modules of simulation code that do not directly specify the game’s behaviour (game logic) or game’s environment (level data)” (Wang et al, 2003).
    [Show full text]
  • Configuration Pinocchio
    Configuration Pinocchio: The Lies Plainly Seen and the Quest to be a Real Discipline Andre P. Masella Ontario Institute for Cancer Research Abstract particularly Amazon Elastic Compute Cloud in 2006. As the layers of indirectly coupled components have The construction of configuration files has long been increased, the complexity of configurations have in- considered outside of the domain of “programming”. creased to match. As a central problem, the composabil- However, configuration files have a way of growing more ity of the configurations does not match the composabil- complex. There is a struggle between keeping a config- ity of the servers they describe. Moreover, the configu- uration terse, by having the system infer information au- rations of different servers operate in radically different tomatically, and explicit, without having excessive dupli- ways, each developing unique methods of propagating cation. Either the configuration file develops embedded default values and concisely expressing repetitive infor- domain-specific programming languages or a text-based mation. macro language is put in front. I will identify and catego- To build better configuration management software, rize patterns in the evolution of these programming lan- one must first understand the problem being solved. Con- guages and describe what kinds of patterns are needed to figuration seems simple enough: simply provide some avoid them. values to an application on start-up. Unfortunately, the reality is more nuanced. Firstly, the number of methods 1 Introduction for informing an application of its configuration is larger than expected. These include command line arguments, There has been a shift in the kinds of configurations writ- configuration files, environment variables, and values in ten.
    [Show full text]
  • Blue Cat's Plug'n Script User Manual
    Blue Cat's Plug'n Script User Manual "Craft your own effects and instruments" 1 Blue Cat's Plug'n Script User Manual Copyright (c) 2014-2021 Blue Cat Audio Table Of Content Introduction Description System Requirements Installation First Launch Using Blue Cat's Plug'n Script Introduction The User Interface Operation Scripting Tutorial Angelscript Scripting Reference AngelScript Version AngelScript Add- ons API Script Reference Advanced Scripting Topics Debugging Scripts Optimization and Best Practices Native Programming Tutorial Native Programming Reference API C + + Script Reference C Script Reference Customizing the User Interface Adding a User Manual Resources Standalone Application Basics Blue Cat Audio Plug- ins Basics User Interface Basics Controls Keyboard Mouse Presets Management MIDI & Automation Control More Blue Cat's Plug'n Script Parameters Input Output Plug- in Settings The Global Settings Window The Preset Settings Window About Skins Changing the Skin Create a Custom Skin More Extra Skins Tutorials Updates Versions History 2 Blue Cat's Plug'n Script User Manual Copyright (c) 2014-2021 Blue Cat Audio Note: An online version of this user manual is available here. 3 Blue Cat's Plug'n Script User Manual Copyright (c) 2014-2021 Blue Cat Audio Introduction Description Blue Cat's Plug'n Script is an audio and MIDI scripting plug- in and application that can be programmed to build custom effects or virtual instruments, without quitting your favorite DAW software. With this plug- in, you can write your own plug- in with very little knowledge about programming. If you do not care about programming, Blue Cat's Plug'n Script can also be used as a regular multi effects processor with existing scripts or to get someone else write this very particular utility you have been searching for years and cannot find anywhere.
    [Show full text]