32blit / 32blit-sdk Goto Github PK

Using a cross-compiled SDL2 library and attempting to build a project for Win32 results in "undefined reference to `SDL_main'"

Steps to reproduce:

1. Enter any project directory
2. Make a build directory
3. Set up with cmake .. -DCMAKE_TOOLCHAIN_FILE=../../../mingw.toolchain -DSDL2_DIR=/usr/local/cross-tools/i686-w64-mingw32/lib/cmake/SDL2 -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
4. Run "make"

Example verbose output:

[100%] Linking CXX executable platformer.exe
/usr/bin/cmake -E cmake_link_script CMakeFiles/platformer.dir/link.txt --verbose=1
/usr/bin/cmake -E remove -f CMakeFiles/platformer.dir/objects.a
/usr/bin/i686-w64-mingw32-ar cr CMakeFiles/platformer.dir/objects.a @CMakeFiles/platformer.dir/objects1.rsp
/usr/bin/i686-w64-mingw32-g++    -Wl,--whole-archive CMakeFiles/platformer.dir/objects.a -Wl,--no-whole-archive  -o platformer.exe -Wl,--out-implib,libplatformer.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/platformer.dir/linklibs.rsp
/usr/local/cross-tools/i686-w64-mingw32/lib/libSDL2main.a(SDL_windows_main.o): In function `main_getcmdline':
/mnt/c/Users/32blit/Documents/Development/Pimoroni/SDL2-2.0.10/build.mingwx86/../src/main/windows/SDL_windows_main.c:175: undefined reference to `SDL_main'
collect2: error: ld returned 1 exit status
CMakeFiles/platformer.dir/build.make:102: recipe for target 'platformer.exe' failed
make[2]: *** [platformer.exe] Error 1
make[2]: Leaving directory '/mnt/c/Users/32blit/Documents/Development/Pimoroni/32blit-beta/examples/platformer/build.mingw'
CMakeFiles/Makefile2:71: recipe for target 'CMakeFiles/platformer.dir/all' failed
make[1]: *** [CMakeFiles/platformer.dir/all] Error 2
make[1]: Leaving directory '/mnt/c/Users/32blit/Documents/Development/Pimoroni/32blit-beta/examples/platformer/build.mingw'
Makefile:86: recipe for target 'all' failed
make: *** [all] Error 2

Main exists in Main.cpp of the SDL HAL, with the correct signature.

tried to get a rgba png file formated from aseprite to use in code, get error from line 207 -> too many arguments, expected 3.

png is just 16x16px.

For every percentage update when running make on the latest master commit, the printed messages are spammed like this

[ 63%] Building CXX object 32blit/CMakeFiles/BlitEngine.dir/types/map.cpp.o
shared:WARNING: LLVM version appears incorrect (seeing "11.0", expected "10.0")
[ 66%] Building CXX object 32blit/CMakeFiles/BlitEngine.dir/types/mat3.cpp.o
shared:WARNING: LLVM version appears incorrect (seeing "11.0", expected "10.0")
[ 69%] Building CXX object 32blit/CMakeFiles/BlitEngine.dir/types/mat4.cpp.o
shared:WARNING: LLVM version appears incorrect (seeing "11.0", expected "10.0")
[ 72%] Building CXX object 32blit/CMakeFiles/BlitEngine.dir/types/vec2.cpp.o
shared:WARNING: LLVM version appears incorrect (seeing "11.0", expected "10.0")
[ 75%] Building CXX object 32blit/CMakeFiles/BlitEngine.dir/types/vec3.cpp.o
shared:WARNING: LLVM version appears incorrect (seeing "11.0", expected "10.0")

Is this a new warning, or has the target been dropped to 10.0 for some reason?

To clarify, its when running

emcmake cmake .. -G "Unix Makefiles"
make

following instructions from here

Joystick now regularly jumps to the top left corner whenever you move it to the bottom right corner.

Last known good commit: 29be45c

Right now our README.md is getting bigger by the minute with all the necessary steps to get working.

While the Wiki is great for FAQs and more esoteric issues I think it might be worth creating a documentation folder and having a WINDOWS.md, LINUX.md and OSX.md for noise-free instructions.

Thoughts?

