JorgeGzm opened a new pull request, #3681:
URL: https://github.com/apache/nuttx-apps/pull/3681
## Summary
Two independent problems in the NXDoom port.
**The blit assumed a 32-bit frame buffer.** It wrote a `uint32_t` per pixel
and
converted the palette with `ARGBTO32` as it went, so the image came out
wrong on
anything else. It also drew at the origin, leaving the image in a corner of a
display it does not fill, and indexed the source by the output column, which
costs an integer division for every pixel of every frame.
The palette is now converted once per palette change into the format the
frame
buffer actually reports, output columns are mapped to source columns through
a
table built at startup, and the result is centred. Output rows that come from
the same source row are copied rather than converted again.
Four options are added, **all disabled by default**, so a board can trade
memory
for speed where it pays:
* `GAMES_NXDOOM_FB_CMAP` — blit palette indices and let a frame buffer that
has
a colour map do the conversion in hardware while it scans out.
* `GAMES_NXDOOM_FILLSCREEN` — stretch over the whole display rather than
scaling by a whole number.
* `GAMES_NXDOOM_ROWSTAGE` — build each row in a staging buffer so the frame
buffer only sees burst-friendly copies.
* `GAMES_NXDOOM_STATIC_SCRNBUF` — place the render target in `.bss`, keeping
it
out of external memory on a board whose heap is mostly that.
**Most keycodes were not mapped.** `translate_key()` knew only the four
cursor
keys and Enter; everything else fell through and was returned unchanged. The
keycodes it did not know are small integers that collide with ASCII, so
pressing F1 typed `a`, F2 typed `b`, and so on. All the keys the codec can
report are now mapped, including the modifiers, so Ctrl fires, Shift runs and
Alt strafes. That limitation is currently documented in the port as not
fixable; PR A adds the keycodes that make it possible.
Both `open()` calls gained `O_CLOEXEC`.
## Impact
* **Users:** the four new options default to `n`, so a build that does not
enable them takes the same path as before. Two behaviours do change for
everyone:
* the image is now centred rather than drawn in the corner of a display it
does not fill (no change where it fills exactly, such as the simulator);
* F-keys, Home/End/PgUp and the modifiers now produce the right DOOM key
instead of a colliding ASCII character.
* **Build:** no new dependencies.
* **Hardware:** frame buffers of 8, 16, 24 and 32 bits per pixel are now
handled; previously only 32 worked.
* **Compatibility:** for the previously working case (32 bpp, whole-number
scale) the output is unchanged. `colmap[x] = x * 320 / outw` was verified
to
equal the old `x / scale` for every column at every scale from 1 to 8 (zero
differences), and the palette table uses the same `ARGBTO32`.
* **Security:** none.
## Testing
**Host:** Linux x86_64.
**Boards:** LINUM-STM32H753BI (1024x600 LTDC panel, frame buffer in SDRAM),
and
the simulator.
`nxstyle` reports 0 warnings on both changed files. Builds are warning-free.
**Regression, existing configurations:**
| configuration | geometry | result |
|---|---|---|
| `sim:nxdoom`, no new option enabled | 1920x1200, 32 bpp, scale 6 | builds
and **runs** |
| `raspberrypi-4b:nxdoom`, no new option enabled | 1920x1080, 32 bpp, scale
5 | builds, 0 warnings |
| `sim` set to the Raspberry Pi 4B geometry | 1920x1080, 32 bpp, scale 5 |
builds and **runs** |
| `linum-stm32h753bi:nxdoom`, all options on | 1024x600, 8 bpp CLUT | builds
and **runs** |
Both existing configurations were built with none of the new options enabled,
which is the path they take by default.
The Raspberry Pi 4B is the case where the image does not fill the display:
its
frame buffer is 1920x1080 at 32 bpp, so DOOM is scaled by 5 to 1600x1000 and
is
now centred rather than drawn in the corner. I have the board's toolchain but
not the board, so in addition to building it I reproduced its geometry in the
simulator and ran the game there, which exercises the same non-filling,
centred
path.
Simulator run, no new option enabled:
```
DOOM Shareware
i_init: Setting up machine state.
m_init: Init miscellaneous info.
r_init: Init DOOM refresh daemon - [ ]...................
p_init: Init Playloop state.
hu_init: Setting up heads up display.
st_init: Init status bar.
```
**Effect of the options**, measured on the LINUM board at 1024x600 with a
frame
counter added temporarily to `i_finish_update()`, playing the same
attract-mode
demo:
| `ROWSTAGE` | `STATIC_SCRNBUF` | frame rate |
|---|---|---|
| off | off | 5.1 fps |
| off | on | 6.5 fps |
| on | off | 8.4 fps |
| on | on | **13.7 fps** |
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
