{% set title = "Adidas Runtastic | Alessio Laiso" %} {% set description = "Runtastic is a leader in the digital health and fitness space, providing optimized tracking solutions for collecting, managing and analyzing training data." %} {% extends "portfolio/_layout.html" %} {% block content %}
Runtastic is a leader in the digital health and fitness space, providing optimized tracking solutions for collecting, managing and analyzing training data. In my time with the company, I worked on their suite of apps both before and after the startup was acquired by Adidas in 2015.
Adidas Runtastic
Sep 2014–Dec 2015
Health and fitness is an extremely competitive space for mobile apps. In a team of four, I was one of the designers who took care of the design of the whole suite of Runtastic apps (about a dozen at the time). I took the lead on multiple projects for both iOS and Android, working closely with Apple and Google on their wearable operating systems and early versions of Material Design. I was part of cross-platform user research and user experience discussions, as well as producing assets like icons and illustrations.
As dedicated fitness and sleep trackers were increasing in popularity, Runtastic set to the vision of giving the community an app to learn more about their sleep patterns without the need of a device other than their phone. To build Sleep Better, the team perfected sleep algorithms working together with a sleep lab and gaining insights from sleep specialists. Note: the Sleep better app was discontinued in September 2019 - 4 years after Runtastic was aquired by Adidas.
When I joined Runtastic, in September 2014, the launch of Sleep Better was due in two months, but the Android design was far behind the iOS design, with many cross-platform decisions still to be made.
I took the responsibility of designing most of the Android screens of the app, also taking part in cross-platform discussions. Working close with the three other designers in the team, developers and the project manager was an effective way to get me up to speed quickly in the new company. Five months later, in March 2015, I was the main designer responsible for Sleep Better for iPad and Android tablets.
A great effort was put into aligning the two platforms (iOS and Android) as much as possible while making the experience feel native to both. Sleep Better for Android was the first Runtastic app designed following Google’s Material Design guidelines, which were extensive but still immature, and kept on changing quite often. As a result of this, we quickly had to find new solutions and adapt our designs. Feedback from internal and external users was core to how we iterated on our designs, and we run extensive user research to refine our concept and improve the usability of the app. In addition to this, we collaborated with the engineering team to improve the sleep tracking algorithm.
Sleep Better's launch was Runtastic’s most successful launch ever, with many downloads in the first week and huge featurings in the app stores and media coverage. The quality and speed of my work were really appreciated by the team and were very important for a timely launch of the app.
Runtastic Libra is a smart scale that analyses body metrics — including weight, body fat and water percentage — and can transfer data to a smartphone using Bluetooth. The company had launched the scale in the Fall 2013, but one year later the companion app was still only available for iOS. Customers were often writing to the support team and on social media, asking when the Android app would finally be released. Note: after Runtastic was aquired by Adidas in August 2015, the company stopped selling hardware and the Libra app was discontinued in September 2019.
I was the lead designer of the Android app, discussing the screens with the designer who had worked on the iOS version, and working closely with the developers who were implementing the UI. The synergy with the project manager and the developers was great, and led to a great human and professional esteem among the members of the team.
The iOS design was taken as a starting point for the Android app, to offer a consistent experience across the platforms. Rather than just reskinning the iOS app, we gathered feedback from existing users to see how we could improve the experience. We identified and interviewed external users as well as some colleagues from other teams in the company who were using the scale with the iOS app.
While a few users complained about Bluetooth connectivity issues with the scale, the general feedback about the UX was positive. However, the graph showing the history of the measurements was obscure to many. The redesign of the legend at the right of the graph, with clear units of measurements for both weight and body fat percentage, led to a massive improvement in our usability testing sessions.
Some power users also complained it was hard to keep track of changes in their body
composition. Opening one measurement at a time — and remembering each value — was the only way to do so. To
make this comparison easier, we decided to provide the users with a full body composition graph showing the
percentages of each value (body fat, muscles, tissue, bones) as they change through time.
In
addition to this, when users set goals in the app (like “lose 4 kg by the 1st of June”) they were not able
to see how they were progressing toward that goal in the weight history graph. With the addition of a simple
dashed line, we made that very easy to understand at a glance.
The Runtastic community was really happy to finally be able to use the Libra scale with Android devices. The interface was one of the most praised aspects of the app in the reviews in the Store. In addition to this, the great team work on this project made the whole team look forward to working together again in our next project.
Shortly after I started working at Runtastic, the company launched the Material Design overhaul of the flagship app. In the following months, we received some feedback from Google and I took the responsibility of redesigning some of the screens as well as designing some news ones. The newly introduced running leaderboard, for example, added an important social element that significantly increased user engagement.
Runtastic’s imagery was quite inconsistent when I joined the company. During my time there I produced many illustrations and assets, leading the team effort to find a consistent style. As a part of this work, I redesigned the the Runtastic icon set, optimizing the icons on the pixel grid and using consistent visual traits across over 100 icons.
Following these updates, the Runtastic app for Android was included in the Editor’s choice collection and was one of the 15 apps included in the Material Design Showcase at Google I/O 2015.
In the Spring of 2015 Google UK launched a campaign for Android with the slogan “Be together. Not the same.”, in which Runtastic had a huge featuring.
The Runtastic app was also featured in the “Build better” video series by Facebook, for the F8 conference in 2015.


Reading Question 5.
In Islamic law, riba, which can mean interest or excessive interest, depedning on interpretation, is prohibited. Instead, a system called murabaha is used. Explain what murabaha is and how it differs from an interest-bearing loan. Do you think this system is more or less fair to borrowers? Is it more or less fair to lenders? Explain why you gave the answers that you did. Do you think this system could be a good alternative to payday loans? Why or why not?


fun setDisabled(disabled: Boolean): CommandBuilder<T>
Sets whether the command to build is disabled.
Return The current CommandBuilder instance.


This document demonstrates the ability of the calibre DOCX Input plugin to convert the various typographic features in a Microsoft Word (2007 and newer) document. Convert this document to a modern ebook format, such as AZW3 for Kindles or EPUB for other ebook readers, to see it in action.
There is support for images, tables, lists, footnotes, endnotes, links, dropcaps and various types of text and paragraph level formatting.
To see the DOCX conversion in action, simply add this file to calibre using the “Add Books” button and then click “Convert”. Set the output format in the top right corner of the conversion dialog to EPUB or AZW3 and click “OK”.
Here, we demonstrate various types of inline text formatting and the use of embedded fonts.
Here is some bold, italic, bold-italic, underlined and struck out text. Then, we have a superscript and a subscript. Now we see some red, green and blue text. Some text with a yellow highlight. Some text in a box. Some text in inverse video.
A paragraph with styled text: subtle emphasis followed by strong text and intense emphasis. This paragraph uses document wide styles for styling rather than inline text properties as demonstrated in the previous paragraph — calibre can handle both with equal ease.
This document has embedded the Ubuntu font family. The body text is in the Ubuntu typeface, here is some text in the Ubuntu Mono typeface, notice how every letter has the same width, even i and m. Every embedded font will automatically be embedded in the output ebook during conversion.
You can do crazy things with paragraphs, if the urge strikes you. For instance this paragraph is right aligned and has a right border. It has also been given a light gray background.
For the lovers of poetry amongst you, paragraphs with hanging indents, like this often come in handy. You can use hanging indents to ensure that a line of poetry retains its individual identity as a line even when the screen is too narrow to display it as a single line. Not only does this paragraph have a hanging indent, it is also has an extra top margin, setting it apart from the preceding paragraph.
| ITEM | NEEDED |
|---|---|
| Books | 1 |
| Pens | 3 |
| Pencils | 2 |
| Highlighter | 2 colors |
| Scissors | 1 pair |
Tables in Word can vary from the extremely simple to the extremely complex. calibre tries to do its best when converting tables. While you may run into trouble with the occasional table, the vast majority of common cases should be converted very well, as demonstrated in this section. Note that for optimum results, when creating tables in Word, you should set their widths using percentages, rather than absolute units. To the left of this paragraph is a floating two column table with a nice green border and header row.
Now let’s look at a fancier table—one with alternating row colors and partial borders. This table is stretched out to take 100% of the available width.
| City or Town | Point A | Point B | Point C | Point D | Point E |
|---|---|---|---|---|---|
| Point A | — | ||||
| Point B | 87 | — | |||
| Point C | 64 | 56 | — | ||
| Point D | 37 | 32 | 91 | — | |
| Point E | 93 | 35 | 54 | 43 | — |
Next, we see a table with special formatting in various locations. Notice how the formatting for the header row and sub header rows is preserved.
| College | New students | Graduating students | Change |
|---|---|---|---|
| Undergraduate | |||
| Cedar University | 110 | 103 | +7 |
| Oak Institute | 202 | 210 | -8 |
| Graduate | |||
| Cedar University | 24 | 20 | +4 |
| Elm College | 43 | 53 | -10 |
| Total | 998 | 908 | 90 |
Source: Fictitious data, for illustration purposes only
Next, we have something a little more complex, a nested table, i.e. a table inside another table. Additionally, the inner table has some of its cells merged. The table is displayed horizontally centered.
|
To the left is a table inside a table, with some cells merged. |
We end with a fancy calendar, note how much of the original formatting is preserved. Note that this table will only display correctly on relatively wide screens. In general, very wide tables or tables whose cells have fixed width requirements don’t fare well in ebooks.
| December 2007 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Sun | Mon | Tue | Wed | Thu | Fri | Sat | ||||||
| 1 | ||||||||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 | ||||||
| 9 | 10 | 11 | 12 | 13 | 14 | 15 | ||||||
| 16 | 17 | 18 | 19 | 20 | 21 | 22 | ||||||
| 23 | 24 | 25 | 26 | 27 | 28 | 29 | ||||||
| 30 | 31 |
Miscellaneous structural elements you can add to your document, like footnotes, endnotes, dropcaps and the like.
Footnotes1 and endnotes2 are automatically recognized and both are converted to endnotes, with backlinks for maximum ease of use in ebook devices.
Drop caps are used to emphasize the leading paragraph at the start of a section. In Word it is possible to specify how many lines of text a drop-cap should use. Because of limitations in ebook technology, this is not possible when converting. Instead, the converted drop cap will use font size and line height to simulate the effect as well as possible. While not as good as the original, the result is usually tolerable. This paragraph has a “D” dropcap set to occupy three lines of text with a font size of 58.5 pts. Depending on the screen width and capabilities of the device you view the book on, this dropcap can look anything from perfect to ugly.
Two kinds of links are possible, those that refer to an external website and those that refer to locations inside the document itself. Both are supported by calibre. For example, here is a link pointing to the calibre download page. Then we have a link that points back to the section on paragraph level formatting in this document.
There are two approaches that calibre takes when generating a Table of Contents. The first is if the Word document has a Table of Contents itself. Provided that the Table of Contents uses hyperlinks, calibre will automatically use it. The levels of the Table of Contents are identified by their left indent, so if you want the ebook to have a multi-level Table of Contents, make sure you create a properly indented Table of Contents in Word.
If no Table of Contents is found in the document, then a table of contents is automatically generated from the headings in the document. A heading is identified as something that has the Heading 1 or Heading 2, etc. style applied to it. These headings are turned into a Table of Contents with Heading 1 being the topmost level, Heading 2 the second level and so on.
You can see the Table of Contents created by calibre by clicking the Table of Contents button in whatever viewer you are using to view the converted ebook.
Demonstration of DOCX support in calibre 1
Images can be of three main types. Inline images are images that are part of the normal text flow, like this image of a green dot . Inline images do not cause breaks in the text and are usually small in size. The next category of image is a floating image, one that “floats “ on the page and is surrounded by text. Word supports more types of floating images than are possible with current ebook technology, so the conversion maps floating images to simple left and right floats, as you can see with the left and right arrow images on the sides of this paragraph.
The final type of image is a “block” image, one that becomes a paragraph on its own and has no text on either side. Below is a centered green dot.
Centered images like this are useful for large pictures that should be a focus of attention.
Generally, it is not possible to translate the exact positioning of images from a Word document to an ebook. That is because in Word, image positioning is specified in absolute units from the page boundaries. There is no analogous technology in ebooks, so the conversion will usually end up placing the image either centered or floating close to the point in the text where it was inserted, not necessarily where it appears on the page in Word.
All types of lists are supported by the conversion, with the exception of lists that use fancy bullets, these get converted to regular bullets.
One
Two
One, with a very long line to demonstrate that the hanging indent for the list is working correctly
Two
One
Two
Three
Four with a very long line to demonstrate that the hanging indent for the list is working correctly.
Five
Six
A Multi-level list with bullets:
One
Two
This bullet uses an image as the bullet item
Four
Five
One
Two
An interruption in our regularly scheduled listing, for this essential and very relevant public service announcement.
We now resume our normal programming
Four
In paged media, footnotes are usually displayed at the bottom of the text. However, in ebooks, a better paradigm is to make them clickable endnotes that the user can browse at her pleasure. This conversion is handled automatically by calibre.↩
Endnotes are typically used for longer notes, they remain endnotes when converted into ebook form, except that they have an additional backlink to make it easy to return to the current position after reading the note.↩