blit::debug() is defined in the SDL HAL, but currently not the STM32 HAL. Calling it will cause the program to crash spectacularly.

Maybe just me being a bit slow, but where it says the tool is now in tools/src/32Blit I got a bit confused about the fact that is relative to the current path, apposed to the same directory that exists in the root directory (except that tools/src/32Blit.cpp) which threw me for a minute.
Feel free to close if it's not worth spoonfeeding.

timers do not start counting after setting duration, start and loops and do even not start if you update the timers manually

Based on the geometry example, it looks like joystick X value goes positive when you push left. This is the opposite of screen coordinates. This assumes the example is not buggy, which I currently have no way of verifying.

If this is the case, I strongly recommend flipping the joystick X axis in the STM HAL to make it easier to understand.

Joystick Y axis seems to go positive when you push down, which matches screen coordinates.

Note: In SDL, right and down are positive, so one of the HAL will need to handle this no matter what.

I recommend replacing all linear algebra code with this header:

https://github.com/sgorsten/linalg

It is public domain and very complete. It is all implemented using templates so it supports any type.

For example using linalg.h, vec2.hpp can be completely replaced by the following:

#include <linalg.h>
typedef linalg::vec<float, 2> vec2;

and perhaps a few syntactic changes where vec2 is used.

We've tested the DAC on its own, but need to add it to the house-of-cards that is the STM32 HAL firmware. Previous attempts with bringing the DAC online tended to interfere with other peripherals, so we need to tread carefully.

DAC should use DMA which I'm given to understand must be in a particular memory region.

We should try to load .wav samples right off the SD card. At ~800KB/sec we have more than enough bandwidth to stream 16bit mono samples.

When attempting to compile under WSL (using the 32blit.toolchain file), the following error is returned.

/home/username/32blit-beta/32blit/graphics/mode7.cpp: In function 'vec2 blit::world_to_screen(vec2, float, float, vec2, float, float, blit::rect)':
/home/username/32blit-beta/32blit/graphics/mode7.cpp:49:24: error: 'copysign' is not a member of 'std'
     float theta_sign = std::copysign(1.0f, theta);
                        ^
/home/username/32blit-beta/32blit/graphics/mode7.cpp:49:24: note: suggested alternative:
In file included from /home/username/32blit-beta/32blit/graphics/mode7.cpp:6:0:
/usr/include/newlib/math.h:266:15: note:   'copysign'
 extern double copysign _PARAMS((double, double));
               ^
