This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
notes:comporg:spring2024:projects:def0 [2024/02/14 23:03] – [Set Drawing Points] cburling | notes:comporg:spring2024:projects:def0 [2024/02/15 04:58] (current) – [Drawing Regions] rspringe | ||
---|---|---|---|
Line 5: | Line 5: | ||
1. Select your region | 1. Select your region | ||
- | * out GPU_SelectedRegion, | + | <code asm> |
+ | out GPU_SelectedRegion, | ||
+ | </ | ||
2. Set your drawing points | 2. Set your drawing points | ||
- | * out GPU_DrawingPointX, | + | <code asm> |
- | | + | out GPU_DrawingPointX, |
+ | out GPU_DrawingPointY, | ||
+ | </ | ||
3. Draw your stuff | 3. Draw your stuff | ||
- | * out GPU_Command, | + | <code asm> |
+ | out GPU_Command, | ||
+ | </ | ||
It may prove useful to slap these commands into a subroutine, preferably with a nice name for easy tracking when debugging. | It may prove useful to slap these commands into a subroutine, preferably with a nice name for easy tracking when debugging. | ||
Line 39: | Line 45: | ||
=====Drawing Regions===== | =====Drawing Regions===== | ||
+ | Before a region can be drawn, its borders have to be defined within the texture file. | ||
+ | |||
+ | This is done similarly to the define_region functions in C: | ||
+ | <code C> | ||
+ | define_region(minX, | ||
+ | </ | ||
+ | |||
+ | Except that here, you have to input each coordinate value individually, | ||
+ | |||
+ | Getting only the necessary lines from the compiled code, defining a region would look like so: | ||
+ | <code asm> | ||
+ | out GPU_RegionMinX, | ||
+ | out GPU_RegionMinY, | ||
+ | . . . | ||
+ | out GPU_RegionHotSpotY, | ||
+ | </ | ||
+ | |||
+ | Where " | ||
+ | |||
To display your regions you have to say where you want to display the region. That is done by putting in values for X and Y into 2 different registers. Here is what that looks like: | To display your regions you have to say where you want to display the region. That is done by putting in values for X and Y into 2 different registers. Here is what that looks like: | ||
Line 77: | Line 102: | ||
" | " | ||
" | " | ||
+ | |||
+ | mov R0, 13 | ||
+ | ilt R0, 14 ; would set the value in R0 to 0 as the result of the comparison is true. | ||
+ | |||
*One needs to keep in mind that when these comparisons are passed, they are replaced with a resulting value, like 1 or 0. So do be careful when comparing a register to an integer or another register. | *One needs to keep in mind that when these comparisons are passed, they are replaced with a resulting value, like 1 or 0. So do be careful when comparing a register to an integer or another register. | ||
Line 82: | Line 111: | ||
**A good idea is to move the value one wants evaluated to another register and have the second one evaluated, as to not overwrite memory and cause oneself trouble | **A good idea is to move the value one wants evaluated to another register and have the second one evaluated, as to not overwrite memory and cause oneself trouble | ||
=====Loops===== | =====Loops===== | ||
+ | While there are no loops as we recognize from C, (while, do while, for) we have the equivalent of the infamous go-to.\\ | ||
+ | Further up in the Gamepad section we used the conditional jumps which are in essence a type of boolean loop. | ||
+ | |||
+ | The main loop that will run this and future programs is a well placed unconditional jump | ||
+ | <code asm> | ||
+ | jmp __label | ||
+ | </ | ||
+ | where your label would be somethin akin to '' | ||
+ | |||
+ | You'd also need a label such like '' | ||
=====TASK===== | =====TASK===== |