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).
Mode 40: 40x25 attribute mode
Re: Mode 40: 40x25 attribute mode
Re: Mode 40: 40x25 attribute mode
What about scrolling text up the screen like most BASIC games? Or can that be done with a simple memcpy?
Re: Mode 40: 40x25 attribute mode
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).
Re: Mode 40: 40x25 attribute mode
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.
Re: Mode 40: 40x25 attribute mode
I would say a simple "memmove", which correctly copies between overlapping sections. To scroll up one character row, you would have to do this: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.
Code: Select all
memmove(vram, vram + VRAM_TILES_H, (VRAM_TILES_V - 1U) * VRAM_TILES_H);
- nicksen782
- Posts: 714
- Joined: Wed Feb 01, 2012 8:23 pm
- Location: Detroit, United States
- Contact:
Re: Mode 40: 40x25 attribute mode
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.
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.
Re: Mode 40: 40x25 attribute mode
Cool, thanks!
Re: Mode 40: 40x25 attribute mode
I created a new derivative with 16 color palettized attributes. I added it to Master:
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
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
Re: Mode 40: 40x25 attribute mode
Wow, again, this video mode streak is legendary!