32blit/CMakeFiles/BlitEngine.dir/build.make:374: recipe for target '32blit/CMakeFiles/BlitEngine.dir/graphics/mode7.cpp.obj' failed
make[2]: *** [32blit/CMakeFiles/BlitEngine.dir/graphics/mode7.cpp.obj] Error 1
CMakeFiles/Makefile2:85: recipe for target '32blit/CMakeFiles/BlitEngine.dir/all' failed
make[1]: *** [32blit/CMakeFiles/BlitEngine.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

I'm using an Ubuntu 16.04 based WSL and gcc/g++-9

Right now I'm not 100% sure if this is a hardware fault due to me using my SD card slot as a ground connection for an oscilloscope, or an issue with how/when the SD card is initialised.

It seems to be the case that I can insert an SD card and have it work fine through device resets, but as soon as it is removed, or the battery is disconnected it will fail to work until I undergo an arcane ritual of slowly inserting the SD card while repeatedly resetting.

A vague guess is that something is preventing the card from entering SPI mode during the normal start-up procedure, and this can be fudged by not-quite-inserting-the-card. It looks like SPI mode requires the CS signal to be asserted (active low) during start up. Since the card will not exit SPI mode until a power cycle (which reset does not cause) it will work fine until power is otherwise lost.

Now that we have releases building we need to add a couple of additional files to the release tree:

1. README.txt - to document the intent and origin of the distributed files, and installation instructions for STM32 releases
2. LICENSE.txt - to reiterate the repository license and clarify that the source for all binaries is available in this repository, and the source code for SDL2.dll (where applicable) is available.
3. CHANGELOG.txt - to summarise changes- updating this file would be a manual step before releases and I want to avoid too many of those, specially since the GitHub release info can/should contain a list of changes.

STM32 build fails (at least on Linux). There is the following error:

rnentjes@rnentjes-MS-7B79:~/Development/32blit/32blit-beta/examples/palette-cycle/build.stm32$ make
-- Configuring done
-- Generating done
-- Build files have been written to: /home/rnentjes/Development/32blit/32blit-beta/examples/palette-cycle/build.stm32
[ 73%] Built target BlitHalSTM32
[ 98%] Built target BlitEngine
[ 99%] Linking CXX executable palette-cycle.elf
Building palette-cycle.bin
Building palette-cycle.dfu
/usr/bin/objcopy: Unable to recognise the format of the input file `/home/rnentjes/Development/32blit/32blit-beta/examples/palette-cycle/build.stm32/palette-cycle.elf'
make[2]: *** [CMakeFiles/palette-cycle.dir/build.make:236: palette-cycle.elf] Error 1
make[2]: *** Deleting file 'palette-cycle.elf'
make[1]: *** [CMakeFiles/Makefile2:74: CMakeFiles/palette-cycle.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

There is a semicolon in an assignment in 32blit-stm32/Makefile:91 which shouldn’t be there. This causes the PREFIX to not be set and then it will pick up the command from the path.

In follow up to #105, using C++11's enum class it would be possible to define a type-safe enumeration type representing a set of button states.

This would function similarly to the current situation in that you could define bitwise operators to operate on the type, but it would prevent certain accidents that might occur by using a non-typesafe solution such as std::uint16_t or a plain enum.

For example, one common mistake made by some people when using bitsets is to try to combine bits using + instead of |, which can lead to errors if the same bit is added twice, or if two bits overlap.
E.g. buttons = blit::Button::A + blit::Button::B + blit::Button::A.

With scoped enumerations, which are not implicitly convertible to int, you could either implement operator + in terms of |, or disallow operator + altogether, thus preventing this scenario.

As I'm sure you can imagine, there are a number of similar situations in which enum's ability to be implicitly converted to int can cause subtle bugs or errors that will not be detected by the compiler as they may well appear to it as being intentional.

It is entirely possible to convert a scoped enumeration to an integer by manual conversion with a static_cast or C-style cast if need be, but in the majority of cases that should be unnecessary as the bitwise operations should suffice.

Ultimately the biggest benefit is that it creates a designated (type-safe) type that represents a group of buttons, which makes code that interacts with and manipulates buttons much more self-descriptive.

Of course, nothing in life is free, there are a few potential downsides,
mostly in relation to backwards compatibility with exsting code:

One potential downside is that this change would prevent the practice of writing code like if(blit::buttons & blit::buttons::A) and would force the practice of the more verbose if((blit::buttons & buttons::A) != buttons::None) because it is not possible to define a conversion operator for a scoped enumeration.

One other potential downside is that you wouldn't be able to write blit::A instead of blit::Button::A, which might break some existing code, but arguably this is actually a benefit because blit::A is not very descriptive.

I'd like to note that this change would not preclude the #63 proposal and could easily work in conjunction with it.

[build] [1/1 100% :: 0.066] Linking CXX executable examples/flight/flight.elf
[build] FAILED: examples/flight/flight.elf 
[build] : && /usr/bin/arm-none-eabi-g++  -mcpu=cortex-m7 -mthumb -mfloat-abi=hard  -mfpu=fpv5-d16 -Os -Wall -fdata-sections -ffunction-sections -Wattributes -Wdouble-promotion -Wno-unused-variable -Wno-write-strings -fpermissive -Os -DNDEBUG  -specs=nosys.specs -Wl,--gc-sections -specs=nano.specs -T /home/daftfreak/programs/32blit-beta/32blit-stm32/STM32H750VBTx_FLASH.ld    -Wl,-Map=flight.map,--cref 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/main.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/stm32h7xx_it.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/stm32h7xx_hal_msp.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_adc.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_adc_ex.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_cortex.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_dac.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_dac_ex.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_hrtim.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_smbus.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_ltdc.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_ltdc_ex.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_dsi.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_qspi.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_spi.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_spi_ex.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_tim.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_tim_ex.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_rcc.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_rcc_ex.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_flash.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_flash_ex.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_gpio.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_hsem.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_dma.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_dma_ex.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_mdma.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_pwr.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_pwr_ex.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_i2c.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_i2c_ex.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_exti.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_rng.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_pcd.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_pcd_ex.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_ll_usb.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Middlewares/Third_Party/FatFs/src/diskio.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Middlewares/Third_Party/FatFs/src/ff.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Middlewares/Third_Party/FatFs/src/ff_gen_drv.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Middlewares/Third_Party/FatFs/src/option/syscall.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Middlewares/ST/STM32_USB_Device_Library/Core/Src/usbd_core.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Middlewares/ST/STM32_USB_Device_Library/Core/Src/usbd_ctlreq.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Middlewares/ST/STM32_USB_Device_Library/Core/Src/usbd_ioreq.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Src/usbd_cdc.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/system_stm32h7xx.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/user_diskio.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/fatfs.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/fatfs_sd.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/usb_otg.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/usb_device.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/usbd_conf.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/usbd_desc.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/usbd_cdc_if.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/gpio.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/adc.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/dac.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/debug.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/dma.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/hrtim.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/i2c.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/i2c-msa301.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/i2c-bq24295.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/ltdc.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/quadspi.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/spi.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/spi-st7272a.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/sys.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/tim.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/rng.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/32blit.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/Src/CDCLogging.c.obj 32blit-stm32/CMakeFiles/BlitHalSTM32.dir/startup_stm32h750xx.s.obj examples/flight/CMakeFiles/flight.elf.dir/flight.cpp.obj  -o examples/flight/flight.elf  32blit/libBlitEngine.a && cd /home/daftfreak/programs/32blit-beta/build/examples/flight && /usr/bin/arm-none-eabi-objcopy -O ihex /home/daftfreak/programs/32blit-beta/build/examples/flight/flight.elf flight.hex && /usr/bin/arm-none-eabi-objcopy -O binary -S /home/daftfreak/programs/32blit-beta/build/examples/flight/flight.elf flight.bin && /home/daftfreak/programs/32blit-beta/tools/dfu build --force --out flight.dfu flight.bin && arm-none-eabi-size /home/daftfreak/programs/32blit-beta/build/examples/flight/flight.elf
[build] /usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: examples/flight/flight.elf section `.rodata' will not fit in region `FLASH'
[build] /usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: region `FLASH' overflowed by 5528 bytes

Looks like #38 increased code size enough to make this example too big.

After reset the STM32 runs whatever is in internal flash. If you are debugging something in external flash this currently means you have to go into the menu and switch.

It should be possible to use an openocd script to write a value into memory somewhere and then have the internal program read it and automatically jump to external.

This is similar to the mechanism currently used for DFU, but is a little more complicated because we have to configure QSPI first. By the time that is done, the memory address storing the boot magic has been overwritten.

Tweening functionality is currently commented out, since it's old dead Lua code from before we decided to aim for a cleaner separation of concerns.

It needs re-written to be C++ style.

As per #2 there should be a user API for controlling the RGB LED.

Presently surface::text lives in surface.cpp and defines a very crude text drawing function that's in need of some TLC: https://github.com/pimoroni/32blit-beta/blob/666c5d2ef0315981b02c5eaf448ada026c09fa43/32blit/graphics/surface.cpp#L446-L516

1. Needs to support alignment within its defined rect()
2. Needs to support clipping to screen bounds, and potentially also wrapping/clipping to rect() bounds
3. Needs relocating into text.cpp for better separation of concerns

Right now the use of syntax like &minimal_font[0][0] to address the first byte of a specific font is ungainly. Font should possibly be a struct with character size and data address or something similar.

One would expect something like the following:

fb.text("Hello World", blit::font::minimal, rect(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT), blit::text_align::center_center);

To place the text "Hello World" in the center of the display.

And

fb.text("Hello World", blit::font::minimal, point(100, 100), blit::text_align::center_center);

To place the text centered vertically and horizontally around the given screen coordinatewith an implicit clipping rect of the entire screen area.

Timer 15, Channel 1 is used to drive the LCD Backlight Enable pin on PE5. There seems to be some knack to getting it up and running.

For the time being I have configured a fallback GPIO so the backlight will default on if MX_TIM15_init() is not called.

Current WIP resides in the rebuild fork: https://github.com/pimoroni/32blit-beta/tree/refresh-from-stm32-cubemx

The reason is actually explained in the commit:

32blit's RNG is a non-deterministic random number generator or true-RNG. Its output cannot be predicted and used to generate deterministic levels from seeds. std::rand() or perhaps your own LFSR or deterministic number sequence generator should still be used for this.

The SDL HAL uses std::rand() to implement blit::rand(). This means that if you use both of them in your game, then std::rand() will produce different values on hardware vs SDL.

The SDL implementation of blit::rand() should instead use some other implementation which does not affect std::rand().

Example:

blit::fb.rectangle(
    blit::point(1, 1),
    blit::point(3, 3)
);

This will draw a rectangle 1 wide and 2 high. It should draw a rectangle 2 wide and 2 high.

#175 introduced the ability to add binary assets to a project, but currently doesn’t allow any transformation from source.

It would be great if assets could be added by type and converted for use- IE a sprite calls sprite builder and then compiles the resulting binary data into the project ala Daft-Freak@a373fa4

// action buttons
{SDLK_z, blit::button::A},
{SDLK_x, blit::button::B},
{SDLK_c, blit::button::X},
{SDLK_y, blit::button::Y},

zxcv?

It would be very useful in reading the examples code if the original graphic assets (png/psd/gif/jpeg) could be put in the repository, please. Will certainly help with #17

As discussed on the discord channel, this seems like a useful set of functions to have.
There are some open-source libs out there already in C++, but licensing is my concern for just using those, so I'm standing clear of this one.

There are currently no user-side blit:: API functions for accessing a SD card.

"shmup" is currently very thin on the ground and only currently demos a dawn/dusk palette cycling transition that could be used between levels or during the game progres.

We discussed a procedurally-generated branching level design for this example with a minimap and have some image concepts of this somewhere.

SD card throughput has been less than stellar, and while we're using a 1-bit bus I don't believe we're quite as close to the theoretical maximum speed as it's possible to get. Looking over the SD card code reveals codepaths and potential inefficiencies that could cause slowdown, I've fixed some of these with significant resulting gains in performance. I think it's worth trying to find more opportunity to eke throughput out of the SD card.

@Daft-Freak Probably one for you.
I'm following the VSCode.md file and got to change the configuration provider and the list is empty
Seen here
As you can see I do have both plugins installed, the list is empty, but I did eventually have a notification to 'configure the project'.
Any troubleshooting suggestions you might have?

In screen_to_world :
float distance = ((far - near) / float(s.y - viewport.y)) + near; is inf for the first line. Which results in nan getting returned. That eventually gets converted to a uint16_t in mipmap_texture_span, resulting in RuntimeError: invalid conversion to integer.

Example: https://cupboard.daftgames.net/32blit/shell.html?app=flight

Currently fb.clear() does not reset the pen to black. It will clear the screen with whatever pen was last selected in the render method.

So this render method:

    fb.clear();
    fb.pen(blit::rgba(255, 255, 255));
    fb.rectangle(rect(5, 5, 5, 5));

Will actually paint the entire screen white from the second time rendering is called. The tiny rectangle will not be visible at all, because everything is white.

I recommend clear() should reset the pen to black as well.

Maybe even add a new clear_color rgba variable that would be black by default, and that can be changed to whatever you want your clear color to be.

Currently the API provides us with button statuses only (is it pressed or is it released). The demo game scrolly-tile does some bitfield magic to keep track of what is actually done with the buttons - and not just if it is held or not.

Relevant code:

	uint16_t changed = blit::buttons ^ last_buttons;
	uint16_t pressed = changed & blit::buttons;
	uint16_t released = changed & ~blit::buttons;

It would be great if this same functionality would be part of the engine.

Instead of just blit::buttons it could be a struct of some kind, where you would have three members:

• status - to check the status of a single button, like what blit::buttons is now.
• pressed - that would tell which button was pressed since last time
• released - that would tell which button was released since last time

ALthough it might be a little bit long to write, it would increase clarity.

For example: if ( blit::buttons::pressed & blit::button::A )

I see a comment from @Gadgetoid in the Engine/API project cards about sending deltas rather than absolute time.

I can easily calculate the deltas but conversely I could accumulate them to get the actual time - however my brain says it would like the actual time so if I want something to happen as soon after a certain amount of time has elapsed, we can store time + x somewhere and quickly check that at the beginning of either block.

I'm aware of the timer API but I'm thinking of keeping things simple for novice programmers (me, school students, etc) and I sort of like the init/render/update setup as a mirror of the constructs they see (micro:bit on-start & forever or Arduino setup & loop)

End-user code should have the ability to control the onboard buzzer within certain parameters.

The following engine headers include using namespace blit;.

• types/map.hpp
• graphics/surface.hpp
• graphics/tilemap.hpp

This causes every file that includes them to also use the namespace, leading to random name collisions in user code. This filters through to any file that includes 32blit.hpp.

Note that fixing this will probably break all the examples that don't already contain using namespace blit;.

It's probably to be expected considering it's an early release, but some of the example can't be build as is:

• fire
  Complain about missing engine and graphics namespace (they don't exist in the 32blit source tree)
• flight
  For similar reasons (there are more errors, but could be due to the namespace issue)
• matrix-test
  Similar reasons again
• platformer
  Similar reasons, also look for an input namespace
• sprite-test
  Similar reasons
• logo
  Again same reasons
• particles
  Same
• tilemap_test
  Same
• racer
  This one is an oddball. It is at link time that error come. It miss the functions:

• update(unsigned int)
• render(unsigned int)
• init()

All the non mentioned one seems to compile.

This one is definitely wrong. Code:

    blit::fb.pen(blit::rgba(0, 0, 0));
    blit::fb.circle(blit::point(4, 4), 3);

Result:

There's a number of things in this library that could be improved by using C++11 features (e.g. using constexpr float pi instead of #define M_PI, using alignas instead of #pragma pack, using scoped enumerations), but before I raised any of those things as issues I wanted to check - is there a particular reason why C++11 features are being (or at least appear to be) avoided?

I messed up my branches and can't seem to do a pull request without handing over my first born.

Please copy the content from my fork here (https://github.com/LordEidi/32blit-beta/blob/master/docs/Tools.md) and add it to the docs folder. You might want to remove the Readme.md in the tools folder for it still points to the old script.

Regarding storage of save games and scores, it would be great to have an API for that, so that we do not have to worry about file acccess or block writing. I think you had quite some discussions earlier on how this whole thing should work, what should be in the device memory vs the SD card. I don't remember is there was a definite solution reached?

Anyway, for local storage I would like to see something like:

• ls_enumerate() -- Enumerate saved "blobs".
• ls_save() -- Save a new blob with a given name. Give it a name (string), data (pointer to data), and a length. It stores it some where.
• ls_get_length() -- Get length of blob maybe? Give it a name (string), return the length
• ls_load() -- Load a blob with a given name. Give it a name (string), data storage (pointer to storage in memory) and a length of the buffer. If it fits there, it gets loaded.

(ls stands for local storage, and of course this just brings up another issue on how you want to name these things in code ... prefixes vs namespace vs classes, etc? )

More questions that need answers / discussion:

• Should apps have limits on how much data they can store?
• How to worry about storage running out?
• Does Local Storage require an SD card?
• Should we be able to set a priority for storage (so for example the scores need to be saved always, but save data or auto save data might or might not fit).

engine/input.hpp defines the bit masks for each button in an enum:

  enum button {
    DPAD_LEFT = 1,
    DPAD_RIGHT = 2,
    DPAD_UP = 4,
    DPAD_DOWN = 8,
    A = 16,
    B = 32,
    X = 64,
    Y = 128,
    MENU = 256,
    HOME = 512,
    JOYSTICK = 1024
  };

  extern uint32_t buttons;

The type of an enum is undefined - it may be signed or unsigned. Usually is it signed. If you try to take the bitwise or of buttons and a button mask defined in the enum, this gives a compiler warning.

I think this should be exactly equivalent (in particular, it should use no memory):

  namespace button {
    static const uint32_t DPAD_LEFT = (1<<0);
    static const uint32_t DPAD_RIGHT = (1<<1);
    static const uint32_t DPAD_UP = (1<<2);
    static const uint32_t DPAD_DOWN = (1<<3);
    static const uint32_t A = (1<<4);
    static const uint32_t B = (1<<5);
    static const uint32_t X = (1<<6);
    static const uint32_t Y = (1<<7);
    static const uint32_t MENU = (1<<8);
    static const uint32_t HOME = (1<<9);
    static const uint32_t JOYSTICK = (1<<10);
  }

  extern uint32_t buttons;

We should be able to:

pressed(button::L1)
pressed(button::R1)

Analog readings for L2/R2 might be more problematic, since these are user expansion headers and connected devices may vary.

As mentioned in #35 the asset builder is currently producing output that's incompatible with the engine:

https://github.com/pimoroni/32blit-beta/blob/64eefb68736bb262fb51fab687d253bbad582ed6/tools/asset-builder#L80-L85

Disagrees with:

https://github.com/pimoroni/32blit-beta/blob/64eefb68736bb262fb51fab687d253bbad582ed6/32blit/types/pixel_format.hpp#L7-L13

The asset builder needs to separate code paths:

1. packed - for producing palette based images of type 0x03 that use an RGBA palette in all cases and is loaded with load_from_packed
2. raw - for producing raw hpp-header style code or binary output that uses RGB, RGBA or RGB565 and is loaded by initialising it as a surface or loading the raw bytes (from SD card) into an existing surface.

The asset builder should proably also be renamed image-builder or similar, so that code used for building game files (which will likely require headers) and audio files (which will be no-doubt complex) can live in separate tools and be more easily maintained.

The asset builder also needs documentation to set expectations from it- what are the practical limitations of packed vs raw data? IE: raw can, in theory, be unlimited in size if it's read from SD card using seek operations to select individual portions.

How should multiple assets be packed together and stored for access from a game that uses SD card?

I can setup world with: TileMap world((uint8_t *) terrainTiles, (uint8_t *) terrainData, Size(32, 24), SpriteSheet::load(tilemapPackedData));

but world.draw(&screen, Rect(0, 0, 320, 240), nullptr);

results in 8 rows of the 8x8 tiles drawn as expected, 8 rows of blank and then 8 rows as expected. Transforms for sprites and for the TileMap work OK. The blanks are due to the following returning -1:
https://github.com/pimoroni/32blit-beta/blob/5576e3dc53f1076e82fc829af5beae68d6742d09/32blit/graphics/tilemap.cpp#L49

I can see it's somewhere in the XOR on line 53 but I'm a bit lost on why this is here so I'm passing this on to a someone who knows the design.

This is an issue on both X & Y axes, a 12 x 8 world will have some blank columns, a 12 x 12 will have blank rows & columns. A 4 x 4 world works.

I'm using code from 8th Feb, last commit 5576e3d.

The following graphics primitives aren't implemented in the blit API. They probably should be for completeness:

• Unfilled rectangle.
• Unfilled circle.
• Filled ellipse.
• Unfilled ellipse.
• Filled polygon.

An unfilled ellipse algorithm is described here: https://dai.fmph.uniba.sk/upload/0/01/Ellipse.pdf

Once ellipses are implemented, the circle implementations can be a wrapper around them to save space.

Filled polygons can be implemented by drawing filled triangles:

    for(n=1; n<(points-1); n++)
        triangle(p[0], p[n], p[n+1]);

A FAT filesystem on external Flash- assuming it is possible (block size, wear leveling concerns, etc)- would be useful for myriad reasons not limited to storing games, settings, save states and Lua scripts without requiring an SD card.

It would require a new implementation of user_diskio.c:

https://github.com/pimoroni/32blit-beta/blob/d788e63013a37b7eac0cd19d76398844fcb624fd/32blit-stm32/Src/user_diskio.c

And linking into the FATFS system: https://github.com/pimoroni/32blit-beta/blob/master/32blit-stm32/Src/fatfs.c#L33

There's a - possibly useful - implementation available under the MIT license here: https://github.com/amvasil/stm32-qspi-fat-usb/blob/master/Src/fat_qspi_drv.c

Currently I've fudged a lot of the hardware control into the 32blit engine API, and it feels a little wrong to keep it here. Some of these things - battery for instance - have no equivilent in the SDL HAL (although one could argue they might).

That said does - for example - LED control really differ so much from reading the accelerometer conceptually?