https://wiki.scummvm.org/api.php?action=feedcontributions&user=Dsymonds&feedformat=atomScummVM :: Wiki - User contributions [en]2024-03-29T09:36:49ZUser contributionsMediaWiki 1.36.0https://wiki.scummvm.org/index.php?title=User:Dsymonds&diff=6168User:Dsymonds2007-05-28T01:40:37Z<p>Dsymonds: Update some details.</p>
<hr />
<div>{{User|<br />
handle=dsymonds|<br />
name=David Symonds|<br />
memberSince=6 Jan 2007|<br />
workingOn=[[AGI|AGI Engine]]|<br />
email=dsymonds _at_ scummvm _dot_ org<br />
}}<br />
<br />
<tt>dsymonds</tt> is a developer in the ScummVM Project, working on the AGI engine. He really hasn't done much recently because of (a) a PhD, (b) other projects, and (c) slackness.<br />
<br />
He can be contacted via email at: dsymonds _at_ scummvm _dot_ org<br />
<br />
--[[User:Dsymonds|dsymonds]] 22:59, 28 May 2007 (UTC)</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Space_Quest&diff=6011Space Quest2007-05-07T12:37:52Z<p>Dsymonds: /* Platform Compatibility */ spelling fix.</p>
<hr />
<div>{{GameDescription|<br />
name=Space Quest: The Sarien Encounter|<br />
image=[[Image:Space-Quest-1.png]]|<br />
release=1984|<br />
alternateNames=Space Quest I<br/>SQ, SQ1|<br />
publisher=[[Sierra]]|<br />
developer=[[Sierra]]|<br />
platforms=MS-DOS, Tandy 1000<br/> Mac, Apple II<br/> Apple IIGS, Amiga<br/> Atari ST, PCjr|<br />
engine=[[AGI]], SCI|<br />
support=Not officially supported.<br/>A WIP AGI engine is available<br/>in our SVN repository. The<br/>SCI version is not supported.<br />
}}<br />
'''Space Quest: The Sarien Encounter''' was the first game in the [[Space Quest series]]. The game follows a janitor on board the scientific spaceship Arcada. After waking from an on-duty nap in a broom closet, he discovers that an evil alien race called the Sariens stole the Star Generator, an experimental weapon that was being held on board, and killed all of the Arcada's crew members.<br />
<br />
After crash landing on the planet Kerona, Roger must find a way to sneak aboard the the Sarien starship Deltaur to stop the vicious aliens from using the Star Generator against Roger's home planet of Xenon.<br />
<br />
==Requirements==<br />
Disk Space: 548 KB<br/><br />
Memory Requirements: 512k of RAM<br />
<br />
==Game Variants==<br />
The MS-DOS, Apple II, Apple IIGS, Atari ST, Tandy 1000, and PCjr versions are similar in terms of graphics. The Amiga version used an extended palette.<br />
<br />
==Data Files==<br />
All of the files required for Space Quest to run<br />
<br />
LOGDIR<br/><br />
PICDIR<br/><br />
SNDDIR<br/><br />
VIEWDIR<br/><br />
OBJECT<br/><br />
VOL.*<br/><br />
WORDS.TOK<br />
<br />
==Platform Compatibility==<br />
List of platforms where Space Quest is known to work / not to work<br />
<br />
{| border="0"<br />
|-<br />
|Legend:<br />
|-<br />
|style="background:lightgreen;width:100px"|Completable<br />
|-<br />
|style="background:#ffff77;width:100px"|Not Completable<br />
|-<br />
|style="background:#ff7777;width:100px"|Doesn't Work<br />
|-<br />
|}<br />
<br />
{| border="1" cellpadding="2" width=100%<br />
|+Space Quest Compatibility by Platform<br />
|- style="background:silver"<br />
|Platform||Game Version||Status<br />
|- style="background:lightgreen"<br />
|Windows||MS-DOS||Completable with minor glitches<br />
|-<br />
|}<br />
<br />
==External links==<br />
*[http://en.wikipedia.org/wiki/Space_Quest_I:_The_Sarien_Encounter Wikipedia article on Space Quest]<br />
*[http://www.sq7.org/omnipedia/index.php/Category:SQ1 Omnipedia article on Space Quest]<br />
<br />
[[Category:AGI Games]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=AGI/Specifications/Introduction&diff=5800AGI/Specifications/Introduction2007-04-05T14:15:27Z<p>Dsymonds: Put in my real name</p>
<hr />
<div><span id="Introduction"></span><br />
=Introduction=<br />
<br />
AGI (Adventure Game Interpreter) was the first major interpreter used by Sierra. With the release of King's Quest 1 in the early 80's, it introduced the gaming world to the concept of a 3D graphical adventure game, where the player could move a character around the screen, behind, in front of and over objects. Other commands could be typed in, just like a text adventure. This concept, in various forms, has been used many many times since, by Sierra and other companies such as Lucas Arts. It has proved very successful and continues to be used today in games such as Larry 7.<br />
<br />
<span id="About"></span><br />
==About this document==<br />
<br />
The latest version of this document can be found at http://wiki.scummvm.org/index.php/AGI/Specifications.<br />
<br />
If you have any questions about the individual sections in this document, use the "Discussion" page of that section.<br />
<br />
If you have documented an aspect of the interpreter, or have updated your documentation which is already included this document, please send it to the ScummVM team ([http://scummvm.org/contact.php contact information]) so that it can be added in future versions.<br />
<br />
<span id="Audience"></span><br />
<br />
==Audience==<br />
<br />
AGI specs is intended for people writing AGI programs such as editors, viewers and interpreters. It is not supposed to be a beginners' introduction to AGI, or a LOGIC programming guide for those who just want to create games (although it can serve as a reference for more advanced LOGIC programmers). If you want to learn the LOGIC programming language, we suggest you read the logic section of the AGI Studio help file, and the various other bits of documentation and tutorials available on-line. The programming info contained in this document is mostly from the AGDS package and uses different syntax and terminology for the language and can be confusing if you are using AGI Studio for your programming.<br />
<br />
<br />
<span id="Conventions"></span><br />
==Conventions used in this document==<br />
<br />
* Keyboard key names are given in fixed with font (e.g. ENTER).<br />
* Metasyntatic variables are given in italics (e.g. n).<br />
* File names are case sensitive and given in fixed width font (e.g. sierra.com).<br />
* AGI resource names are given in all caps (e.g. LOGIC, VIEW).<br />
* AGI command names are given in fixed width font (e.g. print.at).<br />
* AGI variable n is noted as vn or Var(n) (e.g. v15, Var(18)).<br />
* AGI flag n is noted as fn or Flag(n) (e.g. f2, Flag(11)).<br />
<br />
<span id="WhatsStillMissing"></span><br />
==What's still missing==<br />
<br />
Although this document has many details about the AGI specs, a few pieces of information are still missing:<br />
<br />
* Savegame file format<br />
* Some chunks of the memory organization<br />
* Unknown view table entries<br />
* Unknown fields in the IIgs sound header<br />
* The release date of many AGI games<br />
* The purpose of commands 171, 172 and 174<br />
* The meaning of bit 0 in the argument byte<br />
* The meaning of bytes 0--1 in the VIEW resource header<br />
* Canonical names of commands 170--181<br />
* Canonical variable and flag names<br />
* More information about differences of AGI in other platforms (Amiga, Apple II, CoCo, etc)<br />
* Any information about Donald Duck's Playground<br />
<br />
<span id="ChangeLog"></span><br />
==Change Log==<br />
===Version 3.1 (6 January 2007)===<br />
* Added note about control lines and priority screen pixel scanning.<br />
<br />
===Version 3.0 (22 May 1999)===<br />
<br />
* Documentation converted to SGML, to allow easy conversion to other formats such as HTML, LaTeX, GNU info or plain text.<br />
* Typos fixed.<br />
* Removed redundant pieces of information.<br />
* Re-organized and re-ordered sections; added credits, audience and notation subsections.<br />
* Adopted uniform notation (all code examples and function names in fixed width font, hexadecimal numbers, characters and strings in C format, case sensitive file names)<br />
* "Version control" section renamed "AGI interpreter versions".<br />
* Removed sort-by-date and interpreter version cross-reference from "AGI interpreter versions".<br />
* Added cross-references in the LOGIC commands description.<br />
* Added unknown170--unknown181 command descriptions written by Dark Minister.<br />
* Added IIgs SOUND resource format<br />
* Added some bits of information to addn, step.size and other commands.<br />
<br />
===Version 2.0 (11 July 1998)===<br />
<br />
* Date corrected in section "Game IDs".<br />
* Added a note on the main page explaining what AGI specs is for. Hopefully this will reduce the confusion that some people have been having when using this to learn the logic programming language.<br />
<br />
====3 March 1998====<br />
<br />
* Updated section "Game IDs" with some more info about game IDs and interpreter encryption.<br />
* Corrected put and put.v commands in section Command list (the second argument of put and the first argument of put.v are supposed to be a vars).<br />
<br />
====27 January 1998====<br />
<br />
* Removed sections 4.2 (logic structure), 3.4 (dir/vol file format), 6.2 (view format), 8.2 (OBJECT format) and 8.3 (WORDS.TOK format). These were sections from the AGDS documentation which contained basically the same information as other more recent documentation in AGI specs. Section numbers above those removed have been moved down.<br />
* Added sections "LOGIC syntax" and "Command list and argument types".<br />
* Replaced sections "How the interpreter works" and "PICTURE resource format" with a better translations.<br />
* Added more info about the AGDS package in section "The AGDS package".<br />
* Updated section "Websites and people"<br />
* Corrected the title of section "Version 3 resource storage".<br />
* Updated the URL for the windows help version of AGI specs in section "Introduction".<br />
* Fixed up a small formatting error in section "Version differences" (the header for one of the tables was repeated so it was removed).<br />
<br />
====5 December 1997====<br />
<br />
* Info about windows help version added to section 1.1.<br />
* Corrections made to info on brush patterns in picture documentation (section 5.1).<br />
* Fixed up some small formatting errors in sections 3.4, 3.5, 4.3 and 8.4.<br />
<br />
====5 October 1997====<br />
<br />
* Section 2.7 (version control) updated.<br />
* Section 6.1 (View format) updated.<br />
<br />
====16 September 1997====<br />
<br />
* I forgot to add the version differences section when I converted all the documentation to HTML. It's there now.<br />
* Fixed some problems in the index in section 3.x.<br />
<br />
====31 August 1997====<br />
<br />
* AGI specs is now available!<br />
* A not about the dates on documents: almost all of the original ASCII text versions of these documents did not have a date on them, so I have put the "last updated" date to be 31 August 1997, which is when they first appeared in the HTML version of AGI Specs.<br />
<br />
<br />
<span id="Credits"></span><br />
<br />
==Credits==<br />
<br />
The following people (and probably more) have contributed to this document. Please contact the document maintainer to add more names to this list.<br />
<br />
* Peter Kelly<br />
* Lance Ewing<br />
* Alex Simkin<br />
* Vassili Bykov<br />
* Anders M. Olsson<br />
* Jeremy Hayes<br />
* Joakim Möller<br />
* Martin Tillenius<br />
* Stuart George<br />
* Dark Minister<br />
* Kevin A. Lee<br />
* Jens Christian Restemeier<br />
* Paul Lunga<br />
* Ian Schmidt<br />
* David Symonds<br />
* Claudio Matsuoka</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Summer_of_Code/Application/2007&diff=5614Summer of Code/Application/20072007-03-07T22:37:09Z<p>Dsymonds: /* About ScummVM */ grammar tweaks</p>
<hr />
<div>== Introduction & overview ==<br />
<br />
This is the application of the [http://www.scummvm.org ScummVM] project for the [http://code.google.com/soc Google Summer of Code]. Let's start with a quick overview of the facts before turning to the more elaborate parts of this document.<br />
<br />
{| cellpadding="3"<br />
|Project: || [http://www.scummvm.org ScummVM]<br />
|-<br />
|Participation in prior SoCs: || None<br />
|-<br />
|Applications for prior SoCs: || None<br />
|-<br />
|Organization administrator: || fingolfin (max AT quendi.de)<br />
|-<br />
|Backup administrator: || sev (sev.mail AT gmail.com)<br />
|-<br />
|Project License: || GPL<br />
|-<br />
|Ideas page: || [[OpenTasks]]<br />
|-<br />
|IRC channel: || #scummvm on irc.freenode.net<br />
|-<br />
|Development mailing list: || https://lists.sourceforge.net/lists/listinfo/scummvm-devel<br />
|-<br />
|Mentors: ||<br />
* [[User:Fingolfin|Max Horn]], Google Account: max AT quendi.de<br />
* [[User:Jubanka|Kostas Nakos]], Google Account: knakos AT gmail.com<br />
* [[User:Sev|Eugene Sandulenko]], Google Account: sev.mail AT gmail.com<br />
|}<br />
<br />
== About ScummVM ==<br />
<br />
The ScummVM project aims to allow users to run on modern hardware a variety of commercially available graphical point-and-click adventure games including Monkey Island, Simon the Sorcerer, Space Quest, and many more. To this end, ScummVM features a complete reimplementation of each supported game engine (Virtual Machine - VM) in a structured fashion using the C++ language. The development team works by either reverse engineering game executables (usually with the permission of creators of the game), or by using the original source code of the games provided by the creators. The number of engines is constantly growing thanks to a very agile and diversified development team.<br />
<br />
The VM approach followed by ScummVM results in efficient code, which has been ported to numerous Operating Systems. Besides running on all mainstream desktop environments, namely Windows, Mac OS X and most Unix variants (Linux, *BSD, Solaris, ...), ScummVM works on popular game consoles (Nintendo DS, PlayStation 2, PlayStation Portable and more), smart phones and PDAs (WinCE, PalmOS or Symbian based), and even on many not-so-mainstream systems (like BeOS, AmigaOS or OS/2).<br />
<br />
ScummVM's high portability is a direct consequence of the flexible and modular structure of its architecture, which can be roughly divided into the following three major categories: <br />
# Backends, which are responsible for supporting specific target devices, like PalmOS or WinCE,<br />
# Engines, also called front ends internally, contain the actual game specific (VM) code, and<br />
# Infrastructure code, which provides easy and portable baseline functionality, such as access to audio (including MIDI), graphics, user input, data access, a custom graphical user interface, and more.<br />
<br />
The large team of developers is split in groups which focus in different aspects of the architecture, in a manner derived from the above mentioned categorization. The team members are often not strictly confined to their respective group. Developers may assume different roles in several teams. Currently, the developers are split in the following subteams:<br />
* Porters: Responsible for a specific ScummVM port.<br />
* Engine authors: Responsible for a specific game engine and its associated bug reports (support).<br />
* Infrastructure development: Includes for example developers working on MIDI code, on the built-in custom GUI, etc.<br />
* Packagers: Not all ports require dedicated backends. For example our SDL backend is highly portable, but it still requires somebody to test and compile it. Packagers execute this function.<br />
* Documentation / web site management<br />
* Project leads: There are currently three project leads. They all are also represented in one of the above categories, but besides this they organize and coordinate things, make decisions, solve disputes etc.<br />
<br />
All of this enables us to be highly productive in a team of about 30 currently active developers (out of an all-time pool of over 60), who work together on a codebase exceeding 600,000 lines of code. In addition we have many non-developer contributors, and a huge and highly active community. We are among the most active projects hosted on sourceforge.net with well over 100,000 monthly downloads and ~9 million project web hits per month.<br />
<br />
== What we hope to gain ==<br />
For one thing, we hope to attract new blood: we hope to gain some new active developers via these projects. While we already have several very active contributors, these people are already mostly busy in specific subprojects and tasks. New people mean new ideas, new energy, and new ways of thinking. Therefore, a longer lasting engagement of our student contributors would be our highest hope.<br />
<br />
Furthermore, all of our developers work on ScummVM in their spare time. But for some tasks, it's most effective if you can spend a certain block of time working on this task exclusively; just what we would get via the SoC.<br />
Hence, we hope to gain some nice shiny new code providing useful new functionality to our users and developers. Even if the authors don't stick around, this will benefit all of the ScummVM community.<br />
<br />
Lastly, we also believe that we can learn a lot from this whole event in terms of interaction with prospective new team members, how to motivate students to participate in our projects, and so forth: knowledge that may turn out to be very valuable outside of the SoC, too.<br />
<br />
== Our mentors ==<br />
Our mentors were selected as volunteers from the development team who are already intimately familiar with the internals of ScummVM, our coding conventions etc.. All three are familiar with guiding people (in particular, students) through project work effectively (in fact, two of them happen to be lead developers of ScummVM). As such, we are convinced that we are able to guide interested students through the Summer of Code to the net benefit of all involved parties.<br />
<br />
== How we will deal with participants 'missing in action' ==<br />
We hope that nobody will disappear, but we plan to take a proactive approach, i.e., we will try to minimize the risk of a loss of communication, but if it happens, we are prepared to deal with it, too.<br />
<br />
For the mentors, the risk is relatively low; two are project leads and are reachable virtually 24/7 (in case of emergencies). We all have exchanged sufficient contact information (including cell phone numbers etc.) to be able to discover our whereabouts etc. Should something really bad happen (like somebody ending up in hospital and hence unable to work, a natural disaster, etc.), we will attempt to shift students to new mentors (among the existing mentors, or drawn from our backup pool of mentors). This will depend on the number of students we have to mentor.<br />
<br />
As for the students, for starters we plan to exchange as much communication data as possible (cell phone numbers, postal addresses etc.). Through a friendly atmosphere we hope to minimize the risk of any student being "afraid" to report problems they might have etc.. On the other hand, we will make it clear that we expect dedicated work of the students and that unannounced/unjustified disappearances will draw consequences, like negative reports or even the failure of the whole project. Still, establishing a positive and friendly connection between student and mentor will be the cornerstone of our efforts in this regard. If the student trusts the mentor and tells him about his fear, uncertainties and problems early on, they can try to find a solution together, possibly with the help of the rest of the team. Also, integrating the students into our community should reduce the likelihood of disappearances further (see also the next section).<br />
<br />
A common cause (we believe, based on our own experiences as students *g*) is a lack of structure in the assigned work, resp. an inability of the student to make real progress. To avoid this, we will request that students come up with a (realistic) project plan / schedule. The mentors will watch the progress with the students and discuss it with them regularly (at least weekly). We hope to detect potential problems early on this way, thus being able to help the students get around them, to the benefit of all.<br />
<br />
If all fails, though, and a student really vanishes completely, we will have to deal with the consequences, just like with regular projects in a company. Projects *can* fail, after all, no matter how hard you try to avoid it.<br />
<br />
== Integrating students with the community ==<br />
Our community uses forums, IRC, a Wiki and our mailing list for a vivid exchange of thoughts all the time. We will urge the students to participate in all of them; especially on IRC can they directly talk to many nice and helpful team and community members. The mentors will introduce the students to the rest of the team (making sure everybody knows who the students are). There are people active in the IRC channel virtually 24/7, thanks to the international nature of the project.<br />
<br />
We also expect the students to talk to non-mentor team members on a regular basis about parts of ScummVM for which these team members are experts (if these parts happen to be relevant for the student's project). To achieve that, the mentors will specifically introduce them to each other, and will try to encourage them to work together.<br />
<br />
== Student application template ==<br />
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].<br />
<br />
* '''Name'''<br />
* '''Email'''<br />
* '''Project Title'''<br />
* '''Possible Mentor''' (optional)<br />
* '''Benefits to the ScummVM Community''' - a good project will not just be fun to work on, but also generally useful to others.<br />
* '''Deliverables''' - It is very important to list quantifiable results here e.g.<br />
** "Improve X modules in ways Y and Z."<br />
** "Write 3 new man pages for the new interfaces."<br />
** "Improve test coverage by writing X more unit/regression tests."<br />
** "Improve performance in FOO by X%."<br />
* '''Project Schedule''' - How long will the project take? When can you begin work?<br />
* '''Availability''' - How many hours per week can you spend working on this? What other obligations do you have this summer?<br />
* '''Bio''' - Who are you? What makes you the best person to work on this project?</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Summer_of_Code/Application/2007&diff=5613Summer of Code/Application/20072007-03-07T22:36:02Z<p>Dsymonds: /* About ScummVM */ "9 millions" -> "9 million"</p>
<hr />
<div>== Introduction & overview ==<br />
<br />
This is the application of the [http://www.scummvm.org ScummVM] project for the [http://code.google.com/soc Google Summer of Code]. Let's start with a quick overview of the facts before turning to the more elaborate parts of this document.<br />
<br />
{| cellpadding="3"<br />
|Project: || [http://www.scummvm.org ScummVM]<br />
|-<br />
|Participation in prior SoCs: || None<br />
|-<br />
|Applications for prior SoCs: || None<br />
|-<br />
|Organization administrator: || fingolfin (max AT quendi.de)<br />
|-<br />
|Backup administrator: || sev (sev.mail AT gmail.com)<br />
|-<br />
|Project License: || GPL<br />
|-<br />
|Ideas page: || [[OpenTasks]]<br />
|-<br />
|IRC channel: || #scummvm on irc.freenode.net<br />
|-<br />
|Development mailing list: || https://lists.sourceforge.net/lists/listinfo/scummvm-devel<br />
|-<br />
|Mentors: ||<br />
* [[User:Fingolfin|Max Horn]], Google Account: max AT quendi.de<br />
* [[User:Jubanka|Kostas Nakos]], Google Account: knakos AT gmail.com<br />
* [[User:Sev|Eugene Sandulenko]], Google Account: sev.mail AT gmail.com<br />
|}<br />
<br />
== About ScummVM ==<br />
<br />
The ScummVM project aims to allow users to run on modern hardware a variety of commercially available graphical point-and-click adventure games including Monkey Island, Simon the Sorcerer, Space Quest, and many more. To this end, ScummVM features a complete reimplementation of each supported game engine (Virtual Machine - VM) in a structured fashion using the C++ language. The development team works by either reverse engineering game executables (usually with the permission of creators of the game), or by using the original source code of the games provided by the creators. The number of engines is constantly growing thanks to a very agile and diversified development team.<br />
<br />
The VM approach followed by ScummVM results in efficient code, which has been ported to numerous Operating Systems. Besides running on all mainstream desktop environments, namely Windows, Mac OS X and most Unix variants (Linux, *BSD, Solaris, ...), ScummVM works on popular game consoles (Nintendo DS, PlayStation 2, PlayStation Portable and more), smart phones and PDAs (WinCE, PalmOS or Symbian based), and even on many not-so-mainstream systems (like BeOS, AmigaOS or OS/2).<br />
<br />
ScummVM's high portability is a direct consequence of the flexible and modular structure of its architecture, which can be roughly divided into the following three major categories: <br />
# Backends, which are responsible for supporting specific target devices, like PalmOS or WinCE,<br />
# Engines, also called front ends internally, contain the actual game specific (VM) code, and<br />
# Infrastructure code, which provides easy and portable baseline functionality, such as access to audio (including MIDI), graphics, user input, data access, a custom graphical user interface, and more.<br />
<br />
The large team of developers is split in groups which focus in different aspects of the architecture, in a manner derived from the above mentioned categorization. The team members are often not strictly confined to their respective group. Developers may assume different roles in several teams. Currently, the developers are split in the following subteams:<br />
* Porters: Responsible for a specific ScummVM port.<br />
* Engine authors: Responsible for a specific game engine and its associated bug reports (support).<br />
* Infrastructure development: Includes for example developers working on MIDI code, on the built-in custom GUI, etc.<br />
* Packagers: Not all ports require dedicated backends. For example our SDL backend is highly portable, but it still requires somebody to test and compile it. Packagers execute this function.<br />
* Documentation / web site management<br />
* Project leads: There are currently three project leads. They all are also represented in one of the above categories, but besides this they organize and coordinate things, make decisions, solve disputes etc.<br />
<br />
All of this enables us to be highly productive in a team of about 30 currently active developers (out of an all time pool of well over 60), who work together on a codebase exceeding 600,000 LOC. In addition we have many non-developer contributors, and a huge and highly active community. We are among the most active projects hosted on sourceforge.net with well over 100,000 monthly downloads and ~9 million project web hits per month.<br />
<br />
== What we hope to gain ==<br />
For one thing, we hope to attract new blood: we hope to gain some new active developers via these projects. While we already have several very active contributors, these people are already mostly busy in specific subprojects and tasks. New people mean new ideas, new energy, and new ways of thinking. Therefore, a longer lasting engagement of our student contributors would be our highest hope.<br />
<br />
Furthermore, all of our developers work on ScummVM in their spare time. But for some tasks, it's most effective if you can spend a certain block of time working on this task exclusively; just what we would get via the SoC.<br />
Hence, we hope to gain some nice shiny new code providing useful new functionality to our users and developers. Even if the authors don't stick around, this will benefit all of the ScummVM community.<br />
<br />
Lastly, we also believe that we can learn a lot from this whole event in terms of interaction with prospective new team members, how to motivate students to participate in our projects, and so forth: knowledge that may turn out to be very valuable outside of the SoC, too.<br />
<br />
== Our mentors ==<br />
Our mentors were selected as volunteers from the development team who are already intimately familiar with the internals of ScummVM, our coding conventions etc.. All three are familiar with guiding people (in particular, students) through project work effectively (in fact, two of them happen to be lead developers of ScummVM). As such, we are convinced that we are able to guide interested students through the Summer of Code to the net benefit of all involved parties.<br />
<br />
== How we will deal with participants 'missing in action' ==<br />
We hope that nobody will disappear, but we plan to take a proactive approach, i.e., we will try to minimize the risk of a loss of communication, but if it happens, we are prepared to deal with it, too.<br />
<br />
For the mentors, the risk is relatively low; two are project leads and are reachable virtually 24/7 (in case of emergencies). We all have exchanged sufficient contact information (including cell phone numbers etc.) to be able to discover our whereabouts etc. Should something really bad happen (like somebody ending up in hospital and hence unable to work, a natural disaster, etc.), we will attempt to shift students to new mentors (among the existing mentors, or drawn from our backup pool of mentors). This will depend on the number of students we have to mentor.<br />
<br />
As for the students, for starters we plan to exchange as much communication data as possible (cell phone numbers, postal addresses etc.). Through a friendly atmosphere we hope to minimize the risk of any student being "afraid" to report problems they might have etc.. On the other hand, we will make it clear that we expect dedicated work of the students and that unannounced/unjustified disappearances will draw consequences, like negative reports or even the failure of the whole project. Still, establishing a positive and friendly connection between student and mentor will be the cornerstone of our efforts in this regard. If the student trusts the mentor and tells him about his fear, uncertainties and problems early on, they can try to find a solution together, possibly with the help of the rest of the team. Also, integrating the students into our community should reduce the likelihood of disappearances further (see also the next section).<br />
<br />
A common cause (we believe, based on our own experiences as students *g*) is a lack of structure in the assigned work, resp. an inability of the student to make real progress. To avoid this, we will request that students come up with a (realistic) project plan / schedule. The mentors will watch the progress with the students and discuss it with them regularly (at least weekly). We hope to detect potential problems early on this way, thus being able to help the students get around them, to the benefit of all.<br />
<br />
If all fails, though, and a student really vanishes completely, we will have to deal with the consequences, just like with regular projects in a company. Projects *can* fail, after all, no matter how hard you try to avoid it.<br />
<br />
== Integrating students with the community ==<br />
Our community uses forums, IRC, a Wiki and our mailing list for a vivid exchange of thoughts all the time. We will urge the students to participate in all of them; especially on IRC can they directly talk to many nice and helpful team and community members. The mentors will introduce the students to the rest of the team (making sure everybody knows who the students are). There are people active in the IRC channel virtually 24/7, thanks to the international nature of the project.<br />
<br />
We also expect the students to talk to non-mentor team members on a regular basis about parts of ScummVM for which these team members are experts (if these parts happen to be relevant for the student's project). To achieve that, the mentors will specifically introduce them to each other, and will try to encourage them to work together.<br />
<br />
== Student application template ==<br />
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].<br />
<br />
* '''Name'''<br />
* '''Email'''<br />
* '''Project Title'''<br />
* '''Possible Mentor''' (optional)<br />
* '''Benefits to the ScummVM Community''' - a good project will not just be fun to work on, but also generally useful to others.<br />
* '''Deliverables''' - It is very important to list quantifiable results here e.g.<br />
** "Improve X modules in ways Y and Z."<br />
** "Write 3 new man pages for the new interfaces."<br />
** "Improve test coverage by writing X more unit/regression tests."<br />
** "Improve performance in FOO by X%."<br />
* '''Project Schedule''' - How long will the project take? When can you begin work?<br />
* '''Availability''' - How many hours per week can you spend working on this? What other obligations do you have this summer?<br />
* '''Bio''' - Who are you? What makes you the best person to work on this project?</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Summer_of_Code/Application/2007&diff=5612Summer of Code/Application/20072007-03-07T22:35:23Z<p>Dsymonds: /* About ScummVM */ re-work some grammar for clarity</p>
<hr />
<div>== Introduction & overview ==<br />
<br />
This is the application of the [http://www.scummvm.org ScummVM] project for the [http://code.google.com/soc Google Summer of Code]. Let's start with a quick overview of the facts before turning to the more elaborate parts of this document.<br />
<br />
{| cellpadding="3"<br />
|Project: || [http://www.scummvm.org ScummVM]<br />
|-<br />
|Participation in prior SoCs: || None<br />
|-<br />
|Applications for prior SoCs: || None<br />
|-<br />
|Organization administrator: || fingolfin (max AT quendi.de)<br />
|-<br />
|Backup administrator: || sev (sev.mail AT gmail.com)<br />
|-<br />
|Project License: || GPL<br />
|-<br />
|Ideas page: || [[OpenTasks]]<br />
|-<br />
|IRC channel: || #scummvm on irc.freenode.net<br />
|-<br />
|Development mailing list: || https://lists.sourceforge.net/lists/listinfo/scummvm-devel<br />
|-<br />
|Mentors: ||<br />
* [[User:Fingolfin|Max Horn]], Google Account: max AT quendi.de<br />
* [[User:Jubanka|Kostas Nakos]], Google Account: knakos AT gmail.com<br />
* [[User:Sev|Eugene Sandulenko]], Google Account: sev.mail AT gmail.com<br />
|}<br />
<br />
== About ScummVM ==<br />
<br />
The ScummVM project aims to allow users to run on modern hardware a variety of commercially available graphical point-and-click adventure games including Monkey Island, Simon the Sorcerer, Space Quest, and many more. To this end, ScummVM features a complete reimplementation of each supported game engine (Virtual Machine - VM) in a structured fashion using the C++ language. The development team works by either reverse engineering game executables (usually with the permission of creators of the game), or by using the original source code of the games provided by the creators. The number of engines is constantly growing thanks to a very agile and diversified development team.<br />
<br />
The VM approach followed by ScummVM results in efficient code, which has been ported to numerous Operating Systems. Besides running on all mainstream desktop environments, namely Windows, Mac OS X and most Unix variants (Linux, *BSD, Solaris, ...), ScummVM works on popular game consoles (Nintendo DS, PlayStation 2, PlayStation Portable and more), smart phones and PDAs (WinCE, PalmOS or Symbian based), and even on many not-so-mainstream systems (like BeOS, AmigaOS or OS/2).<br />
<br />
ScummVM's high portability is a direct consequence of the flexible and modular structure of its architecture, which can be roughly divided into the following three major categories: <br />
# Backends, which are responsible for supporting specific target devices, like PalmOS or WinCE,<br />
# Engines, also called front ends internally, contain the actual game specific (VM) code, and<br />
# Infrastructure code, which provides easy and portable baseline functionality, such as access to audio (including MIDI), graphics, user input, data access, a custom graphical user interface, and more.<br />
<br />
The large team of developers is split in groups which focus in different aspects of the architecture, in a manner derived from the above mentioned categorization. The team members are often not strictly confined to their respective group. Developers may assume different roles in several teams. Currently, the developers are split in the following subteams:<br />
* Porters: Responsible for a specific ScummVM port.<br />
* Engine authors: Responsible for a specific game engine and its associated bug reports (support).<br />
* Infrastructure development: Includes for example developers working on MIDI code, on the built-in custom GUI, etc.<br />
* Packagers: Not all ports require dedicated backends. For example our SDL backend is highly portable, but it still requires somebody to test and compile it. Packagers execute this function.<br />
* Documentation / web site management<br />
* Project leads: There are currently three project leads. They all are also represented in one of the above categories, but besides this they organize and coordinate things, make decisions, solve disputes etc.<br />
<br />
All of this enables us to be highly productive in a team of about 30 currently active developers (out of an all time pool of well over 60), who work together on a codebase exceeding 600,000 LOC. In addition we have many non-developer contributors, and a huge and highly active community. We are among the most active projects hosted on sourceforge.net with well over 100,000 monthly downloads and ~9 millions project web hits per month.<br />
<br />
== What we hope to gain ==<br />
For one thing, we hope to attract new blood: we hope to gain some new active developers via these projects. While we already have several very active contributors, these people are already mostly busy in specific subprojects and tasks. New people mean new ideas, new energy, and new ways of thinking. Therefore, a longer lasting engagement of our student contributors would be our highest hope.<br />
<br />
Furthermore, all of our developers work on ScummVM in their spare time. But for some tasks, it's most effective if you can spend a certain block of time working on this task exclusively; just what we would get via the SoC.<br />
Hence, we hope to gain some nice shiny new code providing useful new functionality to our users and developers. Even if the authors don't stick around, this will benefit all of the ScummVM community.<br />
<br />
Lastly, we also believe that we can learn a lot from this whole event in terms of interaction with prospective new team members, how to motivate students to participate in our projects, and so forth: knowledge that may turn out to be very valuable outside of the SoC, too.<br />
<br />
== Our mentors ==<br />
Our mentors were selected as volunteers from the development team who are already intimately familiar with the internals of ScummVM, our coding conventions etc.. All three are familiar with guiding people (in particular, students) through project work effectively (in fact, two of them happen to be lead developers of ScummVM). As such, we are convinced that we are able to guide interested students through the Summer of Code to the net benefit of all involved parties.<br />
<br />
== How we will deal with participants 'missing in action' ==<br />
We hope that nobody will disappear, but we plan to take a proactive approach, i.e., we will try to minimize the risk of a loss of communication, but if it happens, we are prepared to deal with it, too.<br />
<br />
For the mentors, the risk is relatively low; two are project leads and are reachable virtually 24/7 (in case of emergencies). We all have exchanged sufficient contact information (including cell phone numbers etc.) to be able to discover our whereabouts etc. Should something really bad happen (like somebody ending up in hospital and hence unable to work, a natural disaster, etc.), we will attempt to shift students to new mentors (among the existing mentors, or drawn from our backup pool of mentors). This will depend on the number of students we have to mentor.<br />
<br />
As for the students, for starters we plan to exchange as much communication data as possible (cell phone numbers, postal addresses etc.). Through a friendly atmosphere we hope to minimize the risk of any student being "afraid" to report problems they might have etc.. On the other hand, we will make it clear that we expect dedicated work of the students and that unannounced/unjustified disappearances will draw consequences, like negative reports or even the failure of the whole project. Still, establishing a positive and friendly connection between student and mentor will be the cornerstone of our efforts in this regard. If the student trusts the mentor and tells him about his fear, uncertainties and problems early on, they can try to find a solution together, possibly with the help of the rest of the team. Also, integrating the students into our community should reduce the likelihood of disappearances further (see also the next section).<br />
<br />
A common cause (we believe, based on our own experiences as students *g*) is a lack of structure in the assigned work, resp. an inability of the student to make real progress. To avoid this, we will request that students come up with a (realistic) project plan / schedule. The mentors will watch the progress with the students and discuss it with them regularly (at least weekly). We hope to detect potential problems early on this way, thus being able to help the students get around them, to the benefit of all.<br />
<br />
If all fails, though, and a student really vanishes completely, we will have to deal with the consequences, just like with regular projects in a company. Projects *can* fail, after all, no matter how hard you try to avoid it.<br />
<br />
== Integrating students with the community ==<br />
Our community uses forums, IRC, a Wiki and our mailing list for a vivid exchange of thoughts all the time. We will urge the students to participate in all of them; especially on IRC can they directly talk to many nice and helpful team and community members. The mentors will introduce the students to the rest of the team (making sure everybody knows who the students are). There are people active in the IRC channel virtually 24/7, thanks to the international nature of the project.<br />
<br />
We also expect the students to talk to non-mentor team members on a regular basis about parts of ScummVM for which these team members are experts (if these parts happen to be relevant for the student's project). To achieve that, the mentors will specifically introduce them to each other, and will try to encourage them to work together.<br />
<br />
== Student application template ==<br />
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].<br />
<br />
* '''Name'''<br />
* '''Email'''<br />
* '''Project Title'''<br />
* '''Possible Mentor''' (optional)<br />
* '''Benefits to the ScummVM Community''' - a good project will not just be fun to work on, but also generally useful to others.<br />
* '''Deliverables''' - It is very important to list quantifiable results here e.g.<br />
** "Improve X modules in ways Y and Z."<br />
** "Write 3 new man pages for the new interfaces."<br />
** "Improve test coverage by writing X more unit/regression tests."<br />
** "Improve performance in FOO by X%."<br />
* '''Project Schedule''' - How long will the project take? When can you begin work?<br />
* '''Availability''' - How many hours per week can you spend working on this? What other obligations do you have this summer?<br />
* '''Bio''' - Who are you? What makes you the best person to work on this project?</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Summer_of_Code/Application/2007&diff=5605Summer of Code/Application/20072007-03-07T20:48:09Z<p>Dsymonds: /* Integrating students with the community */ tweak writing</p>
<hr />
<div>== Introduction & overview ==<br />
<br />
This is the application of the [http://www.scummvm.org ScummVM] project for the [http://code.google.com/soc Google Summer of Code]. Let's start with a quick overview of the facts before turning to the more elaborate parts of this document.<br />
<br />
{| cellpadding="3"<br />
|Project: || [http://www.scummvm.org ScummVM]<br />
|-<br />
|Participation in prior SoCs: || None<br />
|-<br />
|Applications for prior SoCs: || None<br />
|-<br />
|Organization administrator: || fingolfin (max AT quendi.de)<br />
|-<br />
|Backup administrator: || sev (sev.mail AT gmail.com)<br />
|-<br />
|Project License: || GPL<br />
|-<br />
|Ideas page: || [[OpenTasks]]<br />
|-<br />
|IRC channel: || #scummvm on irc.freenode.net<br />
|-<br />
|Development mailing list: || https://lists.sourceforge.net/lists/listinfo/scummvm-devel<br />
|-<br />
|Mentors: ||<br />
* [[User:Fingolfin|Max Horn]], Google Account: max AT quendi.de<br />
* [[User:Jubanka|Kostas Nakos]], Google Account: knakos AT gmail.com<br />
* [[User:Sev|Eugene Sandulenko]], Google Account: sev.mail AT gmail.com<br />
|}<br />
<br />
== About ScummVM ==<br />
<br />
The ScummVM project aims to allow users to run on modern hardware a variety of commercially available graphical point-and-click adventure games including Monkey Island, Simon the Sorcerer, Space Quest, and many more. To this end, ScummVM features a complete reimplementation of each supported game engine (Virtual Machine - VM) in a structured fashion using the C++ language. The development team works either by reverse engineering game executables, usually with the permission of creators of the game, or by using the original source code of the games provided by the creators. The number of engines is constantly growing thanks to a very agile and diversified development team.<br />
<br />
The VM approach followed by ScummVM results in efficient code, which has been ported to numerous Operating Systems. Besides running on all mainstream desktop environments, namely Windows, Mac OS X or most Unix variants (Linux, *BSD, Solaris, ...), ScummVM works on popular game consoles (Nintendo DS, PlayStation 2, PlayStation Portable and more), smart phones and PDAs (WinCE, PalmOS or Symbian based), and even on many not-so-mainstream systems (like BeOS, AmigaOS or OS/2).<br />
<br />
ScummVM's high portability is a direct consequence of the flexible and modular structure of its architecture, which can be roughly divided into the following three major categories: <br />
# Backends, which are responsible for supporting specific target devices, like PalmOS or WinCE,<br />
# Engines, also called front ends internally, contain the actual game specific (VM) code, and<br />
# Infrastructure code, which provides easy and portable baseline functionality, such as access to audio (including MIDI), graphics, user input, data access, a custom graphical user interface, and more.<br />
<br />
The large team of developers is split in groups which focus in different aspects of the architecture, in a manner derived from the above mentioned categorization. The team members are often not strictly confined to their respective group. Developers may assume different roles in several teams. Currently, the developers are split in the following subteams:<br />
* Porters: Responsible for a specific ScummVM port.<br />
* Engine authors: Responsible for a specific game engine and its associated bug reports (support).<br />
* Infrastructure development: Includes for example developers working on MIDI code, on the built-in custom GUI, etc.<br />
* Packagers: Not all ports require dedicated backends. For example our SDL backend is highly portable, but it still requires somebody to test and compile it. Packagers execute this function.<br />
* Documentation / web site management<br />
* Project leads: There are currently three project leads. They all are also represented in one of the above categories, but besides this they organize and coordinate things, make decisions, solve disputes etc.<br />
<br />
All of this enables us to be highly productive in a team of about 30 currently active developers (out of an all time pool of well over 60), who work together on a codebase exceeding 600,000 LOC. In addition we have many non-developer contributors, and a huge and highly active community. We are among the most active projects hosted on sourceforge.net with well over 100,000 monthly downloads and ~9 millions project web hits per month.<br />
<br />
== What we hope to gain ==<br />
For one thing, we hope to attract new blood: we hope to gain some new active developers via these projects. While we already have several very active contributors, these people are already mostly busy in specific subprojects and tasks. New people mean new ideas, new energy, and new ways of thinking. Therefore, a longer lasting engagement of our student contributors would be our highest hope.<br />
<br />
Furthermore, all of our developers work on ScummVM in their spare time. But for some tasks, it's most effective if you can spend a certain block of time working on this task exclusively; just what we would get via the SoC.<br />
Hence, we hope to gain some nice shiny new code providing useful new functionality to our users and developers. Even if the authors don't stick around, this will benefit all of the ScummVM community.<br />
<br />
Lastly, we also believe that we can learn a lot from this whole event in terms of interaction with prospective new team members, how to motivate students to participate in our projects, and so forth: knowledge that may turn out to be very valuable outside of the SoC, too.<br />
<br />
== Our mentors ==<br />
Our mentors were selected as volunteers from the development team who are already intimately familiar with the internals of ScummVM, our coding conventions etc.. All three are familiar with guiding people (in particular, students) through project work effectively (in fact, two of them happen to be lead developers of ScummVM). As such, we are convinced that we are able to guide interested students through the Summer of Code to the net benefit of all involved parties.<br />
<br />
== How we will deal with participants 'missing in action' ==<br />
We hope that nobody will disappear, but we plan to take a proactive approach, i.e., we will try to minimize the risk of a loss of communication, but if it happens, we are prepared to deal with it, too.<br />
<br />
For the mentors, the risk is relatively low; two are project leads and are reachable virtually 24/7 (in case of emergencies). We all have exchanged sufficient contact information (including cell phone numbers etc.) to be able to discover our whereabouts etc. Should something really bad happen (like somebody ending up in hospital and hence unable to work, a natural disaster, etc.), we will attempt to shift students to new mentors (among the existing mentors, or drawn from our backup pool of mentors). This will depend on the number of students we have to mentor.<br />
<br />
As for the students, for starters we plan to exchange as much communication data as possible (cell phone numbers, postal addresses etc.). Through a friendly atmosphere we hope to minimize the risk of any student being "afraid" to report problems they might have etc.. On the other hand, we will make it clear that we expect dedicated work of the students and that unannounced/unjustified disappearances will draw consequences, like negative reports or even the failure of the whole project. Still, establishing a positive and friendly connection between student and mentor will be the cornerstone of our efforts in this regard. If the student trusts the mentor and tells him about his fear, uncertainties and problems early on, they can try to find a solution together, possibly with the help of the rest of the team. Also, integrating the students into our community should reduce the likelihood of disappearances further (see also the next section).<br />
<br />
A common cause (we believe, based on our own experiences as students *g*) is a lack of structure in the assigned work, resp. an inability of the student to make real progress. To avoid this, we will request that students come up with a (realistic) project plan / schedule. The mentors will watch the progress with the students and discuss it with them regularly (at least weekly). We hope to detect potential problems early on this way, thus being able to help the students get around them, to the benefit of all.<br />
<br />
If all fails, though, and a student really vanishes completely, we will have to deal with the consequences, just like with regular projects in a company. Projects *can* fail, after all, no matter how hard you try to avoid it.<br />
<br />
== Integrating students with the community ==<br />
Our community uses forums, IRC, a Wiki and our mailing list for a vivid exchange of thoughts all the time. We will urge the students to participate in all of them; especially on IRC can they directly talk to many nice and helpful team and community members. The mentors will introduce the students to the rest of the team (making sure everybody knows who the students are). There are people active in the IRC channel virtually 24/7, thanks to the international nature of the project.<br />
<br />
We also expect the students to talk to non-mentor team members on a regular basis about parts of ScummVM for which these team members are experts (if these parts happen to be relevant for the student's project). To achieve that, the mentors will specifically introduce them to each other, and will try to encourage them to work together.<br />
<br />
== Student application template ==<br />
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].<br />
<br />
* '''Name'''<br />
* '''Email'''<br />
* '''Project Title'''<br />
* '''Possible Mentor''' (optional)<br />
* '''Benefits to the ScummVM Community''' - a good project will not just be fun to work on, but also generally useful to others.<br />
* '''Deliverables''' - It is very important to list quantifiable results here e.g.<br />
** "Improve X modules in ways Y and Z."<br />
** "Write 3 new man pages for the new interfaces."<br />
** "Improve test coverage by writing X more unit/regression tests."<br />
** "Improve performance in FOO by X%."<br />
* '''Project Schedule''' - How long will the project take? When can you begin work?<br />
* '''Availability''' - How many hours per week can you spend working on this? What other obligations do you have this summer?<br />
* '''Bio''' - Who are you? What makes you the best person to work on this project?</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Summer_of_Code/Application/2007&diff=5604Summer of Code/Application/20072007-03-07T20:37:18Z<p>Dsymonds: /* What we hope to gain */ minor punctuation tweak</p>
<hr />
<div>== Introduction & overview ==<br />
<br />
This is the application of the [http://www.scummvm.org ScummVM] project for the [http://code.google.com/soc Google Summer of Code]. Let's start with a quick overview of the facts before turning to the more elaborate parts of this document.<br />
<br />
{| cellpadding="3"<br />
|Project: || [http://www.scummvm.org ScummVM]<br />
|-<br />
|Participation in prior SoCs: || None<br />
|-<br />
|Applications for prior SoCs: || None<br />
|-<br />
|Organization administrator: || fingolfin (max AT quendi.de)<br />
|-<br />
|Backup administrator: || sev (sev.mail AT gmail.com)<br />
|-<br />
|Project License: || GPL<br />
|-<br />
|Ideas page: || [[OpenTasks]]<br />
|-<br />
|IRC channel: || #scummvm on irc.freenode.net<br />
|-<br />
|Development mailing list: || https://lists.sourceforge.net/lists/listinfo/scummvm-devel<br />
|-<br />
|Mentors: ||<br />
* [[User:Fingolfin|Max Horn]], Google Account: max AT quendi.de<br />
* [[User:Jubanka|Kostas Nakos]], Google Account: knakos AT gmail.com<br />
* [[User:Sev|Eugene Sandulenko]], Google Account: sev.mail AT gmail.com<br />
|}<br />
<br />
== About ScummVM ==<br />
<br />
The ScummVM project aims to allow users to run on modern hardware a variety of commercially available graphical point-and-click adventure games including Monkey Island, Simon the Sorcerer, Space Quest, and many more. To this end, ScummVM features a complete reimplementation of each supported game engine (Virtual Machine - VM) in a structured fashion using the C++ language. The development team works either by reverse engineering game executables, usually with the permission of creators of the game, or by using the original source code of the games provided by the creators. The number of engines is constantly growing thanks to a very agile and diversified development team.<br />
<br />
The VM approach followed by ScummVM results in efficient code, which has been ported to numerous Operating Systems. Besides running on all mainstream desktop environments, namely Windows, Mac OS X or most Unix variants (Linux, *BSD, Solaris, ...), ScummVM works on popular game consoles (Nintendo DS, PlayStation 2, PlayStation Portable and more), smart phones and PDAs (WinCE, PalmOS or Symbian based), and even on many not-so-mainstream systems (like BeOS, AmigaOS or OS/2).<br />
<br />
ScummVM's high portability is a direct consequence of the flexible and modular structure of its architecture, which can be roughly divided into the following three major categories: <br />
# Backends, which are responsible for supporting specific target devices, like PalmOS or WinCE,<br />
# Engines, also called front ends internally, contain the actual game specific (VM) code, and<br />
# Infrastructure code, which provides easy and portable baseline functionality, such as access to audio (including MIDI), graphics, user input, data access, a custom graphical user interface, and more.<br />
<br />
The large team of developers is split in groups which focus in different aspects of the architecture, in a manner derived from the above mentioned categorization. The team members are often not strictly confined to their respective group. Developers may assume different roles in several teams. Currently, the developers are split in the following subteams:<br />
* Porters: Responsible for a specific ScummVM port.<br />
* Engine authors: Responsible for a specific game engine and its associated bug reports (support).<br />
* Infrastructure development: Includes for example developers working on MIDI code, on the built-in custom GUI, etc.<br />
* Packagers: Not all ports require dedicated backends. For example our SDL backend is highly portable, but it still requires somebody to test and compile it. Packagers execute this function.<br />
* Documentation / web site management<br />
* Project leads: There are currently three project leads. They all are also represented in one of the above categories, but besides this they organize and coordinate things, make decisions, solve disputes etc.<br />
<br />
All of this enables us to be highly productive in a team of about 30 currently active developers (out of an all time pool of well over 60), who work together on a codebase exceeding 600,000 LOC. In addition we have many non-developer contributors, and a huge and highly active community. We are among the most active projects hosted on sourceforge.net with well over 100,000 monthly downloads and ~9 millions project web hits per month.<br />
<br />
== What we hope to gain ==<br />
For one thing, we hope to attract new blood: we hope to gain some new active developers via these projects. While we already have several very active contributors, these people are already mostly busy in specific subprojects and tasks. New people mean new ideas, new energy, and new ways of thinking. Therefore, a longer lasting engagement of our student contributors would be our highest hope.<br />
<br />
Furthermore, all of our developers work on ScummVM in their spare time. But for some tasks, it's most effective if you can spend a certain block of time working on this task exclusively; just what we would get via the SoC.<br />
Hence, we hope to gain some nice shiny new code providing useful new functionality to our users and developers. Even if the authors don't stick around, this will benefit all of the ScummVM community.<br />
<br />
Lastly, we also believe that we can learn a lot from this whole event in terms of interaction with prospective new team members, how to motivate students to participate in our projects, and so forth: knowledge that may turn out to be very valuable outside of the SoC, too.<br />
<br />
== Our mentors ==<br />
Our mentors were selected as volunteers from the development team who are already intimately familiar with the internals of ScummVM, our coding conventions etc.. All three are familiar with guiding people (in particular, students) through project work effectively (in fact, two of them happen to be lead developers of ScummVM). As such, we are convinced that we are able to guide interested students through the Summer of Code to the net benefit of all involved parties.<br />
<br />
== How we will deal with participants 'missing in action' ==<br />
We hope that nobody will disappear, but we plan to take a proactive approach, i.e., we will try to minimize the risk of a loss of communication, but if it happens, we are prepared to deal with it, too.<br />
<br />
For the mentors, the risk is relatively low; two are project leads and are reachable virtually 24/7 (in case of emergencies). We all have exchanged sufficient contact information (including cell phone numbers etc.) to be able to discover our whereabouts etc. Should something really bad happen (like somebody ending up in hospital and hence unable to work, a natural disaster, etc.), we will attempt to shift students to new mentors (among the existing mentors, or drawn from our backup pool of mentors). This will depend on the number of students we have to mentor.<br />
<br />
As for the students, for starters we plan to exchange as much communication data as possible (cell phone numbers, postal addresses etc.). Through a friendly atmosphere we hope to minimize the risk of any student being "afraid" to report problems they might have etc.. On the other hand, we will make it clear that we expect dedicated work of the students and that unannounced/unjustified disappearances will draw consequences, like negative reports or even the failure of the whole project. Still, establishing a positive and friendly connection between student and mentor will be the cornerstone of our efforts in this regard. If the student trusts the mentor and tells him about his fear, uncertainties and problems early on, they can try to find a solution together, possibly with the help of the rest of the team. Also, integrating the students into our community should reduce the likelihood of disappearances further (see also the next section).<br />
<br />
A common cause (we believe, based on our own experiences as students *g*) is a lack of structure in the assigned work, resp. an inability of the student to make real progress. To avoid this, we will request that students come up with a (realistic) project plan / schedule. The mentors will watch the progress with the students and discuss it with them regularly (at least weekly). We hope to detect potential problems early on this way, thus being able to help the students get around them, to the benefit of all.<br />
<br />
If all fails, though, and a student really vanishes completely, we will have to deal with the consequences, just like with regular projects in a company. Projects *can* fail, after all, no matter how hard you try to avoid it.<br />
<br />
== Integrating students with the community ==<br />
Our community uses forums, IRC, a Wiki and our mailing list for a vivid exchange of thoughts all the time. We will urge the students to participate in all of them; especially on IRC can they directly talk to many nice and helpful team and community members. The mentors will introduce the students to the rest of the team (making sure everybody knows who the students are). There are people active in the IRC channel virtually 24/7, thanks to the international nature of the project.<br />
<br />
We also expect the students to talk to non-mentor team members on a regular basis about parts of ScummVM for which these team members are experts (at least if these parts happen to be relevant for the student's project). To achieve that, the mentors will specifically introduce them to each other, and will try to incite them to work together.<br />
<br />
== Student application template ==<br />
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].<br />
<br />
* '''Name'''<br />
* '''Email'''<br />
* '''Project Title'''<br />
* '''Possible Mentor''' (optional)<br />
* '''Benefits to the ScummVM Community''' - a good project will not just be fun to work on, but also generally useful to others.<br />
* '''Deliverables''' - It is very important to list quantifiable results here e.g.<br />
** "Improve X modules in ways Y and Z."<br />
** "Write 3 new man pages for the new interfaces."<br />
** "Improve test coverage by writing X more unit/regression tests."<br />
** "Improve performance in FOO by X%."<br />
* '''Project Schedule''' - How long will the project take? When can you begin work?<br />
* '''Availability''' - How many hours per week can you spend working on this? What other obligations do you have this summer?<br />
* '''Bio''' - Who are you? What makes you the best person to work on this project?</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Summer_of_Code/Application/2007&diff=5603Summer of Code/Application/20072007-03-07T20:36:29Z<p>Dsymonds: /* What we hope to gain */ re-work some more grammar</p>
<hr />
<div>== Introduction & overview ==<br />
<br />
This is the application of the [http://www.scummvm.org ScummVM] project for the [http://code.google.com/soc Google Summer of Code]. Let's start with a quick overview of the facts before turning to the more elaborate parts of this document.<br />
<br />
{| cellpadding="3"<br />
|Project: || [http://www.scummvm.org ScummVM]<br />
|-<br />
|Participation in prior SoCs: || None<br />
|-<br />
|Applications for prior SoCs: || None<br />
|-<br />
|Organization administrator: || fingolfin (max AT quendi.de)<br />
|-<br />
|Backup administrator: || sev (sev.mail AT gmail.com)<br />
|-<br />
|Project License: || GPL<br />
|-<br />
|Ideas page: || [[OpenTasks]]<br />
|-<br />
|IRC channel: || #scummvm on irc.freenode.net<br />
|-<br />
|Development mailing list: || https://lists.sourceforge.net/lists/listinfo/scummvm-devel<br />
|-<br />
|Mentors: ||<br />
* [[User:Fingolfin|Max Horn]], Google Account: max AT quendi.de<br />
* [[User:Jubanka|Kostas Nakos]], Google Account: knakos AT gmail.com<br />
* [[User:Sev|Eugene Sandulenko]], Google Account: sev.mail AT gmail.com<br />
|}<br />
<br />
== About ScummVM ==<br />
<br />
The ScummVM project aims to allow users to run on modern hardware a variety of commercially available graphical point-and-click adventure games including Monkey Island, Simon the Sorcerer, Space Quest, and many more. To this end, ScummVM features a complete reimplementation of each supported game engine (Virtual Machine - VM) in a structured fashion using the C++ language. The development team works either by reverse engineering game executables, usually with the permission of creators of the game, or by using the original source code of the games provided by the creators. The number of engines is constantly growing thanks to a very agile and diversified development team.<br />
<br />
The VM approach followed by ScummVM results in efficient code, which has been ported to numerous Operating Systems. Besides running on all mainstream desktop environments, namely Windows, Mac OS X or most Unix variants (Linux, *BSD, Solaris, ...), ScummVM works on popular game consoles (Nintendo DS, PlayStation 2, PlayStation Portable and more), smart phones and PDAs (WinCE, PalmOS or Symbian based), and even on many not-so-mainstream systems (like BeOS, AmigaOS or OS/2).<br />
<br />
ScummVM's high portability is a direct consequence of the flexible and modular structure of its architecture, which can be roughly divided into the following three major categories: <br />
# Backends, which are responsible for supporting specific target devices, like PalmOS or WinCE,<br />
# Engines, also called front ends internally, contain the actual game specific (VM) code, and<br />
# Infrastructure code, which provides easy and portable baseline functionality, such as access to audio (including MIDI), graphics, user input, data access, a custom graphical user interface, and more.<br />
<br />
The large team of developers is split in groups which focus in different aspects of the architecture, in a manner derived from the above mentioned categorization. The team members are often not strictly confined to their respective group. Developers may assume different roles in several teams. Currently, the developers are split in the following subteams:<br />
* Porters: Responsible for a specific ScummVM port.<br />
* Engine authors: Responsible for a specific game engine and its associated bug reports (support).<br />
* Infrastructure development: Includes for example developers working on MIDI code, on the built-in custom GUI, etc.<br />
* Packagers: Not all ports require dedicated backends. For example our SDL backend is highly portable, but it still requires somebody to test and compile it. Packagers execute this function.<br />
* Documentation / web site management<br />
* Project leads: There are currently three project leads. They all are also represented in one of the above categories, but besides this they organize and coordinate things, make decisions, solve disputes etc.<br />
<br />
All of this enables us to be highly productive in a team of about 30 currently active developers (out of an all time pool of well over 60), who work together on a codebase exceeding 600,000 LOC. In addition we have many non-developer contributors, and a huge and highly active community. We are among the most active projects hosted on sourceforge.net with well over 100,000 monthly downloads and ~9 millions project web hits per month.<br />
<br />
== What we hope to gain ==<br />
For one thing, we hope to attract new blood: we hope to gain some new active developers via these projects. While we already have several very active contributors, these people are already mostly busy in specific subprojects and tasks. New people mean new ideas, new energy, and new ways of thinking. Therefore, a longer lasting engagement of our student contributors would be our highest hope.<br />
<br />
Furthermore, all of our developers work on ScummVM in their spare time. But for some tasks, it's most effective if you can spend a certain block of time working on this task exclusively; just what we would get via the SoC.<br />
Hence, we hope to gain some nice shiny new code providing useful new functionality to our users and developers. Even if the authors don't stick around, this will benefit all of the ScummVM community.<br />
<br />
Lastly, we also believe that we can learn a lot from this whole event in terms of interaction with prospective new team members, how to motivate students to participate in our projects etc.; knowledge that may turn out to be very valuable outside of the SoC, too.<br />
<br />
== Our mentors ==<br />
Our mentors were selected as volunteers from the development team who are already intimately familiar with the internals of ScummVM, our coding conventions etc.. All three are familiar with guiding people (in particular, students) through project work effectively (in fact, two of them happen to be lead developers of ScummVM). As such, we are convinced that we are able to guide interested students through the Summer of Code to the net benefit of all involved parties.<br />
<br />
== How we will deal with participants 'missing in action' ==<br />
We hope that nobody will disappear, but we plan to take a proactive approach, i.e., we will try to minimize the risk of a loss of communication, but if it happens, we are prepared to deal with it, too.<br />
<br />
For the mentors, the risk is relatively low; two are project leads and are reachable virtually 24/7 (in case of emergencies). We all have exchanged sufficient contact information (including cell phone numbers etc.) to be able to discover our whereabouts etc. Should something really bad happen (like somebody ending up in hospital and hence unable to work, a natural disaster, etc.), we will attempt to shift students to new mentors (among the existing mentors, or drawn from our backup pool of mentors). This will depend on the number of students we have to mentor.<br />
<br />
As for the students, for starters we plan to exchange as much communication data as possible (cell phone numbers, postal addresses etc.). Through a friendly atmosphere we hope to minimize the risk of any student being "afraid" to report problems they might have etc.. On the other hand, we will make it clear that we expect dedicated work of the students and that unannounced/unjustified disappearances will draw consequences, like negative reports or even the failure of the whole project. Still, establishing a positive and friendly connection between student and mentor will be the cornerstone of our efforts in this regard. If the student trusts the mentor and tells him about his fear, uncertainties and problems early on, they can try to find a solution together, possibly with the help of the rest of the team. Also, integrating the students into our community should reduce the likelihood of disappearances further (see also the next section).<br />
<br />
A common cause (we believe, based on our own experiences as students *g*) is a lack of structure in the assigned work, resp. an inability of the student to make real progress. To avoid this, we will request that students come up with a (realistic) project plan / schedule. The mentors will watch the progress with the students and discuss it with them regularly (at least weekly). We hope to detect potential problems early on this way, thus being able to help the students get around them, to the benefit of all.<br />
<br />
If all fails, though, and a student really vanishes completely, we will have to deal with the consequences, just like with regular projects in a company. Projects *can* fail, after all, no matter how hard you try to avoid it.<br />
<br />
== Integrating students with the community ==<br />
Our community uses forums, IRC, a Wiki and our mailing list for a vivid exchange of thoughts all the time. We will urge the students to participate in all of them; especially on IRC can they directly talk to many nice and helpful team and community members. The mentors will introduce the students to the rest of the team (making sure everybody knows who the students are). There are people active in the IRC channel virtually 24/7, thanks to the international nature of the project.<br />
<br />
We also expect the students to talk to non-mentor team members on a regular basis about parts of ScummVM for which these team members are experts (at least if these parts happen to be relevant for the student's project). To achieve that, the mentors will specifically introduce them to each other, and will try to incite them to work together.<br />
<br />
== Student application template ==<br />
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].<br />
<br />
* '''Name'''<br />
* '''Email'''<br />
* '''Project Title'''<br />
* '''Possible Mentor''' (optional)<br />
* '''Benefits to the ScummVM Community''' - a good project will not just be fun to work on, but also generally useful to others.<br />
* '''Deliverables''' - It is very important to list quantifiable results here e.g.<br />
** "Improve X modules in ways Y and Z."<br />
** "Write 3 new man pages for the new interfaces."<br />
** "Improve test coverage by writing X more unit/regression tests."<br />
** "Improve performance in FOO by X%."<br />
* '''Project Schedule''' - How long will the project take? When can you begin work?<br />
* '''Availability''' - How many hours per week can you spend working on this? What other obligations do you have this summer?<br />
* '''Bio''' - Who are you? What makes you the best person to work on this project?</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Summer_of_Code/Application/2007&diff=5602Summer of Code/Application/20072007-03-07T20:35:08Z<p>Dsymonds: /* What we hope to gain */ re-jig some grammar</p>
<hr />
<div>== Introduction & overview ==<br />
<br />
This is the application of the [http://www.scummvm.org ScummVM] project for the [http://code.google.com/soc Google Summer of Code]. Let's start with a quick overview of the facts before turning to the more elaborate parts of this document.<br />
<br />
{| cellpadding="3"<br />
|Project: || [http://www.scummvm.org ScummVM]<br />
|-<br />
|Participation in prior SoCs: || None<br />
|-<br />
|Applications for prior SoCs: || None<br />
|-<br />
|Organization administrator: || fingolfin (max AT quendi.de)<br />
|-<br />
|Backup administrator: || sev (sev.mail AT gmail.com)<br />
|-<br />
|Project License: || GPL<br />
|-<br />
|Ideas page: || [[OpenTasks]]<br />
|-<br />
|IRC channel: || #scummvm on irc.freenode.net<br />
|-<br />
|Development mailing list: || https://lists.sourceforge.net/lists/listinfo/scummvm-devel<br />
|-<br />
|Mentors: ||<br />
* [[User:Fingolfin|Max Horn]], Google Account: max AT quendi.de<br />
* [[User:Jubanka|Kostas Nakos]], Google Account: knakos AT gmail.com<br />
* [[User:Sev|Eugene Sandulenko]], Google Account: sev.mail AT gmail.com<br />
|}<br />
<br />
== About ScummVM ==<br />
<br />
The ScummVM project aims to allow users to run on modern hardware a variety of commercially available graphical point-and-click adventure games including Monkey Island, Simon the Sorcerer, Space Quest, and many more. To this end, ScummVM features a complete reimplementation of each supported game engine (Virtual Machine - VM) in a structured fashion using the C++ language. The development team works either by reverse engineering game executables, usually with the permission of creators of the game, or by using the original source code of the games provided by the creators. The number of engines is constantly growing thanks to a very agile and diversified development team.<br />
<br />
The VM approach followed by ScummVM results in efficient code, which has been ported to numerous Operating Systems. Besides running on all mainstream desktop environments, namely Windows, Mac OS X or most Unix variants (Linux, *BSD, Solaris, ...), ScummVM works on popular game consoles (Nintendo DS, PlayStation 2, PlayStation Portable and more), smart phones and PDAs (WinCE, PalmOS or Symbian based), and even on many not-so-mainstream systems (like BeOS, AmigaOS or OS/2).<br />
<br />
ScummVM's high portability is a direct consequence of the flexible and modular structure of its architecture, which can be roughly divided into the following three major categories: <br />
# Backends, which are responsible for supporting specific target devices, like PalmOS or WinCE,<br />
# Engines, also called front ends internally, contain the actual game specific (VM) code, and<br />
# Infrastructure code, which provides easy and portable baseline functionality, such as access to audio (including MIDI), graphics, user input, data access, a custom graphical user interface, and more.<br />
<br />
The large team of developers is split in groups which focus in different aspects of the architecture, in a manner derived from the above mentioned categorization. The team members are often not strictly confined to their respective group. Developers may assume different roles in several teams. Currently, the developers are split in the following subteams:<br />
* Porters: Responsible for a specific ScummVM port.<br />
* Engine authors: Responsible for a specific game engine and its associated bug reports (support).<br />
* Infrastructure development: Includes for example developers working on MIDI code, on the built-in custom GUI, etc.<br />
* Packagers: Not all ports require dedicated backends. For example our SDL backend is highly portable, but it still requires somebody to test and compile it. Packagers execute this function.<br />
* Documentation / web site management<br />
* Project leads: There are currently three project leads. They all are also represented in one of the above categories, but besides this they organize and coordinate things, make decisions, solve disputes etc.<br />
<br />
All of this enables us to be highly productive in a team of about 30 currently active developers (out of an all time pool of well over 60), who work together on a codebase exceeding 600,000 LOC. In addition we have many non-developer contributors, and a huge and highly active community. We are among the most active projects hosted on sourceforge.net with well over 100,000 monthly downloads and ~9 millions project web hits per month.<br />
<br />
== What we hope to gain ==<br />
For one thing, we hope to attract new blood: we hope to gain some new active developers via these projects. While we already have several very active contributors, these people are already mostly busy in specific subprojects and tasks. New people mean new ideas, new energy, and new ways of thinking. Therefore, a longer lasting engagement of our student contributors would be our highest hope.<br />
<br />
Furthermore, all of our developers work on ScummVM in their spare time. But for certain tasks, it's simply best if you can spend a certain time working on this task more or less exclusively -- i.e., just what we would get via the SoC.<br />
Hence, we hope to gain some nice shiny new code providing useful new functionality to our users and developers. Even if the authors don't stick around, this will benefit all of the ScummVM community.<br />
<br />
Lastly, we also believe that we can learn a lot from this whole event in terms of interaction with prospective new team members, how to motivate students to participate in our projects etc.; knowledge that may turn out to be very valuable outside of the SoC, too.<br />
<br />
== Our mentors ==<br />
Our mentors were selected as volunteers from the development team who are already intimately familiar with the internals of ScummVM, our coding conventions etc.. All three are familiar with guiding people (in particular, students) through project work effectively (in fact, two of them happen to be lead developers of ScummVM). As such, we are convinced that we are able to guide interested students through the Summer of Code to the net benefit of all involved parties.<br />
<br />
== How we will deal with participants 'missing in action' ==<br />
We hope that nobody will disappear, but we plan to take a proactive approach, i.e., we will try to minimize the risk of a loss of communication, but if it happens, we are prepared to deal with it, too.<br />
<br />
For the mentors, the risk is relatively low; two are project leads and are reachable virtually 24/7 (in case of emergencies). We all have exchanged sufficient contact information (including cell phone numbers etc.) to be able to discover our whereabouts etc. Should something really bad happen (like somebody ending up in hospital and hence unable to work, a natural disaster, etc.), we will attempt to shift students to new mentors (among the existing mentors, or drawn from our backup pool of mentors). This will depend on the number of students we have to mentor.<br />
<br />
As for the students, for starters we plan to exchange as much communication data as possible (cell phone numbers, postal addresses etc.). Through a friendly atmosphere we hope to minimize the risk of any student being "afraid" to report problems they might have etc.. On the other hand, we will make it clear that we expect dedicated work of the students and that unannounced/unjustified disappearances will draw consequences, like negative reports or even the failure of the whole project. Still, establishing a positive and friendly connection between student and mentor will be the cornerstone of our efforts in this regard. If the student trusts the mentor and tells him about his fear, uncertainties and problems early on, they can try to find a solution together, possibly with the help of the rest of the team. Also, integrating the students into our community should reduce the likelihood of disappearances further (see also the next section).<br />
<br />
A common cause (we believe, based on our own experiences as students *g*) is a lack of structure in the assigned work, resp. an inability of the student to make real progress. To avoid this, we will request that students come up with a (realistic) project plan / schedule. The mentors will watch the progress with the students and discuss it with them regularly (at least weekly). We hope to detect potential problems early on this way, thus being able to help the students get around them, to the benefit of all.<br />
<br />
If all fails, though, and a student really vanishes completely, we will have to deal with the consequences, just like with regular projects in a company. Projects *can* fail, after all, no matter how hard you try to avoid it.<br />
<br />
== Integrating students with the community ==<br />
Our community uses forums, IRC, a Wiki and our mailing list for a vivid exchange of thoughts all the time. We will urge the students to participate in all of them; especially on IRC can they directly talk to many nice and helpful team and community members. The mentors will introduce the students to the rest of the team (making sure everybody knows who the students are). There are people active in the IRC channel virtually 24/7, thanks to the international nature of the project.<br />
<br />
We also expect the students to talk to non-mentor team members on a regular basis about parts of ScummVM for which these team members are experts (at least if these parts happen to be relevant for the student's project). To achieve that, the mentors will specifically introduce them to each other, and will try to incite them to work together.<br />
<br />
== Student application template ==<br />
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].<br />
<br />
* '''Name'''<br />
* '''Email'''<br />
* '''Project Title'''<br />
* '''Possible Mentor''' (optional)<br />
* '''Benefits to the ScummVM Community''' - a good project will not just be fun to work on, but also generally useful to others.<br />
* '''Deliverables''' - It is very important to list quantifiable results here e.g.<br />
** "Improve X modules in ways Y and Z."<br />
** "Write 3 new man pages for the new interfaces."<br />
** "Improve test coverage by writing X more unit/regression tests."<br />
** "Improve performance in FOO by X%."<br />
* '''Project Schedule''' - How long will the project take? When can you begin work?<br />
* '''Availability''' - How many hours per week can you spend working on this? What other obligations do you have this summer?<br />
* '''Bio''' - Who are you? What makes you the best person to work on this project?</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Summer_of_Code/Application/2007&diff=5601Summer of Code/Application/20072007-03-07T20:33:29Z<p>Dsymonds: /* What we hope to gain */ colon more appropriate than an emdash</p>
<hr />
<div>== Introduction & overview ==<br />
<br />
This is the application of the [http://www.scummvm.org ScummVM] project for the [http://code.google.com/soc Google Summer of Code]. Let's start with a quick overview of the facts before turning to the more elaborate parts of this document.<br />
<br />
{| cellpadding="3"<br />
|Project: || [http://www.scummvm.org ScummVM]<br />
|-<br />
|Participation in prior SoCs: || None<br />
|-<br />
|Applications for prior SoCs: || None<br />
|-<br />
|Organization administrator: || fingolfin (max AT quendi.de)<br />
|-<br />
|Backup administrator: || sev (sev.mail AT gmail.com)<br />
|-<br />
|Project License: || GPL<br />
|-<br />
|Ideas page: || [[OpenTasks]]<br />
|-<br />
|IRC channel: || #scummvm on irc.freenode.net<br />
|-<br />
|Development mailing list: || https://lists.sourceforge.net/lists/listinfo/scummvm-devel<br />
|-<br />
|Mentors: ||<br />
* [[User:Fingolfin|Max Horn]], Google Account: max AT quendi.de<br />
* [[User:Jubanka|Kostas Nakos]], Google Account: knakos AT gmail.com<br />
* [[User:Sev|Eugene Sandulenko]], Google Account: sev.mail AT gmail.com<br />
|}<br />
<br />
== About ScummVM ==<br />
<br />
The ScummVM project aims to allow users to run on modern hardware a variety of commercially available graphical point-and-click adventure games including Monkey Island, Simon the Sorcerer, Space Quest, and many more. To this end, ScummVM features a complete reimplementation of each supported game engine (Virtual Machine - VM) in a structured fashion using the C++ language. The development team works either by reverse engineering game executables, usually with the permission of creators of the game, or by using the original source code of the games provided by the creators. The number of engines is constantly growing thanks to a very agile and diversified development team.<br />
<br />
The VM approach followed by ScummVM results in efficient code, which has been ported to numerous Operating Systems. Besides running on all mainstream desktop environments, namely Windows, Mac OS X or most Unix variants (Linux, *BSD, Solaris, ...), ScummVM works on popular game consoles (Nintendo DS, PlayStation 2, PlayStation Portable and more), smart phones and PDAs (WinCE, PalmOS or Symbian based), and even on many not-so-mainstream systems (like BeOS, AmigaOS or OS/2).<br />
<br />
ScummVM's high portability is a direct consequence of the flexible and modular structure of its architecture, which can be roughly divided into the following three major categories: <br />
# Backends, which are responsible for supporting specific target devices, like PalmOS or WinCE,<br />
# Engines, also called front ends internally, contain the actual game specific (VM) code, and<br />
# Infrastructure code, which provides easy and portable baseline functionality, such as access to audio (including MIDI), graphics, user input, data access, a custom graphical user interface, and more.<br />
<br />
The large team of developers is split in groups which focus in different aspects of the architecture, in a manner derived from the above mentioned categorization. The team members are often not strictly confined to their respective group. Developers may assume different roles in several teams. Currently, the developers are split in the following subteams:<br />
* Porters: Responsible for a specific ScummVM port.<br />
* Engine authors: Responsible for a specific game engine and its associated bug reports (support).<br />
* Infrastructure development: Includes for example developers working on MIDI code, on the built-in custom GUI, etc.<br />
* Packagers: Not all ports require dedicated backends. For example our SDL backend is highly portable, but it still requires somebody to test and compile it. Packagers execute this function.<br />
* Documentation / web site management<br />
* Project leads: There are currently three project leads. They all are also represented in one of the above categories, but besides this they organize and coordinate things, make decisions, solve disputes etc.<br />
<br />
All of this enables us to be highly productive in a team of about 30 currently active developers (out of an all time pool of well over 60), who work together on a codebase exceeding 600,000 LOC. In addition we have many non-developer contributors, and a huge and highly active community. We are among the most active projects hosted on sourceforge.net with well over 100,000 monthly downloads and ~9 millions project web hits per month.<br />
<br />
== What we hope to gain ==<br />
For one thing, we hope to attract new blood: we hope to gain some new active developers via these projects. While we already have several very active contributors, these are already mostly tied up in specific subprojects and tasks. New people mean new ideas, new energy, new ways of thinking. So a longer lasting engagement of our student contributors would be our highest hope.<br />
<br />
Furthermore, all of our developers work on ScummVM in their spare time. But for certain tasks, it's simply best if you can spend a certain time working on this task more or less exclusively -- i.e., just what we would get via the SoC.<br />
Hence, we hope to gain some nice shiny new code providing useful new functionality to our users and developers. Even if the authors don't stick around, this will benefit all of the ScummVM community.<br />
<br />
Lastly, we also believe that we can learn a lot from this whole event in terms of interaction with prospective new team members, how to motivate students to participate in our projects etc.; knowledge that may turn out to be very valuable outside of the SoC, too.<br />
<br />
== Our mentors ==<br />
Our mentors were selected as volunteers from the development team who are already intimately familiar with the internals of ScummVM, our coding conventions etc.. All three are familiar with guiding people (in particular, students) through project work effectively (in fact, two of them happen to be lead developers of ScummVM). As such, we are convinced that we are able to guide interested students through the Summer of Code to the net benefit of all involved parties.<br />
<br />
== How we will deal with participants 'missing in action' ==<br />
We hope that nobody will disappear, but we plan to take a proactive approach, i.e., we will try to minimize the risk of a loss of communication, but if it happens, we are prepared to deal with it, too.<br />
<br />
For the mentors, the risk is relatively low; two are project leads and are reachable virtually 24/7 (in case of emergencies). We all have exchanged sufficient contact information (including cell phone numbers etc.) to be able to discover our whereabouts etc. Should something really bad happen (like somebody ending up in hospital and hence unable to work, a natural disaster, etc.), we will attempt to shift students to new mentors (among the existing mentors, or drawn from our backup pool of mentors). This will depend on the number of students we have to mentor.<br />
<br />
As for the students, for starters we plan to exchange as much communication data as possible (cell phone numbers, postal addresses etc.). Through a friendly atmosphere we hope to minimize the risk of any student being "afraid" to report problems they might have etc.. On the other hand, we will make it clear that we expect dedicated work of the students and that unannounced/unjustified disappearances will draw consequences, like negative reports or even the failure of the whole project. Still, establishing a positive and friendly connection between student and mentor will be the cornerstone of our efforts in this regard. If the student trusts the mentor and tells him about his fear, uncertainties and problems early on, they can try to find a solution together, possibly with the help of the rest of the team. Also, integrating the students into our community should reduce the likelihood of disappearances further (see also the next section).<br />
<br />
A common cause (we believe, based on our own experiences as students *g*) is a lack of structure in the assigned work, resp. an inability of the student to make real progress. To avoid this, we will request that students come up with a (realistic) project plan / schedule. The mentors will watch the progress with the students and discuss it with them regularly (at least weekly). We hope to detect potential problems early on this way, thus being able to help the students get around them, to the benefit of all.<br />
<br />
If all fails, though, and a student really vanishes completely, we will have to deal with the consequences, just like with regular projects in a company. Projects *can* fail, after all, no matter how hard you try to avoid it.<br />
<br />
== Integrating students with the community ==<br />
Our community uses forums, IRC, a Wiki and our mailing list for a vivid exchange of thoughts all the time. We will urge the students to participate in all of them; especially on IRC can they directly talk to many nice and helpful team and community members. The mentors will introduce the students to the rest of the team (making sure everybody knows who the students are). There are people active in the IRC channel virtually 24/7, thanks to the international nature of the project.<br />
<br />
We also expect the students to talk to non-mentor team members on a regular basis about parts of ScummVM for which these team members are experts (at least if these parts happen to be relevant for the student's project). To achieve that, the mentors will specifically introduce them to each other, and will try to incite them to work together.<br />
<br />
== Student application template ==<br />
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].<br />
<br />
* '''Name'''<br />
* '''Email'''<br />
* '''Project Title'''<br />
* '''Possible Mentor''' (optional)<br />
* '''Benefits to the ScummVM Community''' - a good project will not just be fun to work on, but also generally useful to others.<br />
* '''Deliverables''' - It is very important to list quantifiable results here e.g.<br />
** "Improve X modules in ways Y and Z."<br />
** "Write 3 new man pages for the new interfaces."<br />
** "Improve test coverage by writing X more unit/regression tests."<br />
** "Improve performance in FOO by X%."<br />
* '''Project Schedule''' - How long will the project take? When can you begin work?<br />
* '''Availability''' - How many hours per week can you spend working on this? What other obligations do you have this summer?<br />
* '''Bio''' - Who are you? What makes you the best person to work on this project?</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Glossary&diff=4819Glossary2007-01-16T02:49:03Z<p>Dsymonds: add wiki link</p>
<hr />
<div>; AGI : Sierra On-Line [[AGI|Adventure Game Interpreter]], a system for creating adventure games<br />
; BASS : [[Beneath a Steel Sky]], an adventure game<br />
; BS : Broken Sword, a series of adventure games developed by [[Revolution|Revolution Software]]<br />
; COMI : [[The Curse of Monkey Island]], the third installment of the famous [[Monkey Island]] series<br />
; DOTT : [[Day of the Tentacle]], a SCUMM adventure game<br />
; FM-TOWNS : The FM-TOWNS was a series of x86 computers built by Fujitsu and targetted at the Japanese gaming market in the form of the "FM-TOWNS Marty" 32-bit consoles. Various early SCUMM games were enhanced and ported to this platform by LucasArts. Much of this porting work was done by [http://www.leiterman.com/ Jim Leiterman].<br />
; FOA : [[Indiana Jones and the Fate of Atlantis|Fate of Atlantis]], also known as Indiana Jones 4, a SCUMM adventure game<br />
; FOTAQ : [[Flight of the Amazon Queen]], an adventure game<br />
; FT : [[Full Throttle]], a SCUMM adventure game<br />
; HE : [[Humongous Entertainment]]<br />
; IHNM : [[I Have No Mouth, and I Must Scream]], a game based on the [[SAGA|SAGA engine]]<br />
; iMUSE : Interactive Music Streaming Engine, or Interactive Music and Sound Effects. A sound system that was created by Michael Z. Land and Peter McConnell for Monkey Island 2. It was further developed for Sam & Max Hit the Road, where it was also credited to Justin Graham. Once described as a "souped-up MIDI sequencer", a digital version was developed for the later games. Possibly by Michael McMahon.<br />
; INSANE : INteractive Streaming ANimation Engine, a secondary scripting engine for interactive SMUSH scenes.<br />
; ITE : [[Inherit The Earth]], a game based on the [[SAGA|SAGA engine]]<br />
; LEC : [[LucasArts|LucasArts Entertainment Company]]<br />
; MI : [[Monkey Island]], a series of SCUMM adventure games<br />
; MM : [[Maniac Mansion]], a SCUMM adventure game<br />
; MT-32 : The Roland MT-32 is a MIDI synthesizer module. Many DOS games from the early 90s featured special sound tracks custom-tailored for this device.<br />
; SAGA : Scripts for Animated Graphic Adventures. A scripting engine originally developed by The Dreamers Guild, Inc. Later rights to the version used for ITE were obtained by [http://www.wyrmkeep.com "The Wyrmkeep Entertainment Co."]<br />
; SCUMM : [[SCUMM|Script Creation Utility for Maniac Mansion]], a scripting language (and not really an engine; see SPUTM) originally developed by LucasArts for creating graphics adventures.<br />
; SCUMMVM : SCUMM Virtual Machine, or see some [[ScummVM Name|other names]].<br />
; SMUSH : TODO<br />
; SPUTM : SCUMM Presentation Utility (properly abbreviated as SPUâ„¢ with a trademark symbol), the actual script interpreter and engine behind SCUMM-scripted titles.</div>Dsymondshttps://wiki.scummvm.org/index.php?title=User:Dsymonds&diff=4818User:Dsymonds2007-01-16T02:46:37Z<p>Dsymonds: add a userbox for myself</p>
<hr />
<div>{{User|<br />
handle=dsymonds|<br />
name=David Symonds|<br />
memberSince=6 Jan 2007|<br />
workingOn=[[AGI|AGI Engine]]<br />
}}<br />
<br />
<tt>dsymonds</tt> is a developer in the ScummVM Project, working on the AGI engine.<br />
<br />
He can be contacted via email at: dsymonds _at_ scummvm _dot_ org<br />
<br />
--[[User:Dsymonds|dsymonds]] 22:59, 7 January 2007 (UTC)</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Developers_Bios&diff=4658Developers Bios2007-01-09T02:35:50Z<p>Dsymonds: Added myself</p>
<hr />
<div>This is a (hopefully) complete list of all people that have worked on ScummVM or contributed code. <br />
The idea is that we want to see where everybody comes from and maybe a small biography. <br />
This could be anything from "Loves coding on ScummVM while working on Windows Vista source at Microsoft" <br />
to the next bestseller at your local bookstore: you decide.<br />
<br />
I have created a Perl script that automatically parses the GPS information on this Wiki page and incorporates it onto [http://scummvm.thewicked.nl/images/ World and Europe maps of ScummVM Developers] of various resolutions using [http://xplanet.sourceforge.net/ xplanet]. <br />
So if you do not want to add a small bio we would at least ask you to enter the GPS coordinates of your location so the maps will be populated.<br />
Please enter your location information according to the following wiki syntax so my parse script can find them: <br />
<br />
:Location: Country, City, GPS XXnXX, YYeYY<br />
:Location: The Netherlands, Amsterdam, GPS 52n22, 4e54<br />
<br />
You can easily look up your own GPS coordinates at [http://www.astro.com/cgi/aq.cgi?lang=e astro.com].<br />
You can directly copy-paste the GPS coordinates from the astro.com results. The script is now run automatically once per day @ 00:00 CET.<br />
<br />
Also, if you know the (partial) location for another developer and you don't think he/she (do we have any females working on ScummVM?) can enter it themselves, feel free to add these too for maximum results. Please realize that some of the data on this page may be inaccurate, or hopelessly old and neglected, especially the website links, so remember to take these with a grain of salt :P<br />
<br />
:enjoy!<br />
:SumthinWicked<br />
<br />
http://scummvm.thewicked.nl/images/ScummVM-Developers-World-1024x512.png<br />
<br />
<br>Go [http://scummvm.thewicked.nl/images/ here] to see more maps of ScummVM Developers in Europe & the World. <br />
The high-resolution maps also contain developers names with the locations. <br />
[http://scummvm.thewicked.nl/images/ScummVM-Developers-Europe-1142x798.png This] is a particularly good one.<br />
<br />
<br><br><br />
<br />
== The ScummVM team ==<br />
<br />
<br />
=== James Brown ===<br />
:Handle: [[User:Ender|Ender]]<br />
:ScummVM: Lead developer, SCUMM Engine, Wiki/Forums Administration<br />
:Location: Australia, Perth, GPS 31s59, 115e49<br />
:Occupation: Systems Administrator<br />
:Website: http://www.enderboi.com/<br />
<br />
=== Max Horn ===<br />
:Handle: [[User:Fingolfin|Fingolfin]]<br />
:ScummVM: Lead developer, SCUMM engine, SDL backend, Sound mixer, GUI, infrastructure...<br />
:Location: Germany, Darmstadt, GPS 49n53, 8e40<br />
:Occupation: PhD student (math)<br />
<br />
=== Eugene Sandulenko ===<br />
:Handle: [[User:sev|sev]]<br />
:ScummVM: Lead developer, Engine: SCUMM (FT INSANE, MM NES, MM C64, game detection, Herc/CGA), HE, SAGA, Gob, OSystem, initial MT-32 support, Asm routines<br />
:Location: Ukraine, Kharkiv, GPS 49n55, 36e18<br />
:Occupation:<br />
<br />
=== Torbj&ouml;rn Andersson ===<br />
:Handle: [[User:eriktorbjorn|eriktorbjorn]]<br />
:ScummVM: Engine: SCUMM, Broken Sword 2, SAGA, Gob, AGOS<br />
:Location: Sweden, Borlänge, GPS 60n30, 15e25<br />
:Occupation: Programmer<br />
<br />
=== Oystein Eftevaag ===<br />
:Handle: [[User:vinterstum|vinterstum]]<br />
:ScummVM: Engine: Kyra<br />
:Location: Norway, Oslo, GPS 59n55, 10e45<br />
:Occupation: Postgrad student, web developer<br />
<br />
=== David Eriksson ===<br />
:Handle: [[User:twogood|twogood]]<br />
:ScummVM: Engine: Flight of the Amazon Queen<br />
:Location: Sweden, Stockholm, GPS 59n20, 18e03<br />
:Occupation: <br />
<br />
=== Robert G&ouml;ffringmann ===<br />
:Handle: [[User:Lavosspawn|Lavosspawn]], Cody56 (on IRC)<br />
:ScummVM: Engine: Beneath a Steel Sky, Broken Sword 1<br />
:Location: Germany, Dortmund, GPS 51n31, 7e28<br />
:Occupation: Student<br />
<br />
=== Jonathan Gray ===<br />
:Handle: [[User:khalek|khalek]]<br />
:ScummVM: Engine: SCUMM, HE, Broken Sword 2<br />
:Location: Australia, Melbourne, GPS 37s49, 144e58<br />
:Occupation: <br />
<br />
=== Sven Hesse ===<br />
:Handle: [[User:DrMcCoy|DrMcCoy]]<br />
:ScummVM: Engine: Gob<br />
:Location: Germany, Braunschweig, GPS 52n16, 10e31<br />
:Occupation: Student (computer science)<br />
<br />
=== Travis Howell ===<br />
:Handle: [[User:Kirben|Kirben]]<br />
:ScummVM: Engine: SCUMM, HE, AGOS<br />
:Location: Australia, Melbourne, GPS 37s49, 144e58<br />
:Occupation: <br />
<br />
=== Oliver Kiehl ===<br />
:Handle: [[User:Olki|olki]]<br />
:ScummVM: Engine: Beneath a Steel Sky, AGOS<br />
:Location: UK, Cardiff, GPS 51n29, 3w13<br />
:Occupation: Postgraduate Student<br />
<br />
=== Pawe&#322; Ko&#322;odziejski ===<br />
:Handle: [[User:Aquadran|Aquadran]]<br />
:ScummVM: Engine: SCUMM (Codecs, iMUSE, Smush, etc.)<br />
:Location:<br />
:Occupation:<br />
<br />
=== Andrew Kurushin ===<br />
:Handle: [[User:ajax16384|ajax16384]]<br />
:ScummVM: Engine: SAGA<br />
:Location: Russia, Ivanovo, GPS 57n0, 40e59<br />
:Occupation:<br />
<br />
=== Gregory Montoir ===<br />
:Handle: [[User:Cyx|Cyx]]<br />
:ScummVM: Engine: Flight of the Amazon Queen, HE, Kyra<br />
:Location: France, Rennes, GPS 48n05, 1w41<br />
:Occupation: <br />
<br />
=== Willem Jan Palenstijn ===<br />
:Handle: [[User:wjp|wjp]]<br />
:ScummVM: Engine: Gob, Packaging for Fedora/RedHat<br />
:Location: The Netherlands, Leiden, GPS 52n10, 4e30<br />
:Occupation: PhD student (math) <br />
<br />
=== Joost Peters ===<br />
:Handle: [[User:JoostP|JoostP]]<br />
:ScummVM: Engine: Beneath a Steel Sky, Flight of the Amazon Queen, Port: PSP<br />
:Location: The Netherlands, 's-Hertogenbosch, GPS 51n42, 5e19<br />
:Occupation:<br />
<br />
=== Johannes Schickel ===<br />
:Handle: [[User:LordHoto|LordHoto]]<br />
:ScummVM: Engine: Kyra, GUI improvements<br />
:Location: Germany, Gelnhausen, GPS 50n11, 9e11<br />
:Occupation: <br />
<br />
=== Chris Apers ===<br />
:Handle: [[User:chrilith|chrilith]]<br />
:ScummVM: Port: PalmOS<br />
:Location: France, Neuilly sur Marne, GPS 48n51, 2e32<br />
:Occupation: <br />
:Website: http://capers.free.fr/<br />
<br />
=== Nicolas Bacca ===<br />
:Handle: [[User:Arisme|Arisme]]<br />
:ScummVM: Port: Windows CE<br />
:Location: France, Courbevoie, GPS 48n54, 2e15<br />
:Occupation: SIM cards, mobility & stuff :)<br />
:Website: http://arisme.free.fr/<br />
<br />
=== Kostas Nakos ===<br />
:Handle: [[User:knakos|knakos]] aka Jubanka<br />
:ScummVM: Port: Windows CE<br />
:Location: Greece, Athens, GPS 38n01, 23e42<br />
:Occupation: PhD Student<br />
:Website: http://users.uoa.gr/~knakos and http://pocketatari.atari.org<br />
<br />
=== Jurgen Braam ===<br />
:Handle: [[User:SumthinWicked|SumthinWicked]]<br />
:ScummVM: Port: SymbianOS maintainer<br />
:Location: The Netherlands, Amsterdam, GPS 52n22, 4e54<br />
:Occupation: Student, CEO<br />
:Website: http://territory.cjb.net/<br />
<br />
=== Marcus Comstedt ===<br />
:Handle: [[User:Zeldin|Zeldin]]<br />
:ScummVM: Port: Dreamcast<br />
:Location: Sweden, Linköping, GPS 58n25, 15e37<br />
:Occupation: <br />
:Website: [http://www.lysator.liu.se/~marcus/ ]<br />
<br />
=== Hans-J&ouml;rg Frieden ===<br />
:Handle: [[User:HJF|HJF]]<br />
:ScummVM: Port: AmigaOS 4<br />
:Location: Germany, Trier, GPS 49n45, 6e38<br />
:Occupation: <br />
:Website: http://www.hyperion-entertainment.com/<br />
<br />
=== Lars Persson ===<br />
:Handle: [[User:Anotherguest|Anotherguest]]<br />
:ScummVM: Port: SymbianOS, ESDL<br />
:Location: Sweden, Malmö, GPS 55n36, 13e0<br />
:Occupation:<br />
:Website: http://anotherguest.b0.se/<br />
<br />
=== Won Star ===<br />
:Handle: [[User:wonst719|wonst719]]<br />
:ScummVM: Port: GP32<br />
:Location: South Korea, GPS 34n85, 128e59<br />
:Occupation:<br />
<br />
=== Jerome Fisher ===<br />
:Handle: [[User:KingGuppy|KingGuppy]]<br />
:ScummVM: MT-32 emulator<br />
:Location: Germany, Wuppertal, GPS 51n16, 7e11<br />
:Occupation: <br />
<br />
=== Jochen Hoenicke ===<br />
:Handle: [[User:hoenicke|hoenicke]]<br />
:ScummVM: Speaker &amp; PCjr sound support, Adlib work<br />
:Location: Germany, Oldenburg, GPS 53n08, 8e13<br />
:Occupation:<br />
<br />
=== Joachim Eberhard ===<br />
:Handle: [[User:joachimeberhard|joachimeberhard]]<br />
:ScummVM: For numerous contributions to documentation<br />
:Location: Austria, Lannach<br />
:Occupation: Self-employed<br />
<br />
=== David Symonds ===<br />
:Handle: [[User:Dsymonds|dsymonds]]<br />
:ScummVM: AGI Engine<br />
:Location: Australia, Sydney, GPS 33s52, 151e13<br />
:Occupation: PhD student (Comp. Sci), Software Engineer<br />
<br />
== Retired Team Members ==<br />
<br />
<br />
=== Ralph Brorsen ===<br />
:Handle: [[User:painelf|painelf]]<br />
:ScummVM: Help with GUI implementation<br />
:Location: Denmark, Copenhagen, GPS 55n40, 12e35<br />
:Occupation: <br />
:Website: [http://www.ojuice.net/1163/nick.htm ]<br />
<br />
=== Jamieson Christian ===<br />
:Handle: [[User:jamieson630|jamieson630]]<br />
:ScummVM: iMUSE, MIDI, all things musical<br />
:Location: USA, Madison WI, GPS 43n04, 89w24<br />
:Occupation: <br />
<br />
=== Vincent Hamm ===<br />
:Handle: [[User:yazoo|yazoo]]<br />
:ScummVM: Co-Founder<br />
:Location: France, Paris, GPS 48n52, 2e20<br />
:Occupation:<br />
:Website: http://www.yaz0r.net/<br />
<br />
=== Ruediger Hanke ===<br />
:Handle: <br />
:ScummVM: Port: MorphOS<br />
:Location: Germany, Paderborn, GPS 51n43, 8e45<br />
:Occupation: <br />
:Website: [http://wwwcs.uni-paderborn.de/cs/ag-monien/LEHRE/WS00_01/PG_PVMS/members.htm ]<br />
<br />
=== Felix Jakschitsch ===<br />
:Handle: [[User:yot|yot]]<br />
:ScummVM: Zak256 reverse engineering<br />
:Location: Germany<br />
:RIP: 13 March 2003, [http://www.scummvm.org/?shownews=archive#2003-03-18 scummvm.org news]<br />
<br />
=== Mutwin Kraus ===<br />
:Handle: [[User:mutle|mutle]]<br />
:ScummVM: Original MacOS porter<br />
:Location: Germany, Düsseldorf, GPS 51n12, 6e47<br />
:Occupation: <br />
<br />
=== Peter Moraliyski ===<br />
:Handle: [[User:ph0x|ph0x]]<br />
:ScummVM: Port: GP32<br />
:Location: Hungary, Budapest, GPS 47n30, 19e05<br />
:Occupation: <br />
:Website: [http://www.ojuice.net/6484/nick.htm ]<br />
<br />
=== Jeremy Newman ===<br />
:Handle: [[User:laxdragon|laxdragon]]<br />
:ScummVM: Former webmaster<br />
:Location: USA, Minneapolis MN, GPS 44n59, 93w16<br />
:Occupation: <br />
:Website: http://www.dracowulf.com/<br />
<br />
=== Ludvig Strigeus ===<br />
:Handle: [[User:ludde|ludde]]<br />
:ScummVM: Original ScummVM and SimonVM author<br />
:Location: Sweden, Gothenburg, GPS 57n43, 11e58<br />
:Occupation: <br />
<br />
=== Lionel Ulmer ===<br />
:Handle: [[User:bbrox|bbrox]]<br />
:ScummVM: Port: X11<br />
:Location: France, Toulouse, GPS 43n36, 1e26<br />
:Occupation: <br />
<br />
<br />
== Contributors ==<br />
<br />
<br />
=== Tore Anderson ===<br />
:Handle: [[User:tore|tore]]<br />
:ScummVM: Packaging for Debian GNU/Linux<br />
:Location: Norway, Oslo, GPS 59n55, 10e45<br />
:Occupation: <br />
<br />
=== Dob&oacute; Bal&aacute;zs ===<br />
:Handle: [[User:draven|draven]]<br />
:ScummVM: Website design<br />
:Location: Hungary<br />
:Occupation: <br />
<br />
=== Stuart Caie ===<br />
:Handle: [[User:Kyzer|Kyzer]]<br />
:ScummVM: Decoders for Simon 1 Amiga data files<br />
:Location: Scotland/UK, Edinburgh, GPS 55n57, 3w13<br />
:Occupation: <br />
<br />
=== Yaroslav Fedevych ===<br />
:Handle: [[User:jafd|jafd]]<br />
:ScummVM: HTML/CSS for the website<br />
:Location: Ukraine, Lviv, GPS 49n51, 23e59<br />
:Occupation:<br />
<br />
=== Chris Gray ===<br />
:Handle: [[User:Psychoid|Psychoid]]<br />
:ScummVM: Windows64 builds<br />
:Location: UK, Middlesbrough, GPS 54n35, 1w14<br />
:Occupation: <br />
<br />
=== Matthew Hoops ===<br />
:Handle: [[User:Clone2727|clone2727]]<br />
:ScummVM: Wiki editor<br />
:Location: USA, Edison NJ, GPS 40n31, 74w25<br />
:Occupation:<br />
<br />
=== Janne Huttunen ===<br />
:Handle: <br />
:ScummVM: V3 actor mask support, Dig/FT SMUSH audio<br />
:Location: Finland, Kuopio, GPS 62n54, 27e41<br />
:Occupation: <br />
<br />
=== Kov&aacute;cs Endre J&aacute;nos ===<br />
:Handle: [[User:KovacsUr|KovacsUr]]<br />
:ScummVM: Several fixes for Simon1<br />
:Location: Hungary<br />
:Occupation: <br />
<br />
=== Jeroen Janssen ===<br />
:Handle: [[User:japj|japj]]<br />
:ScummVM: Numerous readability and bugfix patches<br />
:Location: The Netherlands<br />
:Occupation: <br />
<br />
=== Andreas Karlsson ===<br />
:Handle: [[User:Sprawl|Sprawl]]<br />
:ScummVM: Initial port for EPOC/SymbianOS<br />
:Location: Sweden, Gothenburg, GPS 57n43, 11e58<br />
:Occupation: <br />
:Website: http://dreo.org/<br />
<br />
=== Robert Kelsen ===<br />
:Handle: <br />
:ScummVM: Packaging for SlackWare<br />
:Location: Australia, Melbourne, GPS 37s49, 144e58<br />
:Occupation: <br />
:Website: http://members.optusnet.com.au/rkelsen/<br />
<br />
=== Jean Marc ===<br />
:Handle: <br />
:ScummVM: ScummVM logo<br />
:Location: <br />
:Occupation: <br />
<br />
=== Claudio Matsuoka ===<br />
:Handle: <br />
:ScummVM: Daily Linux builds<br />
:Location: Brazil, Curitiba, GPS 25s2540, 49w1623<br />
:Occupation: <br />
<br />
=== Mikesch Nepomuk ===<br />
:Handle: <br />
:ScummVM: MI1 VGA floppy patches, initial sound support Indy3/MI1<br />
:Location: Germany, Koblenz, GPS 50n21, 7e35<br />
:Occupation: Systems Engineer f. Internet Security<br />
<br />
=== Juha Niemimäki ===<br />
:Handle: <br />
:ScummVM: AmigaOS 4 port maintaining<br />
:Location: Finland, Oulu, GPS 65n01, 25e28<br />
:Occupation: <br />
<br />
=== Nicolas Noble ===<br />
:Handle: [[User:pixel|pixel]]<br />
:ScummVM: Config file and ALSA support<br />
:Location: France, Moulins-les-metz, GPS 49n08, 6e10<br />
:Occupation: <br />
<br />
=== Stefan Parviainen ===<br />
:Handle: [[User:pafcu|pafcu]]<br />
:ScummVM: Packaging for BeOS<br />
:Location: Finland, Helsinki, GPS 60n10, 24e58<br />
:Occupation: <br />
<br />
=== 'Quietust' ===<br />
:Handle: [[User:Quietust|Quietust]]<br />
:ScummVM: Sound support for Amiga SCUMM V2/V3 games, MM NES support<br />
:Location: GPS 43n0, 88w0<br />
:Occupation: <br />
:Website: http://qmt.ath.cx/~quietust/<br />
<br />
=== Andreas Röver ===<br />
:Handle: <br />
:ScummVM: Broken Sword 1/2 MPEG2 cutscene support<br />
:Location: Germany, Erfurt, GPS 50n58, 11e01<br />
:Occupation:<br />
<br />
=== Edward Rudd ===<br />
:Handle: <br />
:ScummVM: Fixes for playing MP3 versions of MI1/Loom audio<br />
:Location: <br />
:Occupation: <br />
<br />
=== Daniel Schepler ===<br />
:Handle: <br />
:ScummVM: Final MI1 CD music support, initial Ogg Vorbis support<br />
:Location: <br />
:Occupation: <br />
<br />
=== Paul Smedley ===<br />
:Handle: [[User:Creeping|Creeping]]<br />
:ScummVM: OS/2 fixes and packaging<br />
:Location: <br />
:Occupation: <br />
<br />
=== Andr&eacute; Souza ===<br />
:Handle: <br />
:ScummVM: SDL-based OpenGL renderer<br />
:Location: <br />
:Occupation: <br />
<br />
=== Tim ??? ===<br />
:Handle: [[User:realmz|realmz]]<br />
:ScummVM: Initial MI1 CD music support<br />
:Location: <br />
:Occupation:<br />
<br />
=== Ori Avtalion ===<br />
:Handle: [[User:Salty-horse|salty-horse]]<br />
:ScummVM: Subtitle controls, bug reports<br />
:Location: Israel, Avichail, GPS 32n35175, 34e8688<br />
:Occupation: Programmer<br />
<br />
== Special thanks to ==<br />
<br />
<br />
=== Sander Buskens ===<br />
:Handle: <br />
:ScummVM: For his work on the initial reversing of Monkey2<br />
:Location: <br />
:Occupation: <br />
<br />
=== 'Canadacow' ===<br />
:Handle: [[User:Canadacow|Canadacow]]<br />
:ScummVM: For the original MT-32 emulator<br />
:Location: <br />
:Occupation: <br />
<br />
=== Kevin Carnes ===<br />
:Handle: <br />
:ScummVM: For Scumm16, the basis of ScummVM's older gfx codecs<br />
:Location: <br />
:Occupation: <br />
<br />
=== Ivan Dubrov ===<br />
:Handle: <br />
:ScummVM: For contributing the initial version of the Gobliiins engine<br />
:Location: <br />
:Occupation: <br />
<br />
=== 'Jezar' ===<br />
:Handle: [[User:Jezar|Jezar]]<br />
:ScummVM: For his freeverb filter implementation<br />
:Location: <br />
:Occupation: <br />
<br />
=== Jim Leiterman ===<br />
:Handle: <br />
:ScummVM: Various :Location: <br />
:Occupation: on his FM-TOWNS/Marty SCUMM ports<br />
:Location: <br />
:Occupation: <br />
<br />
=== 'lloyd' ===<br />
:Handle: [[User:lloyd|lloyd]]<br />
:ScummVM: For deep tech details about C64 Zak &amp; MM<br />
:Location: <br />
:Occupation: <br />
<br />
=== Jimmi Th&oslash;gersen ===<br />
:Handle: <br />
:ScummVM: For ScummRev, and much obscure code/documentation<br />
:Location: <br />
:Occupation: <br />
<br />
=== 'Tristan' ===<br />
:Handle: [[User:Tristan|Tristan]]<br />
:ScummVM: For additional work on the original MT-32 emulator<br />
:Location: <br />
:Occupation:</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Template_talk:GameDescription&diff=4644Template talk:GameDescription2007-01-09T01:10:48Z<p>Dsymonds: </p>
<hr />
<div>==Image Section==<br />
First off, thanks to [[User:Md5|Md5]] for adding this. The screenshots add some color. ;)<br />
<br />
Secondly, this causes certain games that we don't have support for (ie. [[Escape from Monkey Island]], [[Broken Sword 3]], etc.) to have '''{{{Image}}}''' in this template. I don't know how everyone else feels about this, but it doesn't exactly look right to see that written there. Maybe we could just put something like "Not Supported in ScummVM" in the image place? -[[User:Clone2727|Clone2727]] 22:19, 8 January 2007 (UTC)<br />
<br />
I've fixed it. You needed a pipe ("|") at the end of ''image:'' <nowiki>{{{image|}}}</nowiki> or <nowiki>{{{image|foo bar}}}</nowiki><br />
<br />
The stuff after the pipe will be substituted if the ''image'' variable is undefined.<br />
<br />
--[[User:Dsymonds|dsymonds]] 00:36, 9 January 2007 (UTC)<br />
<br />
:Thanks a lot! -[[User:Clone2727|Clone2727]] 01:05, 9 January 2007 (UTC)<br />
<br />
Bizarreness: [[Space_Quest]] is working, but not [[Space_Quest_II]] for some reason. Huh?<br />
<br />
--[[User:Dsymonds|dsymonds]] 01:10, 9 January 2007 (UTC)</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Space_Quest_II&diff=4642Space Quest II2007-01-09T01:07:40Z<p>Dsymonds: </p>
<hr />
<div>{{GameDescription|<br />
name=Space Quest II: Vohaul's Revenge|<br />
image=[[Image:Space-Quest-2.png]]|<br />
release=1987|<br />
alternateNames=Space Quest II<br/>SQ2|<br />
publisher=[[Sierra]]|<br />
developer=[[Sierra]]|<br />
platforms=MS-DOS, Tandy 1000<br/> Mac, Apple II<br/> Apple IIGS, Amiga<br/> Atari ST, PCjr|<br />
engine=[[AGI]]|<br />
support=Not officially supported.<br/>A WIP engine is available<br/>in our SVN repository.<br />
}}<br />
'''Space Quest II: Vohaul's Revenge''' was the second game in the [[Space Quest series]]. The game follows Roger Wilco, who is newly appointed to Xenon Orbital Station 4 and promoted to head (and only) janitor. He is abducted by Sludge Vohaul, and survives a crash landing while in transport to the Labion labour mines. Roger must make his way to Vohaul's asteroid base and once again stop him from destroying life on the planet Xenon.<br />
<br />
==External links==<br />
*[http://en.wikipedia.org/wiki/Space_Quest_II:_Vohaul%27s_Revenge Wikipedia article on Space Quest II]<br />
<br />
[[Category:Games]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Space_Quest_II&diff=4639Space Quest II2007-01-09T01:02:30Z<p>Dsymonds: Silly wiki...</p>
<hr />
<div>{{GameDescription|<br />
name=Space Quest II: Vohaul's Revenge|<br />
image=http://wiki.scummvm.org/images/a/ad/Space-Quest-2.png|<br />
release=1987|<br />
alternateNames=Space Quest II<br/>SQ2|<br />
publisher=[[Sierra]]|<br />
developer=[[Sierra]]|<br />
platforms=MS-DOS, Tandy 1000<br/> Mac, Apple II<br/> Apple IIGS, Amiga<br/> Atari ST, PCjr|<br />
engine=[[AGI]]|<br />
support=Not officially supported.<br/>A WIP engine is available<br/>in our SVN repository.<br />
}}<br />
'''Space Quest II: Vohaul's Revenge''' was the second game in the [[Space Quest series]]. The game follows Roger Wilco, who is newly appointed to Xenon Orbital Station 4 and promoted to head (and only) janitor. He is abducted by Sludge Vohaul, and survives a crash landing while in transport to the Labion labour mines. Roger must make his way to Vohaul's asteroid base and once again stop him from destroying life on the planet Xenon.<br />
<br />
==External links==<br />
*[http://en.wikipedia.org/wiki/Space_Quest_II:_Vohaul%27s_Revenge Wikipedia article on Space Quest II]<br />
<br />
[[Category:Games]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Space_Quest_II&diff=4638Space Quest II2007-01-09T00:57:48Z<p>Dsymonds: Add screenshot</p>
<hr />
<div>{{GameDescription|<br />
name=Space Quest II: Vohaul's Revenge|<br />
image=[[Image:Space-Quest-2.png]]|<br />
release=1987|<br />
alternateNames=Space Quest II<br/>SQ2|<br />
publisher=[[Sierra]]|<br />
developer=[[Sierra]]|<br />
platforms=MS-DOS, Tandy 1000<br/> Mac, Apple II<br/> Apple IIGS, Amiga<br/> Atari ST, PCjr|<br />
engine=[[AGI]]|<br />
support=Not officially supported.<br/>A WIP engine is available<br/>in our SVN repository.<br />
}}<br />
'''Space Quest II: Vohaul's Revenge''' was the second game in the [[Space Quest series]]. The game follows Roger Wilco, who is newly appointed to Xenon Orbital Station 4 and promoted to head (and only) janitor. He is abducted by Sludge Vohaul, and survives a crash landing while in transport to the Labion labour mines. Roger must make his way to Vohaul's asteroid base and once again stop him from destroying life on the planet Xenon.<br />
<br />
==External links==<br />
*[http://en.wikipedia.org/wiki/Space_Quest_II:_Vohaul%27s_Revenge Wikipedia article on Space Quest II]<br />
<br />
[[Category:Games]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=File:Space-Quest-2.png&diff=4637File:Space-Quest-2.png2007-01-09T00:57:18Z<p>Dsymonds: </p>
<hr />
<div></div>Dsymondshttps://wiki.scummvm.org/index.php?title=Space_Quest&diff=4636Space Quest2007-01-09T00:51:48Z<p>Dsymonds: Whoops ... bad wiki link</p>
<hr />
<div>{{GameDescription|<br />
name=Space Quest: The Sarien Encounter|<br />
image=[[Image:Space-Quest-1.png]]|<br />
release=1984|<br />
alternateNames=Space Quest I<br/>SQ, SQ1|<br />
publisher=[[Sierra]]|<br />
developer=[[Sierra]]|<br />
platforms=MS-DOS, Tandy 1000<br/> Mac, Apple II<br/> Apple IIGS, Amiga<br/> Atari ST, PCjr|<br />
engine=[[AGI]], SCI|<br />
support=Not officially supported.<br/>A WIP AGI engine is available<br/>in our SVN repository. The<br/>SCI version is not supported.<br />
}}<br />
'''Space Quest: The Sarien Encounter''' was the first game in the [[Space Quest series]]. The game follows a janitor on board the scientific spaceship Arcada. After waking from an on-duty nap in a broom closet, he discovers that an evil alien race called the Sariens stole the Star Generator, an experimental weapon that was being held on board, and killed all of the Arcada's crew members.<br />
<br />
After crash landing on the planet Kerona, Roger must find a way to sneak aboard the the Sarien starship Deltaur to stop the vicious aliens from using the Star Generator against Roger's home planet of Xenon.<br />
<br />
==External links==<br />
*[http://en.wikipedia.org/wiki/Space_Quest_I:_The_Sarien_Encounter Wikipedia article on Space Quest]<br />
*[http://www.sq7.org/omnipedia/index.php/Category:SQ1 Omnipedia article on Space Quest]<br />
<br />
[[Category:Games]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Space_Quest&diff=4635Space Quest2007-01-09T00:50:13Z<p>Dsymonds: Add screenshot</p>
<hr />
<div>{{GameDescription|<br />
name=Space Quest: The Sarien Encounter|<br />
image=Space-Quest-1.png|<br />
release=1984|<br />
alternateNames=Space Quest I<br/>SQ, SQ1|<br />
publisher=[[Sierra]]|<br />
developer=[[Sierra]]|<br />
platforms=MS-DOS, Tandy 1000<br/> Mac, Apple II<br/> Apple IIGS, Amiga<br/> Atari ST, PCjr|<br />
engine=[[AGI]], SCI|<br />
support=Not officially supported.<br/>A WIP AGI engine is available<br/>in our SVN repository. The<br/>SCI version is not supported.<br />
}}<br />
'''Space Quest: The Sarien Encounter''' was the first game in the [[Space Quest series]]. The game follows a janitor on board the scientific spaceship Arcada. After waking from an on-duty nap in a broom closet, he discovers that an evil alien race called the Sariens stole the Star Generator, an experimental weapon that was being held on board, and killed all of the Arcada's crew members.<br />
<br />
After crash landing on the planet Kerona, Roger must find a way to sneak aboard the the Sarien starship Deltaur to stop the vicious aliens from using the Star Generator against Roger's home planet of Xenon.<br />
<br />
==External links==<br />
*[http://en.wikipedia.org/wiki/Space_Quest_I:_The_Sarien_Encounter Wikipedia article on Space Quest]<br />
*[http://www.sq7.org/omnipedia/index.php/Category:SQ1 Omnipedia article on Space Quest]<br />
<br />
[[Category:Games]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=File:Space-Quest-1.png&diff=4634File:Space-Quest-1.png2007-01-09T00:49:28Z<p>Dsymonds: </p>
<hr />
<div></div>Dsymondshttps://wiki.scummvm.org/index.php?title=Template_talk:GameDescription&diff=4633Template talk:GameDescription2007-01-09T00:36:50Z<p>Dsymonds: /* Image Section */</p>
<hr />
<div>==Image Section==<br />
First off, thanks to [[User:Md5|Md5]] for adding this. The screenshots add some color. ;)<br />
<br />
Secondly, this causes certain games that we don't have support for (ie. [[Escape from Monkey Island]], [[Broken Sword 3]], etc.) to have '''{{{Image}}}''' in this template. I don't know how everyone else feels about this, but it doesn't exactly look right to see that written there. Maybe we could just put something like "Not Supported in ScummVM" in the image place? -[[User:Clone2727|Clone2727]] 22:19, 8 January 2007 (UTC)<br />
<br />
I've fixed it. You needed a pipe ("|") at the end of ''image:'' <nowiki>{{{image|}}}</nowiki> or <nowiki>{{{image|foo bar}}}</nowiki><br />
<br />
The stuff after the pipe will be substituted if the ''image'' variable is undefined.<br />
<br />
--[[User:Dsymonds|dsymonds]] 00:36, 9 January 2007 (UTC)</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Template_talk:GameDescription&diff=4632Template talk:GameDescription2007-01-09T00:36:21Z<p>Dsymonds: </p>
<hr />
<div>==Image Section==<br />
First off, thanks to [[User:Md5|Md5]] for adding this. The screenshots add some color. ;)<br />
<br />
Secondly, this causes certain games that we don't have support for (ie. [[Escape from Monkey Island]], [[Broken Sword 3]], etc.) to have '''{{{Image}}}''' in this template. I don't know how everyone else feels about this, but it doesn't exactly look right to see that written there. Maybe we could just put something like "Not Supported in ScummVM" in the image place? -[[User:Clone2727|Clone2727]] 22:19, 8 January 2007 (UTC)<br />
<br />
I've fixed it. You needed a pipe ("|") at the end of ''image:'' <nowiki>{{{image|}}}</nowiki><br />
<br />
The stuff after the pipe will be substituted if the ''image'' variable is undefined.<br />
<br />
--[[User:Dsymonds|dsymonds]] 00:36, 9 January 2007 (UTC)</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Template:GameDescription&diff=4631Template:GameDescription2007-01-09T00:30:26Z<p>Dsymonds: Yay! The fix works!</p>
<hr />
<div>{| border="0" cellpadding="2" cellspacing="1" align="right" style="margin-left:1em; background:#CADCFB;"<br />
!colspan="3" | {{{name}}}<br />
|- border="0" cellpadding="2" cellspacing="1" align="center" style="margin-left:1em; background:#ffffff;"<br />
|- align="center" style="background:#ffffff"<br />
!colspan="3" | {{{image|<i>no screenshot available</i>}}}<br />
|- style="background:#ffffff"<br />
|First release || {{{release}}}<br />
|- style="background:#ffffff"<br />
|Also known as || {{{alternateNames}}}<br />
|- style="background:#ffffff"<br />
|Published by || {{{publisher}}}<br />
|- style="background:#ffffff"<br />
|Developed by || {{{developer}}}<br />
|- style="background:#ffffff"<br />
|Platforms || {{{platforms}}}<br />
|- style="background:#ffffff"<br />
|Engine || {{{engine}}}<br />
|- style="background:#ffffff"<br />
|Support || {{{support}}}<br />
|}</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Template:GameDescription&diff=4630Template:GameDescription2007-01-09T00:29:44Z<p>Dsymonds: test a fix</p>
<hr />
<div>{| border="0" cellpadding="2" cellspacing="1" align="right" style="margin-left:1em; background:#CADCFB;"<br />
!colspan="3" | {{{name}}}<br />
|- border="0" cellpadding="2" cellspacing="1" align="center" style="margin-left:1em; background:#ffffff;"<br />
|- align="center" style="background:#ffffff"<br />
!colspan="3" | {{{image|}}}<br />
|- style="background:#ffffff"<br />
|First release || {{{release}}}<br />
|- style="background:#ffffff"<br />
|Also known as || {{{alternateNames}}}<br />
|- style="background:#ffffff"<br />
|Published by || {{{publisher}}}<br />
|- style="background:#ffffff"<br />
|Developed by || {{{developer}}}<br />
|- style="background:#ffffff"<br />
|Platforms || {{{platforms}}}<br />
|- style="background:#ffffff"<br />
|Engine || {{{engine}}}<br />
|- style="background:#ffffff"<br />
|Support || {{{support}}}<br />
|}</div>Dsymondshttps://wiki.scummvm.org/index.php?title=User:Dsymonds&diff=4613User:Dsymonds2007-01-07T22:59:04Z<p>Dsymonds: update email address</p>
<hr />
<div><tt>dsymonds</tt> is a developer in the ScummVM Project, working on the AGI engine.<br />
<br />
He can be contacted via email at: dsymonds _at_ scummvm _dot_ org<br />
<br />
--[[User:Dsymonds|dsymonds]] 22:59, 7 January 2007 (UTC)</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Sarien/Hires_Badness&diff=4603Sarien/Hires Badness2007-01-06T17:59:46Z<p>Dsymonds: Add note about completion of hires-removal</p>
<hr />
<div>As of r25037, the ''hires'' mode is all gone, and the AGI engine is a thousand lines lighter.<br />
<br />
--[[User:Dsymonds|dsymonds]] 17:59, 6 January 2007 (UTC)<br />
<br />
----<br />
<br />
Sarien's ''hires'' mode causes some behavioural glitches, and should be removed in favour of leaving these Scale2x-style graphical enhancements to the ScummVM backends, especially since it can be made optional at that point.<br />
<br />
The primary problem comes from [[AGI/Specifications/Overview#Priority|AGI's priority screens]], which control how the background scenery and the movable objects interact. For the uninitiated, you can think of it as a sort of "depth channel" (by analogy with an alpha channel). To add more complexity, [[AGI/Specifications/Overview#Control_lines|control lines]] are also drawn on the priority screen, and they are responsible for the demarcation of no-go areas and for triggering various events (opening automatic doors, triggering traps, etc.).<br />
<br />
AGI is a fairly touchy engine, and really requires pixel-perfect rendering internally; the ''hires'' mode thus causes a few problems, because it effectively smears the sharp borders that the rest of the AGI engine expects, leading to incorrect interpretation.<br />
<br />
At the very least, this is redundant code, since the ScummVM backends can do the Scale2x effects, and have it configurable too!<br />
<br />
=== Space Quest 2 ===<br />
These aren't actually errors, but give a feel for what could go wrong in other places.<br />
<br />
[[Image:sarien-hires-craft.png]]<br />
<br />
[[Image:sarien-hires-body.png]]<br />
<br />
Below is the priority screen for that room. Different colours are different depths: the ego can walk "between" the aqua bushes on the left and the green bushes on the right, but only when he's at the right "priority".<br />
<br />
[[Image:sarien-hires-priority.png]]<br />
<br />
In fact, a bit further in to the game: (notice the diagonal control lines)<br />
<br />
[[Image:sq2-rm11.png]]<br />
<br />
<br />
[[Image:sq2-rm11-pri.png]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Sarien/Hires_Badness&diff=4565Sarien/Hires Badness2007-01-06T13:24:11Z<p>Dsymonds: Add more explanation</p>
<hr />
<div>Sarien's ''hires'' mode causes some behavioural glitches, and should be removed in favour of leaving these Scale2x-style graphical enhancements to the ScummVM backends, especially since it can be made optional at that point.<br />
<br />
The primary problem comes from [[AGI_Specifications/Overview#Priority|AGI's priority screens]], which control how the background scenery and the movable objects interact. For the uninitiated, you can think of it as a sort of "depth channel" (by analogy with an alpha channel). To add more complexity, [[AGI_Specifications/Overview#Control_lines|control lines]] are also drawn on the priority screen, and they are responsible for the demarcation of no-go areas and for triggering various events (opening automatic doors, triggering traps, etc.).<br />
<br />
AGI is a fairly touchy engine, and really requires pixel-perfect rendering internally; the ''hires'' mode thus causes a few problems, because it effectively smears the sharp borders that the rest of the AGI engine expects, leading to incorrect interpretation.<br />
<br />
At the very least, this is redundant code, since the ScummVM backends can do the Scale2x effects, and have it configurable too!<br />
<br />
=== Space Quest 2 ===<br />
These aren't actually errors, but give a feel for what could go wrong in other places.<br />
<br />
[[Image:sarien-hires-craft.png]]<br />
<br />
[[Image:sarien-hires-body.png]]<br />
<br />
Below is the priority screen for that room. Different colours are different depths: the ego can walk "between" the aqua bushes on the left and the green bushes on the right, but only when he's at the right "priority".<br />
<br />
[[Image:sarien-hires-priority.png]]<br />
<br />
In fact, a bit further in to the game: (notice the diagonal control lines)<br />
<br />
[[Image:sq2-rm11.png]]<br />
<br />
<br />
[[Image:sq2-rm11-pri.png]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Sarien/Hires_Badness&diff=4564Sarien/Hires Badness2007-01-06T13:21:34Z<p>Dsymonds: added more screenshots</p>
<hr />
<div>Sarien's ''hires'' mode causes some behavioural glitches, and should be removed in favour of leaving these Scale2x-style graphical enhancements to the ScummVM backends, especially since it can be made optional at that point.<br />
<br />
The primary problem comes from [[AGI_Specifications/Overview#Priority|AGI's priority screens]], which control how the background scenery and the movable objects interact. For the uninitiated, you can think of it as a sort of "depth channel" (by analogy with an alpha channel). To add more complexity, [[AGI_Specifications/Overview#Control_lines|control lines]] are also drawn on the priority screen, and they are responsible for the demarcation of no-go areas and for triggering various events (opening automatic doors, triggering traps, etc.).<br />
<br />
AGI is a fairly touchy engine, and really requires pixel-perfect rendering internally; the ''hires'' mode thus causes a few problems, because it effectively smears the sharp borders that the rest of the AGI engine expects, leading to incorrect interpretation.<br />
<br />
<br />
=== Space Quest 2 ===<br />
These aren't actually errors, but give a feel for what could go wrong in other places.<br />
<br />
[[Image:sarien-hires-craft.png]]<br />
<br />
[[Image:sarien-hires-body.png]]<br />
<br />
Below is the priority screen for that room. Different colours are different depths: the ego can walk "between" the aqua bushes on the left and the green bushes on the right, but only when he's at the right "priority".<br />
<br />
[[Image:sarien-hires-priority.png]]<br />
<br />
In fact, a bit further in to the game: (notice the diagonal control lines)<br />
<br />
[[Image:sq2-rm11.png]]<br />
<br />
<br />
[[Image:sq2-rm11-pri.png]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=File:Sq2-rm11-pri.png&diff=4563File:Sq2-rm11-pri.png2007-01-06T13:20:59Z<p>Dsymonds: </p>
<hr />
<div></div>Dsymondshttps://wiki.scummvm.org/index.php?title=File:Sq2-rm11.png&diff=4562File:Sq2-rm11.png2007-01-06T13:20:22Z<p>Dsymonds: </p>
<hr />
<div></div>Dsymondshttps://wiki.scummvm.org/index.php?title=File:Sarien-hires-priority.png&diff=4561File:Sarien-hires-priority.png2007-01-06T13:12:46Z<p>Dsymonds: </p>
<hr />
<div></div>Dsymondshttps://wiki.scummvm.org/index.php?title=Sarien/Hires_Badness&diff=4560Sarien/Hires Badness2007-01-06T13:12:26Z<p>Dsymonds: </p>
<hr />
<div>Sarien's ''hires'' mode causes some behavioural glitches, and should be removed in favour of leaving these Scale2x-style graphical enhancements to the ScummVM backends, especially since it can be made optional at that point.<br />
<br />
The primary problem comes from [[AGI_Specifications/Overview#Priority|AGI's priority screens]], which control how the background scenery and the movable objects interact. For the uninitiated, you can think of it as a sort of "depth channel" (by analogy with an alpha channel). To add more complexity, [[AGI_Specifications/Overview#Control_lines|control lines]] are also drawn on the priority screen, and they are responsible for the demarcation of no-go areas and for triggering various events (opening automatic doors, triggering traps, etc.).<br />
<br />
AGI is a fairly touchy engine, and really requires pixel-perfect rendering internally; the ''hires'' mode thus causes a few problems, because it effectively smears the sharp borders that the rest of the AGI engine expects, leading to incorrect interpretation.<br />
<br />
<br />
=== Space Quest 2 ===<br />
These aren't actually errors, but give a feel for what could go wrong in other places.<br />
<br />
[[Image:sarien-hires-craft.png]]<br />
<br />
[[Image:sarien-hires-body.png]]<br />
<br />
Below is the priority screen for that room. Different colours are different depths: the ego can walk "between" the aqua bushes on the left and the green bushes on the right, but only when he's at the right "priority".<br />
<br />
[[Image:sarien-hires-priority.png]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Sarien/Hires_Badness&diff=4559Sarien/Hires Badness2007-01-06T13:08:27Z<p>Dsymonds: </p>
<hr />
<div>Sarien's ''hires'' mode causes some behavioural glitches, and should be removed in favour of leaving these Scale2x-style graphical enhancements to the ScummVM backends, especially since it can be made optional at that point.<br />
<br />
The primary problem comes from [[AGI_Specifications/Overview#Priority|AGI's priority screens]], which control how the background scenery and the movable objects interact. For the uninitiated, you can think of it as a sort of "depth channel" (by analogy with an alpha channel). To add more complexity, [[AGI_Specifications/Overview#Control_lines|control lines]] are also drawn on the priority screen, and they are responsible for the demarcation of no-go areas and for triggering various events (opening automatic doors, triggering traps, etc.).<br />
<br />
AGI is a fairly touchy engine, and really requires pixel-perfect rendering internally; the ''hires'' mode thus causes a few problems, because it effectively smears the sharp borders that the rest of the AGI engine expects, leading to incorrect interpretation.<br />
<br />
<br />
=== Space Quest 2 ===<br />
These aren't actually errors, but give a feel for what could go wrong in other places.<br />
<br />
[[Image:sarien-hires-craft.png]]<br />
<br />
[[Image:sarien-hires-body.png]]<br />
<br />
Below is the priority screen for that room. Different colours are different depths: the ego can walk "between" the aqua bushes on the left and the green bushes on the right, but only when he's at the right "priority".<br />
<br />
[[Image:Sq2-priority-screen.png]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Sarien/Hires_Badness&diff=4558Sarien/Hires Badness2007-01-06T13:06:09Z<p>Dsymonds: Corrected wild accusation about a particular instance of what I think is still a problem.</p>
<hr />
<div>Sarien's ''hires'' mode causes some behavioural glitches, and should be removed in favour of leaving these Scale2x-style graphical enhancements to the ScummVM backends, especially since it can be made optional at that point.<br />
<br />
The primary problem comes from [[AGI_Specifications/Overview#Priority|AGI's priority screens]], which control how the background scenery and the movable objects interact. For the uninitiated, you can think of it as a sort of "depth channel" (by analogy with an alpha channel). To add more complexity, [[AGI_Specifications/Overview#Control_lines|control lines]] are also drawn on the priority screen, and they are responsible for the demarcation of no-go areas and for triggering various events (opening automatic doors, triggering traps, etc.).<br />
<br />
AGI is a fairly touchy engine, and really requires pixel-perfect rendering internally; the ''hires'' mode thus causes a few problems, because it effectively smears the sharp borders that the rest of the AGI engine expects, leading to incorrect interpretation.<br />
<br />
<br />
=== Space Quest 2 ===<br />
These aren't actually errors, but give a feel for what could go wrong in other places.<br />
<br />
[[Image:sarien-hires-craft.png]]<br />
<br />
[[Image:sarien-hires-body.png]]<br />
<br />
This is the priority screen for that room:<br />
<br />
[[Image:Sq2-priority-screen.png]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=File:Sq2-priority-screen.png&diff=4557File:Sq2-priority-screen.png2007-01-06T13:05:32Z<p>Dsymonds: </p>
<hr />
<div></div>Dsymondshttps://wiki.scummvm.org/index.php?title=Sarien/Hires_Badness&diff=4555Sarien/Hires Badness2007-01-06T11:54:04Z<p>Dsymonds: add info about control lines</p>
<hr />
<div>Sarien's ''hires'' mode causes some behavioural glitches, and should be removed in favour of leaving these Scale2x-style graphical enhancements to the ScummVM backends, especially since it can be made optional at that point.<br />
<br />
The primary problem comes from [[AGI_Specifications/Overview#Priority|AGI's priority screens]], which control how the background scenery and the movable objects interact. For the uninitiated, you can think of it as a sort of "depth channel" (by analogy with an alpha channel). To add more complexity, [[AGI_Specifications/Overview#Control_lines|control lines]] are also drawn on the priority screen, and they are responsible for the demarcation of no-go areas and for triggering various events (opening automatic doors, triggering traps, etc.).<br />
<br />
AGI is a fairly touchy engine, and really requires pixel-perfect rendering internally; the ''hires'' mode thus causes a few problems, because it effectively smears the sharp borders that the rest of the AGI engine expects, leading to incorrect interpretation.<br />
<br />
Here's a couple of screenshots from Space Quest 2 to demonstrate the kind of things that go wrong:<br />
<br />
[[Image:sarien-hires-craft.png]]<br />
<br />
[[Image:sarien-hires-body.png]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Sarien/Hires_Badness&diff=4554Sarien/Hires Badness2007-01-06T11:31:19Z<p>Dsymonds: fix wiki link</p>
<hr />
<div>Sarien's ''hires'' mode causes some behavioural glitches, and should be removed in favour of leaving these Scale2x-style graphical enhancements to the ScummVM backends, especially since it can be made optional at that point.<br />
<br />
The primary problem comes from [[AGI_Specifications/Overview#Priority|AGI's priority screens]], which control how the background scenery and the movable objects interact. For the uninitiated, you can think of it as a sort of "depth channel" (by analogy with an alpha channel).<br />
<br />
AGI is a fairly touchy engine, and really requires pixel-perfect rendering internally; the ''hires'' mode thus causes a few problems.<br />
<br />
Here's a couple of screenshots from Space Quest 2 to demonstrate the kind of things that go wrong:<br />
<br />
[[Image:sarien-hires-craft.png]]<br />
<br />
[[Image:sarien-hires-body.png]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Sarien/Hires_Badness&diff=4553Sarien/Hires Badness2007-01-06T11:30:21Z<p>Dsymonds: more info about why the priority screen is important to AGI</p>
<hr />
<div>Sarien's ''hires'' mode causes some behavioural glitches, and should be removed in favour of leaving these Scale2x-style graphical enhancements to the ScummVM backends, especially since it can be made optional at that point.<br />
<br />
The primary problem comes from [[AGI_Specifications/Overview#Priority AGI's priority screens]], which control how the background scenery and the movable objects interact. For the uninitiated, you can think of it as a sort of "depth channel" (by analogy with an alpha channel).<br />
<br />
AGI is a fairly touchy engine, and really requires pixel-perfect rendering internally; the ''hires'' mode thus causes a few problems.<br />
<br />
Here's a couple of screenshots from Space Quest 2 to demonstrate the kind of things that go wrong:<br />
<br />
[[Image:sarien-hires-craft.png]]<br />
<br />
[[Image:sarien-hires-body.png]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Sarien/Hires_Badness&diff=4552Sarien/Hires Badness2007-01-06T11:14:52Z<p>Dsymonds: </p>
<hr />
<div>Sarien's ''hires'' mode causes some behavioural glitches, and should be removed in favour of leaving these Scale2x-style graphical enhancements to the ScummVM backends, especially since it can be made optional at that point.<br />
<br />
AGI is a fairly touchy engine, and really requires pixel-perfect rendering internally; the ''hires'' mode thus causes a few problems.<br />
<br />
Here's a couple of screenshots from Space Quest 2 to demonstrate the kind of things that go wrong:<br />
<br />
[[Image:sarien-hires-craft.png]]<br />
<br />
[[Image:sarien-hires-body.png]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=File:Sarien-hires-craft.png&diff=4551File:Sarien-hires-craft.png2007-01-06T11:13:09Z<p>Dsymonds: </p>
<hr />
<div></div>Dsymondshttps://wiki.scummvm.org/index.php?title=File:Sarien-hires-body.png&diff=4550File:Sarien-hires-body.png2007-01-06T11:12:05Z<p>Dsymonds: </p>
<hr />
<div></div>Dsymondshttps://wiki.scummvm.org/index.php?title=Copyright_FAQ&diff=4549Copyright FAQ2007-01-06T10:30:11Z<p>Dsymonds: Fixed copyright term length</p>
<hr />
<div>This '''Copyright FAQ''' exists to clear up the legal situation of the games supported by ScummVM and to address common issues.<br />
<br />
==Why is copying/downloading my favorite LucasArts game a problem?==<br />
<br />
Apart from the obvious (the game was written by people with commercial intent, they own it, so they can ask you not to get it for free) copying games also endangers the ScummVM project.<br />
<br />
Providing support for obviously "warezed" versions of games could create the impression that ScummVM promotes copyright violations. Needless to say, this is not in the interest of the ScummVM developers. Game companies often keep a close eye on projects which are re-implementing their game engines; any negative connotation makes it more likely for a project to be shut down.<br />
<br />
==Game XY isn't being sold any more. Is it ok to download it?==<br />
<br />
Unless declared otherwise by the copyright holder you are not allowed to get the game free of charge. You can find most games for purchase on [http://www.ebay.com eBay].<br />
<br />
==What about abandonware?==<br />
<br />
Abandonware is not a proper legal concept. Copyright of computer software seems to end 95 years after publication (at least in the [http://en.wikipedia.org/wiki/Copyright_law_of_the_United_States#Duration_of_copyright USA]). Feel free to check back in around 2080 if you're allowed to download the games then.<br />
<br />
==What am I allowed to download free of charge?==<br />
* [[Beneath a Steel Sky]]<br />
* [[Flight of the Amazon Queen]]<br />
* [[Lure of the Temptress]]<br />
* video packs for Broken Sword 1 and Broken Sword 2<br />
* demos of copyrighted games<br />
* [[ScummVM]] itself, of course :)<br />
<br />
==Which other games am I allowed to download legally?==<br />
* Check [http://www.liberatedgames.com/ Liberated Games]<br />
<br />
==Legal disclaimer==<br />
While this document was written with the best intentions, the author is not a lawyer. If you know that something in here is obviously wrong, make a suggestion, don't sue. :)</div>Dsymondshttps://wiki.scummvm.org/index.php?title=Sarien/Hires_Badness&diff=4547Sarien/Hires Badness2007-01-06T10:16:14Z<p>Dsymonds: Create Sarien/Hires page</p>
<hr />
<div>Sarien's ''hires'' mode causes some behavioural glitches, and should be removed in favour of leaving these Scale2x-style graphical enhancements to the ScummVM backends.<br />
<br />
Here's a couple of screenshots from Space Quest 2 to demonstrate the kind of things that go wrong:<br />
<br />
[[Image:sarien-hires-craft.png]]<br />
<br />
[[Image:sarien-hires-body.png]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=AGI&diff=4546AGI2007-01-06T10:10:32Z<p>Dsymonds: add link</p>
<hr />
<div>== About ==<br />
The AGI (Adventure Game Interpreter) engine was used by Sierra in their early adventure games. The AGI engine was used in the following games:<br />
* [[King's Quest]] (1984)<br />
* [[King's Quest II]] (1985)<br />
* [[The Black Cauldron]] (1986)<br />
* [[Donald Duck's Playground]] (1986)<br />
* [[King's Quest III]] (1986)<br />
* [[Space Quest]] (1986)<br />
* [[Leisure Suit Larry]] (1987)<br />
* [[Mixed-Up Mother Goose]] (1987)<br />
* [[Police Quest]] (1987)<br />
* [[Space Quest II]] (1987)<br />
* [[Gold Rush]] (1988)<br />
* [[King's Quest IV]] (1988)<br />
* [[Manhunter]] (1988)<br />
* [[Manhunter 2]] (1989)<br />
<br />
It was also used in a digital "christmas card" given by Sierra to computer stores in 1986 to demonstrate the capabilities of the computers at the time, as well as the capabilities of the AGI engine. The program was designed to be started in the morning and run throughout the entire Christmas day.<br />
<br />
This module is from the Sarien project, used with permission.<br />
<br />
== Resources ==<br />
* [[AGI/TODO|AGI TODO]]: TODO Page<br />
* [[AGI/Fan Games|AGI Fan Games]]: Fan created games using the AGI engine<br />
* [[AGI Specifications]]: AGI Specs, based on version 3.0, with our modifications<br />
* [[Sierra Game Versions]]: Versions of Sierra's Games (AGI & SCI)<br />
<br />
== Old Sarien Screenshots ==<br />
* [[Sarien/HallofShame|Sarien Hall of Shame]]: Development Outtakes<br />
* [[Sarien/EndScreens|Sarien End Screens]]: Games Finished with Sarien<br />
* [[Sarien/Features|Sarien Features]]<br />
* [[Sarien/Hires_Badness|Sarien Hires badness]]<br />
<br />
==External links==<br />
* [http://en.wikipedia.org/wiki/Adventure_Game_Interpreter Wikipedia on AGI]<br />
* [http://sarien.sourceforge.net/ Sarien homepage]<br />
* [http://www.classicgaming.com/agisci/sierradm.shtml AGI/SCI Demos and Christmas Cards] <br />
* [http://web.archive.org/web/20021027082346/www.mega-tokyo.com/sarien/index.php3?menu=games&page=demo_packs AGI Demo Packs and KQ4 Demo]<br />
<br />
[[Category:Engines]]</div>Dsymondshttps://wiki.scummvm.org/index.php?title=AGI/Specifications/Savegame&diff=4545AGI/Specifications/Savegame2007-01-06T08:29:41Z<p>Dsymonds: more formatting tweaks, plus more info</p>
<hr />
<div>----<br />
This is a '''WORK IN PROGRESS'''; do not rely on this information, and please [[User:Dsymonds|let Dave know]] if you're going to be changing this in any significant way.<br />
----<br />
<br />
Where a numeric value is specified over multiple bytes, it is always ''little-endian'', unless otherwise noted.<br />
<br />
<br />
=== Header (40 bytes) ===<br />
'''0-30''' (31 bytes) Savegame description. This can be up to 30 printable characters, and is padded out with NUL (\0) bytes to a total of 31 bytes.<br />
<br />
'''31-32''' (2 bytes) Unknown (0xE1 0x05); maybe a savegame version number?<br />
<br />
'''33-39''' (7 bytes) Game ID ("SQ2", "KQ3", "LLLLL", etc.), NUL padded.<br />
<br />
=== Game state ===<br />
'''40-295''' (256 bytes) Variables, 1 variable per byte<br />
<br />
'''296-327''' (32 bytes) Flags, 8 flags per byte<br />
<br />
'''328-331''' (4 bytes) Clock ticks since game started. 1 clock tick == 50ms.<br />
<br />
...<br />
<br />
'''344-345''' (2 bytes) ? 1 => player_control<br />
<br />
'''346-347''' (2 bytes) Current [[AGI_Specifications/Pic|PICTURE]]<br />
<br />
...<br />
<br />
'''356-555''' (200 bytes) ? Controller map (50 controllers, 4 bytes each)<br />
<br />
'''556-1515''' (960 bytes) 24 strings, each 40 bytes long.<br />
<br />
'''1516-1521''' (6 bytes) ? Text colours<br />
<br />
=== Other bits ===<br />
'''2334-?''' (? bytes) Inventory object names, each NUL terminated.</div>Dsymondshttps://wiki.scummvm.org/index.php?title=AGI/Specifications/Savegame&diff=4544AGI/Specifications/Savegame2007-01-06T08:24:16Z<p>Dsymonds: /* Game state */</p>
<hr />
<div>----<br />
This is a '''WORK IN PROGRESS'''; do not rely on this information, and please [[User:Dsymonds|let Dave know]] if you're going to be changing this in any significant way.<br />
----<br />
<br />
Where a numeric value is specified over multiple bytes, it is always ''little-endian'', unless otherwise noted.<br />
<br />
<br />
=== Header (40 bytes) ===<br />
'''Bytes 0-30''' (31 bytes) Savegame description. This can be up to 30 printable characters, and is padded out with NUL (\0) bytes to a total of 31 bytes.<br />
<br />
'''Bytes 31-32''' (2 bytes) Unknown (0xE1 0x05); maybe a savegame version number?<br />
<br />
'''Bytes 33-39''' (7 bytes) Game ID ("SQ2", "KQ3", "LLLLL", etc.), NUL padded.<br />
<br />
=== Game state ===<br />
'''Bytes 40-295''' (256 bytes) Variables, 1 variable per byte<br />
<br />
'''Bytes 296-327''' (32 bytes) Flags, 8 flags per byte<br />
<br />
'''Bytes 328-331''' (4 bytes) Clock ticks since game started. 1 clock tick == 50ms.<br />
<br />
...<br />
<br />
'''344-345''' (2 bytes) ? 1 => player_control<br />
<br />
'''346-347''' (2 bytes) Current [[AGI_Specifications/Pic|PICTURE]]<br />
<br />
...<br />
<br />
'''356-555''' (200 bytes) ? Controller map (50 controllers, 4 bytes each)<br />
<br />
'''Bytes 556-1515''' (960 bytes) 24 strings, each 40 bytes long.<br />
<br />
=== Other bits ===<br />
'''Bytes 2334-?''' (? bytes) Inventory object names, each NUL terminated.</div>Dsymondshttps://wiki.scummvm.org/index.php?title=AGI/Specifications/Savegame&diff=4543AGI/Specifications/Savegame2007-01-06T08:18:20Z<p>Dsymonds: more info</p>
<hr />
<div>----<br />
This is a '''WORK IN PROGRESS'''; do not rely on this information, and please [[User:Dsymonds|let Dave know]] if you're going to be changing this in any significant way.<br />
----<br />
<br />
Where a numeric value is specified over multiple bytes, it is always ''little-endian'', unless otherwise noted.<br />
<br />
<br />
=== Header (40 bytes) ===<br />
'''Bytes 0-30''' (31 bytes) Savegame description. This can be up to 30 printable characters, and is padded out with NUL (\0) bytes to a total of 31 bytes.<br />
<br />
'''Bytes 31-32''' (2 bytes) Unknown (0xE1 0x05); maybe a savegame version number?<br />
<br />
'''Bytes 33-39''' (7 bytes) Game ID ("SQ2", "KQ3", "LLLLL", etc.), NUL padded.<br />
<br />
=== Game state ===<br />
'''Bytes 40-295''' (256 bytes) Variables, 1 variable per byte<br />
<br />
'''Bytes 296-327''' (32 bytes) Flags, 8 flags per byte<br />
<br />
'''Bytes 328-331''' (4 bytes) Clock ticks since game started, little-endian. 1 clock tick == 50ms.<br />
<br />
...<br />
<br />
'''344-345''' (2 bytes) ? 1 => player_control<br />
<br />
'''346-347''' (2 bytes) Current [[AGI_Specifications/Pic|PICTURE]]<br />
<br />
...<br />
<br />
'''356-555''' (200 bytes) ? Controller map (50 controllers, 4 bytes each)<br />
<br />
'''Bytes 556-1515''' (960 bytes) 24 strings, each 40 bytes long.<br />
<br />
=== Other bits ===<br />
'''Bytes 2334-?''' (? bytes) Inventory object names, each NUL terminated.</div>Dsymondshttps://wiki.scummvm.org/index.php?title=AGI/Specifications/Savegame&diff=4542AGI/Specifications/Savegame2007-01-06T08:14:29Z<p>Dsymonds: note about endianness</p>
<hr />
<div>----<br />
This is a '''WORK IN PROGRESS'''; do not rely on this information, and please [[User:Dsymonds|let Dave know]] if you're going to be changing this in any significant way.<br />
----<br />
<br />
Where a numeric value is specified over multiple bytes, it is always ''little-endian'', unless otherwise noted.<br />
<br />
<br />
=== Header (40 bytes) ===<br />
'''Bytes 0-30''' (31 bytes) Savegame description. This can be up to 30 printable characters, and is padded out with NUL (\0) bytes to a total of 31 bytes.<br />
<br />
'''Bytes 31-32''' (2 bytes) Unknown (0xE1 0x05); maybe a savegame version number?<br />
<br />
'''Bytes 33-39''' (7 bytes) Game ID ("SQ2", "KQ3", "LLLLL", etc.), NUL padded.<br />
<br />
=== Game state ===<br />
'''Bytes 40-295''' (256 bytes) Variables, 1 variable per byte<br />
<br />
'''Bytes 296-327''' (32 bytes) Flags, 8 flags per byte<br />
<br />
<br />
'''Bytes 328-331''' (4 bytes) Clock ticks since game started, little-endian. 1 clock tick == 50ms.<br />
<br />
...<br />
<br />
'''Bytes 556-1515''' (960 bytes) 24 strings, each 40 bytes long. Actually, I'm not positive that it's all 24 strings; it could only be 12 strings in some versions!<br />
<br />
=== Other bits ===<br />
'''Bytes 2334-?''' (? bytes) Inventory object names, each NUL terminated.</div>Dsymonds