Search the Community
Showing results for tags 'scrolling'.
Found 15 results
-
I am trying to do infinite scrolling in text mode. The idea is that screen is larger (twice) MAXWIDTH = 96 This is my DLI definition: dl_start dta DL_BLANK8 + DL_DLI dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 1)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 2)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 3)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 4)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 5)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 6)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 7)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 8)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 9)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 10)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 11)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 12)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 13)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 14)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 15)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 16)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 17)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 18)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 19)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 20)) dta DL_BLANK8 dta DL_BLANK8 + DL_DLI dta DL_MODE_40x24T2 + DL_LMS, a(SCREEN_BOTTOM) dta DL_JVB, a(dl_start) If I want to put character in visible part of the screen (while I am not scrolling the screen) I am having trouble. I have determined that I can put character within X position between 4 and 43. That leads to the problem to write a procedure to calculate sprite collision. cx:=43; cy:=20; addresscalc:=SCREEN_GAME + row_max[cy] + cx; // addresscalc:=SCREEN_GAME + cy * 96 + cx; Poke(addresscalc, SWARN); SWARN is a const for character #. As you can see cx=43 draws almost to the right. There is 1 character to the right, same situation is on left when I draw at cx=4. That is problematic when I try to understand and modify playfield after sprite and playfield collision. The question is how should I organize screen and calculate position from pixels to character position in playfield? I was trying to calculate cx and cy with cx:= ((missle_x - 48) div 4); cy:= ((missle_y - 48 ) div 4);
-
Hi everyone, A few of us (@Muddyfunster, @Synthpopalooza) were having a discussion about data compression and unpacking of data such as level maps and sound/tunes. I was doing a bit of study around the AA forum and came across some discussions here: https://atariage.com/forums/topic/316628-most-efficient-compression-for-atari/ https://atariage.com/forums/topic/291154-any-compressor-between-rle-and-lz4/ There appears to be a number of routines which might be useful some of which do have a 6502 conversion for other machines. I see the main feature having the ability to unpack stored data from ROM into RAM. For example both Millie & Molly and Exo have a huge amount of ROM set aside (eg. 1-2 banks!) for pokey music reducing our capacity to include more features etc. I see the process working as follows: Compress a binary data file using a command-line tool Convert compressed binary data in a data table To unpack - set the input (ROM) and output (RAM) pointers and process As an example I used the zx0 compressor to reduce 4096 bytes down to 680 bytes. Anyway, does anyone have any working examples which we could utilise in 7800basic? (assembly is fine for use in the backend) I feel this could be a really useful step for 7800 developers to have an ability to store compressed data. EXAMPLE CODE (currently LZ4, ZX0, ZX7) Thanks to @playsoft, @Eagle and @xxl for assisting with compression libraries and @RevEng for initial 7800basic compatibility 20220215.Compression.zip
-
I put together a description of implementing fine horizontal scrolling in BASIC with assembly code executed during the vertical blank. This is a pretty high-level description and is directed at those learning this for the first time. A simple demo is provided with BASIC code and assembly code explained. An ATR file is provided. Fine horizontal scrolling has a lot of moving parts and can be hard to understand for those who have not yet mastered it. I hope someone finds this take on it helpful. Comments welcome! Fine horizontal scrolling post from Atari Projects- 4 replies
-
- 3
-
-
-
- fine horizontal scrolling
- horizontal scrolling
- (and 4 more)
-
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
- 123 replies
-
- 14
-
-
I'm trying to troubleshoot a console I got off eBay. Video is scrolling, it's in black and white and also has static. It's hard to tell if I have any audio as well with the static. Any suggestions?
-
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
- 18 replies
-
- 10
-
-
- scrolling
- collision detection
- (and 1 more)
-
I've been playing around with bits for this game for over a year now but am struggling find the motivation to finish it. Leave some comments and spur me on to finishing this project. It's a platform game using some of the mechanics you'd expect from a modern platformer but to my knowledge there's nothing quite like this for the 2600. Find attached a demo of the basic physics/mechanics of the game. There is no goal at the moment you just have to keep moving up the screen to avoid death. It picks a new level every time you die. You can't lose and the level data repeats, I've got another file I'm working on with the level designer in it. COTC_Demo.bas.bin Controls: Fire - Jump Fire/Fire - Double Jump Fire - While on Wall - Wall Jump Up/Up - Fly Left/Left or Right/Right - Dash I've got plans well beyond what's in this demo. In the demo you can't lose and the level data scrolls. COTC_Demo.bas.bin
- 5 replies
-
- 3
-
-
- New game
- Platformer
- (and 2 more)
-
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.
-
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
-
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.
- 17 replies
-
- 1
-
-
- multi-sprite
- TI-99
- (and 2 more)
-
Does anyone know how the smooth scrolling in Warzone 2 was done? Are there other examples of games using smooth scrolling?
-
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
-
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
-
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
-
Posted on behalf of @ProfDrJWM
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord