From 533ac91079738dc4b957c836f92113fee3b2c8ce Mon Sep 17 00:00:00 2001 From: lonkaars Date: Wed, 15 Feb 2023 21:19:31 +0100 Subject: fix markdown for document converter --- docs/architecture.md | 18 ++++++++++-------- docs/research.md | 28 ++++++++++++++-------------- 2 files changed, 24 insertions(+), 22 deletions(-) (limited to 'docs') diff --git a/docs/architecture.md b/docs/architecture.md index 4ebc674..9c1e5f5 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -14,10 +14,10 @@ Important notes: The playable character has 4 actions that it can perform: -- horizontal movement +- horizontal movement - aiming -- jump -- ability / use +- jump +- ability / use To perform these action there will be 6 buttons for the user to use. @@ -51,11 +51,12 @@ The game engine will be designed to support 2D games. The engine will use a stat FSM is a useful tool for managing game states and transitions. A game can have many different states, such as a title screen, a level selection screen, a loading screen, and various gameplay states. Each state represents a particular configuration of the game, with different sets of variables, objects, and logic The state machine will be designed with the following states: -1. Initialization: The initialization state will be responsible for initializing all game-related variables and subsystems, including the FPGA-based picture processing unit. -2. Title Screen: The title screen state will display the game's title screen and wait for user input to start the game or access the options menu. -3. Options: The options state will allow the user to configure game settings, such as sound and graphics options. -4. Game Play: The game play state will be responsible for running the game logic and updating the game state. -5. Game Over: The game over state will display the game over screen and wait for user input to restart the game or return to the title screen. + +1. Initialization: The initialization state will be responsible for initializing all game-related variables and subsystems, including the FPGA-based picture processing unit. +2. Title Screen: The title screen state will display the game's title screen and wait for user input to start the game or access the options menu. +3. Options: The options state will allow the user to configure game settings, such as sound and graphics options. +4. Game Play: The game play state will be responsible for running the game logic and updating the game state. +5. Game Over: The game over state will display the game over screen and wait for user input to restart the game or return to the title screen. # PPU @@ -275,6 +276,7 @@ The Audio Processing Unit (APU) is programmed on the FPGA, here it will produce These signals will be generated using PWM, this allows a digital signal to act as an analog signal. Using this method it is theoretically possible to create all of the aforementioned signals. ![Audio signal with PWM](../assets/audioPWM.svg) + This figure shows an example signal (in blue), created by the FPGA. and the corresponding analog signal (in red). diff --git a/docs/research.md b/docs/research.md index ecabfe6..a7a6dcb 100644 --- a/docs/research.md +++ b/docs/research.md @@ -234,21 +234,21 @@ There are a lot of ways of creating tiles and sprites for pixel art. Underneath The playable character has 4 actions that it can perform: -- horizontal movement +- horizontal movement - aiming -- jump -- ability / use +- jump +- ability / use To control these actions there has to be at least 4 inputs. These can either be a button or joystick. The actions can be done as follows: -| Action | Button | Joystick | -| ------ | ------ | -------- | -| Movement | x | x | -| Aiming | x | x | -| Jump | x | | -| Ability | x | | +| Action | Button | Joystick | +| -------- | ------ | -------- | +| Movement | x | x | +| Aiming | x | x | +| Jump | x | | +| Ability | x | | ## Handling @@ -271,12 +271,12 @@ This will decrease the delay between the user-input and onscreen gameplay. The hardware of the game consist out of a microcontroller(stm32) and a FPGA(basys3). The hardware components needs to communicate with each other. For this a protocol is needed. See table 1 for a comparison of possible protocols: -| Protocol | UART | I2C | SPI | +| Protocol | UART | I2C | SPI | | -------- | ----- | ---- | --- | -|Number of lines | 1/2 | 2 | 4 | -|Duplex | Half-duplex | Half-duplex | Full-duplex | -|Data transfer speed | Upto 5mbps | Upto 3.4Mbps – 5Mbps | Default at 50Mbps. Upto 100Mbps | -|Speed | Slowest | Faster than UART | Fastest | +|Number of lines | 1/2 | 2 | 4 | +|Duplex | Half-duplex | Half-duplex | Full-duplex | +|Data transfer speed | Upto 5mbps | Upto 3.4Mbps – 5Mbps | Default at 50Mbps. Upto 100Mbps | +|Speed | Slowest | Faster than UART | Fastest | There are only two devices that has to be connected. Complexity and master/slave amount are not relevant for this purpose. If there are multiple entities the delay will increase and decreases the playability of the game. -- cgit v1.2.3 From 0730ad350a3a58de3a60ebe00e141a66875c5c33 Mon Sep 17 00:00:00 2001 From: lonkaars Date: Wed, 15 Feb 2023 21:23:07 +0100 Subject: merge #11 --- docs/architecture.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'docs') diff --git a/docs/architecture.md b/docs/architecture.md index 9c1e5f5..c1a2a95 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -24,7 +24,7 @@ To perform these action there will be 6 buttons for the user to use. A joystick is not needed for the movement because the movement is not complex, so button fulfill this. The layout will be as follows: -![Example controller layout](https://user-images.githubusercontent.com/17066065/219126294-b3fe11eb-e216-433a-9317-38f3e2ca4743.png) +![Example controller layout](https://user-images.githubusercontent.com/17066065/219142627-4fde02c2-edfc-43c5-8a3b-dd739cb472aa.png) ## Input handling: @@ -32,15 +32,15 @@ The hardware consist out of a microcontroller and a FPGA. The microcontroller will process the game logic. For this reason the input will be handled by the microcontroller as this will improve playability (stated in research). -The controller will have four buttons, so 4 data pins are needed on the microcontroller plus a ground and 3.3V or 5V pin. -In total there are 6 pins needed. -If the game is going to be played by 2 person, there are 4 more data pins needed so 8 data pins for both controllers. +The controller will have six buttons, so six data pins are needed on the microcontroller plus a ground and 3.3V or 5V pin. +In total there are eight pins needed. +If the game is going to be played by 2 persons, there are six more data pins needed so 8 data pins for both controllers. For data transfer between STM32 and FPGA there are 4 pins needed at maximum (SPI for instance). The STM32 will be used and most STM32 boards have enough I/O pins for our needs. The STM32 F030 and F091 provided by Avans both have 15 digital pins and 6 analog pins. The buttons will be connected as follows: -![Logic lines between processor and controller](https://user-images.githubusercontent.com/17066065/219113354-cbda7776-bc95-4d1f-8eb9-364f7d4f1b8d.png) +![Logic lines between processor and controller](https://user-images.githubusercontent.com/17066065/219143412-d6fb80b6-c5ab-4504-8151-864f6e4693a2.png) To implement the input in the game, the input should be checked at the start of each game cycle. In this case there are no interrupts needed. -- cgit v1.2.3