aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/architecture.md29
-rw-r--r--docs/research.md48
2 files changed, 76 insertions, 1 deletions
diff --git a/docs/architecture.md b/docs/architecture.md
index 1af2383..3452862 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -10,6 +10,35 @@ Important notes:
# Game controllers
+## Input
+The playable character has 4 actions that it can perform:
+- movement on the x-axis (left / right)
+- jump
+- ability / use
+To perform these action there will be 4 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:
+
+![image](https://user-images.githubusercontent.com/17066065/219126294-b3fe11eb-e216-433a-9317-38f3e2ca4743.png)
+
+## Input handling:
+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.
+For data transfer between STM32 and FPHA 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:
+
+![image](https://user-images.githubusercontent.com/17066065/219113354-cbda7776-bc95-4d1f-8eb9-364f7d4f1b8d.png)
+
+To implement the input in the game, the input should be ckecked at the start of each game cycle. In this case there are no interupts needed.
+
# STM32 software
The game engine will be designed to support 2D games. The engine will use a state machine to manage game states and transitions between them. The state machine will be implemented using a finite state machine (FSM) design pattern. The engine will also include support for handling user input, game logic, and sound.
diff --git a/docs/research.md b/docs/research.md
index a3e86ff..682ed43 100644
--- a/docs/research.md
+++ b/docs/research.md
@@ -98,7 +98,7 @@ int main() {
setup();
while(1) loop();
}
-
+```
# Generating audio signals
In order to generate sound for this project, a few posibilities exist (see chapters below)
@@ -204,3 +204,49 @@ There are a lot of ways of creating tiles and sprites for pixel art. Underneath
| Asesprite | https://www.aseprite.org/ |Yes | pixel art |
+# Input
+The playable character has 4 actions that it can perform:
+- movement on the x-axis
+- 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-axis| x | x |
+| Jump | x | |
+| Ability | x | |
+
+## Handling
+A joystick requires an ac input port.
+A button can use both a ac and dc input port.
+So the hardware needs to have both an ac input and a dc input, if a button and a joystick are used.
+The input can be handled by either the FPGA(stm32) or microcontroller (STM32).
+The microcontroller has the possibility to run multiple task simultaneously if needed.
+The FPGA code contains multiple entities.
+Data transfer between these entities takes at least one clock cycle.
+If there are multiple entities the delay will increase and decreases the playability of the game.
+
+## Conlcusion
+For gameplay reasons it is recommended to have the input handling as close as possible to the game logic unit.
+This will decrease the delay between the user-input and onscreen gameplay.
+
+# Microcontroller FGPA communication
+
+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 |
+| -------- | ----- | ---- | --- |
+|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.
+
+## Conlcusion
+It is recommended that SPI will be the communication protocol because of the data transfer speeds. The is a lot of data transfer between the microcontroller and FPGA.