In the last days i checked out a lot of homebrew programs if found here, like ladybug, Pcman4k or Man goes down, and a couple of others, for seeing how these particular effects in these games were done, and thinking about how i would do them myself.
Most of the stuff i was able to get analyzed, like when do sprites flicker in these games, and when not. How are the dots in ladybug and pacman4k displayed, although they have different colors from the rest of the playfield(simply alternating lines), and a couple of other stuff i have witnessed..
I really wonder how the title screens of ladybug and Man goes down are made. Especially the Ladybug title graphic seems to be made by a couple of sprites next to each other, otherwise i cannot explain the "hi-res-ness", and is certainly more than 16 pixels broad.
Any pointers to this from the experienced people here?
0
How do you guys do those "hi res" title screens...?
Started by Steril707, Aug 16 2007 2:57 PM
5 replies to this topic
#2 OFFLINE
tschak909
-
-
- 159 posts
Chopper Commander
- Location:USA
Posted Thu Aug 16, 2007 4:09 PM
Steril707, on Thu Aug 16, 2007 2:57 PM, said:
In the last days i checked out a lot of homebrew programs if found here, like ladybug, Pcman4k or Man goes down, and a couple of others, for seeing how these particular effects in these games were done, and thinking about how i would do them myself.
Most of the stuff i was able to get analyzed, like when do sprites flicker in these games, and when not. How are the dots in ladybug and pacman4k displayed, although they have different colors from the rest of the playfield(simply alternating lines), and a couple of other stuff i have witnessed..
I really wonder how the title screens of ladybug and Man goes down are made. Especially the Ladybug title graphic seems to be made by a couple of sprites next to each other, otherwise i cannot explain the "hi-res-ness", and is certainly more than 16 pixels broad.
Any pointers to this from the experienced people here?
Most of the stuff i was able to get analyzed, like when do sprites flicker in these games, and when not. How are the dots in ladybug and pacman4k displayed, although they have different colors from the rest of the playfield(simply alternating lines), and a couple of other stuff i have witnessed..
I really wonder how the title screens of ladybug and Man goes down are made. Especially the Ladybug title graphic seems to be made by a couple of sprites next to each other, otherwise i cannot explain the "hi-res-ness", and is certainly more than 16 pixels broad.
Any pointers to this from the experienced people here?
Think about it, once a sprite has been used, it can be rewritten. :-)
-Thom
#3 OFFLINE
Steril707
-
-
- 170 posts
Chopper Commander
- Location:München
Posted Thu Aug 16, 2007 7:21 PM
tschak909, on Fri Aug 17, 2007 12:09 AM, said:
Steril707, on Thu Aug 16, 2007 2:57 PM, said:
In the last days i checked out a lot of homebrew programs if found here, like ladybug, Pcman4k or Man goes down, and a couple of others, for seeing how these particular effects in these games were done, and thinking about how i would do them myself.
Most of the stuff i was able to get analyzed, like when do sprites flicker in these games, and when not. How are the dots in ladybug and pacman4k displayed, although they have different colors from the rest of the playfield(simply alternating lines), and a couple of other stuff i have witnessed..
I really wonder how the title screens of ladybug and Man goes down are made. Especially the Ladybug title graphic seems to be made by a couple of sprites next to each other, otherwise i cannot explain the "hi-res-ness", and is certainly more than 16 pixels broad.
Any pointers to this from the experienced people here?
Most of the stuff i was able to get analyzed, like when do sprites flicker in these games, and when not. How are the dots in ladybug and pacman4k displayed, although they have different colors from the rest of the playfield(simply alternating lines), and a couple of other stuff i have witnessed..
I really wonder how the title screens of ladybug and Man goes down are made. Especially the Ladybug title graphic seems to be made by a couple of sprites next to each other, otherwise i cannot explain the "hi-res-ness", and is certainly more than 16 pixels broad.
Any pointers to this from the experienced people here?
Think about it, once a sprite has been used, it can be rewritten. :-)
-Thom
Well, i know...But wouldn't that mean i have to flicker them, if they are on the same scanline? The Ladybug title is definitely wider than 16 pixels (=2 spites). And the only other way to display more sprites in the same scanline area without flicker that i have heard about so far is the RESP0 strobing trick. But this seems to display only copies of the same sprite.
So, again, thats out of the question...
Gimme a clue !!!
#4 OFFLINE
batari
-
-
- 6,236 posts
)66]U('=I;B$*
- begin 644 contest
Posted Thu Aug 16, 2007 7:52 PM
Steril707, on Thu Aug 16, 2007 8:21 PM, said:
Gimme a clue !!!
#5 OFFLINE
supercat
-
-
- 6,367 posts
Quadrunner
Posted Thu Aug 16, 2007 9:26 PM
Steril707, on Thu Aug 16, 2007 8:21 PM, said:
Well, i know...But wouldn't that mean i have to flicker them, if they are on the same scanline?
Why wait for the next scan line before rewriting a sprite? The popular 'six digit score trick' sets both players for three copies close and positions Player 1 eight pixels to the right of Player 0. Vertical delay is enabled for both sprites. Before the beam reaches the first copy of Player 0, the program hits GRP0 with the first shape, GRP1 with the second shape (copying GRP0 into the player 0 shifter), and GRP0 with the third shape (copying GRP1 into the player 1 shifter). The registers X, Y, and accumulator hold the other three shapes. Just after the beam finishes scanning Player 0, the code should store the fourth shape into GRP1 (copying GRP0 into shifter 0), the fifth shape into GRP0 (copying GRP1 into shifter 1), the sixth shape into GRP1 (copying GRP0 into shifter 0) and anything into GRP0 (copying GRP1 into shifter 1). Since the beam moves nine pixels during each store, the beam will move 27 pixels between the first and last of those four stores. There are 32 pixels between the end of the first Player 0 copy and the start of the last Player 1 copy, so things work with one cycle to spare.
#6 OFFLINE
Steril707
-
-
- 170 posts
Chopper Commander
- Location:München
Posted Fri Aug 17, 2007 5:09 AM
hmmmm, i think i get it... Thanks a lot for the fast answer... 
Why wait for the next scan line before rewriting a sprite? The popular 'six digit score trick' sets both players for three copies close and positions Player 1 eight pixels to the right of Player 0. Vertical delay is enabled for both sprites. Before the beam reaches the first copy of Player 0, the program hits GRP0 with the first shape, GRP1 with the second shape (copying GRP0 into the player 0 shifter), and GRP0 with the third shape (copying GRP1 into the player 1 shifter). The registers X, Y, and accumulator hold the other three shapes. Just after the beam finishes scanning Player 0, the code should store the fourth shape into GRP1 (copying GRP0 into shifter 0), the fifth shape into GRP0 (copying GRP1 into shifter 1), the sixth shape into GRP1 (copying GRP0 into shifter 0) and anything into GRP0 (copying GRP1 into shifter 1). Since the beam moves nine pixels during each store, the beam will move 27 pixels between the first and last of those four stores. There are 32 pixels between the end of the first Player 0 copy and the start of the last Player 1 copy, so things work with one cycle to spare.
supercat, on Fri Aug 17, 2007 5:26 AM, said:
Steril707, on Thu Aug 16, 2007 8:21 PM, said:
Well, i know...But wouldn't that mean i have to flicker them, if they are on the same scanline?
Why wait for the next scan line before rewriting a sprite? The popular 'six digit score trick' sets both players for three copies close and positions Player 1 eight pixels to the right of Player 0. Vertical delay is enabled for both sprites. Before the beam reaches the first copy of Player 0, the program hits GRP0 with the first shape, GRP1 with the second shape (copying GRP0 into the player 0 shifter), and GRP0 with the third shape (copying GRP1 into the player 1 shifter). The registers X, Y, and accumulator hold the other three shapes. Just after the beam finishes scanning Player 0, the code should store the fourth shape into GRP1 (copying GRP0 into shifter 0), the fifth shape into GRP0 (copying GRP1 into shifter 1), the sixth shape into GRP1 (copying GRP0 into shifter 0) and anything into GRP0 (copying GRP1 into shifter 1). Since the beam moves nine pixels during each store, the beam will move 27 pixels between the first and last of those four stores. There are 32 pixels between the end of the first Player 0 copy and the start of the last Player 1 copy, so things work with one cycle to spare.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
