| |
Voltage
Account closed
Registered: Jul 2008
Posts: 14 |
Interview VIC II chip designer - Albert Charpentier
https://www.youtube.com/watch?v=rs6J_PP7O7k |
|
... 13 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
"Split screen" wasn't an unknown technique when the VICII was designed at all, used for colors, gfx modes, scrolling... and sprites - all common. So its more than unlikely it was just a happy accident :) |
| |
Raistlin
Registered: Mar 2007
Posts: 553 |
Quote: at 47 mins they are chatting about Vic demo effects. they seemed very impressed... ;-)
Dave (the interviewer) was apparently talking about my part in Memento Mori with the rotating Genesis Project sprite logo thing... from an email I received from him:-
---
It was your post I was thinking of though!
https://www.c64demo.com/big-animating-sprite-logo/
---
Big sprite arrays like that have been done since the 80s of course so I'm not sure why that part was noticed. I guess probably just because of the blog. I have no idea whether he and Albert were thinking of the same thing - I'd be very honoured of course if Albert had seen my blog... but I doubt it.
Dave also mentioned that we had some slight career overlap - he'd coded the scrolling odometer used in Test Drive 2 (I would later work on Test Drive 4 and beyond..). |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Sprite multiplexing is mentioned on page 152 of the Commodore 64 Programmer's Reference Guide (1st Edition, 4th Printing, 1983):
"You can also display more than 8 sprites in the same way."
This is in Chapter 3, Section "Other Graphic Features", subsection "Interrupt Status Register" |
| |
TheRyk
Registered: Mar 2009
Posts: 2062 |
Not sure if my memory's playing tricks on me, but I remember commercials in magazines in 80s in which C= even advertised sth like "up to 256 sprites" without going into any more detail or mentioning the term multiplexing. Just like Atari used to boast with so-and-so-many colors without really explaining that it was in fact way-less colors from a palette of so-and-so-many (depending on 8 bit/16 bit/mode) |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Quoting TheRykNot sure if my memory's playing tricks on me, but I remember commercials in magazines in 80s in which C= even advertised sth like "up to 256 sprites" without going into any more detail or mentioning the term multiplexing
Well you have 256 possible sprite definitions in a VIC bank, so that’s technically correct. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting MagerValpQuoting TheRyk...sth like "up to 256 sprites"...
Well you have 256 possible sprite definitions in a VIC bank, so that’s technically correct. Hmm, that made me think "Could be even more with bank-switching...", but the very next thought was that the maximal number of sprites on a screen is limited anyway.
So, for PAL with its 312 lines, using normal uncrunched and unexpanded sprites, the max is 312/21 = 14 + 18/21 -> 14 * 8 = 112; for NTSC-VICs it'll be even less. This ofcourse can be extended by sprite-crunching, but I seriously doubt that the engineers at C= were aware of such a trick, not even Mr. Charpentier himself. But I'd be more than happy to be proven wrong;)
Back to the actual topic and the interview: I think Albert Charpentier should get to know all of the dirty VIC-tricks used nowadays, so please someone make it happen he materialises at the next X-party!!! |
| |
dyme
Registered: Nov 2018
Posts: 14 |
I don't really get the obsession with sprite crunching. I mean, theoretically you could reuse the sprite and even change the y-coordinate, but it's too timing critical for games anyway.
The massive sprite demos with fix y-distances could just as easily reuse the same sprite and just change the bitmap, e.g to display 7 pixel height sprites-parts. Am I missing something? Not really new sprites as the vic is concerned, but there would still be like more than 200 seemingly independent moving objects. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: I don't really get the obsession with sprite crunching. I mean, theoretically you could reuse the sprite and even change the y-coordinate, but it's too timing critical for games anyway.
The massive sprite demos with fix y-distances could just as easily reuse the same sprite and just change the bitmap, e.g to display 7 pixel height sprites-parts. Am I missing something? Not really new sprites as the vic is concerned, but there would still be like more than 200 seemingly independent moving objects.
sprite crunching can achieve things thats not possible with other means, for example FLI and sprites, you can make a sprite 3 times taller with sprite crunching (not meeting exit criteria before displayed 3x), but you change screens anyway with d018 for FLI, so you get different gfx line for each of the sprites lines displayed. and you dont have time to write Y coord. or you can avoid bad lines when multiplexing sprites with having a sprite different height, etc. I havent used it myself though, you need to code yourself into a very very very tight corner to have to use it :) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Oswald pretty much broke it down to the core benefit: you do not have to care for the "multiplexing" of the sprites for ~160 rasterlines when applied the right way. Ofcourse, multiplexing in this sense does not involve any sorting routines etc.pp., just the sprite-reuse trick.
IIrc Xbow used this in his routines with sprites over FLI, especially the 5 sprites over FLI in Demus Interruptus. To some extent, this technique could also be applied to Ninja's 6 sprites over FLI, but I faintly remember that his routines needed quite some vic bank hopping and that -in its current form- it would not allow for 160 lines of completely different sprite data. Maybe I'm wrong, age is eating my brain... |
| |
dyme
Registered: Nov 2018
Posts: 14 |
Oh, right... I guess y'all moved on from the maximum sprite count obsession long ago... I'm apparently still stuck there. FLI and other extremely time constrained stuff totally justify all means of course. |
| Previous - 1 | 2 | 3 - Next |
