analmux Posted September 4, 2003 Share Posted September 4, 2003 but if you are using antic 4 (for your mario...) then i would even try to go for 256 bytes scanlines as you might gain cycles because of the clever moving/positioning routines... It could work out great, but I had to reserve a lot of memory for the program: 1500 bytes left for the screen, so it won't work for my mario. DATA: the 40 levels use 16 kB the program uses 16 kB the fonts use 5 kB the PMshapes use 3kB the music uses 4 kB additional data (tables and screens) 2 kB interrupt driver 1kB WORKSPACE: decompressed areas: 6 kB double PM base: 4 kB itemtables/enemytables: 2 kB effect buffer: 1.5 kB NOT USED ($D000-$D7FF) 2kB leaves 1.5 kB for screen. and 24 lines of 256 bytes are still 6144 bytes, that's a lot of memory. But if you don't use a one-loader strategy (I just wanted my game to be a one-loader ) you can make free more space. ----- mux Quote Link to comment Share on other sites More sharing options...
analmux Posted September 6, 2003 Share Posted September 6, 2003 Heaven...Sheddy... Do you get the principle of my scrolling??? Or is it still too vague?? The exceptional lines, which need a copy are one of the two: -the line that is highest in memory, so it doesn't connect to another line on the high end -the line just before a 4kB boundary. So f.e. an Antic 4 screen needs 1 extra line, because line 24 is highest in memory f.e. Antic E screen needs 2 extra lines, because there's a 4 kB boundary in the middle, and a highest line in the bottom. I've written a turbobasic demo, that shows this. It still has a few bugs (as the principle isn't even perfectly clear for me ) @ Heaven Did you solve the "Move_Window" error: BNE instead of BCC for incrementing a double byte??? ----- mux Quote Link to comment Share on other sites More sharing options...
Sheddy Posted September 6, 2003 Share Posted September 6, 2003 Heaven...Sheddy... Do you get the principle of my scrolling??? Or is it still too vague?? The exceptional lines, which need a copy are one of the two: -the line that is highest in memory, so it doesn't connect to another line on the high end -the line just before a 4kB boundary. So f.e. an Antic 4 screen needs 1 extra line, because line 24 is highest in memory f.e. Antic E screen needs 2 extra lines, because there's a 4 kB boundary in the middle, and a highest line in the bottom. I've written a turbobasic demo, that shows this. It still has a few bugs (as the principle isn't even perfectly clear for me ) @ Heaven Did you solve the "Move_Window" error: BNE instead of BCC for incrementing a double byte??? ----- mux Hi Mux, I get it - and the exception lines to deal with the 4K boundaries idea is brilliant! But since I haven't tried it yet, I'm still wondering what happens on the left and right edges. Sure, I get that you put data in from the "hidden" column every line, but what about when things are halfway hard scrolled? Surely without LMS to include the "hidden" column or some way to hide the very end pixels you get half of what's on the next line down, or half of what's on the line above - rather than the data scrolling in smoothly from the "hidden" column. It's probably just my lack of understanding - I haven't done much scrolling in conjunction with the hardware scroll registers. Show us the demo already ! Quote Link to comment Share on other sites More sharing options...
analmux Posted September 6, 2003 Share Posted September 6, 2003 Okay, here it is: There are 2 ATRs in the zip. It is actually the level-tester from my Mario game in Antic 4. put scrprinc.atr in drive 1 and bootsmp3.atr in drive 2. scrprinc.atr contains a turbobasic prog: type run "d:scrprinc.bat" to load the data and the program. When started the first time you MUST load a level, by holding start down (F4 in emulation). Enter an areanumber between 0 and 63. (drive 2 contains all the areas). When under emulation turn on Turbo (1500% speed) to speed it up, cause it's still just turbobasic, NO code. Scroll around in the levels (look f.e. at area 3, 13, 19, or 31), some of them are just horizontal. Most have horizontal and vertical scrolling. It doesn't stop at the boundaries, so expect some garbage. ----- mux Quote Link to comment Share on other sites More sharing options...
analmux Posted September 6, 2003 Share Posted September 6, 2003 Okay, here it is: There are 2 ATRs in the zip. It is actually the level-tester from my Mario game in Antic 4. put scrprinc.atr in drive 1 and bootsmp3.atr in drive 2. scrprinc.atr contains a turbobasic prog: type run "d:scrprinc.bat" to load the data and the program. When started the first time you MUST load a level, by holding start down (F4 in emulation). Enter an areanumber between 0 and 63. (drive 2 contains all the areas), other numbers might freeze you 8bit. When under emulation turn on Turbo (1500% speed) to speed it up, cause it's still just turbobasic, NO code. Scroll around in the levels (look f.e. at area 3, 13, 19, or 31), some of them are just horizontal. Most have horizontal and vertical scrolling. It doesn't stop at the boundaries, so expect some garbage. Bugs occur, when changing scrolling direction. I think it has something to do with the WriteBuffer part. ----- mux Quote Link to comment Share on other sites More sharing options...
Sheddy Posted September 6, 2003 Share Posted September 6, 2003 Okay, here it is: There are 2 ATRs in the zip. It is actually the level-tester from my Mario game in Antic 4. put scrprinc.atr in drive 1 and bootsmp3.atr in drive 2. scrprinc.atr contains a turbobasic prog: type run "d:scrprinc.bat" to load the data and the program. When started the first time you MUST load a level, by holding start down (F4 in emulation). Enter an areanumber between 0 and 63. (drive 2 contains all the areas), other numbers might freeze you 8bit. When under emulation turn on Turbo (1500% speed) to speed it up, cause it's still just turbobasic, NO code. Scroll around in the levels (look f.e. at area 3, 13, 19, or 31), some of them are just horizontal. Most have horizontal and vertical scrolling. It doesn't stop at the boundaries, so expect some garbage. Bugs occur, when changing scrolling direction. I think it has something to do with the WriteBuffer part. ----- mux Am I the only one having problems? All I get is boot errors with scrprinc.atr in drive 1. But bootsmp3.atr in drive 1 gets a nice super mario title screen - but crashes on F4.... Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted September 6, 2003 Share Posted September 6, 2003 I've remembered a C64 game that I say on a telly in shop when I was a teenage at college (long time ago). I never knew its name until reading though my old C+VG mags that I've recently dragged out of my parents loft. Que-Dex by Thalamus : This has some quick scrolling and it also has a fixed section to the right. How is that done? (Great game BTW - an A8 is up to this) Quote Link to comment Share on other sites More sharing options...
TMR Posted September 6, 2003 Share Posted September 6, 2003 Que-Dex by Thalamus : This has some quick scrolling and it also has a fixed section to the right. How is that done? Hardware sprites with splits to move them down the screen. Matching what the C64 does there exactly would be quite difficult; it's using about four sprites and splitting all their colours (the ball uses the remaining sprites and is overlaid hi-res sprites) and the scrolling is half pixel res horizontally to give some very fine control. But something similar is do-able, it'd just be easier to write most of it from scratch and port the graphics and map data. Quote Link to comment Share on other sites More sharing options...
analmux Posted September 6, 2003 Share Posted September 6, 2003 Hi Sheddy, I'm terribly sorry. Try the link to the "better graphics" thread below. I've posted a message there on [Wed Aug 06, 2003 4:13 pm] from which you can download another ATR. It's a bootable DOS2.0 ATR, and it has turbobasic (type L turbobas.sys ). After booting up turbobasic, open scrprinc.atr in drive 1 and bootsmp3.atr in drive 2, and just type the Turbobasic command: RUN "D:SCRPRINC.BAT" RUN Don't forget to load an area. Hold start F4 when typing "RUN ". have fun p.s. the bootsmp3.atr is the bootable com-file, like it will be on the final version, with the needed data optimizations: I can compress the leveldata further from 24 kB to 16 kB. ----- mux http://www.atariage.com/forums/viewtopic.p...r=asc&start=175 Quote Link to comment Share on other sites More sharing options...
Sheddy Posted September 7, 2003 Share Posted September 7, 2003 Hi Sheddy, I'm terribly sorry. Try the link to the "better graphics" thread below. I've posted a message there on [Wed Aug 06, 2003 4:13 pm] from which you can download another ATR. It's a bootable DOS2.0 ATR, and it has turbobasic (type L <return> turbobas.sys <return>). After booting up turbobasic, open scrprinc.atr in drive 1 and bootsmp3.atr in drive 2, and just type the Turbobasic command: RUN "D:SCRPRINC.BAT" RUN Don't forget to load an area. Hold start F4 when typing "RUN <return>". have fun p.s. the bootsmp3.atr is the bootable com-file, like it will be on the final version, with the needed data optimizations: I can compress the leveldata further from 24 kB to 16 kB. ----- mux http://www.atariage.com/forums/viewtopic.php?t=29511&postdays=0&postorder=asc&start=175 Thanks, that works now. Silly me - of course I needed to have turbobasic to start with! Now to check it out. Quote Link to comment Share on other sites More sharing options...
Sheddy Posted September 7, 2003 Share Posted September 7, 2003 Oh! You are in narrow screen mode with LMS every line - so you are in effect hiding the end pixels to avoid the ends of a line showing the line above or below Very nice by the way. I'm looking forward to a game based on this already. Must have taken a while to get that level data done! 1 Quote Link to comment Share on other sites More sharing options...
analmux Posted September 7, 2003 Share Posted September 7, 2003 Hi Sheddy. You noticed , indeed I use LMSs on every line, but note also that I used Horizontal Finescroll enables in the LMS graphicstype command $54. When it's narrow screen, AND you enable finescrolling you have 4 characters extra on the left AND the right that are not displayed, so you have 32 + 4 + 4 = 40 bytes per line: Also note that Antic is designed in a way you can make buffer areas. Off course when you have a 40byte screen with finescrolling you'd have a 48byte screen without LMSs. Now, note that the LMSs of consecutive antic 4 lines (in my DList) are mapped at exactly 40 bytes away from each other. So the LMSs can be taken out when the principle is debugged. Only on the exceptional lines and the start of screen you'd need the LMS. I've been working on this game for years. I started in 1995 and in the passing years I now and then added data. At the time I didn't plan to add music, just some beeps. I wrote a leveleditor to speed up the development. Now ALL levels are done, and I must focus on coding. Now I found the atari community I have something to work for. ----- mux 1 Quote Link to comment Share on other sites More sharing options...
Sheddy Posted September 7, 2003 Share Posted September 7, 2003 Hi Sheddy. You noticed , indeed I use LMSs on every line, but note also that I used Horizontal Finescroll enables in the LMS graphicstype command $54. When it's narrow screen, AND you enable finescrolling you have 4 characters extra on the left AND the right that are not displayed, so you have 32 + 4 + 4 = 40 bytes per line: Also note that Antic is designed in a way you can make buffer areas. Off course when you have a 40byte screen with finescrolling you'd have a 48byte screen without LMSs. Now, note that the LMSs of consecutive antic 4 lines (in my DList) are mapped at exactly 40 bytes away from each other. So the LMSs can be taken out when the principle is debugged. Only on the exceptional lines and the start of screen you'd need the LMS. I've been working on this game for years. I started in 1995 and in the passing years I now and then added data. At the time I didn't plan to add music, just some beeps. I wrote a leveleditor to speed up the development. Now ALL levels are done, and I must focus on coding. Now I found the atari community I have something to work for. ----- mux Well Mux, thankyou for the lesson today - I had totally forgotten (or maybe never knew) that Antic retrieves more bytes when the fine scrolling is enabled! In fact I had to double check to make sure I could believe my eyes - and here it is, in De Re Atari - chapter 6. My well thumbed copy of "Mapping the Atari" doesn't seem to mention this at all. This is just such a great way of doing scrolling - and it looks like that was how it was intended to be done all along. I'm sure everyone here wishes you well on this project. I found the same encouragement here last year - After years of being "in the wilderness" with my project, it was like coming home to a warm reception. Only problem is, there's less excuse not to finish, now everything's in the open! 1 Quote Link to comment Share on other sites More sharing options...
analmux Posted September 7, 2003 Share Posted September 7, 2003 @ Sheddy You can always apply the same technique with a non-finescrolling display, like your Space Harrier. Just keep HSCROL = 0, but you'd gain the invisible buffer area. By the way, did you notice how my marioscroller is masked by PMg for the vertical buffer?? I think there are some lines in the DList setup part of my program (151,152,153) with REMs in it. Take the REM away, and put a REM before the line in which address 560 is changed. Then you must see a gr. 0 screen without scrolling, but you see the buffers being drawed. ----- mux Quote Link to comment Share on other sites More sharing options...
Sheddy Posted September 7, 2003 Share Posted September 7, 2003 @ Sheddy You can always apply the same technique with a non-finescrolling display, like your Space Harrier. Just keep HSCROL = 0, but you'd gain the invisible buffer area. By the way, did you notice how my marioscroller is masked by PMg for the vertical buffer?? I think there are some lines in the DList setup part of my program (151,152,153) with REMs in it. Take the REM away, and put a REM before the line in which address 560 is changed. Then you must see a gr. 0 screen without scrolling, but you see the buffers being drawed. ----- mux I thought exactly the same. I'm already using widescreen in SH - but I'd get a couple of missiles back with the fine scroll on. (Still need some missiles as the screen is not tall enough to look right at normal width) I hadn't noticed the PMg - I'll have to have a closer look at how everything is working! Quote Link to comment Share on other sites More sharing options...
Jetboot Jack Posted September 10, 2003 Author Share Posted September 10, 2003 Has anyone done Antic E/D software sprites without using 2 screen buffers -- I have to assume that cart games that used Antic E -- Donkey Kong, Galaxian, Gremlins etc, don't double buffer -- 'cos they run in 16K... sTeVE Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 10, 2003 Share Posted September 10, 2003 steve, actually if you're sprite routines are fast enough to deal in 60fps than you don't need double buffering... as DK flickers little bit it does not double buffer... can you remember our timepilot conversation? it's like zone ranger from activision (why not on GBA or 7800???) does not double buffer either... just quick copy routines.... that's all hve Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 10, 2003 Share Posted September 10, 2003 ah sorry steve, to answer your question... yes... i have done this or started... and made some experiences... seach for timepilot post here at atariage and www.s-direktnet.de/homepages/k_nadj/timepilot.html hve Quote Link to comment Share on other sites More sharing options...
Jetboot Jack Posted September 11, 2003 Author Share Posted September 11, 2003 Hve, Thanks for reminding me... sTeVE Quote Link to comment Share on other sites More sharing options...
Allas Posted April 7, 2009 Share Posted April 7, 2009 errors found... check the "move window" routine... the pseudo opcode might not generate the code i thought and mess up the display list. that's mainly the reason for getting messed up... next bug is putting the vram to $x010 and therefore causing 4k boundary display errors as mux pointed out...so i changed the scanline length to 128 bytes... and it seem to help a lot...still some weird pixels but now it's more visible how the whole stuff works... now imagine that the "color bars" are pure antic e gfx like mario background etc... and you got it... mux, can you give me kind of starting adress for the vram...to avoid these 4kblock restriction??? (i was never good at maths... ) hve/tqa demo1.zip In this demo the upper section of scrolling bars show noise along the middle. I notice when Atari scroll vertical bars, this noise effect appears. There is some way to avoid this noise? Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 7, 2009 Share Posted April 7, 2009 Make sure you're storing to the HSCROL register during the offscreen area... ideally you'd just do it during VBlank. For multiple scrolling areas, just use DLIs in strategic places. Only tried it in the emulator - also don't trust the emulator because it's not necessarily frame-synced with what your monitor's doing. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 8, 2009 Share Posted April 8, 2009 huh? code snippets by me dated 2002? cool.... Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.