Jump to content
  • 0
Ed Minchau

scrolling in bitmap mode

Question

I am trying to do an video in bitmap mode.  I have layer 0 set up for a 256 color 320 x 240 bitmap, but have set Hscale and Vscale to $20 so that it only displays a 160x120 bitmap, with the idea of drawing on one of the quarters that isn't being displayed.  I cannot seem to get hscroll or vscroll to work at all though, it always just shows the top left quarter.  I could show the image on the bottom left by changing the tilebase (bitmap start pointer) but that doesn't work for showing the right side quadrants (the top left of the image would never be a multiple of 512).

This has been bedeviling me for a while.  I know hscroll and vscroll work in tile mode.  Do they not work in bitmap mode?

Share this post


Link to post
Share on other sites

Recommended Posts

  • 0

I am late to the party, the question was already answered but since the documentation is a bit unclear I elaborated a bit more on my blog, especially because the Palette Offset works differently on 8bpp Sprites.

  • Color 0 is again transparent, so binary value of %0000 0000 will simply show the color of the layer below (if there is one)
  • Colors 1-15 will be affected by Palette Offset in Map data in the same way as in above example for 4bpp mode which makes sense because they only use 4 lower bits anyway and are simply complemented by top 4 bits from the offset. If Offset is 0 then Palette is unchanged.
  • Colors 16-255 are not affected by the Palette Offset and are taken directly from the palette. Note that this is different from the behavior for the 8bpp sprites.

 

 

Share this post


Link to post
Share on other sites
  • 0

No they don't. If you really need scrolling, you can fake the bitmap mode with tile mode. Since you're only using 160x120, there should be no problems having enough different tiles.

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)
8 hours ago, Ed Minchau said:

I am trying to do an video in bitmap mode.  I have layer 0 set up for a 256 color 320 x 240 bitmap, but have set Hscale and Vscale to $20 so that it only displays a 160x120 bitmap, with the idea of drawing on one of the quarters that isn't being displayed.  I cannot seem to get hscroll or vscroll to work at all though, it always just shows the top left quarter.  I could show the image on the bottom left by changing the tilebase (bitmap start pointer) but that doesn't work for showing the right side quadrants (the top left of the image would never be a multiple of 512).

This has been bedeviling me for a while.  I know hscroll and vscroll work in tile mode.  Do they not work in bitmap mode?

If you need 4 buffers, that would still only take 80k (aligning each buffer with 2k boundaries) then just change the tilebase bits 2 and 3 accordingly.  But why would you need more than 2? (draw on 1 while displaying the other)

edit: I see what you mean, you'd have to include logic to avoid "bleeding" into the other buffers, but even if scrolling worked, that would still be true

Edited by x16tial

Share this post


Link to post
Share on other sites
  • 0

@StephenHorn Theres no specific mention of what VScroll does in bitmap mode. You can see why HScroll wouldn't work, but VScroll could. (ie shift the screen up/down by 320/640/xx bytes)

It's just one of those bits of the docs that is a little unclear. I'm not complaining; I mean for a machine that isn't even real, things are pretty good!

Share this post


Link to post
Share on other sites
  • 0

another good thing to keep in mind is that a bitmap can only be 320 or 640 pixels wide, so scrolling is not something that you generally want to do, especially horizontally. The way bitmaps take up VRAM, it's a very inefficient use VRAM to have a bitmap you scroll over.

Share this post


Link to post
Share on other sites
  • 0
2 hours ago, SlithyMatt said:

another good thing to keep in mind is that a bitmap can only be 320 or 640 pixels wide, so scrolling is not something that you generally want to do, especially horizontally. The way bitmaps take up VRAM, it's a very inefficient use VRAM to have a bitmap you scroll over.

What I'm doing is converting two adjacent video frames of 160x68 pixels (to match the original aspect ratio of 2.35:1) into two files 320x34 pixels, the top half of two frames and the bottom half of two frames.  So one frame of the video is on the left half of the screen, one frame on the right half.  That way I can load directly from file to VERA.  The Hscale and Vscale are both set to $20 so only 160x120 pixels show up on the screen.

Basically I've divided up the 320x240 area into four quadrants of 160x120.  The top left is frame 1, top right is frame 2, bottom left is frame 3, bottom right is frame 4.  When loading directly from file to VERA, I have to combine adjacent frames into two 320x34 pixel images, the top half of two frames and the bottom half of two frames.  Then as frame 1 is being displayed, the top half of frames 3 and 4 are being loaded.  Then frame 2 is displayed, and the bottom half of frames 3 and 4 are loaded.  Then frame 3 is shown and the top half of frames 1&2 get loaded, then frame 4 is shown as the bottom half of frames 1 and 2 are loaded, and it repeats to the end of the video.

