A little bit of Mode 9 insanity

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
Jubatian
Posts: 1499
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: A little bit of Mode 9 insanity

Post by Jubatian » Thu Sep 15, 2016 7:35 am

Did you try double scan? I mean that by default it starts quad scan (and it seems by your try, you didn't change it). You can increase the vertical resolution by setting m90_exvram to the video memory which should supply the "odd" rows (I mean "odd" relative to the quad scan output, so rows 2-3, 6-7, 10-11 etc. by real screen coordinates). By default it is set vram, so the odd rows are the same as the even rows (so resulting the quad scan). For every row you need 30 bytes of data.

yllawwally
Posts: 73
Joined: Tue Mar 05, 2013 7:29 pm

Re: A little bit of Mode 9 insanity

Post by yllawwally » Thu Sep 15, 2016 4:49 pm

Not yet. I was thinking I needed to come up with 1700 more bytes. But I could get an extra 1000 fairly easily. I'll try to test that later today.

User avatar
Jubatian
Posts: 1499
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: A little bit of Mode 9 insanity

Post by Jubatian » Thu Sep 15, 2016 5:04 pm

That's one reason why split screen is useful! This way you may have thinner high-res content if you don't have enough memory to have it full screen ;) You may also keep in mind the kernel's SetRenderingParameters function by which you may dynamically set the display's height and vertical position to get a thinner screen (saving RAM that way, for example dropping two tile rows you get 120 bytes of vram free for storing stuff, you could possibly use it to move things temporarily away to gain more space for the 2bpp part).

yllawwally
Posts: 73
Joined: Tue Mar 05, 2013 7:29 pm

Re: A little bit of Mode 9 insanity

Post by yllawwally » Thu Sep 15, 2016 7:11 pm

Here is a sample of the screen with the high resolution enabled. I only could find enough ram to do this much at the moment.
Here are two feature requests. Could I specify where to start and stop high res? For example, maybe I would quad line the first 30 lines,
because clouds are big and fluffy, will I might want the rest to be double scanned. Or maybe quad scan top for clouds and bottom for ground while interesting things are in the middle. Maybe set a different palette of four colors, every four lines or so, taking 30 bytes of ram. Using RLE I compress the level data to 600 bytes, I'm trying to come up with a better method, maybe procedurally generate it. But between levels I can use all that space, plus some other space, and get a little over a 1000 bytes, for interlevel displays. I have a couple ideas of ways I want to use it. I didn't realize at first how powerful being able to give the size to take over from the screen would be. It seems that I would need to use lines even divisible by 8, or the screen will be messed up from the transition from graphic mode to text mode.
uzem_000.jpg
uzem_000.jpg (44.69 KiB) Viewed 2629 times

User avatar
Jubatian
Posts: 1499
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: A little bit of Mode 9 insanity

Post by Jubatian » Thu Sep 15, 2016 8:08 pm

A big problem is that while hacking around fits, those would complicate the usage of the mode.

Palette changing is possible if I fix the centering (I mean getting rid of CENTER_ADJUSTMENT, fixing the display at the same stretch that Megatris also uses) to get 48 cycles, and it would be an useful feature (also consider the text mode, like you could have a differently coloured status row), but it needs extra palettes (in RAM) and a change logic which you would have to follow.

Messing around with a High Res / Low res switch could get cumbersome quick, like you should see that low res is actually not low res (it is just using the same vram bytes for odd rows by pointing them to vram). You should rather try out the method I mentioned in the kernel to shrink the display vertically to free up space in the normal vram (where you may move away data to get more extra vram space for the 2bpp graphics).

