Part II, Lesson 4#37
Conversation
|
At the moment this only implements ball movement, not bouncing. |
|
The current code looks fine to me. |
|
What are we missing here? The text part? @eievui5 do you have any update on this? |
|
We're missing the ball bouncing against the walls and the paddle, and the text. |
|
I'd like some feedback on the bouncing code. The pixel -> tilemap function might be too complex for the tutorial but I'm not sure how else to write it. Otherwise, I think this is pretty understandable :) |
|
The code should be complete now. |
ISSOtm
left a comment
ISSOtm
left a comment
There was a problem hiding this comment.
Alright, the logic seems correct, I just hope we won't start overflowing VBlank time... ><
Co-authored-by: Eldred Habert <eldredhabert0@gmail.com>
|
The text and code is now complete. |
avivace
left a comment
avivace
left a comment
There was a problem hiding this comment.
Wow, this actually reads very smoothly! I just left some minor comments and suggestions and will go over it again later.
Co-authored-by: Antonio Vivace <avivace4@gmail.com>
ISSOtm
left a comment
ISSOtm
left a comment
There was a problem hiding this comment.
Great work! I only have some clean-up suggestions.
Additionally, I would prefer if the Z flag was capitalised, for consistency with the "flags" lesson. (The rationale there was to avoid confusion with the c register.)
And maybe we could link back to some previous lessons, if they are relevant.
may i ask why you wont state that theyre called |
|
I just went with common practice. Using one of these names would probably help (and |
ISSOtm
left a comment
ISSOtm
left a comment
There was a problem hiding this comment.
Some minor changes, and then I'll have to make the explanation diagram for the last paragraph.
Co-authored-by: Eldred Habert <eldredhabert0@gmail.com>
|
Go ahead :) |
|
Here are screenshots of the diagram:
Maybe it should be clarified that we are considering the position of the ball's top-left pixel, though it is highlighted in the above. And, speaking of, going 16 pixels to the right doesn't seem to make much sense given how wide the paddle appears to be. I dunno. |
I’m not sure how much you’ve played around with the physics but i think this has the best feel to it. Any smaller and the player would probably be frustrated by the small paddle size. It might be worth doubling the width of the paddle with another sprite but i don’t think that’s necessary. |
|
Then maybe we should offset the hitbox a bit more to the left, so it's symmetrical? |
|
I'd rather just go edit the ball graphic to be one pixel over to the right. Could you update your diagram to reflect that? |
|
Sure, it's just a PNG, you can edit it in |
|
Thought it was an svg :) should be good now |
|
Alright, that looks good to me. Should we add a "bonus" heading, suggesting how to make the ball bounce when its bottom pixel touches the paddle's? We should suggest "you only need a single instruction!" ( |
|
Maybe. I like that it kinda sinks in. If we wanna add that in at all then maybe it should just be part of the tutorial itself. |
|
I think it would be beneficial to encourage experimentation, especially if it's just a single instruction. |
Co-authored-by: Eldred Habert <eldredhabert0@gmail.com>
|
|
||
| ::: tip | ||
|
|
||
| Please do not get stuck on the details of this next function, as it uses some techniques and instructions we haven't discussed yet. |
There was a problem hiding this comment.
Are we sure we shouldn't introduce (at least some) of those technicques and instruction before introducing them as code? It would be simpler and will avoid people having to "ignore" entire blocks of code because they cannot be understand yet.. Besides, what is the advantage or the purpose in doing this? It just adds backlog for the future ..
There was a problem hiding this comment.
There is so much to explain here that it would take an entire chapter to do so. I don't see any way to explain this without wasting a lot of the reader's time.
There was a problem hiding this comment.
All things considered, I think it would make sense to discuss this function in a chapter of its own, since there is so much to discuss.
Considering the way Part II is written, I think we should explain it after introducing it, so that all of the dry concepts and explanations will at least be in a context and goal already known to the reader.
Thus, I think we should dedicate the lesson following this one to that function. Does that seem reasonable?
There was a problem hiding this comment.
If there is so much to discuss, and if it requires an entire chapter, why exactly are we pushing this to the reader without discussing it beforehand? I don't see any advantage in doing so, except adding complexity in how are the concept presented. What I can propose is to actually write "this chapter that will explain this block" and then we merge/add it here. Eventually maybe this chapter could be split in 2 if it's too long, but I believe that the we definitely exaggerated in the "goal" for this chapter by pushing too much "unexplained" or "ignore this , will be explained" later stuff
There was a problem hiding this comment.
It's simply because all the math and instructions behind this would completely throw off the pacing of the tutorial. Our primary concern at the moment is teaching the logic of assembly and making a game.
I don't think anyone wants to start off "Hello, world!" by explaining all the intricacies of file descriptors and pipes, for example. I would consider this function to be "#include <stdio.h>". It would be nice to explain more, but now is not the time.
There was a problem hiding this comment.
Showing results and explaining them later has been the entire guiding principle behind Part I, since the gb-asm-tutorial-old showed that the "explain everything first, show results at the end" strategy was ineffective.
I think it also helps making the tutorial feeling more cohesive; think of it as a plot thread/cliffhanger?
Maybe we should reword this info box, however. How about:
This function uses a lot of concepts we haven't talked about yet.
We will examine and explain it in the next section; for now, let's assume it does what we want it to.
There was a problem hiding this comment.
"next section" being part 3, or lesson 4.5?
There was a problem hiding this comment.
I meant "next lesson", don't mind me.
There was a problem hiding this comment.
I don't agree with the suggested order of presenting things (let alone pushing entire functions/sections of code to the reader) but it's merely an order issue, it can be re-examined later when such explanations are added. Let's just keep the open points here https://github.com/ISSOtm/gb-asm-tutorial/pull/37#discussion_r1083534581 on our todos.
Everything else looks very good
5 participants
Closes #15