Subject: [stella] Qb: Opinions sought... From: "Andrew Davie" <adavie@xxxxxxxxxxxxx> Date: Tue, 6 Mar 2001 23:46:41 +1100 |
OK, the problem Chris reported regarding the loss of vertical synch on the 4th board.... it's pretty grim, I'm afraid. Basically, the amount of time required to move and draw all the cubes is > the available cycles that I can provide (given the current architecture). Cubes are moved every 2nd frame, so they are also drawn every 2nd frame. I moved the routine from the overscan to the vertical blank - a few more cycles "2800" available there, but also to no avail. I *do* have solutions, but they have consequences. 1) I could limit the number of cubes to 4. Maybe 5. Not a viable option. 2) I could move the cubes on one frame, and draw them on the other frame. This works OK, but there is a significant code penalty (30+ bytes) *and* when creatures are on moving cubes, the creatures shift-about on the cube (ie: they are not 'locked' to dead-center). There's lag between cube movement and cube drawing, whereas the creatures move and draw immediately. I didn't like the effect, but it is a solution, as I said. 3) I could change the entire draw system to an EOR draw, and only draw/move/draw the cubes which are actually moving. I've done this, and it does work. But the worst-case is that it has to erase 3, draw 3 - making 6... which is just as disasterous as the original problem. Also, this is a significant code penalty (40+ bytes). 4) I could draw 3 cubes on one frame, and 3 on the other frame. I haven't tried this one yet (the others I have), but this would leave the creatures locked to the cubes. Probably also a bit of code fiddling - and a fair bit of extra code to cater for the split board-clear. Estimate: about 40 bytes. This seems to be the most viable option, I guess. The bottom line here is that all of my viable solutions come with significant code penalty. As I was down to the last byte - and believe me I've optimised and optimised and optimised - I've had to remove the title screen whilst I've been testing things. And, I don't think I can afford to put it back. The title screen code and data cost me 180 bytes. I know some people feel that it's just not the real thing without a title screen - and my title WAS pretty snazzy.... but it cost 180 bytes. And, it just sits there for a few seconds and looks pretty. Perhaps I should just junk it (a shame), and use the remainder of the bytes to reinstall the points display (which Kurt sorely misses) for the fruits... and even the heart. I'm not sure what else I can really junk to allow the title screen to return (the "1UP" could go easily, and one of the fruit... that would make mmmh... about 50 bytes). So, what do you all think... junk a couple of frames of graphics (1UP, a fruit) and (hopefully) keep the title screen... or junk the title screen and install several more frames of graphics? Something has to give. Cheers A -- _ _ _| _ _ _| _ * _ _ , (_|| )(_|( (/_\/\/ (_|(_|\/(_(/_ ,~' L_|\ ,-' \ see my Museum of Soviet Calculators at ( \ http://www.taswegian.com/MOSCOW/soviet.html \ __ / L,~' "\__/ @--> v - 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 -> |
---|---|---|
[stella] Gunfight 2600: This time i, Manuel Polik | Thread | Re: [stella] Qb: Opinions sought..., Manuel Polik |
Re: [stella] Usefull illegal opcode, Ruffin Bailey | Date | [stella] Source code not resolvable, Ruffin Bailey |
Month |