The split uses line numbers since it was easier to implement. There is no sense to not set it at tile boundary since that way the same vram will be used for both some 2bpp rows and a text row (so either the 2bpp rows or the text row will look messed up). If you want to implement some vertical scrolling trick like rolling in the display from the bottom, play around with that kernel routine (SetRenderingParameters)! It is useful :) (contrary to its documentation, it uses line numbers for both its parameters. The FirstScanlineToRender parameter's default value is 20 for the 224 pixels tall screen).

yllawwally
Posts: 73
Joined: Tue Mar 05, 2013 7:29 pm

Re: A little bit of Mode 9 insanity

Post by yllawwally » Sat Sep 17, 2016 12:09 am

What does the center adjustment do? I haven't played with that option. Is it used for a scrolling type effect? Would it be easier to add more palettes, if they were rom based. So that you have up to 255 fixed palettes, and you can choose one of those. Since each of these would be simply 4 bytes, it would be only 1k of rom at most. And maybe reserve one entry such as palette zero to be ram based. So an additional 4 bytes of ram.

User avatar
D3thAdd3r
Posts: 2437
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: A little bit of Mode 9 insanity

Post by D3thAdd3r » Sat Sep 17, 2016 1:14 am

I would get rid of center adjustment without a second thought since there is benefit. I never heard of anyone having issues and needing to recompile games due to horizontal centering of scanlines.

User avatar
Jubatian
Posts: 1499
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: A little bit of Mode 9 insanity

Post by Jubatian » Sat Sep 17, 2016 9:15 am

Yes, that center_adjustment is a rather useless feature. It is a constant, so you can only set it and compile, supporting it wastes 48 precious HSync cycles. Originally when I did Mode90, I just added it since I had lots of free cycles there, but a palette reload will gobble that up.

For now I am doing a few things with the emulator (and if Artcfox sends in his version of Tempest, I will have to debug what happens with that too), I think in the afternoon I will create you a palette reload feature (for both Mode 90 and 92 in an identical manner, just to keep the two in sync - maybe others later will also like one or another of these modes :) ).

User avatar
Jubatian
Posts: 1499
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: A little bit of Mode 9 insanity

Post by Jubatian » Sat Sep 17, 2016 3:45 pm

I added a palette reload feature (GitHub), to both Mode 90 and Mode 92 such as the two remained compatible with each other.

You now have an m90_pal1:m90_palrel1 and an m90_pal2:m90_palrel2 pair. The pal1 and pal2 variables are the pointers to the 16 color palettes to use, by default they are pointed at palette. The palrel1 and palrel2 variables set the reload lines where the palette should be replaced. By default they are inactive (set 255 so would never trigger). This allows to have three palettes on a single screen, such as to have a top and bottom status bar with different colors. For memory economy if you want a top and bottom status bars sharing the same palette, use the default palette for them, and only specify a new palette for the middle region (game).

It may also be useful for various dynamic effects. For such it might be useful that pal1 has priority, so if the two reloads happen to fire on the same line, pal1 takes priority (and pal2 will not be loaded).

I think this is about what is reasonably possible for this mode pair (there aren't much remaining in cycles), so as it is now, possibly it could get finalized.

If you are really desperate to get a more colorful 2bpp display, Mode74 demonstrated a possibility of doing Commodore 64 style multicolor. That mode works by allowing specifying the 4 color palette for every 8x8 tile (so one tile takes 16 pixel bytes and 2 palette bytes as the latter is taken from the Mode74 16 color palette). It is nearly as memory economic like plain 2bpp, but it needs skill to pixel for it proper! (Although it offers more freedom than Commodore 64's Multicolor where not all colors are freely selectable, it is very difficult to use it well for colorful art, and a good converter also needs careful desing. You might look around a bit in the Commodore 64 scene for examples. With these fat pixels improper use of the mode would look atrocious). With Mode 74 I just mean that at low res, 2bpp multicolor is definitely a possible thing to implement (Mode 74 does it at 7 cycles / pixel with the added complexity of using the 16 color palette).

yllawwally
Posts: 73
Joined: Tue Mar 05, 2013 7:29 pm

Re: A little bit of Mode 9 insanity

Post by yllawwally » Mon Sep 19, 2016 8:06 pm

Does the palette swap affect the palette for the tiles, or just the image mode? Also the palette doesn't seem to swap. Palette 2 seems to always be used. Do the 2 replacement palettes need to be 16bytes? Isn't only the last four bytes being used(palette[12],palette[13],palette[14],palette[15])?
uzem_000.jpg
uzem_000.jpg (45.82 KiB) Viewed 2537 times

Code: Select all

					m90_split = 224;

					palette[12] = 0;
					palette[13] = 0b11010110;
					palette[14] = 0b01011010;
					palette[15] = 0b01010110;

					m90_palrel1 = 40;
					m90_palrel2 = 120;
					//m90_exvram = &Menu[0][0];
					m90_pal1[12] = 40;
					m90_pal1[13] = 0b11011110;
					m90_pal1[14] = 0b01011010;
					m90_pal1[15] = 0b01010110;
					m90_pal2[12] = 28;
					m90_pal2[13] = 0b11110110;
					m90_pal2[14] = 0b01111010;
					m90_pal2[15] = 0b01110110;

					for (unsigned int line=00; line < (56);line++)
						for (unsigned int col=0; col < (30);col++){
						vram[col+((line)*30)] = (const char*)pgm_read_word(&Monster[col+((line+30)*30)]);
						//Menu[0][col+((line)*30)] = (const char*)pgm_read_word(&Monster[col+((line+1)*30)]);
						}

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests