1. Tile-based worlds + scrolling
Lecture 2

2. overview Basically: Old-school New-school A palette of "chunks"
stitch together to make worlds
Old-school
Mega-man
Legend of Zelda
(anything SNES / NES / GB / etc.)
New-school
Harder to spot…and it's 3d
Unity "Prefab" / Unreal "Blueprint"

3. Refresher on pygame blitting
blit = copy (part of) one surface to another
250
212
screen = pygame.display.set_mode((800, 600))
fimg = pygame.image.load("fallout.bmp")
zimg = pygame.image.load("zelda.png")
screen.blit(zimg, (50, 100)) # Blit all
screen.blit(fimg, (400,100),
(200,130,250,212)) # Blit some
fimg
500
700
(200,130)
screen
800
600
(50,100)
(400,100)
zimg
200
400

4. Python Dictionaries The “normal” python sequences (we’ve seen):
Strings: a collection of characters (immutable)
Tuples: a collection of arbitrary objects / values (immutable)
Lists: a collection of arbitrary objects / values (mutable)
How Dictionaries are different:
An unordered set of key-value pairs
…because of this, no “normal” (positional) indexing

5. Python dictionaries
D = {} # Going to be a string => integer dictionary D[“bob”] = 10 # Makes a new key (“bob”) / value (10) pair print(D[“bob”]) # 10 D[“sue”] = 11 D[“bob”] = 13 # Modifies the value associated with “bob” del D[“sue”] print(len(D)) # 1 D2 = {5 : 3.27, 23 : -19.1} print(D2[5]) # 3.27 print(len(D2)) # 2 for key in D2: print(key) # 5 on one line, then 23 on another print(tuple(D2.keys())) # (5, 23) (perhaps not in that order) print(tuple(D2.values()) # (3.27, -19.1)

6. overview Large world, smaller visible section (screen)
All objects (enemies, tiles, power-ups, etc.) are in world-coordinates
Camera is the bridge
Position expressed in world-coordinates
We use it to convert any world-coordinate to screen
I usually picture it in the upper-left corner of the screen
Camera position

7. Camera / screen connection
World => Screen conversions
screenx = worldx – camerax; screeny = worldy – cameray;
Screen => World conversion
worldx = screenx + camerax; worldy = screey + cameray;
Negative / huge values
Clipping!

8. Scrolling: naïve approach
Store world in a large surface.
Use the more-powerful blit command:
screen.blit(background, (0, 0), (camerax, cameray, screenwidth, screenheight))
Problem with our tile-renderer:
Normally, 3 bytes per pixel (1 byte each for red, green, blue)
Say our world is 200 tiles wide, 200 high (32x32 tiles)
200 x 200 x 32 x 32 x 3
= about 120 MB…for a *tiny* map!
2000 x 2000 tile world = 11.4 GB!
Digression: virtual memory

9. smarter approach Just render the things that are (partially) on-screen
We use a bit more CPU power, but use much less RAM.
It’s worth it!
Modifications to our tile-rendering
Find which tile to start with
This is where the upper-left corner of the screen (i.e. …) is located in the world.
Render enough tiles to fill the screen.
Challenge: the first tile usually isn’t at (0,0) on the screen…
[Develop an algorithm using the “worksheet” on the next slide]

10. smarter approach, cont. 10 px 120 px .. 51 52 53 54 55 56 57 58 59 6061 62 63 64 65 66 67 68 … 27 28 29 30 31 32 33 34 35 36 37 38 39
120 px

11. Do we even need tiles? Maybe Alternative: Better alternative:
A list of shapes (images, primitives, etc.)
Still expressed in world units.
Brute-force rendering:
Loop through all shapes, render if (partially) on-screen
Better alternative:
Organize shapes – only draw those that we need to
Ideas:
Spatial Hashing
Quadtrees …