Screen characters are formed by a collection of 8 bytes, 256 bytes apart from each other. One simple way is to have a "character map" of 768 bytes (32x24) in memory to store the characters at each screen location, then the colour attributes would not matter.
I was gonna make the collision system in my game work by detecting the tile graphics themselves and their positions. (for example, a dude moves if there is 8 pixels of space next to him, and can't move any further if there is a brick tile right next to him without any space inbetween)
I would need to see some code example to know how to make it.
If you have MPAGD then take a look at EngineZX.asm then search (if memory serves) for "cang" as those routines check if a 16x16 sprite can move in the 4 directions. It's all commented.
When using the ROM routines you need to open the channel to display things on the bottom two lines. Putting 0 or 1 into the accumulator and calling 5633 will do the job. When you want to display on the rest of the screen, call 5633 with 2 in the accumulator.
Once you've opened the lower screen for printing, make sure you reset the cursor position to the top left. Printing chr$ 22, chr$ 0 and then chr$ 0 will do that. Then you should be able to put another 64 characters in the bottom panel. Don't go beyond that or that part of the screen will scroll up
Yes, that's the way I have always written games. X is the distance from the top of the screen, Y is the distance from the left edge. I usually put comments in to warn people that's how my routines work
Thanks so much for this resource! I have a question: in the section regarding loudspeaker audio where do the constants 437500 and 30.125 come from in this formula ?
← Return to programming tutorial
Comments
Log in with itch.io to leave a comment.
I'm wondering if the code for attribute-based collision could be modified to be character-based instead.
I want to implement something like that to my game.
How easy would that be to do?
Screen characters are formed by a collection of 8 bytes, 256 bytes apart from each other. One simple way is to have a "character map" of 768 bytes (32x24) in memory to store the characters at each screen location, then the colour attributes would not matter.
I was gonna make the collision system in my game work by detecting the tile graphics themselves and their positions. (for example, a dude moves if there is 8 pixels of space next to him, and can't move any further if there is a brick tile right next to him without any space inbetween)
I would need to see some code example to know how to make it.If you have MPAGD then take a look at EngineZX.asm then search (if memory serves) for "cang" as those routines check if a 16x16 sprite can move in the 4 directions. It's all commented.
How to disable the "scroll?" message that keeps appearing whenever I try to place a tile in one of the two rows of space on the bottom of the screen?
Please reply.
When using the ROM routines you need to open the channel to display things on the bottom two lines. Putting 0 or 1 into the accumulator and calling 5633 will do the job. When you want to display on the rest of the screen, call 5633 with 2 in the accumulator.
Thanks!
Now the tiles appear to be scrolling from the bottom and disappearing when they touch the top of the screen.
I don't understand what you're trying to do. If you want to scroll the screen just call the ROM routine at 3582
I put 0 in accumulator and called 5633 and this is what happened.
(the same thing happens when I put 1)
What I'm trying to do is be able to put UDGs and text on the bottom of the screen without the "scroll?" thing ruining it.
Once you've opened the lower screen for printing, make sure you reset the cursor position to the top left. Printing chr$ 22, chr$ 0 and then chr$ 0 will do that. Then you should be able to put another 64 characters in the bottom panel. Don't go beyond that or that part of the screen will scroll up
Is it possible that in the routine "scadd" (Chapter 8) ycoord and xcoord have been accidentally exchanged in the code ?
Yes, that's the way I have always written games. X is the distance from the top of the screen, Y is the distance from the left edge. I usually put comments in to warn people that's how my routines work
Thanks so much for this resource! I have a question: in the section regarding loudspeaker audio where do the constants 437500 and 30.125 come from in this formula ?
HL = Pitch = 437500 / Frequency – 30.125
Oh wait, I found the answer in Dr Logan's book :)
Thank you for this.
Thanks a lot! I have some interest in retro games. But have no idea about ZX machine, or how to make something for it.
Great. A good lecture for summer :)
Thanks
Amazing. The kind of work that cannot be absent in physical format. Thank you.
I'm always grateful when an experienced developer share their knowledge in a structured way. Instant buy :-)