nuttx-apps/games/NXDoom/Kconfig

#
# For a description of the syntax of this configuration file,
# see the file kconfig-language.txt in the NuttX tools repository.
#

config GAMES_NXDOOM
	bool "NXDoom"
	default n
	depends on ALLOW_GPL_COMPONENTS
	depends on VIDEO_FB
	depends on CRYPTO
	depends on LIBC_LOCALE
	---help---
		Play DOOM on NuttX!

if GAMES_NXDOOM

comment "Program options"

config GAMES_NXDOOM_PRIORITY
	int "Priority"
	default 100
	---help---
		The task priority for the NXDoom application.

config GAMES_NXDOOM_STACKSIZE
	int "Stack size"
	default 4096
	---help---
		The stack size for the NXDoom application.

comment "General game options"

choice # Language
	prompt "Game language"
	default GAMES_NXDOOM_LANG_EN

	config GAMES_NXDOOM_LANG_EN
		bool "English"
		---help---
			English language support (original).

	config GAMES_NXDOOM_LANG_FR
		bool "French"
		---help---
			French language support.
endchoice # Language

config GAMES_NXDOOM_PREFDIR
	string "DOOM data directory"
	default "/data"
	---help---
		Directory where DOOM WAD files are stored.

config GAMES_NXDOOM_ENDOOM
	bool "Show ENDOOM"
	default n
	---help---
		Show the ENDOOM screen (https://www.doomwiki.org/wiki/ENDOOM).

comment "Networking options"

config GAMES_NXDOOM_NET
	bool "Enable network features"
	default n
	---help---
		Not ported! Will not work.

if GAMES_NXDOOM_NET

config GAMES_NXDOOM_NET_LOGS
	bool "Enable network logging"
	default n
	---help---
		Enables log information from the network features.

config GAMES_NXDOOM_NET_MAXPLAYERS
	int "Maximum number of players"
	default 6
	---help---
		The maximum number of players, multiplayer/networking.
		This is the maximum supported by the networking code; individual games
		have their own values for MAXPLAYERS that can be smaller.
		ChocolateDOOM default was 8.

config GAMES_NXDOOM_NET_BACKUPTICS
	int "Maximum number of backup tics"
	default 32
	---help---
		The maximum number of backup tics to store locally during a net game.
		ChocalateDOOM default was 128.

config GAMES_NXDOOM_NET_MAXPLAYERNAME
	int "Maximum player name length"
	default 16
	---help---
		The maximum number of characters in a player name for netgames.
		ChocalateDOOM default was 30.

endif # GAMES_NXDOOM_NET

comment "Sound options"

config GAMES_NXDOOM_SOUND
	bool "Enable sound features"
	default n
	---help---
		Not ported! Will not work.

if GAMES_NXDOOM_SOUND

config GAMES_NXDOOM_RTTTL_MUSIC
	bool "RTTTL music"
	default n
	depends on AUDIOUTILS_RTTTL_C
	depends on !DISABLE_PTHREAD
	---help---
		Play music using RTTTL.

config GAMES_NXDOOM_RTTTL_DEVICE
	string "RTTTL device"
	default "/dev/pwm0"
	depends on GAMES_NXDOOM_RTTTL_MUSIC
	---help---
		Device for RTTTL output (only PWM currently supported).

endif # GAMES_NXDOOM_SOUND

comment "Graphics options"

config GAMES_NXDOOM_FBPATH
	string "Framebuffer path"
	default "/dev/fb0"
	---help---
		Path to the framebuffer character driver to use for rendering.

comment "Input options"

choice # Input method
	prompt "NXDoom input method"
	default GAMES_NXDOOM_KEYBOARD

	config GAMES_NXDOOM_KEYBOARD
		bool "Keyboard"
		---help---
			Use a NuttX keyboard character driver.

endchoice # Input method

if GAMES_NXDOOM_KEYBOARD

config GAMES_NXDOOM_KBDPATH
	string "Keyboard device path"
	default "/dev/kbd0"
	---help---
		Path to the keyboard device to use as input.

endif # GAMES_NXDOOM_KEYBOARD

config GAMES_NXDOOM_FB_CMAP
	bool "Draw through the frame buffer colour map"
	default n
	---help---
		DOOM draws into an 8-bit palettised buffer and normally converts
		every pixel to the pixel format of the frame buffer as it blits.
		A frame buffer that has a colour map of its own can do that
		conversion in hardware while it scans the display out, so enable
		this to load the DOOM palette into the colour map and blit the
		palette indices unconverted.

		This needs a frame buffer that is 8 bits per pixel and supports
		FBIOPUT_CMAP, such as an STM32 LTDC layer configured for L8.  It
		both removes the conversion and halves the amount of data written
		per frame, which matters most when the frame buffer is external
		memory.

config GAMES_NXDOOM_FILLSCREEN
	bool "Stretch the image to the whole display"
	default n
	---help---
		By default the 320x200 image is scaled by the largest whole number
		that fits, which leaves a border on a display whose size is not an
		exact multiple of it.  Enable this to stretch the image over the
		entire frame buffer instead, which fills the display at the cost of
		a scale factor that is not uniform across the image.

config GAMES_NXDOOM_ROWSTAGE
	bool "Build each output row in a staging buffer"
	default n
	---help---
		Expand each row into a staging buffer and copy it to the frame
		buffer, rather than writing the frame buffer a pixel at a time.
		Every frame buffer access then becomes a burst-friendly copy, which
		is worth a lot when the frame buffer is external memory and the
		data cache is in write-through mode, and little otherwise.

		Costs a few kilobytes of .bss for the buffer.  A row that does not
		fit is written directly, as if this were disabled.

config GAMES_NXDOOM_STATIC_SCRNBUF
	bool "Place the render target in .bss"
	default n
	---help---
		DOOM renders into a 320x200 buffer that is normally taken from the
		heap.  On a board whose heap is mostly slow external memory the
		allocation lands there, which is close to the worst case:  the
		renderer draws in vertical columns, so consecutive writes are one
		screen width apart and none of them coalesce.

		Enable this to make the buffer a static object instead, so the
		linker places it in internal RAM along with the rest of .bss.  It
		costs 64000 bytes of RAM whether DOOM runs or not, so it is only
		worth it when internal RAM is plentiful and the heap is not.

comment "Optimizations"

config GAMES_NXDOOM_MAXVISPLANES
	int "Maximum number of visplanes"
	default 96
	---help---
		DOOM allocates a static number of 'visplanes' to use for gameplay. The
		original ChocolateDOOM source uses 128 of these. They take a significant
		amount of memory, so you may reduce the number. However, too few planes
		may cause 'visplane overflow' errors, which is more common in complex
		levels.

config GAMES_NXDOOM_MAXOPENINGS
	int "Maximum number of openings"
	default 32
	---help---
		DOOM allocates a static number of 'openings' to use for gameplay. These
		are defined as multiples of the SCREENWIDTH (320). The original
		ChocolateDOOM source uses 64 as the multiplier. They take a significant
		amount of memory, so you may reduce the number. However, too few
		openings will cause 'opening overflow' errors.

config GAMES_NXDOOM_MAXVISSPRITES
	int "Maximum number of visible sprites"
	default 96
	---help---
		DOOM allocates a static number of 'vissprites' to use for gameplay. The
		original ChocolateDOOM source uses 128. They take a significant amount
		of memory, so you may reduce the number. However, too few will cause
		overflow errors.

config GAMES_NXDOOM_MAXDRAWSEGS
	int "Maximum number of drawsegs"
	default 192
	---help---
		DOOM allocates a static number of 'drawsegs' to use for gameplay. The
		original ChocolateDOOM source uses 256. They take a significant amount of
		memory, so you may reduce the number. However, too few will cause
		rendering issues (overflow is checked to avoid crashes).

config GAMES_NXDOOM_RANGECHECK
	bool "Perform range checks"
	default y
	---help---
		The ChocolateDOOM source includes the ability to optionally exclude
		range checking on some array operations.

endif # GAMES_NXDOOM