If I can't get hscroll and vscroll to work in bitmap mode, then I can do something similar with the tileset pointer at half the frame rate, just leaving the right half of the screen blank

Share this post


Link to post
Share on other sites
  • 0
3 hours ago, x16tial said:

If you need 4 buffers, that would still only take 80k (aligning each buffer with 2k boundaries) then just change the tilebase bits 2 and 3 accordingly.  But why would you need more than 2? (draw on 1 while displaying the other)

edit: I see what you mean, you'd have to include logic to avoid "bleeding" into the other buffers, but even if scrolling worked, that would still be true

I am drawing on two frames at the same time.  They are located side by side in video RAM, so that I can load directly from file to VERA.  The top line of the first frame is followed by the top line of the second frame, then the second line of the first frame, second line of second frame etc.

Share this post


Link to post
Share on other sites
  • 0
1 minute ago, Ed Minchau said:

If I can't get hscroll and vscroll to work in bitmap mode, then I can do something similar with the tileset pointer

You don't even need to change the tileset pointer. Just do it with tiles and change your scroll position there. If you use 16x16 tiles, you will only need a 32x16 map - just 1k of VRAM and the rest can be for your tiles.

  • Like 2

Share this post


Link to post
Share on other sites
  • 0
11 hours ago, Guybrush said:

No they don't. If you really need scrolling, you can fake the bitmap mode with tile mode. Since you're only using 160x120, there should be no problems having enough different tiles.

Yeah, I considered that, but I'd lose too much color information and the file conversion would be a lot harder.  Right now my source files are 160x68x256 color, and it's easy to convert the whole palette.  If I went to 8bpp tiles, then each group of 8x8 pixels would have to have colors on the same row of the palette, and creating that palette would be a bear, and the results wouldn't look as good.

Share this post


Link to post
Share on other sites
  • 0
11 minutes ago, SlithyMatt said:

You don't even need to change the tileset pointer. Just do it with tiles and change your scroll position there. If you use 16x16 tiles, you will only need a 32x16 map - just 1k of VRAM and the rest can be for your tiles.

The tileset pointer is the start of the bitmap.  I can just divide the screen in half and switch from one bitmap in one spot in memory to another bitmap in another spot.  Using tiles will make creating the palette much harder and won't look as good.

By the way, excellent series of tutorials you're putting out on youtube.

Share this post


Link to post
Share on other sites
  • 0
1 minute ago, Ed Minchau said:

By the way, excellent series of tutorials you're putting out on youtube.

Thanks!

Changing the bitmap starting pointer works great for vertical scrolling, but will cause corruption for horizontal scrolling. Also, tiles can have exactly the same palette as bitmaps, so I don't see what the issue would be there. It should look identical, just require that extra 1k for the map.

  • Like 1

Share this post


Link to post
Share on other sites
  • 0
14 minutes ago, SlithyMatt said:

Thanks!

Changing the bitmap starting pointer works great for vertical scrolling, but will cause corruption for horizontal scrolling. Also, tiles can have exactly the same palette as bitmaps, so I don't see what the issue would be there. It should look identical, just require that extra 1k for the map.

The issue is with 8bbp tiles an 8x8 section of pixels have to share the same row of 16 colors on the palette.  In bitmap mode I can use the entire palette for each pixel.  My source file is a 256 color bitmap, so it's really easy to convert that to VERA's palette representation.  In tile mode I'd have to do a lot of fooling around to create a reasonable palette, and the limits on the colors in 8x8 sections would just not look as good as a regular bitmap.

Share this post


Link to post
Share on other sites
  • 0
Just now, Ed Minchau said:

The issue is with 8bbp tiles an 8x8 section of pixels have to share the same row of 16 colors on the palette.

That's not true. You have full use of the palette for 8bpp tiles. And if you have a 20x15 map of 16x16 tiles, it takes up exactly the same amount of VRAM as a 320x240 bitmap, and can look identical. The only additional cost is the 1k tile map, but the benefit is the ability to scroll at will.

  • Like 2

Share this post


Link to post
Share on other sites
  • 0

An additional benefit of using a tilemap instead of a bitmap is the ability to replace sections of the map very quickly; what would require rewriting hundreds of pixels with an 8 bpp bitmap only requires swapping out a few 16x16 tiles.

  • Like 1

Share this post


Link to post
Share on other sites
  • 0
16 minutes ago, SlithyMatt said:

That's not true. You have full use of the palette for 8bpp tiles. And if you have a 20x15 map of 16x16 tiles, it takes up exactly the same amount of VRAM as a 320x240 bitmap, and can look identical. The only additional cost is the 1k tile map, but the benefit is the ability to scroll at will.

