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

Community
101

If your example is based on HelloWorld example, it is using -Os optimization. Change it to -O3. Do not trust what is in EmBitz settings UI, but directly look at and edit the EmBitz project file.

1 Like
102

I am using online mbed for compilation – I’ve been already looking into the -O thing and “somewhere on the Internet” (can’t find it now) they said supposedly -O3 (speed) is turned on by default. I didn’t check beyond that though.

EDIT: Also fog experiments :smiley:

out4

EDIT2:

Is it possible to set or at least see the CLI options of the combiler in the mbed online IDE? I am really not sure the optimization is on.

6 Likes
103

The online IDE works with ARMCC (not GCC) and you can set the command line settings shown below. Note that these compile settings are not persistent across browser sessions:

image
image840×415 45.9 KB

1 Like
104

How are you filling the polygon? fillTriangle seems very slow. Try to use drawTriangle just to check if there are any change in FPS.

105

I am not drawing triangles but columns by single pixels. I’d like to write a triangle 3D engine after this though.

1 Like
106

Is the source available somewhere? As Jonne said, using a sin/cos LUT instead of a formula should help, if you aren’t doing so already.

1 Like
107

So are you using drawColumn() ? Just to check.

108

Sure, here and here.

Will try the LUT.

No, the column is rendered by the library pixel by pixel in a Pokitto-independent way. The drawing on the actual display is done via drawPixel(). Is that slow?

I think what I need is profiling – see where the bottleneck is first, then try to optimize that.

EDIT:

For info, current FPS is about 20 - 25.

109

It might be. Which mode are you using?

1 Like
110

Using mode 2, I’d like to switch to mode 13 but somehow can’t get it to work :confused:

111

Also does anyone have an idea why the leftmost column (x == 0) on my Pokitto display overflows to the right side of the display? E.g. doing drawpixel(0,5) draws it on the right side of the display, drawpixel(1,5) draws it on the left (first column). In simulator it works normally (indexed from 0).

EDIT: Is it this?

112

This might help a bit (mode 13 only):

inline void pixelFunc(PixelInfo pixel)
{
  uint8_t color = pixel.isWall ? pixel.hit.direction + 4 : 3;
  uint8_t *buf = p.display.screenbuffer;
  buf += pixel.position.x*2;
  buf += pixel.position.y*p.display.width;
  *buf++ = color;
  *buf = color;
}

Packing all the data into a struct instead of simply using multiple arguments is not very good for performance. In ARM the first 4 arguments are passed as registers. The struct forces it to put everything in memory.

You will also get a little boost if you don’t use a function pointer in this instance. Calling function pointers on ARM is cheap, but it might prevent optimizations in some cases. Simply use a forward declaration in the header, unless you plan on changing the pixelFunction in run-time.

Instead of a pixelFunction, consider having a floorFunction that draws an entire column of floor and a wallFunction for walls.

Edit: Hang on… mode 2? The code I got from gitlab uses mode 13.

1 Like
113

How do you know? I don’t have the settings file there yet.

114

Heh, I don’t. I pulled it, guessed mode 13 and it worked so I just assumed that was correct. :stuck_out_tongue:

1 Like
115

That’s mode 1. What did you do to see this?
I set it to draw half the screen (for (uint16_t i = 0; i < cam.resolution.x/2; ++i)) and didn’t see a line on the right in either mode 2 or 13.

116

Well it just happens every time I run my program, that’s how I noticed it:

image
image747×713 182 KB

I also tried drawing a vertical line on the 0th column only and it bricked my Pokitto completely :slight_smile: Something’s probably terribly wrong somewhere in my settings, my setup isn’t exactly standard.

bin:

raycast.LPC11U68.bin (32.0 KB)

1 Like
117

Are you sure the PokittoLib you’re using is up to date with the one on GitHub?

Also, you can improve performance (getting about 40fps with this and the pixelFunc above) by enabling persistence and drawing the roof/floors with this, instead of using raycasting, before you call render:

// mode 13 only, needs adjustments for mode 2
void clear(){
    uint8_t *buf = p.display.screenbuffer;
    int32_t c = p.display.width*p.display.height/2;
    while( c-->0 ) *buf++ = 0; // roof
    c = p.display.width*p.display.height/2;
    while( c-->0 ) *buf++ = 3; // floor
}
1 Like
118

:scream: I need this.

I’ll check.

EDIT: I’m using the mbed online IDE, imported the latest PokittoLib (from the search/import tab), still the issue is there. Mbed repo.

119

I just checked it, it’s not up to date:

image
image1296×292 58.7 KB

SET and CLR are swapped, compared to the github version on the right.
This was fixed a while ago, you might be missing out on other fixes/improvements. IIRC, mbed doesn’t use the hand-optimized assembly version of the code.

2 Likes
120

mbed online ide does not allow inline assembler. It is an unfortunate limitation.

@drummyfish, in order to get to the more powerful code, you need to user EmBitz or Platformio or Code::Blocks for the hardware.

2 Likes