Jump to content
IGNORED

Smooth scrolling


Asmusr

Recommended Posts

There is a further trick that is so overly complicated that I don't have used it, but you can define characters while the scene is scrolling.

 

So effectively the complexity of scene would be only limited by your ROM space.

  • Like 1
Link to comment
Share on other sites

Do you still have the source code you used for your video available? I would like to test if changing the location of the sprite tables in VDP RAM makes a difference. I would also like to try it on my PAL console. Thanks.

 

Here's the source and an EA#3 object file (Windows text out of Asm994A).

 

bitmaptest.zip

Link to comment
Share on other sites

I can confirm that in Tursi's test program the bug does not appear when you have 3 pattern tables and only one color table. I tested it on a European (TMS9929A based) console. Moving the sprite pattern table to >3800 did not change anything.

Link to comment
Share on other sites

This is an impressive one for the tms9918a:

http://www.youtube.com/watch?v=3wcsjlgz5AI

 

I thought only the 9938 or 9958 was the MSX chip as I have the manual on the MSX chips and the 9918a is never mentioned as one?

Also I have never heard of a 9918 that had more then 16K but could be expanded by paging RAM to 64K but never 128K?

Link to comment
Share on other sites

Cool but the Smooth Scrolling gave me a idea for a application that leads to a new game.

 

Features:

1. Uses the 1024K of the SAMS in Classic99 but should be able to run on a normal TI99/4A with HARD drive or multiple disks.

2. Loads screen from SAMS and saves them to SAMS as you move.

3. Just to create the screen map takes 10 minutes using Classic99 in System Maximum on CPU Throttling and RXB.

4. As it can save the screen maps the game can be stopped and restarted where you left off but have to start over at the beginning starting point.

5. Old obstacles and goals are saved as the game progresses. Thus the game can be ended and saved back to disks or hard drives.

6. New game maps can be generated by the player for new games or modify old game obstacles or goals.

7. The game is entirely only able to be run in RXB. (Assembly is possible but highly unlikely as memory not shared by running program and the maps in RXB)

 

I am not a game writer but wanted to create something not seen before and uses the full potential of the SAMS.

Link to comment
Share on other sites

  • 3 weeks later...

Just an update to show that my space scrolling demo is still (slowly) progressing. There have been some tough pills to swallow in the process of turning the demo into a framework for a game, but it still looks like a doable project.

 

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

 

The frame rate has dropped from 60 to 30 FPS to provide time for a game loop, but to compensate you can now scroll either 1,2 or 4 pixels per frame. At 2 pixels per frame it still looks nice and smooth, but at 4 pixels per frame it becomes quite bumpy.

 

Because of the >8 sprite bug in half bitmap mode I now update all 3 VDP pattern tables unless an F18A is detected (Classic99 detects an F18A by the method I use). This makes the frame rate drop further to 20 FPS, which is not terrible (see how it looks in Win994a), but my plan is to dynamically switch full pattern table updating on/off depending on whether more than 8 sprites are visible. Has this been tried before? (Note: at the moment I don't think >8 sprites are ever visible).

 

I have added a basic example of interaction with the scrolling background - you can now shoot the pyramids. This requires more character patterns to be updated so it has to be limited to a few tiles.

 

I have also added basic support for enemy ships moving around in predefined paths (no interaction yet), and a few animations.

 

Disk image (E/A 3: SCO) and source code attached.

spacescroll2.zip

  • Like 6
Link to comment
Share on other sites

  • 4 weeks later...

In this demo project I wanted to try out two new things on the same kind of space graphics I use in the half-bitmap mode project (which, BTW, is still going strong):

  • Horizontal scrolling
  • Scrolling in normal graphics mode 1

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

 

The attractive thing about using mode 1 for scrolling is that it's possible to use pattern table switching, which is not possible in bitmap mode. This demo uses four pattern table buffers, each divided into a low character set (0-127) and a high character set (128-255). This allows you to pre-load up to 128 patterns in 8 scroll positions/frames into VDP RAM. The demo also utilizes two name/screen table buffers - one for the low character set and one for the high character set. The scheme for switching buffers goes like this:

  • Frame 0: Pattern table 0, Name table 0 - low
  • Frame 1: Pattern table 1, Name table 0 - low
  • Frame 2: Pattern table 2, Name table 0 - low
  • Frame 3: Pattern table 3, Name table 0 - low
  • Frame 4: Pattern table 0, Name table 1 - high
  • Frame 5: Pattern table 1, Name table 1 - high
  • Frame 6: Pattern table 2, Name table 1 - high
  • Frame 7: Pattern table 3, Name table 1 - high

In terms of performance only the preparation of the name tables matters. Since we have 4 frames to prepare a table of 768 bytes we need to send only 192 bytes to the VDP RAM per frame. This leaves plenty of CPU cycles for sprites and other stuff - even at 60 FPS. The demo shows different speeds from 15 FPS to 60 FPS at 1 pixel/frame, and the top speed is 60 FPS at 2 pixels/frame. When moving 2 pixels you only have 2 frames to prepare a name table, i.e. 348 bytes per frame.

 

Another good thing about mode 1 compared to half bitmap mode is that all 32 sprites can be used without running into the 'duplication bug'.

 

The downside of using mode 1 is the limited colors, of course. Two adjacent tiles in the direction of scrolling must either use the same foreground color or the pattern for one of them must not contain any foreground color pixels (i.e. a 'space'). The same rule applies to the background colors. (Actually, horizontal scrolling in bitmap mode is subject to the same color limitations but applied to each individual scan line.)

 

I'm going to post an update to the Magellan thread that provides better tools for designing mode 1 scrolling graphics plus an export function for generating the transition map, which I used for this project.

 

This attachment contains a dsk file with the demo (looks much better in Classic99 and even better on hardware than on the video).

hscroll.zip

The source code is also included. Note that the code is overly complicated because of the scrolling at different speeds and because of the wrap around of the map. If these features were not required it could be done much simpler.

  • Like 4
Link to comment
Share on other sites

Thank you for all the positive feedback. I see lots of potential for using this technique for games (platform, driving, pinball to name a few ideas), and I hope that some of you will be inspired to make your own projects so we can share ideas and techniques. For now I'm focused on the vertically scrolling, half-bitmap project, which is beginning to look like a game, but I'm still not 100% sure what the objectives of the game are...

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

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

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...