Jump to content
  • entries
    651
  • comments
    2,627
  • views
    873,607

Stay Frosty, Part 10

SpiceWare

895 views

Last time around, while visiting family for Thanksgiving, I'd implemented a preliminary starfield. I'd originally tried doing so using missile 1, but it didn't work (in Stella) so I changed it to use missile 0. In and of itself that was fine, but missile 0 was used for the melt trail so needed to be repositioned after displaying the stars. As a quick workaround I just added 2 extra scanlines to reposition missile 0, which had bumped the scanline count from 262 to 264.


 

Stella Debug Colors


blogentry-3056-0-88601600-1544830931.png




 

Missile 0 Stars (orange)


blogentry-3056-0-28828900-1544830919_thumb.png


When I posted about the stars, batari came back with:


We tried the starfield trick last year and the emulation is very inaccurate. Stella is only designed to emulate the exact conditions from Cosmic Ark, not the general starfield trick.


So I changed it over to use the ball and removed the missile 0 reposition. (Stella's been greatly enhanced since then and now accurately emulates the starfield trick with all objects).



 

Ball stars(light blue)


blogentry-3056-0-66737300-1544830893_thumb.png


Star Test ROMs:
frostyStarTestNTSC.bin
frostyStarTestPAL.bin

That worked, though Albert replied back with:


I just tested it on a four switch with a Commodore 1702 monitor and it matches your screenshot but it's very flickery, so much so that it's distracting.

I agreed, the problem was in order to draw enough stars I was having to flicker them at 15 Hz. After further discussion I ended up reverting to my original implementation that used missile 1, reduced flicker to 30 Hz, then used 2-copies-wide on one frame and 2-copies-medium on the other to add additional stars. Alternating copies between wide and medium solved a problem with the stars being too repetitive in their layout.



 


Missile 1 Stars (green)
blogentry-3056-0-93145500-1544830923_thumb.png


Besides that I revamped the controls to use left-right and fire for jump, as well as added preliminary inertia.

ROMs:
frosty071123NTSC.bin
frosty071123PAL.bin

Source:
sf_source071123.zip

Blog entry covers November 23, 2007

  • Like 5


7 Comments


Recommended Comments

 

 

Hi  @SpiceWare !!

 

 

thank you so much for your work like always.

 

I'm trying to compile this source code sf_source071123 on linux ubuntu with DASM 2.20.14

 

I'm using this command line to do the job:

 

dasm frosty.asm -lfrosty.lst -f3 -v5 -ofrosty.bin

 

and i get:

 

frosty.asm (473): error: Illegal forced Addressing mode on 'sta'.
frosty.asm (1286): error: Illegal forced Addressing mode on 'sta'.

Fatal assembly error: Source is not resolvable.

 

Am I doing or writing something wrong?

all it's in the same directory, vcs.h, macro.h, graphics.h, frosty.asm

 

ty in advance.

Edited by zilog_z80a

Share this comment


Link to comment

 

Hi @Thomas Jentzsch

 

4 minutes ago, Thomas Jentzsch said:

That's a bug in DASM, remove the ,x or ,y

 

sorry, what is x or y?

 

please teach me, in that lines i just have found a jump bank table.

 

ty.

Share this comment


Link to comment

 

@Thomas Jentzsch

wait, the horizontal reposition has a sta.wx

 

i have removed the x.

 

what has changed?

now the compiler works, must i do something to replace that x for other thing?

 

works the same sta.wx than sta.w with just one dummie?

 

i know that .w is some kind of delay.

Edited by zilog_z80a

Share this comment


Link to comment

The problem is, that the lasted version of DASM doesn't like force operators which are repeated by the instruction (e.g. sta.wx address,x). This is a known bug which will be fixed soon. A force operator can be used to e.g change a 4 cycle ZP,x write into a 5 cycle abs,x write. And timing is crucial for a 2600 ROM, especially when it comes to positioning of a sprite.

 

A workaround for current DASM is to remove ",x" in "sta.wx address,x" or to revert to an earlier DASM version.

  • Like 1
  • Thanks 1

Share this comment


Link to comment
2 minutes ago, Thomas Jentzsch said:

The problem is, that the lasted version of DASM doesn't like force operators which are repeated by the instruction (e.g. sta.wx address,x). This is a known bug which will be fixed soon. A force operator can be used to e.g change a 4 cycle ZP,x write into a 5 cycle abs,x write. And timing is crucial for a 2600 ROM, especially when it comes to positioning of a sprite.

 

A workaround for current DASM is to remove ",x" in "sta.wx address,x" or to revert to an earlier DASM version.

 

thanks so much.

 

cheers.

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...