José Pereira #1 Posted December 21, 2015 (edited) Hi. We on A8 have possibility to have an all the screen higher Player like a vertical line. I know that they can re-use the sprites many times across the screen but can they also repeat a sprite on the next scanline like some repeat 8x that will give a vertical line with 168scanlines? Other thing I know is they can have the sprites on the borders. Can they have this sprite 8x repeat vertical line on the left and/or right border? My idea is a charmode scrolling game with the sides with these two sprites lines on the borders... Are there any examples of this on C64? Thanks. Edited December 21, 2015 by José Pereira Quote Share this post Link to post Share on other sites
Bryan #2 Posted December 21, 2015 Does this help? http://www.lemon64.com/forum/viewtopic.php?t=40098&sid=68f429e48fce22ca8f3c8506667f3bda Quote Share this post Link to post Share on other sites
Heaven/TQA #3 Posted December 21, 2015 Codebase64.org Sprite multiplexor... Look at Turrican end boss robot Sprite. Quote Share this post Link to post Share on other sites
Heaven/TQA #4 Posted December 21, 2015 Fli bug is normally covered with sprites... I guess in border as well but tight cycle precise coding? Sack, Jason should give you more info. Quote Share this post Link to post Share on other sites
José Pereira #5 Posted December 21, 2015 Take this example from the Amstrad CPC version of Mad Mix and lets say that on the C64 I want to have something similar. In C64 because of Hardware horizontal scrolling the playing area would be 38Bytes wide then those two sides would be each one multicolour sprites placed outside in the borders, two sprites one on each side and re-used across the collumn with no gap. Could it be or any real example of this already done on C64? P.s.- Thanks Bryan, that is similar but it seems that they didn't really come into something near to what I want. Quote Share this post Link to post Share on other sites
Rybags #6 Posted December 21, 2015 You just change the YPos register, and supposedly it can be done while the "current" sprite is still showing as Vic does a comparitor operation to decide to start a new one. If you want a different image then you'd need to change the data pointer too, this would need to be done more precisely if current/next sprites are joined. There's also a trick to allow a sprite to reshow the current line of data, by toggling the expand Y bit each scanline a sprite can be expaned vertically beyond the normal 2x allowed. This costs lots of CPU cycles though. Sprites in the border involves flipping the screen size bit at the right times. By selecting shrunk screen in the 4 scalines before a standard screen ends, it tricks Vic into not disabling sprites. Then once you reach the scanline where a standard screen would end, put it back to standard screen in preparation for the next frame. Sprites will also be allowed at the top of screen. Allowing sprites in the side borders is a similar technique but requires cycle exact changing of the screen width bit. Also much more costly with CPU as it needs doing every scanline you want it, instead of just one per frame. Sprites can't normally be reused horizontally on the C64, the data is loaded directly to the shift register, there's no on-chip data register like GTIA has to allow it. Though there is at least one demo that has 9 sprites on a scanline in the border, would need to look up what trick is used there. Quote Share this post Link to post Share on other sites
José Pereira #7 Posted December 21, 2015 Here's the image: Quote Share this post Link to post Share on other sites
Rybags #8 Posted December 21, 2015 So, the barber poles are fixed objects and the green/brown area scrolls? C64 could probably do it, you could even animate the poles. But using sprites in side borders then costs you every CPU cycle for the duration. And with what's left you have to take care of scrolling and the game logic. Quote Share this post Link to post Share on other sites
José Pereira #9 Posted December 21, 2015 (edited) Greens and browns middle area is the playing area and it scrolls vertical and horizontal. Let's say that I want to have a C64 version of Mad Mix like the CPC, middle is a charmode with the other 6sprites with no multiplexing for the pac and ghost and reserve 2 for the two sides in multicolour white/red/gray and here is where I need to re-use with no gap. Edited December 21, 2015 by José Pereira Quote Share this post Link to post Share on other sites
popmilo #10 Posted December 21, 2015 Greens and browns middle area is the playing area and it scrolls vertical and horizontal. Let's say that I want to have a C64 version of Mad Mix like the CPC, middle is a charmode with the other 6sprites with no multiplexing for the pac and ghost and reserve 2 for the two sides in multicolour white/red/gray and here is where I need to re-use with no gap. As Rybags said, C64 can do it. You can repeat same sprite vertically by changing its Y coordinate in correct raster line. One example I can think of is Operation Wolf: That vertical energy bar on the right side is made of sprites. It's even doing more than what you ask for as those ammo counters and high score on right side are soft-scrolled to the right so it negates hardware scroll to the left of whole screen and look like they are standing in place. Better question is why would you want to reduce size of scroll area on C64 ? There's simply no good reason for it imho Remembered another one - Wizard warz (much smaller area): Quote Share this post Link to post Share on other sites
José Pereira #11 Posted December 21, 2015 I don't want to reduce C64 wide screen. For a hardware horizontal scrolling that is 38Bytes/chars area I put those two sides 2hardware sprites vertical collumn outside, in the side borders. As an example for that Mad Mix it would end up in something like A8 display 42Bytes wide display on old TVs like this: Left side 2Bytes (collumn - sprite)/38Bytes (playing area - charmode) Middle/Right side 2Bytes (collumn - sprite) That is my idea... Is it possible? P.s.- Thanks Pop for the Operation Wolf explanation. The energy/bullets bar(s) I know was harware sprites like in A8 ours clones but never got how they did the right side panel. That is a great job and that explains why greater market makes better coding/coders. From what you explained that left&right hardware scrolling 'contradiction/vs. battling' although not adding colours seems also possible on A8 but no one ... Thanks for learning one more thing and more, to know something that had me thinking for years. Perhaps the best is, maybe, start more topics to get all the answers to my questions ... Something like 'Monty Python': "The Meaning of Life". Quote Share this post Link to post Share on other sites
TMR #12 Posted December 21, 2015 Take this example from the Amstrad CPC version of Mad Mix and lets say that on the C64 I want to have something similar. In C64 because of Hardware horizontal scrolling the playing area would be 38Bytes wide then those two sides would be each one multicolour sprites placed outside in the borders, two sprites one on each side and re-used across the collumn with no gap. Could it be or any real example of this already done on C64? Max Mix on the CPC isn't in the borders, that could be replicated on the C64 (you don't need to be in 38 column mode if the sprites are masking off the rough edge at the left) easily enough and games like Quedex or Extreme already do variations on that theme, but trying to do it with the side borders disabled... i'd say it wasn't viable for a game. You just change the YPos register, and supposedly it can be done while the "current" sprite is still showing as Vic does a comparitor operation to decide to start a new one. Things like ESCOS or indeed games like Delta rely on being able to recycle sprites by changing the Y; the VIC-II will finish displaying a hardware sprite once it's started so, although you can change the X register on each scanline, altering the Y has no effect until the sprite is done. It works both ways actually, try to move a sprite to start at scanline $40 when the raster is already at $41 and nothing gets displayed. If you want a different image then you'd need to change the data pointer too, this would need to be done more precisely if current/next sprites are joined. There's a few ways to make this faster with more than a couple of sprites or as long as you're not having much in the way of sprite animation (so something like the borders being discussed) methods to significantly reduce the precision needed. But they'd probably take diagrams to explain so i won't bother unless someone asks. =-) Sprites can't normally be reused horizontally on the C64, the data is loaded directly to the shift register, there's no on-chip data register like GTIA has to allow it. Though there is at least one demo that has 9 sprites on a scanline in the border, would need to look up what trick is used there. That'll probably be Krestage 3 but it relies on a trick that wouldn't be any use for games; all of the other demos doing what appears to be nine sprites are using the ghostbyte in some form if memory serves... Quote Share this post Link to post Share on other sites