Pixel scrolling on Pac-Man hardware
- Thread starter Hurray Banana
- Start date
I don't really understand it at all and I'm not afraid to say it!cmonkey said:
From my point of view what you guys are doing is basically inventing the wheel again!
I sort of understand bits of it but it's still way out of my understanding!
Stick with it guys as all the results have been out of this world
- Ben
cmonkey said:
yeah you gave me that. the rotate section is going away in the final version so not too bothered about that bit, but there is lot's to refactor for sure.
ben76 said:I don't really understand it at all and I'm not afraid to say it!
From my point of view what you guys are doing is basically inventing the wheel again!
I sort of understand bits of it but it's still way out of my understanding!
Stick with it guys as all the results have been out of this world
cheers ben
Hey Guys, this is incredible, hardware with no pixel scrolling built in being taught how to do it.
I've only been able to quickly flick through everything but i'm assume you're having to use bitwise shifts to move things through 8-bit boundaries.
On Pac-Man hardware isn't the tile map referenced out of rom? So a byte in the screen RAM represents a specific lookup in the ROM area.
So on a C64 we did parallax starfields by ROL'ing bytes in the character RAM but on this hardware wouldn't that mean needing write access to the tilemap?
Am I overthinking it?
No matter how you've done it, its awesome and opens up a lot of possibilities.
I've only been able to quickly flick through everything but i'm assume you're having to use bitwise shifts to move things through 8-bit boundaries.
On Pac-Man hardware isn't the tile map referenced out of rom? So a byte in the screen RAM represents a specific lookup in the ROM area.
So on a C64 we did parallax starfields by ROL'ing bytes in the character RAM but on this hardware wouldn't that mean needing write access to the tilemap?
Am I overthinking it?
No matter how you've done it, its awesome and opens up a lot of possibilities.
RGP said:
You do have read/write access to the tile ram, but it doesn't help here, because two tiles are affected by one bitmap read.
I'll try and explain how it works James.
The is 1k of tile ram, the bytes here reference the 256 tiles in the tile rom, so putting 56 in tile ram location $4040 (top right corner of main playarea) would draw the 8x8 tile number 56 from rom.
There is also 1k of pallete rom which like the speccy specifies the pallete to use when rendering a specifc tile at that address
What I am doing here is reading a bitmap
0110 0011
each bit represents a full or empty tile ($e and $f)
There is a pixel offset counter 0 to 7 which specifies what tile pair should be drawn for the bitmap (it's a lot more complicated than this because following bitmap values affect what tile is drawn but keeping this simple for clarity)
if the offset is 1 then i need to draw the tile so it looks like it's shifted to the right 1 pixel (tile $d), then tile to the left needs to show the remainder of the tile (tile $c). This carries on moving down the tile list to show the different scroll offsets, until we reach the point where we have moved a full 8 pixels. We then in my rough unoptimised version need to rotate the bit pattern one position to reflect the move of the bitmap. and the process starts again. The bit that falls of the end into the carry is picked up on the left hand side of the bitmap for that row, so we get the continuous wrapping.
Like I said this is a simplification, writing one bitmap actually involves working out what we are doing for two tiles. As I am writing this my brain has just fired up with a potential optimisation to the renderer
I've tried to explain this as simple as I can, any questions just ask.
Had a quick look at re-writing the main part of the horizontal scrolling decode and tile setting routines to try and get some speed up, I think i've found a few cycles on my first tries. I also had a first look at vertical scrolling and already using some new ideas and the favourable way the memory map is laid out it looks like it's probably about twice as fast to scroll vertically.
To explain the memory map a little
to move horizontally between columns you need to add 32 bytes to your address, this instruction is expensive and can be 15 cycles if you can use 2 16 bit registers. To move vertically between rows is a single byte add which can be achieved with INC or DEC which is a 6 cycle instruction. This really makes a difference when writing to vram as when scrolling you have to process a row or column at a time to achieve the scrolling effect.
It will also be super quick to scroll in the top and bottom pairs of tile lines, again because of the memory map being organised in single byte increments. Although not very useful as I only have two rows to mess with, unless I use some high resolution tiles (not full blocks)
Here's a shot of how I work when trying ideas and trying to work out the logic of what I'm doing. The page at the top right has my first guess for vertical scrolling. The 58 is the number of cycles that setting one tile takes currently in the horizontal scroller and the 52 is how long setting two tiles in the vertical scroller is going to take in comparison.
big version here
Hurray Banana2016-09-21 05:27:27
To explain the memory map a little
to move horizontally between columns you need to add 32 bytes to your address, this instruction is expensive and can be 15 cycles if you can use 2 16 bit registers. To move vertically between rows is a single byte add which can be achieved with INC or DEC which is a 6 cycle instruction. This really makes a difference when writing to vram as when scrolling you have to process a row or column at a time to achieve the scrolling effect.
It will also be super quick to scroll in the top and bottom pairs of tile lines, again because of the memory map being organised in single byte increments. Although not very useful as I only have two rows to mess with, unless I use some high resolution tiles (not full blocks)
Here's a shot of how I work when trying ideas and trying to work out the logic of what I'm doing. The page at the top right has my first guess for vertical scrolling. The 58 is the number of cycles that setting one tile takes currently in the horizontal scroller and the 52 is how long setting two tiles in the vertical scroller is going to take in comparison.
big version here
Hurray Banana2016-09-21 05:27:27