| |
Krill
Registered: Apr 2002
Posts: 2850 |
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: 5022 |
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: 2850 |
I was hoping for Glasnost himself to pop up, or someone else from Camelot relating old stories. =) |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
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: 2850 |
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: 2850 |
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: 716 |
@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: 2850 |
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: 5022 |
fix Y coordinate of the virtual bobs explains what you wanted to know I guess. |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
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: 2850 |
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"? |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
Quote: 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"?
so what you wanted to know then, when you know how everything works?
individual sprites are teared up into virtual sprites with the xcoo changes. |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
Quoting Oswaldso what you wanted to know then, when you know how everything works?
individual sprites are teared up into virtual sprites with the xcoo changes. More high-level: If/how the virtual character positions are mapped to the available slots.
"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.)" |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
yeah the positional "bugs" with the scroller its somehow more visible. anyway you just sit down and use some high level language to try out sinuses, find best fit, fix those few issue remaining by hand I guess. |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
Quoting Oswaldanyway you just sit down and use some high level language to try out sinuses, find best fit, fix those few issue remaining by hand I guess. Wonder how that looked like in 1994. |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
well its not like 1994 was in the stone age, it could be done even in excel. |
| |
trident
Registered: May 2002
Posts: 75 |
The idea of the routine feels a little similar to the lots-of-small-hz-sprites-over-a-fpp-logo in A load of old shit by Horizon (A Load of Old Shit). One difference is that the hz sprites are also d017-stretched into position. |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
Quoting Oswaldwell its not like 1994 was in the stone age, it could be done even in excel. Dude...
Of course, Turbo Pascal existed. If you had a PC.
Would still like some original stories about this. |
| |
Martin Piper
Registered: Nov 2007
Posts: 636 |
I tend to use ICU64 or C64DebugGUI to find out what are sprites, chars, bitmaps, when and what the VIC writes are.
http://icu64.blogspot.com/
https://magoarcade.org/c64debuggui/ |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
Quoting Martin PiperI tend to use ICU64 or C64DebugGUI to find out what are sprites, chars, bitmaps, when and what the VIC writes are. Still not the point. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11126 |
Quote:Of course, Turbo Pascal existed. If you had a PC
And more importantly: Amigas, with a wide range of High level languages available. I remember reading about how eg Censor ppl used them a lot for certain things :)
I agree with the approach Krill proposed - seems to be the most sane (and easy!) one. |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
I remember we sat at Raz' dormroom while Glasnost was putting the final touch on it. He made the calculations for that one in Basic on the C64 if I recall correct. |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
Quote: I remember we sat at Raz' dormroom while Glasnost was putting the final touch on it. He made the calculations for that one in Basic on the C64 if I recall correct.
classic :D |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
Quoting Oswaldclassic :D Indeed! =D |
| |
Monte Carlos
Registered: Jun 2004
Posts: 351 |
@Slammer ... and then there was a little bug in the precalculator and he had to fix and run the 3h calculation again, I guess ;)
Maybe I'm wrong, but I can feel the sweat while the tool was running. |
