analmux Posted July 19, 2004 Author Share Posted July 19, 2004 (edited) Maybe when I can finish before 1st of august then I'll definitely take part in the ABBUC programming contest, and then the release of the game will be in october. Edited March 25, 2007 by analmux Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 19, 2004 Share Posted July 19, 2004 don't you need at least 960 bytes x 2 for the wrapper? Quote Link to comment Share on other sites More sharing options...
analmux Posted July 19, 2004 Author Share Posted July 19, 2004 (edited) don't you need at least 960 bytes x 2 for the wrapper? ....No, why ?? Edited March 25, 2007 by analmux Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 19, 2004 Share Posted July 19, 2004 thanks...i know the principle... but you building up the screen by putting strypes on "behind" the actual visible scrolling window and after scrolling f.e. 32 bytes (for narrow screen) you are switching back to the beggining where you have build the new one and start over again... that's exactly how it is done on gameboy (and i guess on SNES as well...) if you use just 1 screen are you then "hardscroll" manually which mean that you are moving the whole vram one char instead of "inc LMS"??? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 19, 2004 Share Posted July 19, 2004 here is my result from our conversation back in sept. '03 demo1.zip Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 19, 2004 Share Posted July 19, 2004 i guess one trick could be the 10bit adress counter of antic which means that wisely choosen of vram starting adress ("your scrolling window") it wraps automaticly... so you might not need 2 screens but as you mentioned one only... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 19, 2004 Share Posted July 19, 2004 and this "minimal wrapper" is best for rombased systems with shortage on vram... f.e. 5200 & 7800 & 600xl & 400. Quote Link to comment Share on other sites More sharing options...
analmux Posted July 20, 2004 Author Share Posted July 20, 2004 (edited) thanks...i know the principle... but you building up the screen by putting strypes on "behind" the actual visible scrolling window and after scrolling f.e. 32 bytes (for narrow screen) you are switching back to the beggining where you have build the new one and start over again... that's exactly how it is done on gameboy (and i guess on SNES as well...) NONONO. Heaven you're still on the wrong track. I know we have discussed the GBA scrolling method back in sept 2003, and that method is like what you did with your demo, but it still uses 2 screens, and two buffers (left and right buffer) to be able to switch back to the beginning after the end is reached. i guess one trick could be the 10bit adress counter of antic which means that wisely choosen of vram starting adress ("your scrolling window") it wraps automaticly No you're mistaken again. Antic can't cross 10bit (=1kbyte) boundaries when it reads displaylists (without jump-instructions). For videomemory it has 4kbyte boundaries (when no extra LMS's are used). It's so unlike my scroller. Edited March 25, 2007 by analmux Quote Link to comment Share on other sites More sharing options...
Cybernoid Posted July 20, 2004 Share Posted July 20, 2004 can you imagine the surface of a torus (or donut ): Certainly! This makes sense. I am using, I think, I similar trick with a game I am working on... well, mostly it is in the experimental stage, but I have written the scroll routine which uses LMS updates. For a normal playfield (40 chars), I have a buffer of 42x23 lines (play area of 40x20). You can scroll in all directions by generating the column to the left or right of the screen, or by generating the rows on top and bottom of the screen before you move there. A 42x23 screen only uses 966 bytes. Because of the way the LMS works, if you douplicate the top row at the bottom, you should be able to move everywhere as long as you can move the data into the area beforehand (say reading from disk, or decompressing or from modem...) Here is a small graphic I use to keep track: // 42 x 23 (50 x 23) // 1111111111222222222233333333334 4 // 0 1234567890123456789012345678901234567890 1 // +-+----------------------------------------+-+ //00|*|**************** 11*******************|*| // +-+----------------------------------------+-+ //01|*|**************** 12*******************|*| //02|*|**************** 13*******************|*| //03|*|**************** 14*******************|*| //04|*|**************** 15*******************|*| //05|*|**************** 16*******************|*| //06|*|**************** 17*******************|*| //07|*|**************** 18*******************|*| //08|*|**************** 19*******************|*| //09|*|**************** 202020202020202020202|0| //10|0|2020202020202020 -1-1-1-1-1-1-1-1-1-1-|1| //11|-|1-1-1-1-1-1-1-1- 00*******************|*| //12|*|**************** 01*******************|*| //13|*|**************** 02*******************|*| //14|*|**************** 03*******************|*| //15|*|**************** 04*******************|*| //16|*|**************** 05*******************|*| //17|*|**************** 06*******************|*| //18|*|**************** 07*******************|*| //19|*|**************** 08*******************|*| //20|*|**************** 09*******************|*| // +-+----------------------------------------+-+ //21|*|**************** 10*******************|*| // +-+----------------------------------------+-+ //22|*|**************** 11*******************|*| // +-+----------------------------------------+-+ This shows the whole screen memory, with the "00" showing the upper left corner with the "*" on screen. The -1 row is off the top of the screen and the 20 row is off the bottom. I can offset the LMS to scroll left, right, up or down, but the trick is to have the extra copy of the first row on the bottom.... I think this can be optimized further... --C Quote Link to comment Share on other sites More sharing options...
analmux Posted July 20, 2004 Author Share Posted July 20, 2004 (edited) Certainly! This makes sense. I am using, I think, I similar trick with a game I am working on... Ah..thank god someone understands. Yes this is almost the same as my MWP-scroller. This shows the whole screen memory, with the "00" showing the upper left corner with the "*" on screen. The -1 row is off the top of the screen and the 20 row is off the bottom. I can offset the LMS to scroll left, right, up or down, but the trick is to have the extra copy of the first row on the bottom.... Yes, I'm using the 0th line as duplicate. Edited March 25, 2007 by analmux Quote Link to comment Share on other sites More sharing options...
analmux Posted July 20, 2004 Author Share Posted July 20, 2004 Well, it's almost done now. I'll not post any progress anymore until it's finished. Today I've made a special level-exit effect (screen clipped by circles), and completed most of the debugged mechanics logic. We can off course continue the discussion here, but I cannot release the game here if I will take part in the ABBUC contest. ...and another thing: I'm soon moving to another town in the Netherlands, where I won't have internet for the coming period, as I'll be living on my own (23 years old, and leaving my parents house), so I might be quiet on the boards soon. ------------------------------ Super Mario Clone status: -levels & graphics: complete -music: most music still to be written -screen/scrolling engine: working -sprite engine: working better -playing routine: almost complete(mechanics working!) -title screen + level decompressor: ready Work already done (estimate): 93 % still working on: -sound effects -music -mario2playfield interaction -sprite-engine extras -some spriteshapes (almost all done) -one level with a bug -pipe&door redirections -enemylist generation -enemy movements Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 20, 2004 Share Posted July 20, 2004 guys, quite interestomg... analmux, i was looking into your display list code in your demo and have recognised that its not the GBA method you are using... weird.... i have to think about in more detail...but thanks for your explanation. i'll gonna search the programming forun... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 20, 2004 Share Posted July 20, 2004 just answer me one of my question: are you generating the screen every VBL? f.e. in super mario all the tiles after calcluation the new position of mario? if so... you would save cpu time with the GBA method? or am i here on the wrong track again? (if yes...then it reminds me up c64 scrolling...) Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 20, 2004 Share Posted July 20, 2004 http://www.atariage.com/forums/viewtopic.p...er=asc&start=25 just found it... what makes me confuse is the horizontal scrolling 1a,1b,1c... as i thought antic will "mess up" your screen layout... f.e. 333 could be a platform (1a) and when scrolling the platform is moving "up" as seen in 1b... ??? Quote Link to comment Share on other sites More sharing options...
Schmutzpuppe Posted July 20, 2004 Share Posted July 20, 2004 This scrolling approach looks interesting, I have to take a deeper look at it. You Super Mario Clone is really cool so far mux I hope you'll make it until the Abbuc deadline. Quote Link to comment Share on other sites More sharing options...
TXG/MNX Posted July 20, 2004 Share Posted July 20, 2004 ...and another thing: I'm soon moving to another town in the Netherlands' date=' where I won't have internet for the coming period, as I'll be living on my own (23 years old, and leaving my parents house), so I might be quiet on the boards soon. [/quote'] Hmm to which town are you movin' ? Just interested Quote Link to comment Share on other sites More sharing options...
Cybernoid Posted July 20, 2004 Share Posted July 20, 2004 A little difference: I cut out all LMS's except the 2 neccesary ones. It saves a lot of cpu-time to have to update only 2 instead of 22 LMS's. However your method really uses a minimum amount of memory' date=' and normal (40byte) screen. I guess you can still use the hscroll option of Antic. I'm using hscroll with narrow playfield, so my graphics lines are exactly 40bytes.[/quote'] Ah, this makes sense. I didn't think about using hscroll with narrow playfield, but this makes things work out nicely. You only have to update the first LMS (maybe one more) and all the other lines work out. With the narrow playfield you have a built-in buffer on the left and right, then if you add a few lines to your screen buffer, you have a buffer for the top and bottom. Nice!!!! Sure. As my MWP-scroller is fully working now' date=' you may have a look in the sourcecode soon.[/quote'] Thanks, I would like to see it... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 20, 2004 Share Posted July 20, 2004 cybernoid, can you send me some light regarding the wrapper??? how do you handle the "crippling" of the scanlines??? i mean if you scroll left you are updating the buffer collum.... but do each alter the copy order each time you are "hardscroll" to the left? f.e. copy 0-20 then 1-20,0 2-20,0,1 etc...??? Quote Link to comment Share on other sites More sharing options...
Cybernoid Posted July 20, 2004 Share Posted July 20, 2004 Hi Heaven. Okay, I read the previous thread on this method, and indeed, it looks like the method I came up with, but more optimized for speed. You only need to update 2 LMS lines (and of course any lines that cross the 4k boundary (or is that 1k?)... anyway, you can "skip over" those bad lines. I used this for my "ansiterm" program. Anyway, on to your questions. I am not sure what you mean by "crippling" of the scan lines. Can you explain a little more? Basically, if you want to move/scroll left, then you must first copy 22 chars of data (20 for the normal on-screen data, and 2 off-screen above and below. You copy this data starting at location (19,10), then (19,11), (19,12), ..., (19,22). Then copy the same char that was copied to (19,22) to (19,0). Continue copying, then update all the LMS values in the Dlist by decrementing by one. If you continue to scroll left, you must copy starting at (19,9), move left, copy at (19,8 ), move left, copy at (19,7), etc. So, yes, you modify the copy order. In my world, I have to update all the LMS, but for Analmux, he only has two. I like this better, and may update what I am doing. I think what may be confusing about the 3x3 squares drawn by analmux is that it shows the locations used, but when scrolling, you are constantly over writing what is stored within those locations. I think he has 4 columns on the left and right, so there must be enough time. I haven't tryed to move too fast yet in my RPG game, so I only have 2 column buffer on each side. I hope this makes sense, and I hope I understand analmux's method's correctly, but I can definitely see how this works. Also, I noticed that my picture shows the screen being 39 chars wide, not 40. It should look like this: // 42 x 23 (50 x 23) // 1111111111222222222233333333334 4 // 0 1234567890123456789012345678901234567890 1 // +-+----------------------------------------+-+ //00|*|***************** 11*******************|*| // +-+----------------------------------------+-+ //01|*|***************** 12*******************|*| //02|*|***************** 13*******************|*| //03|*|***************** 14*******************|*| //04|*|***************** 15*******************|*| //05|*|***************** 16*******************|*| //06|*|***************** 17*******************|*| //07|*|***************** 18*******************|*| //08|*|***************** 19*******************|*| //09|*|***************** 202020202020202020202|0| //10|0|2020202020202020* -1-1-1-1-1-1-1-1-1-1-|1| //11|-|1-1-1-1-1-1-1-1-1 00*******************|*| //12|*|***************** 01*******************|*| //13|*|***************** 02*******************|*| //14|*|***************** 03*******************|*| //15|*|***************** 04*******************|*| //16|*|***************** 05*******************|*| //17|*|***************** 06*******************|*| //18|*|***************** 07*******************|*| //19|*|***************** 08*******************|*| //20|*|***************** 09*******************|*| // +-+----------------------------------------+-+ //21|*|***************** 10*******************|*| // +-+----------------------------------------+-+ //22|*|***************** 11*******************|*| // +-+----------------------------------------+-+ Quote Link to comment Share on other sites More sharing options...
Cybernoid Posted July 20, 2004 Share Posted July 20, 2004 Ah, ha! I see that ANTIC will fetch 48 chars for a normal playfield, so if I increase my buffer size to be 48x23, you only have to load 2 LMS (one at the top of the screen and one at the wrap point) instead of at each line. As long as the screen memory doesn't cross a 4k boundary, then there should be no need for further LMS lines. I think Analmux is using this trick for narrow playfield, where the screen is 40x??. --C Quote Link to comment Share on other sites More sharing options...
Cybernoid Posted July 20, 2004 Share Posted July 20, 2004 If you continue to scroll left, you must copy starting at (19,9), move left, copy at (19,8 ), move left, copy at (19,7), etc. Whoops! This should read: If you continue to scroll left, you must copy starting at (18,10), move left, copy at (17,10), move left, copy at (16,10), etc. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 20, 2004 Share Posted July 20, 2004 can't wait to get back from work... to fire up xasm... i just played little bit with the analmux' demo... it's more clear now... the drawing is little bit misleading as you don't see the "buffers" and how they are filled through the frames... the sm3 demo increases the LMS from $f052 - $f170 = $122 bytes until you reach the right border... if you change the displaylist with at $f510 with 02 02 02 02 02 02 you can see how the screen is messed up but you see how the tiles are moving upwars (as i thought it must be because of the linear vram...) but it showed me that this messing up must be compensated by hand due to the copy order into the buffers... (hope so...) but again... a very clever and fast method indead and perfect for consoles... aeh... 5200, XE game systems... off topic: does anybody still knows "white lion"? i am just listening to the best off: "when children cry..." hahaha mike tramp at its best... Quote Link to comment Share on other sites More sharing options...
Cybernoid Posted July 20, 2004 Share Posted July 20, 2004 if you change the displaylist with at $f510 with 02 02 02 02 02 02 you can see how the screen is messed up but you see how the tiles are moving upwars (as i thought it must be because of the linear vram...) but it showed me that this messing up must be compensated by hand due to the copy order into the buffers... (hope so...) Ah, why wait until leaving work... Anyway, yeah the copy order must change. You must keep track of the (0,0) point anyway. If you know this, then you know where to start copying. Based on which direction you move, you know how to copy. If you follow my previous message, as you move left until you reach the left border you would start copying at (19,10), ..., (1,10), (0,10), (41,9), (40,9)... If you were looking at the memory and you moved left continuously, you would see your screen data square move left then wrap and move up a line, and so on. Moving up and down is much simpler. You would see the square just move up or down in the memory. I am glad, someone else has thought this through well AND it works well!!! Great work Analumx!!! Quote Link to comment Share on other sites More sharing options...
analmux Posted July 20, 2004 Author Share Posted July 20, 2004 (edited) just answer me one of my question: are you generating the screen every VBL? f.e. in super mario all the tiles after calcluation the new position of mario? if so... you would save cpu time with the GBA method? or am i here on the wrong track again? Yes, every VBL. First I read joyports, then compute mario's new position and displacement (subtract old from new position) and then the screen scrolls, all in the same frame. Heaven, can you explain why the GBA method would save time?? Edited March 25, 2007 by analmux Quote Link to comment Share on other sites More sharing options...
Shawn Jefferson Posted July 21, 2004 Share Posted July 21, 2004 I think I understand how you are handling this scrolling. You are using the fact that antic will "wrap" into the next line if you alter the LMS instruction to move 1 byte. So when you move your character to the right, you actually fill the LEFTMOST position of your screen buffer with the new data (one line down because of the wrap effect) instead of scrolling the entire screen and then filling the rightmost bytes. 000000000000 111111111111 222222222222 scrolling right: 000000000000 x11111111111 y22222222222 we will need to fill the "x" with the next data byte for line 0, and fill "y" with the next data byte for line 2, add one to the LMS at the top, and then display the new screen. So our new screen looks like this: 00000000000x 11111111111y 22222222222z and z is why you need an extra line at the bottom, and maybe one at the top too (?) that is off-screen. Is that right? It seems pretty clever, not using much screen memory and cuts down on LMS instructions and the need to adjust 23 lines of them. 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.