Jump to content
IGNORED

Smooth scrolling


Asmusr

Recommended Posts

 

The MSX demo in post #54 (we spit on your 128K RAM ;-) ) inspired me to make this demo of a platform game. As always you should try it on a real console to enjoy the full 60 FPS smooth experience (E/A 3 DSK1.PLC).

 

The big challenge was to coordinate the switching between vertical and horizontal scrolling. I only allow the scroll direction to change on 16 pixels boundaries since my algorithm has a 16 frame cycle. 8 pixels boundaries should be possible, but for a game where the scrolling is just aiming to center the main sprite it's not essential.

 

Scrolling in two directions requires that you store both a horizontal and a vertical map of tile transitions. To maximize performance I also store a copy of each map with the most significant bit set on each tile. The maps are 3K each, so this totals to 12K for the maps alone. If anyone knows a really fast was to copy from CPU to VDP RAM while setting the msb let me know so I could avoid the extra buffers.

 

I have kept the graphics in the demo very simple (only 9 tiles) in order to hold something back should I decide to turn this into a game. For now I'm more interested in working on my Scramble project. If any of you are interested in using the code for your own project just let me know and I will do my best to assist you.

 

Rasmus

Platform demo.zip

  • Like 7
Link to comment
Share on other sites

 

The MSX demo in post #54 (we spit on your 128K RAM ;-) ) inspired me to make this demo of a platform game. As always you should try it on a real console to enjoy the full 60 FPS smooth experience (E/A 3 DSK1.PLC).

 

The big challenge was to coordinate the changes between vertical and the horizontal scrolling. I only allow the scroll direction to change on 16 pixels boundaries since my algorithm has a 16 frame cycle. 8 pixels boundaries should be possible, but for a game where the scrolling is just aiming to center the main sprite it's not essential.

 

Scrolling in two directions requires that you store both a horizontal and a vertical map of tile transitions. To maximize performance I also store a copy of each map with the most significant bit set on each tile. The maps are 3K each, so this totals to 12K for the maps alone. If anyone knows a really fast was to copy from CPU to VDP RAM while setting the msb let me know so I could avoid the extra buffers.

 

I have kept the graphics in the demo very simple (only 9 tiles) in order to hold something back should I decide to turn this into a game. For now I'm more interested in working on my Scramble project. If any of you are interested in using the code for your own project just let me know and I will do my best to assist you.

 

Rasmus

The only way I see this advancing further is to add more memory to the TI by using the SAMS to store the 12K could be increased to 900K. (900K/12K = 75 times more map)

 

At that point you have a hell of a map and still have 100k left over for the program. (100K/32K = 3 times more program space)

Link to comment
Share on other sites

The only way I see this advancing further is to add more memory to the TI by using the SAMS to store the 12K could be increased to 900K. (900K/12K = 75 times more map)

 

At that point you have a hell of a map and still have 100k left over for the program. (100K/32K = 3 times more program space)

Well there is still another possibility. You could store the map in The cartridge space ROM. 64K EPROM allows quite a big map. You could still use the 32K RAM of the PEB. Ofcourse developing for the cartridge space can be a bit frustrating as you have to deal with bank-switching and would be emulator only until you can burn it onto eprom.

Link to comment
Share on other sites

The only way I see this advancing further is to add more memory to the TI by using the SAMS to store the 12K could be increased to 900K. (900K/12K = 75 times more map)

 

At that point you have a hell of a map and still have 100k left over for the program. (100K/32K = 3 times more program space)

If we had a contemporary solution for SAMS, like in the next generation of nanoPEBs, I would definitely use it.

Link to comment
Share on other sites

If we had a contemporary solution for SAMS, like in the next generation of nanoPEBs, I would definitely use it.

The biggest advantage to the SAMS is the amount of memory it takes to switch banks. In RXB it takes zero as I built it into RXB.

 

As for Assembly it takes no Lower 8K support routines to be loaded to access and switch memory blocks.

 

The entire Assembly routine is less then 48 bytes to switch any memory to any memory pages or blocks.

 

Besides any Cart RAM memory are not compatible with normal EA or XB or any other cart unlike the SAMS that can be used my most carts.

 

Including TF or REA or EA or RXB or XB or LOGO or PASCAL or Mini Memory.

