Smooth scrolling

[+acadiel]

Wow, it's a very nice piece of programming... :thumbsup:

 

it seems like that ti99 will be ready to have his first DEMO SCENE soon ...

 

good job guys... i love your work and passion :lust: because you are the energy that our TI99 needed to live.

 

Thank you !!!

 

you are GREAT !

 

 

------------------------------

EDIT:

 

here is a fast Video using my Android Phone:http://http://youtu.be/Fnlx7tXXZkY

Crap, that is impressive!

 

[TheMole]

Absolutely brilliant to see the multicolored sprite and the multi-directional scrolling!

 

I know the F18A's scrolling is quite flexible, but is it possible to set it up in such a way that you could mimic sega master system like scrolling (ie, you only have one screen in memory and you add the new column of characters every time you scroll 8 pixels). That's obviously more work on the CPU for scenarios in which the full map fits in video memory, but it requires much less video memory allowing more room for patterns in ECM3 mode.

 

So, my question is: will scrolling work with only one "page"?

[matthew180]

Yes, that is what is happening here. There is only 1 page being scrolled, and after 7 pixels of vertical scrolling in either direction (up or down), the whole screen (name table data) is copied up or down in VRAM by one row, and the new top or bottom row is added from the map data (which in this case is loaded in the 32K RAM expansion). The screen copying is done by the GPU in this case so it is very fast and removes even more load from the host system.

 

You could also have two name tables set up in a vertical configuration and copy a new screen of data instead of a row at a time. There are lots of options.

[matthew180]

http://www.youtube.com/watch?v=Vcn85aF3aBU

 

I finally got out my video camera and went through all the hoops for making a YouTube video. The colors are a little washed out and there is a jitter every now and then, but it's the best I can do with what I have.

Edited September 16, 2013 by matthew180

[+retroclouds]

Vulgus was my favorite arcade game. I Like the space ship!

[Asmusr]

Here is the second version of my code that turns a generic Magellan export file into a smooth vertically scrolling demo. This is using far less memory than the first version thanks to the suggestions made by Kurt Woloch.

 

To use the code for your own project, follow these steps:

 

1. Download the latest version of Magellan (currently 1.8.1).

2. Create a map in bitmap mode colors with a width of 32 characters.

3. Check that the map contains no more than 128 vertical transitions using the analyzing tool in Magellan. To reduce transitions, eliminate those with fewest occurrences first.

4. Choose Export > Assembler Character Transition Data.

5. Export with the options: Bottom to Top, Wrap Edges: off, No compression, Generate Scrolled Character Frames: 2-character Strips, Current Map Only.

6. Edit the 'Vertical bitmap scroll.a99' file and replace the file name in the COPY directive at the end with that of your own export file.

7. Add the file to a project in WinAsm99, assemble and run.

 

There's more information inside the 'Vertical bitmap scroll.a99' file.

 

I have chosen vertical scrolling in bitmap mode (actually half-bitmap mode) as my first example because this doesn't impose further color restrictions than bitmap mode already has. Let me know if you need sample code for horizontal scrolling or for graphics mode 1, and I will consider adding that to the 'library'.

MagellanScroll-1.1.zip

[Asmusr]

Now that I have resurrected this thread I might as well blog a little about some is the ideas I have for further developing the scrolling algorithms.

 

My first idea is to make a game based on 2 pixel scrolling in graphics mode 1. You could store one full pattern table for each of the four frames in VDP RAM and would therefore be able to use up to 256 transitions without any performance penalty. At 60 FPS 2 pixel scrolling looks very smooth, and I think it would be great for a racing game in lines with Spy Hunter or Bump'n'Jump.

 

My second idea is to create more variation in the graphics by paging the transitions. In its simplest form a page would equal a computer screen. Page 1 and 2 would share pattern transitions 0-63, page 2 and 3 would share transitions 64-127, page 3 and 4 would share a new set of transitions 0-63, and so on. The idea is that the previous set of transitions would just have disappeared from view when it's time to load the next. The trick would be to avoid a delay while new transitions and uploaded to the VDP (in graphics mode 1).

 

My third idea is to take the second idea further and have a sliding window of the currently visible transitions. Magellan would have to be programmed to supervise that when one transition appears into view another one disappears, to keep the number of transitions steady. I'm not sure how the algorithm to select which transitions to upload for a given frame would work.

 

My fourth idea is to make more usage of animations during scrolling. In Titanium I have the blinking lights, and in Scramble I have some tile based explosions, but this could be taken much further by implementing a generic system for changing some of the patterns every frame, dividing the load evenly between frames.

[Kurt_Woloch]

Hmmm... something doesn't seem to be quite right in this version. The A99 files supplied with the ZIP file only have 8 bytes for each transition strip (for pattern and color data each, that is) instead of 16. And the data for the first transition appears twice. Yet, the program supplied on the disk still works (I didn't try to re-assemble it though).

