Subject: Re: [stella] Skeleton - complete From: "Eric Ball" <eball@xxxxxxxxxx> Date: Tue, 10 Sep 2002 09:06:20 -0400 |
Hi Manuel! > Ok, I see. How about doing smaller mazes for those kill-o-zap guys like me? The 16x16 maze takes up one page, no more, no less. It's related to how movement works. Impossible to change. > Uhm... I've read that a few times now, but I don't get why the PAL conversion should cause any severe space problems / table rearrangements. Just adjust the number of WSYNCs for PAL to burn the additional lines away, that shouldn't cost a single byte. For a normal kernel, that may be true. But the Skeleton kernel is based on very large look up tables and heavy use of LDA (ZP),Y. For every line on the screen, I have 6 bytes of maze lookup. And the skeleton player graphics are also done for each visible line. So for PAL, the active screen increases by 20% from 190 lines to 228 lines, with a similar increase in lookup table size. Yes, it's space inefficient, but I found that I didn't have enough cycles and registers to keep multiple counters going. As it is, some of the kernel uses X to help draw the horizontal lines. Let me give you an example. Grab your copy of skeleton.asm and follow along. The kernel is unrolled into 20 line chunks. Each chunk handles drawing one set of walls. There are three wall types: closed, open, and corridor. Each chunk does basically the same thing. Y is the line counter and is also used as an index into the lookup tables. A is typically used for LDA (ZP),Y -> STA PFn, although there are some ANDs/ORs to handle the horizontal lines. X is used in delay loops, although it also gets used to create the horizontal lines. So the sequence is normally: lookup left wall, update PF registers as required, check for Skeleton start/end & lookup/store if necessary. Delay to the middle of the screen. Lookup/store the right wall PF, increment Y, test for end of chunk & handle horizontal lines. Each line is cycle counted in the comments, and most chunks I don't have more than a couple of spare cycles before the STA WSYNC. (And in KERN60, I had to do some fancy footwork because I had to remove the delay loop entirely from the draw skeleton path.) (BTW the PVIEW4 subroutine is in the middle of the kernel to shove KERN60/WAIT60 off the page boundary.) Ideally, I would have multiple counters going: - a line counter - a maze index which would only be updated every n lines - a skeleton index which would be updated depending on the distance If I had the registers and cycles to keep these counters going then I could significantly reduce the size of the lookup tables and simplify the PAL conversion. The other problem is ensuring the location of the lookup tables doesn't cause the LDA (ZP),Y to go over a page boundary. This is particularly true for the skeleton graphics, which need to be stored towards the end of a page. Whew. A long winded explanation for why PAL Skeleton isn't as simple as you might think. But I hope this helps everyone understand how Skeleton works a little better. ---------------------------------------------------------------------------------------------- Archives (includes files) at http://www.biglist.com/lists/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] Skeleton - complete, timchrissnider@xxxxx | Thread | Re: [stella] Skeleton - complete, Eric Ball |
Re: [stella] Dragons & Dragsters, Rob | Date | Re: [stella] Skeleton - complete, Eric Ball |
Month |