[WIP] Old Filmstrip of a CRT Simulator I for the 2600

[Fort Apocalypse]

Use both joysticks to control environment.

 

 

 

 

old_filmstrip_of_a_crt_simulator_i_0.6.bas.bin old_filmstrip_of_a_crt_simulator_i_0.6.bas

Edited June 5, 2022 by Fort Apocalypse

[Fort Apocalypse]

First release.

 

 

 

old_filmstrip_of_a_crt_simulator_i_0.1.bas.bin old_filmstrip_of_a_crt_simulator_i_0.1.bas

Edited June 5, 2022 by Fort Apocalypse

[Fort Apocalypse]

[rsiddall]

On 5/29/2022 at 9:29 PM, Fort Apocalypse said:

Use both joysticks to control environment.

 

old_filmstrip_of_a_crt_simulator_i_0.1.bas.bin 4 kB · 2 downloads old_filmstrip_of_a_crt_simulator_i_0.1.bas 1.06 kB · 1 download

 

Cool recreation! I like the up and down effects best.

[Fort Apocalypse]

1 hour ago, rsiddall said:

Cool recreation! I like the up and down effects best.

Thanks!

 

I was messing around with the ENAM0=2 long vertical missile0, trying to make a Yars' Revenge neutral zone-ish sort of field effect, which was neat, but then it started looking like old film lines, so I threw in some dot noise with variables I just happened to have setup for the pachinko game that went awry, then added random playfield generation for the CRT noise similar to what I was doing in Monthra II. So, this wasn't planned out.

 

If you move the left joystick to the right a little and then move the left joystick up and down randomly, it does look better. If only I could throw in some real partial frames from old 80s movies, the snow area might look a little like getting poor reception on a T.V. antenna or how it used to look trying to watch scrambled cable channels long ago.

 

The idea of an old film effect atop CRT T.V. snow seemed pretty wacky.

Edited May 31, 2022 by Fort Apocalypse

[Fort Apocalypse]

Changes:

• Color doesn't change on it's own anymore
• Use difficulty switches to turn off old film effect or snow
• Use select switch to "change channel"

 

old_filmstrip_of_a_crt_simulator_i_0.2.bas old_filmstrip_of_a_crt_simulator_i_0.2.bas.bin

[+Andrew Davie]

Looks like you are not generating a stable frame there -- should be about 262 scanlines for NTSC.

 

[Fort Apocalypse]

4 hours ago, Andrew Davie said:

Looks like you are not generating a stable frame there -- should be about 262 scanlines for NTSC.

 

I can change it if you think it'd be better; I have a loop that varies by a value that's affected by left joystick moving left and right, so it's intentionally messing with the frame rate, pushing it over the edge a bit, for effect.

 

Instead of doing that, I could maybe try to keep it just within frame rate. Is there a way to output the frame rate in Stella to check?

[+Andrew Davie]

Just now, Fort Apocalypse said:

I can change it if you think it'd be better; I have a loop that varies by a value that's affected by left joystick moving left and right, so it's intentionally messing with the frame rate, pushing it over the edge a bit, for effect.

 

Instead of doing that, I could maybe try to keep it just within frame rate. Is there a way to output the frame rate in Stella to check?

You should always always try to generate stable frames with consistent line counts.

Many TVs will roll and/or not display a picture if your frames have "bad" scanline counts. At the very best, they will jiggle the picture up and down, annoyingly. It's just the "done thing" to form your frames correctly. So yes, fix it. But more to the point, don't just adjust your loop values -- get your timing down right so that you know that you have a stable frame, and why.

You can use Ctrl-L in stella to show the frame rate as an overlay.

[Fort Apocalypse]

4 hours ago, Andrew Davie said:

You should always always try to generate stable frames with consistent line counts.

Many TVs will roll and/or not display a picture if your frames have "bad" scanline counts. At the very best, they will jiggle the picture up and down, annoyingly. It's just the "done thing" to form your frames correctly. So yes, fix it. But more to the point, don't just adjust your loop values -- get your timing down right so that you know that you have a stable frame, and why.

You can use Ctrl-L in stella to show the frame rate as an overlay.

This is going to be less easy to fix than I'd hoped. I turned on developer mode to get the frame rate output, and when I keep the pixel changes under the limit, it doesn't give the same effect that I'm going for, because not enough pixels change to look like more realistic T.V. snow.

 

I'll see what logic and checks I can move out of the loop to improve it.

Edited June 1, 2022 by Fort Apocalypse

[+Andrew Davie]

1 minute ago, Fort Apocalypse said:

I'll see what logic and checks I can move out of the loop to improve it.

 

Welcome to the fun world of programming the '2600.

You're doing great so far. My advice is; remember this is a community of people just busting to help. If you share your code, then no doubt people will offer suggestions for improvements and optimisations. And don't forget, there's always the option of moving towards a bit of assembler code to really speed things up. It's a great pathway to learning how to push the hardware to its limits.

Good luck!

[Fort Apocalypse]

2 hours ago, Andrew Davie said:

 

Welcome to the fun world of programming the '2600.

You're doing great so far. My advice is; remember this is a community of people just busting to help. If you share your code, then no doubt people will offer suggestions for improvements and optimisations. And don't forget, there's always the option of moving towards a bit of assembler code to really speed things up. It's a great pathway to learning how to push the hardware to its limits.

Good luck!

Thanks! I couldn't get it fast enough, unfortunately. I think maybe I could do a better job of it if I was comfortable in assembly, but I can't alter the playfield enough between drawscreens to make it look ok in bB. The goal is to randomize every playfield pixel between drawscreens. I'll put together a simpler program to show what I'm talking about in a minute.