I tried to output some level data from Magellan 1.8.1 myself, and in that data, each transition strip also consists of only 8 bytes, and the duplication of the first transition strip also occurs here. But there is a difference to the files supplied in that the character data now have additional labels PCHxx for each character giving the character number. Actually, I wonder how the program supplied on the disk image still manages to work (almost) correctly... although there seem to be some glitches in the lower third of the screen when running the program on Classic99.

 

Just look at the lowest line of this screenshot... this doesn't look quite right.

 

[Asmusr]

Hmmm... something doesn't seem to be quite right in this version.

 

There's probably a problem somewhere, but I haven't found it. The strips are split into two lines each. For some of them the character transitions into itself, so the lines are duplicated. I don't see the problem in Classic99 either. Which options did you use for exporting from Magellan?

[Kurt_Woloch]

OK, I see. Seems like I misread the comments for the strips... I thought #XX - YY and the end of each line means a transition from character XX to character YY. Instead it's transition character XX, followed by the character number YY which is the half of the transition displayed here, the first line being the "from" and the second one the "to" character, or vice-versa. Sorry, I didn't look as far as I should here.

 

For exporting from Magellan, I used the options that are given in the listing "Vertical bitmap scroll" - Bottom to Top, Wrap Edges: off, No compression, Generate Scrolled; Character Frames: 2-character Strips, Current Map Only. I left everything else the way it was, as far as I know, except for turning on bitmap mode colors.

[Asmusr]

OK, I see. Seems like I misread the comments for the strips... I thought #XX - YY and the end of each line means a transition from character XX to character YY. Instead it's transition character XX, followed by the character number YY which is the half of the transition displayed here, the first line being the "from" and the second one the "to" character, or vice-versa. Sorry, I didn't look as far as I should here.

 

For exporting from Magellan, I used the options that are given in the listing "Vertical bitmap scroll" - Bottom to Top, Wrap Edges: off, No compression, Generate Scrolled; Character Frames: 2-character Strips, Current Map Only. I left everything else the way it was, as far as I know, except for turning on bitmap mode colors.

 

I guess the comments could be more clear, perhaps include the words 'to' and 'from'

 

If you switch off the option 'Include character numbers' you shouldn't see the PCH labels. I have never used them myself, they were added before I started to develop Magellan further.

 

Have you tried to assemble a new object file based on your own map?

[Kurt_Woloch]

Since you asked about it, I tried to assemble a new object file based on my own map, in this case, the 2nd level of Marble Madness (as reduced in Magellan). The result (after I finally managed to correctly convert it to run) does display the top of the map, but instead of scrolling, it just shakes up and down by one pixel repeatedly.

 

EDIT: I tried to debug this a bit, and it seems like on every frame, the direction of scrolling changes from down to up or vice-versa. This is probably caused by the check if the lower or upper boundary is reached. With more time, I could probably spot the error, but I have to go to sleep now.

 

I've attached a ZIP file with the assembler source files used. The archive should contain all relevant files... the object file on the DSK is called VERTICALC and starts automatically. I haven't done anything but replacing the reference to the included source code in your code from "Titanium.a99" to "Marble Screen 2.a99". I've tested it both in Classic99 (QI342) and MESS (0.135), and it does the same in both emulators. By the way, I've also tested your object file (which is also on my DSK) in MESS 0.135, and there it doesn't show the glitch which is visible in Classic99 (QI342).

 

Marble2.zip

Edited November 2, 2013 by Kurt_Woloch

[Asmusr]

Since you asked about it, I tried to assemble a new object file based on my own map, in this case, the 2nd level of Marble Madness (as reduced in Magellan). The result (after I finally managed to correctly convert it to run) does display the top of the map, but instead of scrolling, it just shakes up and down by one pixel repeatedly.

 

I've attached a ZIP file with the assembler source files used. The archive should contain all relevant files... the object file on the DSK is called VERTICALC and starts automatically. I haven't done anything but replacing the reference to the included source code in your code from "Titanium.a99" to "Marble Screen 2.a99". I've tested it both in Classic99 (QI342) and MESS (0.135), and it does the same in both emulators. By the way, I've also tested your object file (which is also on my DSK) in MESS 0.135, and there it doesn't show the glitch which is visible in Classic99 (QI342).

 

Marble2.zip

 

You version is also shaking for me, but when I reassemble it, it works see VERTICALRC on the disk. I'm using WinAsm99 version 3.010 and Classic99 version QI372 (and MESS 0.150).

 

Edit: In the release notes for Win994a 3.010:

• The assembler application has been revised and updated to correct a problem with the resulting machine code generated by a few conditional branch op codes.

Your version: 94  A056 1601            JH   CHGDY
My version:   94  A056 1B01            JH   CHGDY

Marble2.zip

[Asmusr]

This short note appeared in the October issue of Retro Gamer Magazine in the homebrew section:

 

