Trip2018

It's compressed fmv. Nuff said! 👀 😅 Lucky me, after all the kernel and data I'll still have an extra 6k to fool around with. Maybe for an intro?

Oh thanks! The 2k format should be enough because I'm not banking anything more than raw bytes for the vast majority of the rom and any code that I'll likely add, won't interfere with that 2k static.

So I'm trying to make a demo. I want it to be a 64K demo, but I find swapping all 4k of a bank to waste too many cycles when all I'm doing is loading a byte or 2. So I've opted to have a 2k split format similar to what's elaborated here, where the last 2k is static and the rest is bank switched. Problem is, I don't think it exists for 64k... Maybe... I had no issues splitting up the chunks, but I'm not sure how to go about using "hotspots" for a scheme like this. So what I wanna know is: How do these hotspots work? Are they tied to the console, or the rom's chipset? If it's the rom, does that mean I have to define and write my own bankswitching scheme/hotspots? What emulators could I test it on that would work for a case like that?

Batari basic only uses draw screen. That said, you can jump to the next scanline using WSYNC I think

Flickering is, in a sense, a blending of colors. What I would recommend, is overlapping the first layer with the second, that way those areas blend with each other instead of the background. While the first sprite will still blend with the background, both will blend each other and make the sprites more obvious.

So I'm planning to make a wire frame Vector FMV engine and after some thinking I think I have a method. My intentions in using this will remain private for now, beyond "it's for a demo." However, I figure I'd share my notes on formatting and hear if people believe whether or not this is a viable or if anyone has better methods they would like to share. Few things to go off of before I start. I will be using the sprites (2x wide) alternating between 2 positions per scan-line (may dither). I'll call this the canvas. The canvas will be resolution of 32 by 25, and will be taking up 100 bytes of ram. I do not care if it's optimized. It can take it's sweet time if there are too many cycles but I will be adding a timer later as well as music so I still need to save some cycles real-estate. Will be a stock vcs with bank switching. No extra ram or dpc+. Then end goal: Draw vector lines to the canvas, or die trying I plan to store vector groups as frames in rom and each vector will be formatted as such. Line should come in 4 formats 1 Byte for flags (first 2 bits) Bits 00 is a pixel * Bits 01 is a vertical vector Bits 10 is a horizontal vector Bits 11 is a byte * *This is what I mean by "die trying" (This is for compression sake.) If a pixel: Byte 1 (rom) is the y position and byte 2 (rom) is a number from 0-31 that decides the sprite and pixel If V slope: Byte 1 (rom) for the starting pose Byte 2 (stored to ram) line height (counts down and clears at zero) Byte 3 is slope input 1 Byte 4 is slope input 2 Byte 5 (ram) Pointer for x coordinates with a bit to say the number of the input. If H slope: It will be pre-rendered The first byte is the starting y position The second is the total number of bytes in a pre rendered line. the third and fourth are bytes split up into nibbles for a bitmask lookup table and are ANDed against all the outcomes. The remainder is a look up table that starts at the given y position, and whenever the next byte is 0, is set to automatically add the y position to the next byte down (Move to the next byte over if the previous byte contained bit 1) If byte: It with set a given y position and variable to a byte. Contains 2 bytes. The ram location to change, and the the byte to store it there. This was kinda rushed. If there is anything I need to clarify, let me know and I will try to answer and update this post to match if necessary. My best guess is that this won't be viable for games which is why I'm only using it for an animation.

You might be able to generate a table with different bit frequencies to try and do a search of each number of bits. Sort of like Fast Fourier Transform for bits. Not sure how much faster that would be tho.

Oh, that was a lot simpler than I was anticipating! Does the setbyte table loop once the variable is over 7 or would I need to reset the variable before I read? Very much appreciated, thanks!

So I was wondering if there is a simple way to read and select a bit with a variable. Like a possible implementation of a{6} = b{x} I know course it throws an error for that specifically, but are there any alternatives? I'm trying to setup a 4 way platformer map where the bits are read across the x axis.

Not without the superchip kernel. I would also recommend using no blank lines if you want the same look.

Yeah a quick google search says 16 kHz. I'll probably be fine as long as I make it a priority to update at the start of each Hblank.

Do you think it would be more sustainable while still sounding ok if audio updates were on a once-per-scanline basis using the standard kernel?

I think I found something here

I made a small program for generating sin data tables to incorporate into programs. Mess around with it here: https://scratch.mit.edu/projects/614327252/ Hope this helps!

I know if you overflow ram with pfres you can sometimes get a flash of it on screen.

I've messed around with it for a while actually. It seems to only update on a per frame basis as is with the stock tia sounds. Works for fades and nice bloops but still has the base restrictions for pitch and such, something I (hopefully) want to tune out if it's possible.

I'm thinking a sort of accumulator method than can be used for simple 16 byte looped samples. Simple enough for a saw/square/triangle etc.

I'm finally getting back into programming on the vcs again after 4 years and I was curious if it was possible to change variables on the fly while the screen is being drawn or if we're stuck with just drawscreen. Apologies if this is a duplicate of any kind, I did do some digging and couldn't find much besides an implied feature for graphics. Also I am aware that it's not possible to change anything while a scan line is being drawn after my previous post. If it's not possible, are there any resources for writing a kernel so I can do that? I wanna try and see if I can feed numbers into the tia volume for better audio control à la pitfall 2

Yeah. Don't use public forums to keep in contact with people. I just use discord to keep in contact with friends. Especially after my old scratch account got Thanos snapped over something similar in concept to this. (Killing all 5 years of hard work and personal progress). Small communities usually have better moderation so it's better to stick around those.

Naw I'm talking about horizontal resolution. Could we simulate, a smaller pixel width by turning pf pixel bits on/off mid drawing. Or is the hardware too slow?

I haven't been making anything in the past couple of years for the 2600 but this idea has been nagging me for a while. I'm probably blind and this has been asked many times before, but basically, would it be possible to "race the beam" turning playfield bits on/off mid drawing to "double" the playfeild resolution? Or even simpler, simulate a sub pixel offset for smoother scrolling? I'm sure there are a few drawbacks to this like with reading pf bits directly, but it's worth a try

They did have an inner structure to them that would hold the cart in place.