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

Community
59

I honestly have no idea.

I’ll leave that one to @jonne to answer.

I believe (don’t quote me on this) that actually the progmem isn’t really progmem, it’s simulated with flash memory (or possibly write protected) and consequently there’s no special instruction for reading from progmem like there is on the AVR, which means you don’t need a special macro for either reading progmem or putting a variable into progmem.

From what I’ve heard the compiler tries to stick anything marked const or constexpr in progmem, and I’m guessing it will possibly try to put other things in progmem following the same rules as a compiler compiling for desktop would for trying to decide what it can put in the ‘constant data’ section of an executable.

So in other words, don’t worry about it too much and just mark anything you don’t change as const (which I try to do anyway - using const on your variables signals to other code readers that you don’t change that variable at any point).

(Not directly related, but you might be interested in single static assignment form, a technique used by compliers such as GCC to determine which variables are truly const and to do reaching definition analysis.)

Full C++11 (and later). Full standard library.
(Unsurprisingly I am immensely happy about this :P)

You can even use dynamic allocation as long as you don’t overdo it.
If you do though, I’d suggest using smart pointers (unless you find them to have a measurable significant negative impact on speed or size).

Not quite the same but I wrote a C++11 for C++03 programmers (which I didn’t get around to finishing because C++11 was a massive update to the language).

If you’re already experienced with C++ then I can’t think of much more that you’d need to know than:

  • What’s the chip like? - The chip is a 32 bit ARM chip
  • What’s the ISA like? - The instruction set is the 16-bit Thumb instruction set without full 32-bit ARM instructions (and it’s documented here and here)
  • Is the stdlib available? - Yes, completely
  • Whether there’s an FPU? - Don’t know
  • What’s the API like? - Documented here
  • What are the other APIs like? - Documented here, very C++, many classes (and even a few templates)
1 Like
60

No FP in this mcu

2 Likes
61

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

1 Like
62

Yeah, I know, I know :blush:

Its a good idea tho.

Please add to the to-do list.

1 Like
63

Thanks for the answers :slight_smile:

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.

out

3 Likes
64

Also started playing around with my raycasting lib :slight_smile:

out

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

5 Likes
65

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

3 Likes
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? :smiley: Could be optionally left in.

1 Like
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.

68

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

out2

There are two things to keep in mind:

  1. 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.)
  2. 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.)
3 Likes
69

common aesthetic* you mean

70

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

71

your eyes are not planes

cameras also have lenses

1 Like
72

But cameras have planar CCDs.

73

yep but they have optics in front of the ccd

74

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

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

2 Likes
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 :slight_smile: I’m super confused right now.

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).

1 Like
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.