[Omega-TI]

This short note appeared in the October issue of Retro Gamer Magazine in the homebrew section:

 

 

Congratulations, you've hit the 'big leagues'. But as they say, one cannot stand on their laurels forever... do you have anything cooking in the oven?

[Kurt_Woloch]

You version is also shaking for me, but when I reassemble it, it works see VERTICALRC on the disk. I'm using WinAsm99 version 3.010 and Classic99 version QI372 (and MESS 0.150).

Indeed it does... I downloaded the current version of WinAsm99 (actually, the suite it belongs to) and reassembled with this version, and it now works.

 

However, I've now added some music. Rasmus, I hope you don't mind that I've copied your music player from "Titanium" and inserted it here... but the music is quite different to that in Titanium.

 

The filename to run would be VERTICAL2C. Use the LOAD AND RUN option in Editor/Assembler (Option 3).

 

Yes, I know the source code isn't as clean as it could be...

 

Marble2_13_11_10.zip

Edited November 10, 2013 by Kurt_Woloch

[+OLD CS1]

VERY nice! Does the music use all three voices? There seems to be a track missing. I have been obsessing over the music since the discussion moved to "Marble Madness" since the music is a large part of the experience.

[Kurt_Woloch]

VERY nice! Does the music use all three voices? There seems to be a track missing. I have been obsessing over the music since the discussion moved to "Marble Madness" since the music is a large part of the experience.

Actually, the music uses all FOUR voices since the noise voice gets used to play the bass track. This way, lower notes can be played than would normally be possible, in this case, the lowest note is about 44 Hz.

 

Yes, I know that some notes of the original are missing. I think the original uses more than three voices for this song if you listen closely, at least in parts (e.g. in the first half of the song). And I didn't make use of vibrato, envelopes and other features which would be technically possible with the TI, but only make sense with a more advanced player than used here.

 

You could compare this to the Sega Master System version of Marble Madness which uses the same sound chip, but includes some vibrato. There they seem to have used the same trick with the bass notes as me, but I'm pretty sure they got some of the notes wrong, as you can hear here:

 

[Asmusr]

However, I've now added some music. Rasmus, I hope you don't mind that I've copied your music player from "Titanium" and inserted it here... but the music is quite different to that in Titanium.

 

 

Very nice, and it's fine that you're using my sound player. At first I thought you were talking about the music player that I use for the opening music, which is Tursi's work.

 

If you want to add the envelopes and vibrato you need another sound player. You can actually download the music in VGM format (http://www.smspower.org/Music/MarbleMadness-SMS), load it into the MOD2PSG2 player (http://www.smspower.org/Music/Mod2PSG2), and export as a ESPG2MOD file for playback in Tursi's player. The problem here is that the noise generator is different on the Sega than on the TI, so all the bass/noise notes must be adjusted by 15/16, which is a pain to do in the tracker. I think Tursi is also working on a VGM player for the TI that would work directly.

[Tursi]

yes.. it's close, but I need to spend more time on it. It does handle the 15/16 bit noise conversion automatically

[gregallenwarner]

Wow. I just had to jump in here and say, this is hands down, the best programming work I've ever seen on the TI. Excellent work guys!

 

By the way, I'm a HUGE fan of Titanium. I play if often!

[Kurt_Woloch]

Just wanted to mention that I've showed my Marble Madness demo with music (as posted here) on the TI-99 meeting at Wednesday. Strangely, on Klaus's F18A-equipped TI-99 it runs about a third slower than in my version of Classic99, that is, it only scrolls up and down a pixel every 3 frames while the scrolling takes 2 frames in Classic99. Has anyone of you tested it out on other platforms?

[Tursi]

How are you performing frame synchronization?

 

If you are polling, there's a known issue that you can "miss" a sync, it gets reset at the same time it's being set, and the CPU never sees it.

[Asmusr]

My guess is that you're very close to the 2 frame limit, and it just tips over on the hardware. You can measure the duration of the main loop (excluding the call to VSYNC) in Classic99 using the T(XXXX-YYYY) directive. You can also try to comment out the first line of VSYNC:

MOVB @VDPSTA,R0 * Clear flag if already set

Edit: My tests show that a loop takes up to 108000 clock cycles. Are you by any chance running Classic99 in 50Hz mode?

[Tursi]

A couple of notes on the timing...

 

I know that Classic99 runs slightly fast - so the cycle count is potentially low - there are a few cycles I am not accounting for somewhere (probably memory cycles), so if you are close to the edge, that is worth noting.

 

Real TI consoles run at 3,000,000 cycles per second plus or minus 5% (per spec). I have machines that I've measured at both extremes. Again, it's a small amount, but it's worth noting when you're at the edge.

 

At 60Hz you should get about 47500-52500 cycles per frame on hardware. Classic99 should be calculating 50,000 per frame. (I'm honestly not sure if 50hz mode still works!)