Progmem is an AVR-specific workaround. In this (and other mbeds and actually pretty much everything else) all you need is **const**

# Pokitto is on the way, what games should I make?

**jonne**#61

**drummyfish**#63

Thanks for the answers

I’ve added a compiled bin of the 2048 game to the above linked repo, could maybe some of you reading this playtest it a bit so that I can release it “officially”? I’m playing it right now, seems kind of okay.

**drummyfish**#64

Also started playing around with my raycasting lib

Spent last two hours looking for an annoying bug, it’s finally kinda working except for the fisheye distortion.

**Hanski**#65

The fisheye is a common problem in raycasters. IIRC You can fix it by using sin() function.

**drummyfish**#66

I remember dealing with this but can’t remember the solution right away. Will try the sin function, but first I need to remember what the problem is.

Actually it’s a nice effect though, isn’t it? Could be optionally left in.

**Hanski**#67

The problem is probably that the ray is casted from the single point, the observer. So even if z-coordinate is the same, the distance is bigger for objects further left or right that objects in the middle.

**drummyfish**#68

The cos function indeed fixed it, thanks for the tip.

There are two things to keep in mind:

- Don’t cast the rays with constant angle step – this creates a kind of “panorama” view. The rays need to be cast through the view plane, which implies non-constant angle step. (This I knew about.)
- If you want to display the walls as straight (not fisheye) you have to multiply the distance by cos(angle) as you said. (Not exactly sure why yet, let me think about it.)

**drummyfish**#70

Sure, but isn’t this also the case with our eyes and cameras? Why don’t these have the fisheye effect?

**drummyfish**#74

I thought these were only for the focus, zoom etc. – are they there to actually counter the fish eye?

**jonne**#75

yes. the picture on your retina is actually inverted. your brain - a massive supercomputer - turns the image around and does **alot** of postprocessing

look from car / train window. at a distance you see everything clearly. if you look close, its all motion blur. in reality **everything** you see is motion blurred, but the brain removes it in real time. only when you look close to the roadside, the computing power is not enough to remove the blur. amazing, isn’t it?

edit: sorry i didn’t answer your question. i will do that later and explain camera obscura

**drummyfish**#76

I know about these, but exactly because of this additional processing we probably shouldn’t be talking about the eye.

I think pinhole projection doesn’t create any fish eye, and it does not have any optics, so I think we still don’t have this sorted out I’m super confused right now.

**drummyfish**#77

I think I have a kind of satisfying answer, which seem to be confirmed here by a person who seemed to be equally confused.

The point is to find the **perpendicular** distance of the wall (Z-position in camera space in OpenGL terms). And that we get by multiplying by cos(angle) (as seen in the link). This camera-space position we then convert to the screen space by applying the perspective distortion (height/distance).

**FManga**#78

Pinhole cameras often put the film on a curved plane (like the inside of a can). When using a flat film, you’re generally getting a small crop of the image produced by the pinhole. Generally, the wider the field of view, the greater the distortion, so a small crop isn’t going to look like a fish eye.

**drummyfish**#79

But the mathematical model of pinhole camera creates perfectly straight lines, no distortion whatsoever, so “no fish eye” is the default. I think I have already found my answer above, so thankfully everything seems to be consistent again

**Pharap**#80

To quote Lodev:

We don’t use the Euclidean distance however, but instead only the distance perpendicular to the camera plane (projected on the camera direction), to avoid the fisheye effect. The fisheye effect is an effect you see if you use the real distance, where all the walls become rounded, and can make you sick if you rotate.

Note that this part of the code isn’t “fisheye correction”, such a correction isn’t needed for the way of raycasting used here, the fisheye effect is simply avoided by the way the distance is calculated here. It’s even easier to calculate this perpendicular distance than the real distance, we don’t even need to know the exact location where the wall was hit.

He goes on to give:

```
//Calculate distance projected on camera direction (Euclidean distance will give fisheye effect!)
if (side == 0) perpWallDist = (mapX - posX + (1 - stepX) / 2) / rayDirX;
else perpWallDist = (mapY - posY + (1 - stepY) / 2) / rayDirY;
```

Which I’d rewrite as:

```
perpWallDist = (side == 0) ? ((mapX - posX + (1 - stepX) / 2) / rayDirX) : ((mapY - posY + (1 - stepY) / 2) / rayDirY);
```

Or if you’d rather:

```
perpWallDist = (side == 0)
? ((mapX - posX + (1 - stepX) / 2) / rayDirX)
: ((mapY - posY + (1 - stepY) / 2) / rayDirY);
```