By developing this website for the Coffee Can café, we aim to increase its customers in all its branches including attracting more immediate neighbourhood clientele.
Such increase would be achieved by advertising events, presenting a food menu, notifying of suspended coffees, and displaying the eco-friendly happy atmosphere which the café holds.
A further goal is improving the local profile of the cafe beyond the community's apparent shared memory of a Convenience store.
All graphical content is from media supplied by the client. Text content is either paraphrased from content supplied by the client, or where indicated, entirely fictitious.
Username: cp3402
Password: CoffeeCan.3402
A Virtual Private Server (and unpopular domain name) was secured on which to host the staging and production wordpress environments. A full VPS was preferable because the hosting environment and control-panel-only admin method offered by many hosting providers can seem a little restrictive (non-standard ports for SSH access, etc.). The ability to gain root-level shell access to the web server was considered essential for efficient management of the project's infrastructure.
All developers ran their own *AMPP stack (3 WAMPP, 1 MAMPP, 1 LAMPP), rather than utilising a virtual machine environment such as Vagrant. Each developer managed their own *AMPP stack, thus this choice was warranted by efficient (self-)management of each developer's environment.
The Trello board was replaced by a GitHub Projects board when we realised it was being underutilised. GitHub Projects is a tool that was trusted and actully used, thus it was the more appropriate tool for the task.
Various utility scripts and resources for the development team were developed and stored in the work/
directory of our repository. Chief among these was utilities.php
, which allowed individual developers to share monolithic database dumps after customising database-resident URLs to their particular environments. In this way, we all worked on effectively, the same database.


原文地址:https://github.com/labuladong/fucking-algorithm/blob/master/算法思维系列/双指针技巧.md
Translator: miaoxiaozui2017
Author: labuladong
I divide the double pointer technique into two categories.One is fast-and-slow pointer
,and the other is left-and-right pointer
. The former mainly solves the problems in the linked list, such as the typical problem of determination of whether a ring is included in the linked list
.And the latter mainly solves the problems in the array (or string), such as binary search
.
The fast-and-slow pointers are usually initialized to point to the head node of the linked list. When moving forward, the fast
pointer is in the front and the slow
pointer is in the back, which ingeniously solves some problems in the linked list.
1. Determine whether there is a ring in the linked list
This should be the most basic operation of linked list. If the reader already knows this skill, this part can be skipped.
The feature of single linked list is that each node only knows the next node, so a pointer can’t judge whether there is a ring in the linked list.
If there is no ring in the linked list, then this pointer will eventually encounter a null pointer indicating that the linked list is at the end.This is a good situation that it can be judged directly that the linked list does not contain a ring.
While if the linked list contains a ring, the pointer will fall into a dead loop
because there is no null
pointer as the tail node in the ring array.
The classic solution is to use two pointers—one is fast,and the other is slow. If there is no ring, the fast pointer will eventually encounter null
indicating that the linked list does not contain a ring.Or if there is a ring, the fast pointer will eventually exceed the slow pointer by a circle indicating that the linked list contains a ring.
boolean hasCycle(ListNode head) {
ListNode fast, slow;
fast = slow = head;
while (fast != null && fast.next != null) {
fast = fast.next.next;
slow = slow.next;
if (fast == slow) return true;
}
return false;
}
2.A ring is known to exist in the linked list.Return the starting position of this ring
This problem is not difficult at all. It’s a bit like a brain teaser. First, look at the code directly:
ListNode detectCycle(ListNode head) {
ListNode fast, slow;
fast = slow = head;
while (fast != null && fast.next != null) {
fast = fast.next.next;
slow = slow.next;
if (fast == slow) break;
}
//The above code is similar to the hascycle function
slow = head;
while (slow != fast) {
fast = fast.next;
slow = slow.next;
}
return slow;
}
It can be seen that when the fast and slow pointers meet, let any of them points to the head node, and then let them advance at the same speed. When they meet again, the node position is the starting position of the ring. Why is that?
At the first meeting
, if the slow
pointer takes k
steps, then the fast
pointer must take 2k
steps, that is to say, it takes k
steps more than the slow
pointer (or in another word,the length of the ring).
If the distance between the meeting point and the starting point of the ring is m
, then the distance between the starting point of the ring and the head
node is k - m
. That is to say, if we advance k - m
steps from the head
node, we can reach the starting point of the ring.
Coincidentally, if we continue to move k - m
steps from the meeting point, we will also arrive at the starting point of the ring.
So, as long as we point any one of the fast and slow pointers back to head
, and then the two pointers move at the same speed after k - m
steps they will meet at the starting point of the ring.
3. Find the midpoint of the linked list
Similar to the above idea, we can also make the fast pointer advance two steps at a time and the slow pointer advance one step at a time. When the fast pointer reaches the end of the linked list, the slow pointer is exactly in the middle of the linked list.
while (fast != null && fast.next != null) {
fast = fast.next.next;
slow = slow.next;
}
//slow is in the middle
return slow;
When the length of the linked list is odd, slow
happens to stop at the midpoint.If the length is even, the final position of slow
is right in the middle:
An important role in finding the midpoint of a linked list is to merge and sort the linked list.
Recall the merging and sorting
of arrays: find the midpoint index to divide the arrays recursively, and finally merge the two ordered arrays. For linked list, it is very simple to merge two ordered linked lists, and the difficulty lies in dichotomy.
But now that you have learned finding the midpoint of a linked list
, you can achieve the dichotomy of a linked list. For the details of merging and sorting
, this paper will not expand specifically.
4. Looking for the last k element of the linked list
Our idea is still to use the fast-and-slow pointer
.Let the fast
pointer go k
steps first, and then the fast
and slow
pointer starts to move at the same speed. In this way, when the fast
pointer goes to null
at the end of the linked list, the position of the slow
pointer is the last k
list node (for simplification, suppose k
not exceed the length of the linked list):
ListNode slow, fast;
slow = fast = head;
while (k-- > 0)
fast = fast.next;
while (fast != null) {
slow = slow.next;
fast = fast.next;
}
return slow;
The left-and-right pointer in the array actually refer to two index values, which are usually initialized as left = 0
and right = nums.length - 1
.
The previous paper binary search
is explained in detail. Here only the simplest binary algorithm is written to stick out its double pointer feature:
int binarySearch(int[] nums, int target) {
int left = 0;
int right = nums.length - 1;
while(left <= right) {
int mid = (right + left) / 2;
if(nums[mid] == target)
return mid;
else if (nums[mid] < target)
left = mid + 1;
else if (nums[mid] > target)
right = mid - 1;
}
return -1;
}
Let’s take a look at a leetcode question:
As long as the array is ordered, you should think of the double pointer technique. The solution of this problem is similar to binary search. The size of sum
can be adjusted by adjusting left
and right
:
int[] twoSum(int[] nums, int target) {
int left = 0, right = nums.length - 1;
while (left < right) {
int sum = nums[left] + nums[right];
if (sum == target) {
//The index required by the title starts from 1
return new int[]{left + 1, right + 1};
} else if (sum < target) {
left++; // make sum bigger
} else if (sum > target) {
right--; // make sum smaller
}
}
return new int[]{-1, -1};
}
void reverse(int[] nums) {
int left = 0;
int right = nums.length - 1;
while (left < right) {
// swap(nums[left], nums[right])
int temp = nums[left];
nums[left] = nums[right];
nums[right] = temp;
left++; right--;
}
}
This may be the highest level of the double pointer technique. If you master this algorithm, you can solve a large class of substring matching
problems, but the sliding window
is slightly more complex than the algorithms metioned above.
Fortunately, there are framework templates for this kind of algorithm, and this article explains the sliding window
algorithm template, which helps you to “kill” several substrings matching
problems in leetcode.