Edited by RXB
Link to comment
Share on other sites

Well there is still another possibility. You could store the map in The cartridge space ROM. 64K EPROM allows quite a big map. You could still use the 32K RAM of the PEB. Ofcourse developing for the cartridge space can be a bit frustrating as you have to deal with bank-switching and would be emulator only until you can burn it onto eprom.

 

Or better yet, the new 512K ROM cart. Imagine what you could put in there. The copy from cart ROM to VDP or 32K to execute is very fast (it shocked me when I did it with Never Lander the first time on a real system). All you have to do is write to an address segment to select an 8K segment, roll a loop to read and copy the data, and do it again if you need more.

 

If RXB is aware of it, and we could mix some of the XB ROM space with some of the bank switched ROM space (without XB crashing due to lack of some of its ROM routines), we could probably build in some pretty nice support stuff directly into the 512K ROM space for use with XB as well.

Link to comment
Share on other sites

The biggest advantage to the SAMS is the amount of memory it takes to switch banks. In RXB it takes zero as I built it into RXB.

 

As for Assembly it takes no Lower 8K support routines to be loaded to access and switch memory blocks.

 

The entire Assembly routine is less then 48 bytes to switch any memory to any memory pages or blocks.

 

Besides any Cart RAM memory are not compatible with normal EA or XB or any other cart unlike the SAMS that can be used my most carts.

 

Including TF or REA or EA or RXB or XB or LOGO or PASCAL or Mini Memory.

 

 

Unfortunately SAMS is not all that prevalent and a game written solely for it will have a small audience.

 

I would think that using extra memory like SAMS as a storage place for information on disk - so that the program could call it from memory instead of disk - would be a nice method to implement. A standard setup could pull from disk; an advanced setup could use the memory.

 

Many ways to skin the cat...

  • Like 2
Link to comment
Share on other sites

 

A standard setup could pull from disk; an advanced setup could use the memory.

 

Many ways to skin the cat...

 

Very true. Also with many people having switched to virtual disks in emulators like Classic99, using Nano's or CF7's or even other solid state drive replacements for legacy devices, speed is already improved in the 'standard setup' already.

Link to comment
Share on other sites

Any news about that?

I'm comfortable with the ROM part. Tursi can speak to where he is with GROM, and the manual is pretty darn comprehensive. (I'd like to get XB and RXB working on it for a PoC.). Once Tursi is done, it just needs a sponsor or sponsors to get them made and sold. At that time, I can help provide guidance. Matthew got the last batch done, so he can provide input as well.

 

Link to comment
Share on other sites

A patch to allow for RXB to reside and use the 512K cart from XB is easy as GPL does not need access to the ROMs for anything except specialized routines like math or XB only commands.

 

Now moving data into and out of the RAM of the cart would required Assembly as all routines in XB or RXB must use the ROMs to fetch or save variables. So even a CALL LINK would fail to work.

 

As would RXB CALL MOVES or CALL LOAD or CALL PEEK in that all of them use the XB ROMs to access any variable.

Link to comment
Share on other sites

Perhaps RXB could be set up with a prototype of the 512K cart. That way the RXB software could be tuned and delivered with the 512k carts when it becomes generally available. Kinda like RXB being the killer application that pushes the amount of orders. I mean I am sure that the 512k would do fine without RXB, but it would be very nice that when the hardware becomes available there is some cool software available for it.

Link to comment
Share on other sites

I'm comfortable with the ROM part. Tursi can speak to where he is with GROM, and the manual is pretty darn comprehensive. (I'd like to get XB and RXB working on it for a PoC.). Once Tursi is done, it just needs a sponsor or sponsors to get them made and sold. At that time, I can help provide guidance. Matthew got the last batch done, so he can provide input as well.

The GROM is done and has been for a while. The loader is nearly done, and I'm back on that.. well, right now actually. ;) Just resolving a DSR issue (yep! It's biting ME now. ;) ) We do have to figure out how the initial AVR programming will be done... I suppose I can do a number of them.

Link to comment
Share on other sites

The GROM is done and has been for a while. The loader is nearly done, and I'm back on that.. well, right now actually. ;) Just resolving a DSR issue (yep! It's biting ME now. ;) ) We do have to figure out how the initial AVR programming will be done... I suppose I can do a number of them.

 