Edited June 1, 2022 by Fort Apocalypse

[+Andrew Davie]

Caveat: I have never programmed anything in bB. Nonetheless, a review of your source code suggests many possible optimisations to me.  For example, consider the cost of the random number routine - this cannot be cheap to do regularly. Consider instead doing it once/frame, and "mangling" the result for later use.  Shifting/rolling/eor'ing... all will be cheaper than another call, I think. Try instead of doing all the joystick tests every single frame -- only doing them every 10 frames or so. Consider removing the subroutine calls (you even have nested subroutines). These cost cycles.  Consider instead of dealing with individual pixels via pfpixel (which is going to be slow because it has to load/mask/or/store).... dealing with whole PF 'bytes' at a time. That is, you can do 8 pixels at a time in PF1 and PF2, and 4 pixels at a time in PF0.  If bB gives you access to these, you might be able to do somehting like PF1 = rand

These are some things to work with!

[Fort Apocalypse]

24 minutes ago, Andrew Davie said:

Caveat: I have never programmed anything in bB. Nonetheless, a review of your source code suggests many possible optimisations to me.  For example, consider the cost of the random number routine - this cannot be cheap to do regularly. Consider instead doing it once/frame, and "mangling" the result for later use.  Shifting/rolling/eor'ing... all will be cheaper than another call, I think. Try instead of doing all the joystick tests every single frame -- only doing them every 10 frames or so. Consider removing the subroutine calls (you even have nested subroutines). These cost cycles.  Consider instead of dealing with individual pixels via pfpixel (which is going to be slow because it has to load/mask/or/store).... dealing with whole PF 'bytes' at a time. That is, you can do 8 pixels at a time in PF1 and PF2, and 4 pixels at a time in PF0.  If bB gives you access to these, you might be able to do somehting like PF1 = rand

These are some things to work with!

I've attached a revised optimized version showing that it seems that bB can't quite get it done fast enough, even without randomization and with almost minimal checks.

 

I also tried skipping which pfpixel to write, but if enough are skipped to get the number of cycles within limit for NTSC, it stops looking like snow, because it's not changing everything fast enough.

 

I don't know how to just write individual pixels without pfpixel in bB, unfortunately.

 

(corrected- sorry the first version had a bug)

 

too_slow.bas too_slow.bas.asm too_slow.bas.bin

Edited June 1, 2022 by Fort Apocalypse

[Fort Apocalypse]

This is a test that gets in just under the limit using lines and pixel flipping.

 

just_under.bas.bin just_under.bas.asm just_under.bas

[Fort Apocalypse]

Starting to integrate changes back in, and had a psychedelic build. As long as you just press left joystick up and don't press select, it doesn't break and makes some weird noises and audiovisual in a non-compliant way. I didn't even do anything with the audio in my code, so something about the playfield writes went into sound. pfhline/pfvline did similar to me before. I was going to share a movie of it, because it was like entering the grid in Tron.

 

 

old_filmstrip_of_a_crt_simulator_i_0.3a_haywire_build.bas old_filmstrip_of_a_crt_simulator_i_0.3a_haywire_build.bas.asm old_filmstrip_of_a_crt_simulator_i_0.3a_haywire_build.bas.bin

[Fort Apocalypse]

13 minutes ago, Fort Apocalypse said:

...it was like entering the grid in Tron.

 

[KevKelley]

Would it use up less by not using pfpixel and instead switching the bits for the various playfield variables?

[Fort Apocalypse]

6 hours ago, KevKelley said:

Would it use up less by not using pfpixel and instead switching the bits for the various playfield variables?

I think that's a great idea!

 

@KevKelley@Andrew Davie@Random Terrain

 

I'd looked at doing this before but it didn't make sense, but now everything clicked and I understood what pfclear was doing, I looked at the asm from putting a random byte in, then put it all together and figured out how to pfclear with random bytes!

 

(Note: this is almost a copy of pfclear from bB 1.5 includes/pf_drawing.asm- I just changed pfclear_loop to pfsnow_loop and used jsr randomize to load a random value during the copy of pfclear.)

 

   asm
   ifconst pfres
   ldx #pfres*pfwidth-1
   else
   ldx #47-(4-pfwidth)*12 ; will this work?
   endif
pfsnow_loop
   jsr randomize
   ifconst superchip
   sta playfield-128,x
   else
   sta playfield,x
   endif
   dex
   bpl pfsnow_loop
end

 

Edited June 4, 2022 by Fort Apocalypse

[Fort Apocalypse]

Changes:

Snow algo replaced by the new asm code!

 

 

old_filmstrip_of_a_crt_simulator_i_0.4.bas.bin old_filmstrip_of_a_crt_simulator_i_0.4.bas

[Fort Apocalypse]

@Andrew Davie @KevKelley Yay!

[KevKelley]

I first played around with using the playfield variables with Crossdock. I was running low on space and I found using them made things a little easier for doing things like drawing a door open or closed but I had used them in Pinfinger to kind of draw the numbers on part of the screen. I love looking at things like this and trying to figure out different ways to use it for a game. 

[+Andrew Davie]

7 minutes ago, Fort Apocalypse said:

@Andrew Davie @KevKelley Yay!

There you go. Well done.

 

[+Andrew Davie]

Try changing the vertical scratches to black; they will work better IMHO.

 

[Fort Apocalypse]

Changes:

Changed vertical scratches to black.

Left joystick now changes noise.

 

old_filmstrip_of_a_crt_simulator_i_0.5.bas.bin old_filmstrip_of_a_crt_simulator_i_0.5.bas