Jump to content

Search the Community

Showing results for tags 'scrolling'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Atari Systems
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
    • Classic Gaming General
    • Classic Computing
    • Modern Gaming
    • Prototypes
    • Arcade and Pinball
    • Emulation
    • Hardware
    • Gaming Publications and Websites
    • International
  • Marketplace
  • Community
  • Game Programming
  • Site
  • Classic Gaming News
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • 3D Printing's Filament Reference
  • 3D Printing's 3D Objects
  • 3D Printing's Requests
  • 3D Printing's Chat

Blogs

There are no results to display.

There are no results to display.

Calendars

  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar
  • ZeroPage Homebrew's Schedule

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website


Facebook


Twitter


Instagram


YouTube


eBay


GitHub


Custom Status


Location


Interests


Currently Playing


Playing Next

Found 9 results

  1. This is a thread, dedicated to the RXB game called "TI Game Engine X". I wrote this game as entry for the programming contest that did occur until 31th July 2019. Since the time was running out a bit, I wasn't able to completely showcase its possibilities. First I will post the main program, its instructions again and then I will post a nice level for you.
  2. Ok since I've been letting yet another side project rot away for too long and I really don't know if/when I'll get back to it, here's another little demo as I fiddle with scrolling. In a nutshell the program uses plotmapfile to display full screens in 160A and the player can move about in 4 directions, going 1 full tile at a time. When you reach the edge of the screen that is connected to a different map, it will scroll that map in black and white to the new screen then flash the color back. There are only two screens in this program. The screen you start in, and the screen to the left of it. Any other screen edges you can reach are "dead" and won't trigger a change. There's a "template" tmx file included that's got the embedded tiles, etc all set up for adding new screens for playing around with. Additionally this demo includes collision detection between the player and the map tiles. Changing around the order of tiles in the tmx files would obviously mess around with the collision code so keep that in mind. Compiling instructions in a command/dos window are listed in the bank0c.bas file. As mentioned in that file feel free to use anything in the code in your own projects. And yes, I suck at drawing hero sprites. rpg7800.zip rpg.bas.a78 rpg.bas.bin rpg7800-fixed.zip
  3. Titanium is my first game for the Ti-99/4A written purely in assembly language. The name is a reference to the C64 game Uridium - a favorite of mine - from which I have borrowed many ideas, and, of course, to the TI. The game engine and the graphics on level 1 are based on my half-bitmap mode, vertical scrolling demo. (I would like to do a proper port of Uridium for the TI at some point, but that should be based on a different technique for the scrolling.) The game requires a disk drive, a 32K memory expansion, and a E/A cart or similar to run it. To start the game, insert the disk in any drive and use E/A option 5 to run DSKX.TITANIUM. I have not tried it with a real floppy drive, but I expect it to work. The gameplay is very simple: shoot all the targets, e.g. pyramids, to reach the next level. Avoid the blinking spheres and the enemy ships. Use joystick 1 or S, D, E, X + space to control the ship. P pauses the game. I don't know if it's too easy or too hard - it's difficult to tell when you have tried it so many times. This is the first game I'm aware that’s using the F18A, but only to avoid the sprite duplication issue that exists in the old VDPs (9918A, 9928A) in half-bitmap mode. If an F18A is detected the program uses a standard half-bitmap mode with only one pattern table. If an F18A is not present it uses three pattern tables, but still only one color table. This eliminates the problem on the old hardware, but also lowers the frame rate because it doubles the amount of data that must be sent to the VDP. If you press F on the start page you can manually switch between F18A mode and standard mode. This allows you to see the sprite duplication problem in action on the old hardware, and can also be used to increase performance on MESS where the F18A is not detected (the F18A is detected in Classic99). I'm using Tursi's mod player for the music on the start page. I tried to compose my own music, but it ended up sounding very similar to the Blade Runner, so I decided to use that as my main theme. Within the game I'm using my own, simpler sound player and excerpts from Bach's 'toccata and fugue in d minor' - a reference to Gyruss, which is another favorite of mine. I consider the game in its present stage a beta version. I welcome suggestions for improving the gameplay, but major additions at this point are likely to slow down the game. For now I will fix any reported bugs and release the first version, and in a month or two when I regain some energy I may release a version 2. More levels/maps could easily be added without affecting performance. I include the full source code and data files. The maps were created using Magellan, the music using mod2psg2. Thank you to everyone who has helped me on this project. It has been very interesting and a great learning experience, and I think it demonstrates that there's still some potential left in the old TI. [Edit 14 Aug 2013] Added version 1.0 attachment. Titanium_1.0.zip. An XB loader is now included, and the E/A 5 file is called TITA. 64K bank switched (379) ROM image: Titanium3.zip
  4. Trying to fit big game into small amount of memory tends to be hard. Trying to scroll large bitmap screen is even harder. That is where something like complex scrolling method that wastes no RAM comes in handy. During my recent experiments with AnalMux's MWP (minimum wrapping principle) scrolling, I think I found a better way to understand it. Basic principle is still the same, using two LMSs to wrap the screen so that used memory exceeds only slightly more memory than static screen. Here is the image of memory layout according to 'my way' There are maximum two LMSs used (first row is special case as only one LMS is needed). Scrolling right is done by increasing X, when X reaches the end -> X=0, Y=Y+1 Scrolling down is done by increasing Y. As you see on the image, there are only SCREEN_WIDTH-1 bytes added at the end of screen memory. Contents of these bytes need to be copies of 0..SCREEN_WIDTH-1 bytes. In the case of 3x3 size, bytes 9 and 10 are copies of bytes 0 and 1. LMS addresses and appropriate Mode lines should be easy to calculate from Screen height, Screen width, X and Y. Imho, this "add copy of first row to the right of last row" makes much more sense than the explanation with additional zero row in Ironman Wiki documentation. As I'm in middle of making a game with this, If anyone sees any fault in this reasoning please shout
  5. I’m having a few programming issues (which I don’t believe are related to the development language) that I thought I’d throw out to see if anyone has an idea. As per the attached DL fragment, I have set up a scrolling playfield using an entire page per line. As that the LMS instructions are set to the start of each page, and I write to the beginning of those pages, I have every reason to believe that the data I write should show up exactly at the left hand edge of the screen. It does not. The screen appears to be scrolled over 4 bytes to the right, and even with the LMS set to the start (0), I can’t see the start of the data. 112 ;blank lines 128 ;DLI 112 ;blank lines 194,192,63 ;text line 0 ;blank line 116,0,8 ;scrolling Antic 2 116,0,9 ;scrolling Antic 2 116,0,10 ;scrolling Antic 2 116,0,11 ;scrolling Antic 2 116,0,12 ;scrolling Antic 2 I can get around this issue by offsetting my writes by 4 bytes, but this issue continues to bug me. As per the attached executable, I’m getting some corruption on the right hand side of the playfield. Debug mode of Altirra shows nothing there. Code written to dump the locations shows zeros in that area, but apparently random $0F’s written and cleared throughout the lower part of RAM (under 10K) as well as the more stable phantom corruption at the far right. In the attached program, pressing “L” will print all non-zero locations between page 8 and page 32 – make sure Altirra’s printer is configured and activated. “L” will fill the same area with $03’s.You will notice that the three bytes of corruption at the right side cannot be over written. Any ideas for either of these issues would be very welcome! Thank you! TEST1.atr
  6. roland p suggested in another thread to use an interlaced display to achieve slow and smooth vertical scrolling. I remember that this had been proposed also for the Amiga back in the 80s, though I don't think I ever saw it in practice (it may be possible some PS2 titles do it implicitly when scrolling end credits, but I would have to check). So, I decided to give it a try on the 2600. I started with the sync routines from Billy Eno and Glenn Saunders' example. Unfortunately, I only have a PAL VCS/TV, and it turned out that while it in pricinple works, there are some problems with the colors. So I went doing it from scratch for PAL50 kernels after I found a description of how field synchronization works. For PAL this is similar to NTSC in that the sync for the second field starts half a line later, only that for PAL the sync is 2.5 lines long while for NTSC it's 3 lines (this is the interval m in the Field Synchronization diagrams). I used this timing to create a PAL50 demo showing smooth vertically scrolling text. Basically, the text graphics moves at 25Hz, but is smoothed by switching fields inbetween. I've tested this on several CRT TVs and it works even on a 40-something year old BW TV-set. It is, however, a very subtle effect. If you press the left trigger, interlace is turned off and you should be able to see the difference if you go close enough to the screen (if the VCS would have an RGB output and a less blurry image it would probably be more noticable). You can also try it in z26, but you may have to load the ROM a couple of times until the text moves slowly. There's also an NTSC version of this demo. I could not test it on an NTSC system. If someone with a Harmony can try it, please let me know if it still works there too. InterlaceScrollDemo_PAL50.bin InterlaceScrollDemo_NTSC.bin InterlaceScrollDemo.asm
  7. I've been tinkering with the samples included with 7800Basic, and because I'm going to want it eventually, I decided to try to get some horizontal scrolling working. I tried to get vertical scrolling as well, but naturally that failed. I did think of how to get some zelda-styled screen switching vertically but haven't actually tried to implement it yet. At any rate, after a couple weeks of slamming my head into a wall, yesterday I finally stopped and decided to rework the calculations I had done up for it that were causing... interesting results. I cleaned up the code a bit, and I'm sure it's not nearly as efficient as it could be, but it works! Feel free to use/modify/etc for your own games if you think it'll help. As you can see from the graphics used, I essentially built/expanded this from the adventurer.bas sample. scroll.zip scroll.bas.a78
  8. after a lot of interference from the real world and a lot of changing of my mind I have made some progress on the Parsec 2600. https://fieldmousetech.wordpress.com/ that is my tech blog and here are some youtube videos of the meteor and single enemy with scrolling meteors https://youtu.be/Gs8RheHNZmY 1 enemy scrolling test 1 enemy attack test https://youtu.be/sVYBqbyveJ4 I programming the thing in 16k multi-sprite kernel. The multi-sprite kernel does not allow sideways scrolling so i'm doing a lot of slight-of-hand to simulate the look of sideways scrolling. why I didn't use the other kernels is the standard kernel did not allow multiple items on the screen, which killed the swoopers. And the DPC+ kernel kept getting overwhelmed and crashing. I still have the swoopers to do, which I already have the code in the DPC+ and standard kernel and just port over. then the tedious task of gluing the whole thing together which will take a while. update: I think I just came up with a viable way to do a refueling tunnel. will preview soon.
×
×
  • Create New...