Ah, that's not clear in the VERA documentation; 2/4/8 bpp tilemaps are all treated the same here:

"MAP_BASE points to a tile map containing tile map entries, which are 2 bytes each:

Offset Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
0 Tile index (7:0)
1 Palette offset V-flip H-flip Tile index (9:8)

Each pixel in the tile data gives a color index of either 0-3 (2bpp), 0-15 (4bpp), 0-255 (8bpp). This color index is modified by the palette offset in the tile map data using the following logic:

  • Color index 0 (transparent) and 16-255 are unmodified.
  • Color index 1-15 is modified by adding 16 x palette offset."

So if I understand correctly, the tile map would have the tile indices as normal, and the palette offset would have to be 0001 to have colors 10-1f display normally, yes? But the 16x16 tiles themselves would just take up 256 bytes of contiguous memory?  In that case I wouldn't have to load two frames of data at once, and could just load a single frame of data formatted as tiles directly to VERA from file.

I'm shooting for 20fps with 6485Hz 8bit stereo sound here.  This could work.

Share this post


Link to post
Share on other sites
  • 0
1 minute ago, Ed Minchau said:

 

So if I understand correctly, the tile map would have the tile indices as normal, and the palette offset would have to be 0001 to have colors 10-1f display normally, yes?

Close. You can just keep the palette offset zero. It's not really used for 8bpp tiles.

Share this post


Link to post
Share on other sites
  • 0
25 minutes ago, SlithyMatt said:

Close. You can just keep the palette offset zero. It's not really used for 8bpp tiles.

OK, so that second byte of tile map data can still access vflip, hflip, and bits 8 and 9 of the tile index though, yes?  That might make it even easier.

Share this post


Link to post
Share on other sites
  • 0
2 minutes ago, Ed Minchau said:

OK, so that second byte of tile map data can still access vflip, hflip, and bits 8 and 9 of the tile index though, yes?  That might make it even easier.

Yep, absolutely!

Share this post


Link to post
Share on other sites
  • 0
43 minutes ago, DusanStrakl said:

I am late to the party, the question was already answered but since the documentation is a bit unclear I elaborated a bit more on my blog, especially because the Palette Offset works differently on 8bpp Sprites.

  • Color 0 is again transparent, so binary value of %0000 0000 will simply show the color of the layer below (if there is one)
  • Colors 1-15 will be affected by Palette Offset in Map data in the same way as in above example for 4bpp mode which makes sense because they only use 4 lower bits anyway and are simply complemented by top 4 bits from the offset. If Offset is 0 then Palette is unchanged.
  • Colors 16-255 are not affected by the Palette Offset and are taken directly from the palette. Note that this is different from the behavior for the 8bpp sprites.

 

 

Gotta say, your blog and SlithyMatt's youtube tutorials have been very helpful in this little project.

  • Thanks 1

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)
9 hours ago, SlithyMatt said:

Yep, absolutely!

This is working perfectly now.  I'm actually going to be able to do full screen full color video.

 

vidtest.jpg

Edited by Ed Minchau
  • Like 2

Share this post


Link to post
Share on other sites
  • 0

OK, so tile mode works great for this, but I found that the emulator loads data from file to VERA much faster than the actual machine will perform.  60fps at this resolution won't be a problem in the emulator, but my estimate is more along the lines of 20 for the real hardware - it pretty much has to be some factor of 60 to load a new palette in the vertical sync, and I think 30 fps (~360kb/s for this letterboxed video) is probably  pushing it.  And of course I want to load short PCM audio files and push them back into VERA every frame, which would take about 9% of any frame no matter the frame rate.  So, I'm going to pretend VERA isn't loading as fast as it is in the emulator, and count 3 VSYNC pulses for 20fps.  When it gets to the real hardware it'll probably only count 1 VSYNC and do the switch.

  • Like 3

Share this post


Link to post
Share on other sites
  • 0

Video on the X16... wow! I'm looking forward to your first demo 🙂.

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)
8 hours ago, AndyMt said:

Video on the X16... wow! I'm looking forward to your first demo 🙂.

Here's what I've got so far.  There's some glitches as the source file I used was 24 fps, so you can sometimes see where it changes the palette in the middle of the frame.  Also the source BMPs didn't always make color 00 the darkest color, so there's some flickering in the black bars at the top and bottom of the frame.  I also haven't added sound yet.  I'll fix all that soon, but so far it looks pretty good.

Untitled 103.avi

Edited by Ed Minchau
  • Like 3

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   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.


×
×
  • Create New...

Important Information

Please review our Terms of Use