| |
Krill
Registered: Apr 2002
Posts: 2855 |
Bobby Border
One of the most impressive pieces of code (and design!) on this platform is still Glasnost 's part in Camel Park - the one from the screenshot, particularly the side-border DXYCP scroller.
Now, i've never really gotten around to analyse it thoroughly.
And being lazy... How? :) |
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
this is too high level so you just get some answer from a "stranger" here explaining it :D Maybe Clarence comes by. ;) |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
I was hoping for Glasnost himself to pop up, or someone else from Camelot relating old stories. =) |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
looked at it in c64debugger, sprites are used if they were from miggy, each sprite contains those small bobs at varying Y positions, the rastercode rewrites sprite X, d010, sprite color, and multiplexes as needed, plus each line d016, d011,d018. only td011 is ldx'ed from a table everything else is is ldx #, plus A is used to write d018, it's value is eor #xx-ed as needed, probably this is selfmoded from the outside...
the logo is hires bitmap, always last pixelrow of a char row, so 63 cycle stretch, but I count 40 different lines, no idea how is that done, even without dd00... maybe its linecrunch / not linecrunched lines and after 25 lines its shifted enough so it reads from the same bitmap but not colliding with previously read data. |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
So much i knew from looking at the code back in the 90's. ;)
The bitmap stuff is something to do with linecrunch in hires mode, but i don't recall the details. Did a copy of it in the intro of Plushdos though. =) |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Anyways, what i'm wondering about is how the scroller seems so... variable in Y-positioning the characters, while there are obviously very tight restrictions regarding multiplexing, especially with open sideborders.
My guess is that the entire movement and positioning was precalculated, and then some kind of best-fit algorithm (maybe with some manual tweaking) squeezed all individual frames into the corset of hardware limitations.
(There seem to be some artefacts regarding the positioning.) |
| |
HCL
Registered: Feb 2003
Posts: 717 |
@Krill: I think you know all the tech that is behind that part(s). It's just executed to perfection. Sprites are on constant y-position and only moves in x-direction. Since it's moving rather quickly, i assume a few 256-byte tables for d010 are sufficient. Then the d011-stretcher effect in the background, you know how to do it.. but it has to be rather table-driven in order to not waste rastertime outside the timing, and the timing for it sort of comes for free.. |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
The raster tricks themselves are not the question to me, indeed. :)
(I'm that guy who likes to respond to the old "Sprites or chars?" question with "Yes.") |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
fix Y coordinate of the virtual bobs explains what you wanted to know I guess. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
framestepping it at YT, it seems like it is rather fixed in X, that makes the Xcoo "changes" easy :) so its basicly an only Y mover bob routine plotted into sprites with fixed X coo baked into sprite x changes. |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Quoting Oswaldfix Y coordinate of the virtual bobs explains what you wanted to know I guess. That much is obvious from just looking at it. What do you mean by "virtual"? |
... 14 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
