Jump to content

Trip2018

Members
  • Posts

    167
  • Joined

  • Last visited

1 Follower

Contact / Social Media

Profile Information

  • Custom Status
    Fuzzy boi
  • Gender
    Male
  • Location
    nebraska
  • Interests
    Coding, gaming, furries, and art.
  • Currently Playing
    Deltarune
  • Playing Next
    Brawlhala

Recent Profile Visitors

12,917 profile views

Trip2018's Achievements

Chopper Commander

Chopper Commander (4/9)

55

Reputation

  1. 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?
  2. 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.
  3. 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?
  4. Batari basic only uses draw screen. That said, you can jump to the next scanline using WSYNC I think
  5. 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.
  6. 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.
  7. 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.
  8. 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!
  9. 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.
  10. Not without the superchip kernel. I would also recommend using no blank lines if you want the same look.
  11. 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.
  12. 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?
  13. 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!
  14. I know if you overflow ram with pfres you can sometimes get a flash of it on screen.
×
×
  • Create New...