I wouldn't mind doing the AVR initial programming for any planned board runs. My 844USB programs them well and has a "repeat" button on it. :)

  • Like 1
Link to comment
Share on other sites

The GROM is done and has been for a while. The loader is nearly done, and I'm back on that.. well, right now actually. ;) Just resolving a DSR issue (yep! It's biting ME now. ;) ) We do have to figure out how the initial AVR programming will be done... I suppose I can do a number of them.

Tursi why not put the DSR in GROM like a phoney device. It could load anything anywhere when called.

 

My old RXB PDISK used the Lower 8K as a storage device. I also wrote another that used the 8K of the VDP as a storage area for the EA Cart to load a Supercart for switching RAMs in the Cart.

 

Except I know that everyone wants to use a non GPL compatible DSR Link all the time like a ROM only DSR Link with Assembly only access. To bad it just make the project more impossible.

Link to comment
Share on other sites

Putting aside the bitter half.. ;) My problem isn't the DSR itself, it's the DSRLNK I'm using in my library. For some reason the problem /I/ have is that my DSRLNK works on Classic99 and doesn't do jack on hardware. I found one bug yesterday and fixed that, but just a little more digging is needed.

Link to comment
Share on other sites

Putting aside the bitter half.. ;) My problem isn't the DSR itself, it's the DSRLNK I'm using in my library. For some reason the problem /I/ have is that my DSRLNK works on Classic99 and doesn't do jack on hardware. I found one bug yesterday and fixed that, but just a little more digging is needed.

If ya would like another set (or sets) of eyes to help find the problem, feel free to post the code...

Link to comment
Share on other sites

And, picking on Rich's rant :grin: , any DSRLNK should include a search for GPL DSRs. It would be very cool to ship an entire cart with a virtual device in it - that would be possible with an appropriate DSRLNK that, say, searches the GROMs in the event that a ROM search doesn't find a matching device. That would be super-neat!

 

I'm planning to play with GPL this winter - doing too much guitar work at the moment, including building an electric guitar from scratch...

Link to comment
Share on other sites

Ideally, all that is needed to do that is to use the DSRLNK in the console. Thierry's page has some notes on how to do that, I will probably put that into my library.

 

Tim, thanks for the offer! I've got the tools I need to troubleshoot now, since it's been a mystery I've wanted to solve for about a year now. If I'm still stuck I will definitely pop it online to ask. :)

Link to comment
Share on other sites

Rasmus Inspired Scroll Demo

 

** Submitted with permission from Rasmus to use his graphics and map.

 

The rasmus_scroll.zip file contains an F18A version of the early scroll demo Rasmus did that eventually turned into his game Titanium. The F18A version uses the hardware scroll registers to pixel-scroll a tile screen in both the horizontal and vertical directions. A joystick is required and the fire button does not do anything.

 

The GPU is used to block-copy the tiles up or down one tile-row after 7-pixles of vertical scrolling. It is also possible for the whole screen to be scrolled before adjusting the tile data, but this is completely up to the designer. The GPU can copy the VRAM data 2-bytes at a time since it has direct 16-bit access to the VRAM, and the GPU also runs with a 100MHz clock so it is very fast.

 

ECM3 is used to get the same color depth as the GM2 bitmap mode that the original demo used, although ECM3 provides much more flexibility in color use since any pixel in the tile can be any of eight colors.

 

The ship was ripped from the ROM data (including the palette) of a popular coin-op video game from the 80's, so maybe you will recognize it (no, it is not Xevious, although that is one of my favorites too).

 

Classic99 was used for testing up until ECM3 was enabled, since Classic99 has the GPU implemented (and helped me find a bug in my GPU-copy code!) Classic99 does not have the scroll register support (at the time of writing this), but I could see the tile copy taking place and it was very cool since I had totally forgotten that Tursi had added some initial F18A support.

 

The nice thing about using the scroll registers is that the 9900 still has lots of time (and memory) to run a game rather than pixel scrolling. Still, what Rasmus did with the stock 9918A is incredibly impressive!

 

Sorry for not posting a video, I don't have my camera set up.

rasmus_scroll.zip

Link to comment
Share on other sites

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

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

good job guys... i love your work and passion :lust: :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://youtu.be/Fnlx7tXXZkY

Edited by ti99userclub
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...