Mode 40: 40x25 attribute mode

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

Re: Mode 40: 40x25 attribute mode

Post by Jubatian »

D3thAdd3r wrote: Mon Dec 11, 2017 7:07 pm How hard is it to add (non-wrapping) scrolling? For some reason this makes me want to do a clone of the old game Oregon Trail, but might be too much bitmapping.
Only vertical scrolling could have been possible, but I rather avoided it to make the user interface simpler. If you don't have sprites, then fine scrolling isn't that much practical anyway. I took a look at the game, but it only seems to have some very simple scenes, and even those require sprites (such as when arriving to the Kansas river). If you are limited to character mode, you could only do that by creative tile design to fake a scroll. Or use low resolution bitmap mode and draw it (there you also either have to keep redrawing the wagon or the approaching river, choose to redraw the latter and then you don't have to scroll).
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Mode 40: 40x25 attribute mode

Post by Artcfox »

What about scrolling text up the screen like most BASIC games? Or can that be done with a simple memcpy?
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 40: 40x25 attribute mode

Post by Jubatian »

Artcfox wrote: Wed Dec 13, 2017 1:22 am What about scrolling text up the screen like most BASIC games? Or can that be done with a simple memcpy?
Smooth scrolling is not possible, I didn't think it too much practical beyond "eyecandy", and omitting it kept the modes simpler for the end user (less things to configure). Of course you can always memcopy, if it is good for Flight of a Dragon, then what's the fuss? :) (This is where the fast clock pays off: It isn't a prohibitively expensive operation unlike on a C64 for example, and scrolling with memcopy is a lot easier to manage, it likely even saves some ROM as you don't need convoluted code to handle a wrapping VRAM. I think it's no wonder there aren't too many vertical scrolling Mode 3 games).
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Mode 40: 40x25 attribute mode

Post by Artcfox »

I didn't mean smooth scrolling, I just meant like you are typing commands near the bottom of the screen and press Enter and the text scrolls up a line. I was wondering if a single memcpy was the best way to handle that, or if the video mode had any weirdness that would require breaking it up into multiple memcpys.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 40: 40x25 attribute mode

Post by Jubatian »

Artcfox wrote: Wed Dec 13, 2017 6:25 pm I didn't mean smooth scrolling, I just meant like you are typing commands near the bottom of the screen and press Enter and the text scrolls up a line. I was wondering if a single memcpy was the best way to handle that, or if the video mode had any weirdness that would require breaking it up into multiple memcpys.
I would say a simple "memmove", which correctly copies between overlapping sections. To scroll up one character row, you would have to do this:

Code: Select all

memmove(vram, vram + VRAM_TILES_H, (VRAM_TILES_V - 1U) * VRAM_TILES_H);
Of course then fill the bottom row with new content. I don't know how well the standard C library is optimized on the AVR though, although in a text adventure with this mode certainly it wouldn't be a bottleneck.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Mode 40: 40x25 attribute mode

Post by nicksen782 »

This scrolling via memmove is what I do in Bubble Bobble to scroll the screens between levels. It works pretty well actually.

In this example's case you are moving all of vram up and you would need to replace the bottom line. You can also lock-in to certain vram rows by using pointers.

I can vouch that the method works... at least in mode 3.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Mode 40: 40x25 attribute mode

Post by Artcfox »

Cool, thanks!
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 40: 40x25 attribute mode

Post by Jubatian »

I created a new derivative with 16 color palettized attributes. I added it to Master:
Mode 42 example
Mode 42 example
mode42_cuzebox_screenshot.png (41.49 KiB) Viewed 7448 times
You may compare the shot to that of the top post, to observe that it indeed uses less RAM. A palette buffer was unavoidable though, which using the UZEBOX_STACK_TOP define I introduced recently, I located at the top of the RAM (the stack is below that). So you have about 750 bytes more than in Mode 40 at 40x25.

This mode uses slightly more ROM as I could not pack the display code that tight like for the other two modes, but still very little with that a charset is just 2 KBytes.

I also added it to the wiki: Mode 42 entry
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Mode 40: 40x25 attribute mode

Post by D3thAdd3r »

Wow, again, this video mode streak is legendary!
Post Reply