Physical Considerations
Although the probe was designed to be small, it might not physically fit in all target systems.
Contact SupportNet if you have special considerations that require review.
Table 3-1 shows the physical characteristics of the probe.
Table 3-1. Sourcery Probe Personal Physical Characteristics
|
Current Consumption
|
|
Sourcery Probe Personal current consumption from USB cable |
< 200 mA |
|
Sourcery Probe Personal current consumption from target |
< 50
A |
|
Physical dimensions |
|
Sourcery Probe Personal dimensions |
5.375" x 3.25" x 1.250"
(13.63 cm x 8.26 cm x 3.175 cm) |
|
Target connector ribbon length |
5” +/- 0.5” (12.7 +/- 1.25 cm) |
|
Target connector dimensions:
Height
Depth
JTAG/COP width
DPI width
ARM® JTAG width
MIPS
TAM MIPS14-J12
14 pin header
HTST-107-04-L-D- RA
12 pin female socket
SSW-106-02-S-D-RA
TAM ARM20-ARM14
20 pin header
Part# HTST-110-04-L-D_RA
14pin female socket Part#ASP-141004-01
TAM ARM20-TX14
20 pin header
Part# HTST-110-04-L-D_RA
14pin socket
ASP-141004-01
TAM ARM20-TX20
20 pin header
Part# HTST-110-04-L-D_RA
ASP-145056-01
dpi-10
cop-16
|
-
0.38" (0.97 cm)
0.20" (0.51 cm)
0.98" (2.49 cm)
0.68" (1.72 cm)
1.18" (3.00 cm)
0.88" (2.24 cm)
L x W x H:
1.0"x0.36" x 0.5"
0.6'x0.20"x 0.5"
1.3x0.36"x0.5"
0.72" x0.26"x0.6"
1.3"x0.36"x0.5"
0.72" x0.26"x0.6"
1.3"x0.36"x0.5"
0.5"x0.2"x0.45"
0.5" x 0.3" x0.45"
0.8"x0.3"x 0.45" |


dustmaker package¶
Submodules¶
dustmaker.BitReader module¶
-
class
dustmaker.BitReader.
BitReader
(data)¶ Bases:
object
Allows integers to be read in little endian byte order from a sequence of bytes.
-
align
(size=8)¶ Aligns the bit stream to a given multiple of bits. Default alignment is 8-bit alignment.
size – The desired bit alignment.
-
more
()¶ Returns true if there are more bits to be read.
-
read
(bits, signed=False)¶ Reads the next bits bits into an integer in little endian order.
bits – The number of bits to read. signed – Indicates if the MSB is a sign bit.
-
read_bytes
(num)¶ Returns a bytes object containing the next num bytes from the bit stream.
num – The number of bytes to extract from the bit stream.
-
skip
(bits)¶ Skips bits bits in the bit stream.
bits – the number of bits to skip.
-
dustmaker.BitWriter module¶
-
class
dustmaker.BitWriter.
BitWriter
¶ Bases:
object
Allows integers to be written in little endian byte order into a bytes object.
-
align
(size=8)¶ Aligns the bit stream to a given multiple of bits. Default alignment is 8-bit alignment.
size – The desired bit alignment.
-
byte_count
()¶ Returns the number of bytse written so far.
-
bytes
()¶ Returns a bytes object containing all written data so far.
-
write
(bits, val)¶ Writes val as a bits bit integer in little endian order to the bit stream.
bits – The number of bits in val. val – The value of the integer.
-
write_bytes
(data)¶ Write the bytes given by data to the stream.
data – The bytes to write to the stream.
-
dustmaker.Entity module¶
-
class
dustmaker.Entity.
AIController
(vars, rotation=0, unk1=0, unk2=0, unk3=0, unk4=0)¶ Bases:
dustmaker.Entity.Entity
-
TYPE_IDENTIFIER
= 'AI_controller'¶
-
node_append
(val)¶
-
node_clear
()¶
-
node_count
()¶
-
node_pop
(ind=None)¶
-
node_position
(ind, val=None)¶
-
puppet
(val=None)¶
-
remap_ids
(id_map)¶
-
translate
(x, y)¶
-
-
class
dustmaker.Entity.
CameraNode
(vars, rotation=0, unk1=0, unk2=0, unk3=0, unk4=0)¶ Bases:
dustmaker.Entity.Entity
-
TYPE_IDENTIFIER
= 'camera_node'¶
-
connection
(ind, val=None)¶
-
connection_append
(val)¶
-
connection_clear
()¶
-
connection_count
()¶
-
connection_pop
(ind=None)¶
-
remap_ids
(id_map)¶
-
dustmaker.Map module¶
-
class
dustmaker.Map.
Map
(parent=None)¶ Bases:
object
Represents a Dustforce level.
A map contains the following attributes:
map.tiles - A dict mapping (layer, x, y) to Tile objects. map.props - A dict mapping prop ids to Prop objects. map.parent - For backdrops this is the containing map. Otherwise this is
set to None.If the map is not a backdrop (i.e. map.parent == None) then the following attributes will also be available:
map.entities - A dict mapping entity ids to Entity objects. map.backdrop - The backdrop Map object. Backdrop maps can only contain
tiles and props and each tile is the size of 16 tiles in the top level coordinate system.- map.vars - A raw mapping of string keys to Var objects. Some of these
- variables have nicer accessors like map.name(...).
- map.sshot - The level thumbnail image. This appears to be a PNG image
- with some custom or missing header.
-
add_entity
(x, y, entity, id=None)¶ Adds a new entity to the map and returns its id.
x - The x position in tile units of the entity. y - The y position in tile units of the entity. entity - The Entity object to add to the map. id - The entity identifier. If set to None the identifier will be
allocated for you.Raises a MapException if the given id is already in use.
-
add_prop
(layer, x, y, prop, id=None)¶ Adds a new prop to the map and returns its id.
x - The x position in tile units of the prop. y - The y position in tile units of the prop. prop - The Prop object to add to the map. id - The prop identifier. If set to None the identifier will be
allocated for you.Raises a MapException if the given id is already in use.
-
add_tile
(layer, x, y, tile)¶ Adds a new tile to the map.
layer - The layer to add the tile. x - The x position of the tile. y - The y position of the tile. tile - The tile to add to the map.
Raises a MapException if the given position is already occupied.
-
delete_tile
(layer, x, y)¶ Delete the tile at the given position if present.
layer - The layer to add the tile. x - The x position of the tile. y - The y position of the tile.
-
get_entity
(id)¶ Returns the Entity object with the given id or None.
-
get_entity_xposition
(id)¶ Returns the x position of the entity with the given id or None.
-
get_entity_yposition
(id)¶ Returns the y position of the entity with the given id or None.
-
get_prop
(id)¶ Returns the Prop object with the given id or None.
-
get_prop_layer
(id)¶ Returns the layer of the prop with the given id or None.
-
get_prop_xposition
(id)¶ Returns the x position of the prop with the given id or None.
-
get_prop_yposition
(id)¶ Returns the y position of the prop with the given id or None.
-
get_tile
(layer, x, y)¶ Returns the tile at the given position or None.
layer - The layer to add the tile. x - The x position of the tile. y - The y position of the tile.
-
merge_map
(map, _do_remap_ids=True)¶ Merge a map into this one.
map - The Map to merge into this one.
-
name
(val=None)¶ Returns the level name.
val - If not None sets the new name of the Map.
-
remap_ids
(min_id=None)¶ Remap prop and entity ids starting at min_id.
This calls through to all entities to remap any references to other entity ids.
-
start_position
(val=None, player=1)¶ Returns the starting position of a player as a tuple of floats.
val - If not None sets the new player position. player - The player ID to set the position of.
-
translate
(x, y)¶ Translate the entire map x tiles laterally and y tiles horizontally.
- x - The number of tiles to move laterally. If a float tiles will be
- moved by the nearest integer.
- y - The number of tiles to move horizontally. If a float tiles will be
- moved by the nearest integer.
-
virtual_character
(val=None)¶ Returns True if the map uses virtual characters.
val - If not None sets the virtual character flag for the map.
dustmaker.MapException module¶
-
exception
dustmaker.MapException.
MapException
¶ Bases:
Exception
-
exception
dustmaker.MapException.
MapParseException
¶
dustmaker.MapReader module¶
-
dustmaker.MapReader.
read_map
(data)¶ Returns a Map object parsed from data in the Dustforce level format.
data - A sequence of bytes representing a Dustforce level.
On error raises a MapParseException.
dustmaker.MapWriter module¶
-
dustmaker.MapWriter.
write_map
(map)¶ Writes a Map object into a sequence of bytes in the Dustforce level format.
Returns a bytes object representing the level.
On error raises a MapException.
dustmaker.Prop module¶
-
class
dustmaker.Prop.
Prop
(layer_sub, rotation, scale_x, scale_y, prop_set, prop_group, prop_index, palette)¶ Bases:
object
dustmaker.Tile module¶
-
class
dustmaker.Tile.
Tile
(shape, _tile_data=None, _dust_data=None)¶ Bases:
object
Represents a single tile in a Dustforce level. Positional information is stored within Map.
-
edge_angle
(side, val=None)¶ Returns the angle of side as a 16 bit integer.
side – The side to get/set edge angle. val – If present a 16 bit integer to set as the new edge angle.
-
edge_bits
(side, val=None)¶ Returns the 4 bit number associated with side surface of the tile. I’m unsure what each bit means currently. Set all to 0 to freely move through that side of the tile and to 0xF to cause collisions.
side – The side to get/set edge bits. val – If present a 4 bit integer to set as the new edge bits.
-
sprite_palette
(val=None)¶ Returns the palette index associated with this tile.
val – If present the new palette index for this tile.
-
sprite_path
()¶ Returns the palette index associated with this tile. You may retrieve the complete game sprites listing from https://www.dropbox.com/s/jm37ew9p74olgca/sprites.zip?dl=0
val – If present the new palette index for this tile.
-
sprite_set
(val=None)¶ Returns the sprite set from TileSpriteSet associated with this tile.
val – If present a TileSpriteSet to set as the new sprite set.
-
sprite_tile
(val=None)¶ Returns the tile index associated with this tile.
val – If present the new tile index for this tile.
-
-
class
dustmaker.Tile.
TileShape
¶ Bases:
enum.IntEnum
Tiles come in four main types; full, half, big, and small.
Full corresponds to a complete square tile.
Half corresponds to one of the tiles aligned to 45 degrees that take up half of the tile unit. These come in four varieties A, B, C, and D depicted on the wheel below.
Big and small tiles form the inbetween angles. The big tile variant covers 75% of the tile while the small tile variant covers 25% of the tile. Each of these comes in 8 varieties 1-8 depicted in the wheel below.
To determine the angle of a half, big, or small tile from its shape find its identifier in the wheel. Imagine you were located at X and the + characters formed a circle around you; the angle of the tile would be approximately the angle of the circle surface where its label is.:
+++++ +7+ +3+ + + + + B C + + + + 2 6 + + + + + + + X + + + + + + + 8 4 + + + + A D + + + + +1+ +5+ +++++
-
class
dustmaker.Tile.
TileSide
¶ Bases:
enum.IntEnum
-
class
dustmaker.Tile.
TileSpriteSet
¶ Bases:
enum.IntEnum
Used to describe what set of tiles a tile’s sprite comes from.
dustmaker.Var module¶
-
class
dustmaker.Var.
Var
(type, value)¶ Bases:
object
-
class
dustmaker.Var.
VarType
¶ Bases:
enum.IntEnum


This is title
🕑 One or more of the npm packages you are using needs to be built. You're the first person to ever need it! We're building it right now and your preview will start updating again when it's ready.
Console
Clear


ConvertAPI JavaScript library example
Conversion Using Worker Example
Select DOCX file to convert it to PDF, split and zip
Result file:


Thu May 27, 2004
I’ve just spent a couple of hours updating my website and posting a few pictures of our recent vacation, click on this link to go straight there….
Some of the other guys on the tour in Costa Rica have posted their own pictures, some of them show extra stuff in Costa Rica and Angela and I are in some of them, so if you’re at all interested, here are Laura’s pictures and Ryan and Nikki’s pictures…


Buildings
BRICKS AND MORTAR: BUILDING THE AFFILIATED COLLEGES
by Nancy Rockafellar
by Nancy Rockafellar
In 1895, the California Legislature appropriated $250,000 for the "Affiliated Colleges" of the University of California to be located on a 13-acre site overlooking Golden Gate Park. The land was donated by the city's mayor, Adolph Sutro, and the site was designed by architects Krafft, Martens and Coffey to house Sutro's extensive library collection, and to be used for the University of California's colleges of medicine, dentistry, pharmacy, veterinary medicine, and law.
The cornerstone of the medical school was laid on March 27, 1897, in a driving spring rainstorm. Beverly Cole, who by this time had been elected President of the American Medical Association, passed out champagne bottles. Reporters noted that the rain and blowing sand did not dampen the celebration attended by Mayor James Phelan and former Mayor Adolph Sutro. Lieutenant Governor Jeter declared that the raindrops are "nature's tears of joy" for the occasion. "Spread out before us," he proclaimed, "we behold as beautiful and lovely a landscape as one could imagine: at our very feet Golden Gate Park with its green lawns, rising trees, and winding paths, while strains of music float softly through the air."
The completed Romanesque stone buildings of the Affiliated Colleges lined Parnassus Avenue. The Colleges of Dentistry and Pharmacy occupied the building on the left (east), and the College of Medicine was based in the building in thecenter. The third building was intended for the Hastings College of the Law, but the faculty considered it too far from the city's courts and refused to move from Pioneer Hall, where the college was then located. Instead, the building became an anthropological museum and housed archeological specimens and art objects included in the Phoebe Hearst Collection. A smaller building in the rear housed the College of Veterinary Science.
Three buildings were completed and occupied by October of 1898. The 1898 Brochure of the Medical Department of the University of California described the new facilities, including a new auditorium with a capacity of 1,200, spacious laboratories for pathology, bacteriology, chemistry and physiology, and "the finest dissecting room in the world at the present time." The author of the pamphlet also speculated that "the site of the City and County Hospital in contemplation by the Supervisors is to be within a few blocks of the College buildings, thus offering clinical advantages conveniently close at hand."


Files | |
| file | dsp_icfg.h |
| This file contains the prototypes of the APIs present in the device abstraction layer file of ICFG in the C66x DSP subsytems. This also include related macro definitions. All APIs should be called with interrupts disabled to ensure coherency. | |
Macros | |
| #define | DSPICFG_L1P_PGSZ (2048U) |
| Page size for L1P memory protection. | |
| #define | DSPICFG_L1D_PGSZ (2048U) |
| Page size for L1D memory protection. | |
| #define | DSPICFG_L2_PGSZ (16U * 1024U) |
| Page size for L2 memory protection. | |
| #define | MAR_SECTION_SZ (16U * 1024U * 1024U) |
| Page size for MAR registers. | |
| #define | DSP_MAR_PCX_SHIFT (2U) |
| Bit-Fields missing in hw_dsp_icfg.h. | |
| #define | DSPICFG_L1P_CACHE_LINE_SIZE (32U) |
| L1P Cache Line Size. | |
| #define | DSPICFG_L1D_CACHE_LINE_SIZE (64U) |
| L1D Cache Line Size. | |
| #define | DSPICFG_L2_CACHE_LINE_SIZE (128U) |
| L2 Cache Line Size. | |
Typedefs | |
| typedef enum dspicfgMARAttribute | dspicfgMARAttribute_t |
| Enum to create mask for MAR attributes. Refer to device specific documents to check if PCX and WTE are available. | |
| typedef enum dspicfgL2Attribute | dspicfgL2Attribute_t |
| Enum to create mask for L2MPPA (L2 memory protection attributes) registers for DSP L1P/L1D/L2 Memory . | |
| typedef enum dspicfgMemType | dspicfgMemType_t |
| Enum to specify cache type in cache APIs provided in the file. | |
| typedef enum dspicfgCacheSizeL1 | dspicfgCacheSizeL1_t |
| Enum to specify L1 cache size in cache APIs provided in the file. | |
| typedef enum dspicfgCacheSizeL2 | dspicfgCacheSizeL2_t |
| Enum to specify L2 cache size in cache APIs provided in the file. If the devices L2 memory is less than the specified value, all L2 memory will be used as cache. eg: Using DSPICFG_CACHE_SIZE_L2_1024K in TDA2x will be same as using DSPICFG_CACHE_SIZE_L2_256K or DSPICFG_CACHE_SIZE_L2_512K or DSPICFG_CACHE_SIZE_L2_MAX since total L2 memory is 256kiB. | |
Enumerations | |
| enum | dspicfgMARAttribute { DSPICFG_MAR_PC = DSP_MAR_PC_MASK, DSPICFG_MAR_WTE = DSP_MAR_WTE_MASK, DSPICFG_MAR_PCX = DSP_MAR_PCX_MASK, DSPICFG_MAR_PFX = DSP_MAR_PFX_MASK } |
| Enum to create mask for MAR attributes. Refer to device specific documents to check if PCX and WTE are available. More... | |
| enum | dspicfgL2Attribute { DSPICFG_L2MPPA_LOCAL = DSP_L2MPPA_LOCAL_MASK, DSPICFG_L2MPPA_SR = DSP_L2MPPA_SR_MASK, DSPICFG_L2MPPA_SW = DSP_L2MPPA_SW_MASK, DSPICFG_L2MPPA_SX = DSP_L2MPPA_SX_MASK, DSPICFG_L2MPPA_UR = DSP_L2MPPA_UR_MASK, DSPICFG_L2MPPA_UW = DSP_L2MPPA_UW_MASK, DSPICFG_L2MPPA_UX = DSP_L2MPPA_UX_MASK, DSPICFG_L2MPPA_AID_0 = DSP_L2MPPA_AID0_MASK, DSPICFG_L2MPPA_AID_1 = DSP_L2MPPA_AID1_MASK, DSPICFG_L2MPPA_AID_2 = DSP_L2MPPA_AID2_MASK, DSPICFG_L2MPPA_AID_3 = DSP_L2MPPA_AID3_MASK, DSPICFG_L2MPPA_AID_4 = DSP_L2MPPA_AID4_MASK, DSPICFG_L2MPPA_AID_5 = DSP_L2MPPA_AID5_MASK, DSPICFG_L2MPPA_AID_X = DSP_L2MPPA_AIDX_MASK } |
| Enum to create mask for L2MPPA (L2 memory protection attributes) registers for DSP L1P/L1D/L2 Memory . More... | |
| enum | dspicfgMemType { DSPICFG_MEM_L1D, DSPICFG_MEM_L1P, DSPICFG_MEM_L2 } |
| Enum to specify cache type in cache APIs provided in the file. More... | |
| enum | dspicfgCacheSizeL1 |
| Enum to specify L1 cache size in cache APIs provided in the file. | |
| enum | dspicfgCacheSizeL2 |
| Enum to specify L2 cache size in cache APIs provided in the file. If the devices L2 memory is less than the specified value, all L2 memory will be used as cache. eg: Using DSPICFG_CACHE_SIZE_L2_1024K in TDA2x will be same as using DSPICFG_CACHE_SIZE_L2_256K or DSPICFG_CACHE_SIZE_L2_512K or DSPICFG_CACHE_SIZE_L2_MAX since total L2 memory is 256kiB. | |
Functions | |
| int32_t | DSPICFGSetAttribute (uint32_t baseAddr, uint32_t memType, uint32_t pageAddr, uint32_t attributeMask) |
| Set memory protection attributes for specified L1/L2 memory page. Should be called in supervisor mode only. More... | |
| uint32_t | DSPICFGGetAttribute (uint32_t baseAddr, uint32_t memType, uint32_t pageAddr) |
| Get memory protection attributes for specified L1/L2 memory page. More... | |
| int32_t | DSPICFGSetMAR (uint32_t baseAddr, uint32_t startAddr, uint32_t attributeMask) |
| Configure the Memory Attribute Register in DSP for the 16MiB page specified by startAddr. Should be called in supervisor mode only. More... | |
| uint32_t | DSPICFGGetMAR (uint32_t baseAddr, uint32_t startAddr) |
| Get the Memory Attribute Register in DSP for the 16MiB page specified by startAddr. More... | |
| int32_t | DSPICFGCacheEnable (uint32_t baseAddr, uint32_t cacheType, uint32_t size) |
| Enable/Disable specified cache. More... | |
| int32_t | DSPICFGCacheWriteBackAll (uint32_t baseAddr, uint32_t cacheType) |
| Write-back all cache specified by cacheType. More... | |
| int32_t | DSPICFGCacheInvalidateAll (uint32_t baseAddr, uint32_t cacheType) |
| Invalidate all cache specified by cacheType. More... | |
| int32_t | DSPICFGCacheWriteBackInvalidateAll (uint32_t baseAddr, uint32_t cacheType) |
| Write-back and invalidate all cache specified by cacheType. More... | |
| int32_t | DSPICFGCacheWriteBack (uint32_t baseAddr, uint32_t startAddr, uint32_t numBytes) |
| Write-back all cache as per input range specified by startAddr and numBytes. More... | |
| int32_t | DSPICFGCacheInvalidate (uint32_t baseAddr, uint32_t startAddr, uint32_t numBytes) |
| Invalidate all cache as per input range specified by startAddr and numBytes. More... | |
| int32_t | DSPICFGCacheWriteBackInvalidate (uint32_t baseAddr, uint32_t startAddr, uint32_t numBytes) |
| Write-back and Invalidate all cache as per input range specified by startAddr and numBytes. More... | |
| int32_t | DSPICFGMemoryProtectionLock (uint32_t baseAddr, uint32_t key0, uint32_t key1, uint32_t key2, uint32_t key3) |
| Lock Memory Protection registers for Memory Protection Unit and XMC. More... | |
| int32_t | DSPICFGMemoryProtectionUnlock (uint32_t baseAddr, uint32_t key0, uint32_t key1, uint32_t key2, uint32_t key3) |
| Unlock Memory Protection registers for Memory Protection Unit and XMC. More... | |
| int32_t | DSPICFGClearMdmaErrEvt (uint32_t baseAddress) |
| Clear the MDMA Error Event register. More... | |
| uint32_t | DSPICFGGetL2MPUFaultAddr (uint32_t baseAddress) |
| Get the fault location as reported by L2 MPU. More... | |
| uint32_t | DSPICFGGetL2MPUFaultStatus (uint32_t baseAddress) |
| Get the fault status as reported by L2 MPU. More... | |
| int32_t | DSPICFGClearL2MPUFaultRegs (uint32_t baseAddress) |
| Clear the fault registers for location and status in the L2 MPU. More... | |
| uint32_t | DSPICFGGetL1DMPUFaultAddr (uint32_t baseAddress) |
| Get the fault location as reported by L1D MPU. More... | |
| uint32_t | DSPICFGGetL1DMPUFaultStatus (uint32_t baseAddress) |
| Get the fault status as reported by L1D MPU. More... | |
| int32_t | DSPICFGClearL1DMPUFaultRegs (uint32_t baseAddress) |
| Clear the fault registers for location and status in the L1D MPU. More... | |
| uint32_t | DSPICFGGetL1PMPUFaultAddr (uint32_t baseAddress) |
| Get the fault location as reported by L1P MPU. More... | |
| uint32_t | DSPICFGGetL1PMPUFaultStatus (uint32_t baseAddress) |
| Get the fault status as reported by L1P MPU. More... | |
| int32_t | DSPICFGClearL1PMPUFaultRegs (uint32_t baseAddress) |
| Clear the fault registers for location and status in the L1P MPU. More... | |
| enum dspicfgL2Attribute |
Enum to create mask for L2MPPA (L2 memory protection attributes) registers for DSP L1P/L1D/L2 Memory .
| enum dspicfgMARAttribute |
Enum to create mask for MAR attributes. Refer to device specific documents to check if PCX and WTE are available.
| enum dspicfgMemType |
| int32_t DSPICFGCacheEnable | ( | uint32_t | baseAddr, |
| uint32_t | cacheType, | ||
| uint32_t | size | ||
| ) |
Enable/Disable specified cache.
| baseAddr | Base Address of the DSP_ICFG instance. (SOC_DSP_ICFG_BASE) |
| cacheType | Use enum dspicfgMemType_t to specify the cache. |
| size | Specify cache size. Remaining memory will be available as RAM. Argument ignored if enable is 0. Use dspicfgCacheSizeL1_t or dspicfgCacheSizeL2_t enums for L1 and L2 caches respectively. Use DSPICFG_CACHE_SIZEL1_DISABLE or DSPICFG_CACHE_SIZEL2_DISABLE to disable cache. |
| int32_t DSPICFGCacheInvalidate | ( | uint32_t | baseAddr, |
| uint32_t | startAddr, | ||
| uint32_t | numBytes | ||
| ) |
Invalidate all cache as per input range specified by startAddr and numBytes.
| baseAddr | Base Address of the DSP_ICFG instance. (SOC_DSP_ICFG_BASE) |
| startAddr | Starting address on which the cache-operation occurs. |
| numBytes | Specify the range in number of bytes on which cache operation occurs |
| int32_t DSPICFGCacheInvalidateAll | ( | uint32_t | baseAddr, |
| uint32_t | cacheType | ||
| ) |
Invalidate all cache specified by cacheType.
| baseAddr | Base Address of the DSP_ICFG instance. (SOC_DSP_ICFG_BASE) |
| cacheType | Use enum dspicfgMemType_t Using argument DSPICFG_MEM_L2 causes, same operation on L1D cache as well. |
| int32_t DSPICFGCacheWriteBack | ( | uint32_t | baseAddr, |
| uint32_t | startAddr, | ||
| uint32_t | numBytes | ||
| ) |
Write-back all cache as per input range specified by startAddr and numBytes.
| baseAddr | Base Address of the DSP_ICFG instance. (SOC_DSP_ICFG_BASE) |
| startAddr | Starting address on which the cache-operation occurs. |
| numBytes | Specify the range in number of bytes on which cache operation occurs |
| int32_t DSPICFGCacheWriteBackAll | ( | uint32_t | baseAddr, |
| uint32_t | cacheType | ||
| ) |
Write-back all cache specified by cacheType.
| baseAddr | Base Address of the DSP_ICFG instance. (SOC_DSP_ICFG_BASE) |
| cacheType | Use enum dspicfgMemType_t Using argument DSPICFG_MEM_L2 causes, same operation on L1D cache as well. |
| int32_t DSPICFGCacheWriteBackInvalidate | ( | uint32_t | baseAddr, |
| uint32_t | startAddr, | ||
| uint32_t | numBytes | ||
| ) |
Write-back and Invalidate all cache as per input range specified by startAddr and numBytes.
| baseAddr | Base Address of the DSP_ICFG instance. (SOC_DSP_ICFG_BASE) |
| startAddr | Starting address on which the` cache-operation occurs. |
| numBytes | Specify the range in number of bytes on which cache operation occurs |
| int32_t DSPICFGCacheWriteBackInvalidateAll | ( | uint32_t | baseAddr, |
| uint32_t | cacheType | ||
| ) |
Write-back and invalidate all cache specified by cacheType.
| baseAddr | Base Address of the DSP_ICFG instance. (SOC_DSP_ICFG_BASE) |
| cacheType | Use enum dspicfgMemType_t Using argument DSPICFG_MEM_L2 causes, same operation on L1D cache as well. |
| int32_t DSPICFGClearL1DMPUFaultRegs | ( | uint32_t | baseAddress | ) |
Clear the fault registers for location and status in the L1D MPU.
| baseAddress | Base Address of the DSP_ICFG instance (SOC_DSP_ICFG_BASE) |
| int32_t DSPICFGClearL1PMPUFaultRegs | ( | uint32_t | baseAddress | ) |
Clear the fault registers for location and status in the L1P MPU.
| baseAddress | Base Address of the DSP_ICFG instance (SOC_DSP_ICFG_BASE) |
| int32_t DSPICFGClearL2MPUFaultRegs | ( | uint32_t | baseAddress | ) |
Clear the fault registers for location and status in the L2 MPU.
| baseAddress | Base Address of the DSP_ICFG instance (SOC_DSP_ICFG_BASE) |
| int32_t DSPICFGClearMdmaErrEvt | ( | uint32_t | baseAddress | ) |
Clear the MDMA Error Event register.
| baseAddress | Base Address of the XMC instance (SOC_DSP_ICFG_BASE) |
| uint32_t DSPICFGGetAttribute | ( | uint32_t | baseAddr, |
| uint32_t | memType, | ||
| uint32_t | pageAddr | ||
| ) |
Get memory protection attributes for specified L1/L2 memory page.
| baseAddr | Base Address of the DSP_ICFG instance. (SOC_DSP_ICFG_BASE) |
| pageAddr | Starting address of the page in L1/L2 Memory which needs to be protected. Base of L1P Memory address is assumed to be SOC_DSP_L1P_BASE. Base of L1D Memory address is assumed to be SOC_DSP_L1D_BASE. Base of L2 Memory address is assumed to be SOC_DSP_L2_BASE. Therefore, pageAddr == SOC_DSP_L2_BASE will configure 0th page of L2, i.e, (SOC_DSP_L2_BASE to (SOC_DSP_L2_BASE + L2_PAGE_SIZE)). Similar convention applies for L1P/L1D. All addresses will be assumed to be aligned as per DSPICFG_L2_PGSZ, DSPICFG_L1P_PGSZ or DSPICFG_L1D_PGSZ |
| memType | Use enum dspicfgMemType_t to specify memory. |
| uint32_t DSPICFGGetL1DMPUFaultAddr | ( | uint32_t | baseAddress | ) |
Get the fault location as reported by L1D MPU.
| baseAddress | Base Address of the DSP_ICFG instance (SOC_DSP_ICFG_BASE) |
| uint32_t DSPICFGGetL1DMPUFaultStatus | ( | uint32_t | baseAddress | ) |
Get the fault status as reported by L1D MPU.
| baseAddress | Base Address of the DSP_ICFG instance (SOC_DSP_ICFG_BASE) |
| uint32_t DSPICFGGetL1PMPUFaultAddr | ( | uint32_t | baseAddress | ) |
Get the fault location as reported by L1P MPU.
| baseAddress | Base Address of the DSP_ICFG instance (SOC_DSP_ICFG_BASE) |
| uint32_t DSPICFGGetL1PMPUFaultStatus | ( | uint32_t | baseAddress | ) |
Get the fault status as reported by L1P MPU.
| baseAddress | Base Address of the DSP_ICFG instance (SOC_DSP_ICFG_BASE) |
| uint32_t DSPICFGGetL2MPUFaultAddr | ( | uint32_t | baseAddress | ) |
Get the fault location as reported by L2 MPU.
| baseAddress | Base Address of the DSP_ICFG instance (SOC_DSP_ICFG_BASE) |
| uint32_t DSPICFGGetL2MPUFaultStatus | ( | uint32_t | baseAddress | ) |
Get the fault status as reported by L2 MPU.
| baseAddress | Base Address of the DSP_ICFG instance (SOC_DSP_ICFG_BASE) |
| uint32_t DSPICFGGetMAR | ( | uint32_t | baseAddr, |
| uint32_t | startAddr | ||
| ) |
Get the Memory Attribute Register in DSP for the 16MiB page specified by startAddr.
| baseAddr | Base Address of the DSP_ICFG instance. (SOC_DSP_ICFG_BASE) |
| startAddr | Specify the 16MiB aligned start address. |
| int32_t DSPICFGMemoryProtectionLock | ( | uint32_t | baseAddr, |
| uint32_t | key0, | ||
| uint32_t | key1, | ||
| uint32_t | key2, | ||
| uint32_t | key3 | ||
| ) |
Lock Memory Protection registers for Memory Protection Unit and XMC.
| baseAddr | Base Address of the DSP_ICFG instance. (SOC_DSP_ICFG_BASE) |
| key0 | First Key |
| key1 | Second Key |
| key2 | Third Key |
| key3 | Fourth Key |
| int32_t DSPICFGMemoryProtectionUnlock | ( | uint32_t | baseAddr, |
| uint32_t | key0, | ||
| uint32_t | key1, | ||
| uint32_t | key2, | ||
| uint32_t | key3 | ||
| ) |
Unlock Memory Protection registers for Memory Protection Unit and XMC.
| baseAddr | Base Address of the DSP_ICFG instance. (SOC_DSP_ICFG_BASE) |
| key0 | First Key |
| key1 | Second Key |
| key2 | Third Key |
| key3 | Fourth Key |
| int32_t DSPICFGSetAttribute | ( | uint32_t | baseAddr, |
| uint32_t | memType, | ||
| uint32_t | pageAddr, | ||
| uint32_t | attributeMask | ||
| ) |
Set memory protection attributes for specified L1/L2 memory page. Should be called in supervisor mode only.
| baseAddr | Base Address of the DSP_ICFG instance. (SOC_DSP_ICFG_BASE) |
| pageAddr | Starting address of the page in L1/L2 Memory which needs to be protected. Base of L1P Memory address is assumed to be SOC_DSP_L1P_BASE. Base of L1D Memory address is assumed to be SOC_DSP_L1D_BASE. Base of L2 Memory address is assumed to be SOC_DSP_L2_BASE. Therefore, pageAddr == SOC_DSP_L2_BASE will configure 0th page of L2, i.e, (SOC_DSP_L2_BASE to (SOC_DSP_L2_BASE + L2_PAGE_SIZE)). Similar convention applies for L1P/L1D. All addresses will be assumed to be aligned as per DSPICFG_L2_PGSZ, DSPICFG_L1P_PGSZ or DSPICFG_L1D_PGSZ |
| memType | Use enum dspicfgMemType_t to specify memory. |
| attributeMask | Permission masks created by bit-wise "OR"ing of dspicfgL2Attribute_t enums. |
| int32_t DSPICFGSetMAR | ( | uint32_t | baseAddr, |
| uint32_t | startAddr, | ||
| uint32_t | attributeMask | ||
| ) |
Configure the Memory Attribute Register in DSP for the 16MiB page specified by startAddr. Should be called in supervisor mode only.
| baseAddr | Base Address of the DSP_ICFG instance. (SOC_DSP_ICFG_BASE) |
| startAddr | Specify the 16MiB aligned start address. |
| attributeMask | MAR attribute created by bit-wise "OR"ing of dspicfgMARAttribute_t enums. For range 0x0C00_0000 to 0x0FFF_FFFF, only PFX can be set. |


Module artisanryui
artisanryui is a static, global object that allows to replace the inventory
with the Artisanry one.
| activate (artisanry, formspec_provider, output_size) |
Activates the ArtinsaryUI. |
| build_formspec (player, groups) |
Builds the formspec for the artisanryui inventory. |
| change_group (player, formname, fields) |
Callback for when a different group is selected. |
| create_inventory () |
Creates a detached inventory that is used. |
| drop_items (player, formname, fields) |
Drops all items in the input list if the player closes the inventory screen. |
| replace_inventories () |
Replaces the inventory of every currently connected player with
the artisanryui one. |
| replace_inventory (player) |
Replaces the inventory of the given player with the artisanryui one. |
| scroll_page (player, formname, fields) |
Callback for when the scroll buttons are pressed. |
| update_from_input_inventory (player) |
Updates from the input inventory of the given player. |
| update_player_inventory (player, taken_stack) |
Updates the players inventory based on the taken stack. |
| groups |
The cache what group the player has currently selected. |
| last_blueprints_cache |
The last blueprints of the players. |
| pages |
The cache what page the players are currently looking at. |
| artisanry |
The Artisanry object that is used. |
| formspec_provider |
The provider that provides the formspec for players inventory. |
| inventory |
The inventory that is used for the input and output fields. |
| output_size |
The size of the output field. |
Functions
-
activate (artisanry, formspec_provider, output_size)
-
Activates the ArtinsaryUI.
This function replaces all inventories of all currently connected players
and also registers a callback to replace the inventory of every new player.
Parameters:
- artisanry
The Artisanry instance to use.
- formspec_provider
Optional. The provider for the formspec that is
to replace the inventories of the players. This is
a function that accepts the Player object, a List
of sorted and unique group names (without nil) and
returns the formspec. The important fields for
the formspec are a detached inventory with the name
"artisanrui" with the lists "PLAYERNAME-input" and
"PLAYERNAME-output", as two buttons with the names
"artisanryui-next-page" and
"artisanryui-previous-page". Also a dropdown or
similar with the name "artisanryui-group" which
contains the group to display. Can be nil for
the default one.
- output_size
Optional. The size of the output field in the custom
formspec, as in how many single slots there are. Can be
nil for the default value of 35 (7 * 5).
-
build_formspec (player, groups)
-
Builds the formspec for the artisanryui inventory.
Parameters:
- player
The player.
- groups
A List of group names.
Returns:
The formspec for the inventory.
-
change_group (player, formname, fields)
-
Callback for when a different group is selected.
Parameters:
- player
The Player object from which the event originated.
- formname
The name of the form.
- fields
The fields.
-
create_inventory ()
-
Creates a detached inventory that is used.
Returns:
The detached inventory.
-
drop_items (player, formname, fields)
-
Drops all items in the input list if the player closes the inventory screen.
Parameters:
- player
The Player object.
- formname
The name of the form.
- fields
The fields.
-
replace_inventories ()
-
Replaces the inventory of every currently connected player with
the artisanryui one.
-
replace_inventory (player)
-
Replaces the inventory of the given player with the artisanryui one.
Parameters:
- player
The player for which to replace the inventory.
-
scroll_page (player, formname, fields)
-
Callback for when the scroll buttons are pressed.
Parameters:
- player
The Player object from which the event originated.
- formname
The name of the form.
- fields
The fields.
-
update_from_input_inventory (player)
-
Updates from the input inventory of the given player.
Parameters:
- player
The player for which to update the inventories.
-
update_player_inventory (player, taken_stack)
-
Updates the players inventory based on the taken stack.
Parameters:
- player
The player for which to update the inventories.
- taken_stack
The ItemStack that was taken.
Tables
-
groups
-
The cache what group the player has currently selected.
-
last_blueprints_cache
-
The last blueprints of the players.
-
pages
-
The cache what page the players are currently looking at.
Fields
-
artisanry
-
The Artisanry object that is used.
-
formspec_provider
-
The provider that provides the formspec for players inventory.
-
inventory
-
The inventory that is used for the input and output fields.
-
output_size
-
The size of the output field.


Sorry, JavaScript needs to be enabled in order to run this application.
Please enable JavaScript to continue using this application.


Store
Home
About
Catalog
Contact
First item
Second item
Third item
Forth item
Fifth item
Search:
Add Item:
Add Item:
Description:
Price:
Add
Please Enter Valid Data
Copyright © Creativity tuts.
Terms and Conditions
Terms and Conditions
The text will go here....


getObjectUnderPoint used in the tutorial only works if the HTML page is served from a web server, unless you have Safari.


sp65 is a tool that converts images from common formats into formats used on the 6502 platforms that are the targets of the cc65 compiler suite. In addition, it allows some very simple operation with loaded graphics data, like using part of an image for further processing.
The utility has been designed in a way that adding additional source or target formats is easy. The final output is either binary, or C/assembler source.
The sp65 utility accepts the following options:
---------------------------------------------------------------------------
Usage: sp65 [options] file [options] [file]
Short options:
-V Print the version number and exit
-c fmt[,attrlist] Convert into target format
-h Help (this text)
-lc List all possible conversions
-r file[,attrlist] Read an input file
-v Increase verbosity
-w file[,attrlist] Write the output to a file
Long options:
--convert-to fmt[,attrlist] Convert into target format
--dump-palette Dump palette as table
--help Help (this text)
--list-conversions List all possible conversions
--pop Restore the original loaded image
--read file[,attrlist] Read an input file
--slice x,y,w,h Generate a slice from the loaded bitmap
--verbose Increase verbosity
--version Print the version number and exit
--write file[,attrlist] Write the output to a file
---------------------------------------------------------------------------
Below is a description of all the command line options. For the concept of attribute lists see below.
-c, --convert-to format[,attrlist]
Convert a bitmap into one of the supported target formats. The option argument must at least contain the "format" attribute. For more attributes, see section Conversions.
--dump-palette
Dump palette as table.
-h, --help
Print the short option summary shown above.
-lc, --list-conversions
Print a list of possible conversions.
--pop
Restore the working copy of the bitmap from the one originally loaded from the file. This may for example be used when creating several output files from one input file.
-r, --read filename[,attrlist]
Read an input file. The option argument must at least contain the "name" attribute. See input formats for more information.
-v, --verbose
Increase verbosity. Usually only needed for debugging purposes. You may use this option more than one time for even more verbose output.
-V, --version
Print the version number of the assembler. If you send any suggestions or bugfixes, please include the version number.
-w, --write filename[,attrlist]
Write an output file. The option argument must at least contain the "name" attribute. See output formats for more information.
sp65 consists of
These modules can be combined to a pipeline that reads data, does some optional bitmap processing, converts the bitmap into a target format, and writes this binary data to disk in one of several forms.
As described in Processing pipeline, sp65 consists of lots of different modules that may be combined in different ways, to convert an input bitmap to some output.
Many of the processors and converters have options to change the way, they're working. To avoid having lots of command line options that must be parsed on high level and passed down to the relevant parts of the program, sp65 features something called "attribute lists". Attribute lists are lists of attribute/value pairs. These lists are parsed by the main program module without any knowledge about their meaning. Lower level parts just grab the attributes they need.
In general, attribute lists look like this:
attr1=val1[,attr2=val2[,...]]
Instead of the comma, colons may also be used (even mixed).
To simplify things and to make the most common options look "normal", some
mandatory attributes may be given without an attribute name. If the attribute
name is missing, the default name is determined by the position. For example,
the option
--read
does always need a file
name. The attribute name for the file name is "name". To avoid having to type
sp65 --read name=ball.pcx ...
the first attribute gets the default name "name" assigned. So if the first attribute doesn't have a name, it is assumed that it is the file name. This means that instead of the line above, one can also use
sp65 --read ball.pcx ...
The second attribute for --read
is the format of the input file. So when
using
sp65 --read ball.pic:pcx ...
a PCX file named "ball.pic" is read. The long form would be
sp65 --read name=ball.pic:format=pcx ...
Changing the order of the attributes is possible only when explicitly specifying the names of the attributes. Using
sp65 --read pcx:ball.pic ...
will make sp65 complain, because it tries to read a file named "pcx" with an (unknown) format of "ball.pic". The following however will work:
sp65 --read format=pcx:name=ball.pic ...
The attributes that are valid for each processor or converter are listed below.
Input formats are either specified explicitly when using
--read
, or are determined by looking at the
extension of the file name given.
While sp65 is prepared for more, this is currently the only possible input format. There are no additional attributes for this format.
The current bitmap working copy is converted to a GEOS compacted bitmap. This format is used by several GEOS functions (i.e. 'BitmapUp') and is described in 'The Official GEOS Programmers Reference Guide', chapter 4, section 'Bit-Mapped Graphics'.
The current bitmap working copy is converted to GEOS icon format. A GEOS icon has the same format as a C64 high resolution sprite (24x21, monochrome, 63 bytes). There are no additional attributes for this conversion.
Lynx can handle 1, 2, 3 and 4 bits per pixel indexed sprites. The maximum size of a sprite is roughly 508 pixels but in reality the Lynx screen is only 160 by 102 pixels which makes very large sprites useless.
The number per pixels is taken from the number of colors of the input bitmap.
There are a few attributes that you can give to the conversion software.
The first is what kind of encoding to use for the sprite. The attribute for this is called "mode" and the possible values are "literal", "packed" or "transparent". The default is "packed" if no mode is specified.
The "literal" is a totally literal mode with no packing. In this mode the number of pixels per scanline will be a multiple of 8 both right and left from the action point.
If the source bitmap edge ends with a color where the least significant bit is one then there will be an extra 8 zero bits on that scan line.
So if you are using totally literal sprites and intend to change them at runtime then please add a single pixel border far left and far right with zeros in order to prevent graphical glitches in the game.
The standard encoding is called "packed". In this mode the sprite is packed using run-length encoding and literal coding mixed for optimisation to produce a small sprite.
The last encoding mode "transparent" is like packed. But here we know that the index 0 will be transparent so we can clip off all 0 pixels from the left and right edge of the sprite. This will produce the smallest sprite possible on the Lynx. The sprite is not rectangular anymore.
The sprite is painted around the Anchor point. The anchor point x can be between 0 and the width of the sprite - 1. If anchor point x is zero then painting the sprite in location 10,20 will set the left edge of the sprite 10 pixels from the left of the Lynx screen. When the sprite is scaled by hardware the anchor point stays in place and the sprite grows or shrinks around the anchor point. The default value is 0 (left).
The sprite is painted around the Anchor point. The anchor point y can be between 0 and the height of the sprite - 1. If anchor point y is zero then painting the sprite in location 10,20 will set the top of the sprite 20 pixels from the top of the Lynx screen. When the sprite is scaled by hardware the anchor point stays in place and the sprite grows or shrinks around the anchor point. The default value is 0 (top).
Using
--write
it is possible to write
processed data to an output file. An attribute "name" is mandatory, it is used
as the file name for the output. The output format can be specified using an
attribute named "format". If this attribute doesn't exist, the output format
is determined by looking at the file name extension.
For this format, the processed data is written to the output file in raw binary format. There are no additional attributes (besides "name" and "format") for this output format.
For this format, the processed data is written to the output file in ca65 assembler format. There are several attributes for this output format:
The value for this attribute specifies the numeric base for the data values. It may be either 2, 10 or 16. The default is 16. If the base is 2, the numbers are prefixed by '%', if the base is 16, the numbers are prefixed by '$'. For base 10, there is no prefix.
The value for this attribute specifies the number of bytes output in one line of the assembler file. The default is 16.
This is an optional attribute. When given, the output processor will wrap
the data into a .PROC
with the given name. In addition, three constants
are added as local symbols within the .PROC
: COLORS
, WIDTH
and HEIGHT
.
When using C output format, a small piece of C source code is generated that
defines the data containing the output in an array of unsigned char
.
Possible attributes for this format are:
The value for this attribute specifies the numeric base for the data values. It may be either 10 or 16. The default is 16. If the base is 16, the numbers are prefixed by 0x. For base 10, there is no prefix.
The value for this attribute specifies the number of bytes output in one line of the C source code. The default is 16.
This is an optional attribute. When given, the output processor will wrap
the data into an array of unsigned char with the given name. In addition,
three #define
s are added for <ident>_COLORS
,
<ident>_WIDTH
and <ident>_HEIGHT
.
sp65 (and all cc65 binutils) are (C) Copyright 1998-2012 Ullrich von Bassewitz and others. For usage of the binaries and/or sources the following conditions do apply:
This software is provided 'as-is', without any expressed or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.
Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:


#include <cusbd_structs_if.h>
Data Fields | |
| uintptr_t | regBase |
| CUSBD_EpConfig | epIN [CUSBD_NUM_EP_IN] |
| CUSBD_EpConfig | epOUT [CUSBD_NUM_EP_OUT] |
| CUSBD_EpAuxBufferConfig | epOutAuxBufferCfg [CUSBD_NUM_EP_OUT] |
| uint8_t | extendedTBCMode |
| uint32_t | dmultEnabled |
| CUSBD_DMAInterfaceWidth | dmaInterfaceWidth |
| uint32_t | preciseBurstLength |
| CUSBDMA_MemResources(* | epMemRes )[32] |
| uint8_t | forcedUsbMode |
| uintptr_t | didRegPtr |
| uintptr_t | ridRegPtr |
| CH9_UsbSetup * | setupPacket |
| uintptr_t | setupPacketDma |
Configuration of device. Object of this type is used for probe and init functions when checking memory requirements of device object and for hardware controller configuration. Size of device object in bytes is returned on probe function call in CUSBD_SysReq.privDataSize field. Remember that privDataSize returns size of device object only - it doesn't endpoints vector object size. It means that whole memory requirements = device size + (number of endpoints x single endpoint size)
| uintptr_t CUSBD_Config_s::didRegPtr |
Pointer to DID register
| CUSBD_DMAInterfaceWidth CUSBD_Config_s::dmaInterfaceWidth |
DMA interface width, available values: DMA_32_WIDTH, DMA_64_WIDTH
| uint32_t CUSBD_Config_s::dmultEnabled |
hardware feature enabling DMA operation in DMULT mode 1 - enabled, 0 disabled For Device V1: A non-zero value of dmultEnabled enables DMULT mode for all channels For Device V3: Bits[15:0]: Control DMULT enable for EP-Out[15:0] Bits[31:16]: Control DMULT enable for EP-In[15:0]
| CUSBD_EpConfig CUSBD_Config_s::epIN[CUSBD_NUM_EP_IN] |
table of endpoint configuration objects for IN direction
| CUSBDMA_MemResources(* CUSBD_Config_s::epMemRes)[32] |
Keeps addresses of resources of all endpoints
| CUSBD_EpConfig CUSBD_Config_s::epOUT[CUSBD_NUM_EP_OUT] |
table of endpoint configuration objects for OUT direction
| CUSBD_EpAuxBufferConfig CUSBD_Config_s::epOutAuxBufferCfg[CUSBD_NUM_EP_OUT] |
array of endpoint aux buffer configuration objects for OUT direction
| uint8_t CUSBD_Config_s::extendedTBCMode |
Extended TBC enable mode if ETC enabled (0: ETE always disabled, 1:ETE enabled for all speeds)
| uint8_t CUSBD_Config_s::forcedUsbMode |
Forced USB mode (0 - none (default), 2 - USB2/HS, 3 - USB3/SS, other - reserved)
| uint32_t CUSBD_Config_s::preciseBurstLength |
Set configurable burst length in DMA, available values: PRECISE_BURST_0, PRECISE_BURST_1, PRECISE_BURST_2, PRECISE_BURST_4, PRECISE_BURST_8, PRECISE_BURST_16, PRECISE_BURST_32, PRECISE_BURST_64, PRECISE_BURST_128
| uintptr_t CUSBD_Config_s::regBase |
base address of device controller registers
| uintptr_t CUSBD_Config_s::ridRegPtr |
Pointer to RID register
| CH9_UsbSetup* CUSBD_Config_s::setupPacket |
Pointer (virtual) to the setup packet
| uintptr_t CUSBD_Config_s::setupPacketDma |
Physical address of setup packet for DMA


THE LIMEY
Review by John Beachem
* * *
Directed by: Steven Soderbergh Written by: Lem Dobbs
I've always disliked the saying: "A triumph of style over substance". This might be because it is so overused when applied to movies with both style and substance (like last year's "Fight Club"). However, I can think of no more accurate description for Steven Soderbergh's ("Out of Sight") "The Limey". Soderbergh's film is so steeped in style that you may not even notice what a hollow movie it really is. You'll most likely be too busy marveling at the way Soderbergh shifts time periods in a split second while continuing one narrative; or the way he manages to make footage from old Terence Stamp movies fit seamlessly into this current story to notice what a frightfully boring and often incoherent film "The Limey" really is.
Wilson (Terence Stamp) is a man just released from prison after serving time for armed robbery. He receives a letter from a man in America, named Ed (Luis Guzman), telling him that his daughter, Jenny (Melissa George), has just died in a car accident. Wilson travels from England to meet with Ed, in order to determine who "snuffed" his daughter. His search soon leads him to Jenny's ex-boyfriend, Valentine (Peter Fonda). Valentine is a rich music producer who also dabbles in drug running. Wilson also meets up with Elaine (Lesley Ann Warren), Jenny's voice coach in acting school. Wilson, Elaine, and Ed decide to take Valentine down, with a little unwelcome help from the police, who are looking for the money from Valentine's last run.
If you sit back and just look at the plot of this film, without any of the style or interesting camera work, you'll see what a simple film it really is. When you get right down to it, "The Limey" is nothing more than a simplistic revenge story. While Soderbergh's direction may be innovative, it's also rather confusing at times. Images we sometimes see in the middle of the movie have already happend long ago, or will happen at the end of the film. While we're being shown these scenes which may not have happened yet, the characters in the present keep chattering on even though we can no longer see them. It seems interesting at first, but eventually it's just annoying. It also hinders the story because half the scenes shown during these moments are never explained.
The acting in "The Limey" is certainly the film's strongest element. Terence Stamp (who most of today's audiences will only know from his brief appearance in "Star Wars: Episode One") is simply brilliant as a vengeful man who was going to start his life over. Peter Fonda, who gave a great performance in "Ulee's Gold", is sadly miscast yet still manages to do an adequate job. Luis Guzman ("Magnolia") is one of those actors who shows up in almost everything, and all you can think is "I know that guy from somewhere". He does quite a good turn here as Wilson's rather reluctant sidekick. Last, we have Lesley Ann Warren ("Twin Falls Idaho") giving a great, understated performance as the mother Jenny never had. Unfortunately, Warren and Guzman are given very little screen time considering what interesting characters they play.
"The Limey" will certainly go down in history as one of the most fashionable movies of the '90s, but I do hope people in the future are able to see it for what it really is: candy coated outside, empty inside. The movie may only run 86 minutes, but a lot of that time is filler because there is so little plot. As a result, the subplot about Valentine's drug running and troubles with the law are hardly touched upon.  I recommend "The Limey" to arthouse film students, but I can't recommend it to anyone else because I guarantee the rest of you will be quite bored. I give it three out of five stars for acting and technical merit.
Any past movies you want me to review? Send to<EMAIL_ADDRESS>For past reviews, movie news, and other fun stuff, visit: http://www.dependentfilms.net
* * * * * - One of the best movies of the year. * * * * - Great flick, try and catch this one. * * * - Okay movie, hits and misses. * * - Pretty bad, see it at your own risk. * - One of the worst movies ever made. See it only if you enjoy pain.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


I am a Computer Scientist.
I have a range of interests in Video Games, Machine Learning, Deep Learning, Data Science, Software Engineering, Product Management, Big Data and Deep Reinforcement Learning.
I did my Bachelors from National University of Computer and Emerging Sciences , Islamabad, Pakistan majoring in Computer Science from 2012 to 2016.
I worked for two years as Game Developer/Analyst at we.R.Play !
I did my Masters at Stevens Institute of Technology also majoring in Computer Science from 2018 to 2020.
I love to listen, watch and read everything that is related to Software Engineering, Product Management, Artificial Intelligence and Game Development whether documentaries, articles, books or podcasts.
I also read about psychology and philosophy with interest.
I am also a big time hip hop fan - East Coast to West Coast.
I like to play and watch Football plus Cricket. Fan of Football Club FC Bayern Munich and German International Team. Pakistan Team in Cricket.
Play few of my personal games
2. Food Assist.
3. Love.
Games to which I contributed during Development
1. Explottens
2. War Dragons
3. Run Sheeda Run 2 - Under Development
Some of the books I have read in the recent months with my favorites highlighted as yellow are as follows:
1. The Master Algorithm by Pedro Domingos.
2. Sapiens - A brief history by Yuval Noah Harrari.
3. AI Super Powers by Kai Fu Lee.
4. Homo Deus - A brief history of tomorrow by Yuval Noah Harrai.
5. Why Greatness can not be Planned by Kenneth O.Stanley and Joel Lehman.
6. Meet Your Happy Chemicals by Breuning, Loretta Graziano.
7. How Emotions Are Made by Lisa Feldman Barrett.
8. 21 Lessons for the 21st Century by Yuval Noah Harari.
9. The Better Angels of Our Nature by Steven Pinker.
10. Life 3.0 by Max Tegmark.
11. Sex at Dawn by Christopher Ryan, Cacilda Jethá.
12. The Art of Game Design by Jesse Schell.
13. Reinforcement Learning by Sutton and Barto.
14. Thinking Fast and Slow by Daniel Kahneman.


See: Description
| Interface | Description |
|---|---|
| AnnotatedTypeVisitor<R,P> |
A visitor for annotated types.
|
| EnumType.EnumElement<T> |
Represents a single element in an enumeration.
|
| TypeAnnotationChecker |
Checks if a given type annotation is assignable to another.
|
| TypeAnnotationHierarchy |
Models a type hierarchy for type annotations.
|
| TypeVisitor<R,P> |
A visitor for generic types.
|
| Class | Description |
|---|---|
| AnnotatedTypeRef<T> |
A type token that represents an annotated type.
|
| AnnotatedTypes |
Numerous utility methods for using, constructing, and inspecting annotated types.
|
| AnnotatedTypeVisitor.Builder<R,P> |
A builder of visitors, using functional interfaces as the building blocks.
|
| Annotations |
Utility methods for working with instances of
Annotation . |
| ArrayUtils |
Utility methods for dealing with arrays, including primitive arrays.
|
| CallingClass | |
| CallingClass.StackFrame | |
| ClassHierarchyScanner<R,P> |
An object that scans an entire type hierarchy.
|
| ClassHierarchyScanner.Builder<R,P> |
Builder pattern for constructing
ClassHierarchyScanner instances. |
| ClassLoaders | |
| EnumType<T> |
An enumeration of elements.
|
| EnumType.Builder<T> |
A builder for constructing an
EnumType . |
| GenericMethodSignature |
Represents a generic method signature, composed of a method name and sequence of parameter types.
|
| Members |
Reflection utility methods for working with class members: methods and fields.
|
| MethodCapturer<E> |
A mechanism for capturing Java method calls.
|
| MethodSignature |
Represents a method signature, composed of a method name and sequence of parameter types.
|
| SecureUtils |
Several utility methods for checking security for reflective access.
|
| TypeAnnotationHierarchy.Builder |
A builder for creating instances of
TypeAnnotationHierarchy . |
| TypeRef<T> |
A type token that represents a generic type.
|
| Types |
Numerous utility methods for using, constructing, and inspecting generic types.
|
| TypeVisitor.Builder<R,P> |
A builder of visitors, using functional interfaces as the building blocks.
|
| Exception | Description |
|---|---|
| UnknownTypeException |
An exception that may be thrown when an unsupported sub-type of
Type is encountered. |
com.bluegosling.apt.reflect