MaPa Posted October 3, 2008 Share Posted October 3, 2008 that is exactly what I do not get yet... filling the buffers in an easy way means calculating the buffer adresses. The code already calculates LMS's addresses (top let corner of screen too), it's not so difficult to get upper/bottom/left/right buffer addresses from that point. Quote Link to comment Share on other sites More sharing options...
+Philsan Posted October 3, 2008 Share Posted October 3, 2008 Regarding 8 way scrolling games, do you think that Rally Speedway is the best overhead racing game doable or is it possible something like TOCA Touring Car Championship for GameBoy Color? Obviously not at the same graphic level but with isometric view and one or two other cars. By the way, this game has an excellent playability. Quote Link to comment Share on other sites More sharing options...
analmux Posted October 3, 2008 Share Posted October 3, 2008 OK guys. Some things from the past: Description: • smd.atr : "Scrolling MCS Demo", with hardsynth track. Scrolling MCS I wrote back in 2004 to show some possibilities to use PMG underlays for scrolling. Note: it's in all 8 directions I didn't apply any wrapping though. The whole level is layed out uncompressed in memory (it's 20 kB) • sm3.atr : "Super Mario Clone", also with the same hardsynth track. Here I applied MWP principle succesfully. • mwp.txt : "Minimum Wrapping Principle" It is a part of my sm3 engine. Unfortunately I forgot how it exactly links to the other parts of my code. MWP has a few disadvantages. It takes minimum memory (which was the reason for me to design it that way), but takes some CPU time now and then. Indeed (like Heaven pointed out) there's some non-trivial code needed to fill the buffers in the right manner. Quote Link to comment Share on other sites More sharing options...
Oswald Posted October 3, 2008 Share Posted October 3, 2008 hmm I think I get it. one sets 'lms' for each char row, so scrolling up down and wrapping only one char line around is easy. the tricky part is that scrolling horizontally will mix up the char rows fex.: start: aaaaaaaaaaaaa bbbbbbbbbbbbb ccccccccccccccc scrolled to right: ccccaaaaaaaaa aaaabbbbbbbbb bbbbcccccccccc thos updating left/right side gets tricky. nice idea. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted October 3, 2008 Share Posted October 3, 2008 it's one of the hardest scroll methods I am aware off... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted October 3, 2008 Share Posted October 3, 2008 (edited) Oswald...you are not 100% right... the display list is build with 2 LMS while one remains at the top of the display while the second is written directly into the display list slotes and moved in the disiplay list plus updated while scrolling in y-direction... the size per scanline is 24 bytes (scrolling enabled so 4 buffer bytes automaticly added) Edited October 3, 2008 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
MaPa Posted October 3, 2008 Share Posted October 3, 2008 (edited) hmm I think I get it. one sets 'lms' for each char row, so scrolling up down and wrapping only one char line around is easy. the tricky part is that scrolling horizontally will mix up the char rows fex.: start: aaaaaaaaaaaaa bbbbbbbbbbbbb ccccccccccccccc scrolled to right: ccccaaaaaaaaa aaaabbbbbbbbb bbbbcccccccccc thos updating left/right side gets tricky. nice idea. No LMS for each char row, only 2 LMS for whole display, one obviously at the start of DLIST and the second at the point where the data in memory wraps at the begining of block of videoram. Ha, Heaven was faster... and as he wrote about 24 bytes.. it depend's on the graphics mode and screen width of course, but in the demo it is 24. Edited October 3, 2008 by MaPa Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted October 3, 2008 Share Posted October 3, 2008 hmmm.... in theory MaPa is right... we know the left corner, add +24 so we have the start of the right buffer and then go down writing the buffer with +24? but where is then the trick??? maybe it is like with fixed point maths... i thought it is a miracle and i am too stupid to understand but at the end it was nothing to think about... Quote Link to comment Share on other sites More sharing options...
MaPa Posted October 3, 2008 Share Posted October 3, 2008 hmmm.... in theory MaPa is right... we know the left corner, add +24 so we have the start of the right buffer and then go down writing the buffer with +24? but where is then the trick??? Yes, the right buffer is somewhere there, and then "just" add +24 and so on.. and where is the trick? You fill ie. the right buffer down but not whole height of screen but only part of it, till it wraps around and you have to wrap buffer too and start from top of video memory block and fill the rest. And another trick is to not break your brain while coding it all together and make it work correctly Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted October 3, 2008 Share Posted October 3, 2008 Hello folks, this is what I have from the once so glorious "Super Mario 3" project by analmux... not much and maybe not the sources that you were searching for, but anyway... -Andreas Koch. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted October 3, 2008 Share Posted October 3, 2008 (edited) Mapa... where do you know where it wraps??? so i guess every 24 chars? (so 1 screen) look, in this version you should only press left... the demo fills only the right buffer from top do down with the x-offset (mwpx) as charcode. but when 1 screen scrolled you see how the fill-collum-buffer would need to be adjusted to get that correct... and when scrolling in the other direction try to imagine how you would fill up the buffers...if you can tell me the rules... thanks for letting me know... ps. the original code by Gauntman seems to have a bug? in the original demo he writes a counter directly into the screen ram where the char is changing but when scrolling to the right the char jumps at a special position... mwp1.zip Edited October 3, 2008 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
MaPa Posted October 3, 2008 Share Posted October 3, 2008 Mapa... where do you know where it wraps??? so i guess every 24 chars? (so 1 screen) look, in this version you should only press left... the demo fills only the right buffer from top do down with the x-offset (mwpx) as charcode. but when 1 screen scrolled you see how the fill-collum-buffer would need to be adjusted to get that correct... and when scrolling in the other direction try to imagine how you would fill up the buffers...if you can tell me the rules... thanks for letting me know... ps. the original code by Gauntman seems to have a bug? in the original demo he writes a counter directly into the screen ram where the char is changing but when scrolling to the right the char jumps at a special position... Yes, there is a "bug" in original code, but there are not any buffers at all, just scrolling around the ram window. Left/right buffer you just fill fromtop to down from "LMS" or "LMS+24" to down, but not whole screen height but only screenheight-mwpy bytes, then it wraps around and fill the rest (mwpy bytes) from top of video ram window (or say from first possible line). Whenever you reach the wrap point in X axis (one screen width, then it just resets mwpx and increment mwpy), you need copy first line to the last and vice versa, depending on which direction you were scrolling (left/right). Really hard to understand, at least it was for me, and even harder to code it properly Quote Link to comment Share on other sites More sharing options...
Shawn Jefferson Posted October 4, 2008 Share Posted October 4, 2008 (edited) that is exactly what I do not get yet... filling the buffers in an easy way means calculating the buffer adresses. I'm currently "playing" with MWP (why is it called Mininum Warp Principal?) for a project. It's really an elegant technique, I'm suprised it wasn't discovered earlier. I know what you mean about calculating the buffer addresses, and I haven't gotten to that point yet, but I will have to tackle it soon. I'm thinking probably some sort of lookup table based on the mwpy and mwpx variables? Hmmm, reading more of the messages and it seems a lookup table won't be possible for left and right edges, or at least the lookup table will be very big. Edited October 4, 2008 by Shawn Jefferson Quote Link to comment Share on other sites More sharing options...
Oswald Posted October 4, 2008 Share Posted October 4, 2008 why only 24 chars wide ? it wouldnt work in a wider version ? its also strange why 4 chars is added as side buffer. c64 covers 2 chars for horizontal and 1 char for vertical fine scrolling, and nobody knows why the hell they made it 2 chars in for horizontal. 1 char size going under borders is enough in either case. as for my wrong lms assumption, thats me not knowing a8 video chip enough similar scroll technique can be done on the c64, only it really needs HW tricks, and it comes with a disadvantages: the hw trick will take away 4 chars from the visible screen height and as the sprite gfx data pointers are located normally at the end of the screen being invisible (screen+$03f8) due to the wrapping around they become visible it is possible to hide the garbage they represent as chars/color memory (depending on the mode) but its awkward to work with that. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted October 4, 2008 Share Posted October 4, 2008 (edited) Oswald, you can make each scanline as long as you wish til max. 4096 bytes. this is the maximum antic can read per internal adress counter. here you have to know that we are using a simple "Graphics 1" (basic mode) screen which normally takes 20 bytes per line in normal mode, 16 bytes in narrow mode and 24 bytes in overscan mode (antic calles that mode6, thats why you see $x6 in the display list). when enabling Hscroll and vscroll bits ($3x) antic reads automaticly for hscroll 4 chars more per scanline (left border, right border). look at http://www.atariarchives.org/dere/ in the antic and scrolling section. as we are using mode6 (chars = double size in x). hscroll tells antic only to "skip" x-amount of colour clocks (pixels on screen) in that line and to start drawing after that. same to vscroll, skipping amount of scanlines to draw. so... yes, you are right...it would be enough to read less buffer bytes but remember that you can enable "wide playfield" = overscan mode which removes the border by design... so here you would need to read more bytes per line and i guess that's the reason why they read 48/24 bytes when hbit is set in dlist graphics commands and not 42/22. Edited October 4, 2008 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
Oswald Posted October 4, 2008 Share Posted October 4, 2008 still dont get it. you can have only 20 chars in a line in basic ?! dont think so, how come 20 bytes is enough for a line then? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted October 4, 2008 Share Posted October 4, 2008 Oswald... why not? http://www.atariarchives.org/dere/chapt02.php#H2_3 Quote Link to comment Share on other sites More sharing options...
MaPa Posted October 4, 2008 Share Posted October 4, 2008 I think that the word Warp in MWP in the demo is just misstyped word and should be Wrap. I was "playing" with this method too, trying to develop it myself but then I found this demo and started from it, learn it, understand it, adapted to antic mode 4 (char mode 160x192), added filling the buffers from map data... it was really pain Everytime I thought it's ok, in some cases there were graphics errors on screen etc. but finally I got it working. Really nice scrolling method with minimal memory resources, but when you are trying to do soft sprites then, another wird coding comes, the sprites wraps around too, have to write more complicated slower code etc. Maybe there is some elegant way but I didn;t figure it out yet. Regarding to antic fetching more bytes, I think it has to fetch that many more bytes to cover whole HSCROLL range. Hscroll can be 0-15 color clocks, so it is 4 bytes in 40 bytes wide screens and 2 bytes in 20 bytes screen. Of course symetrically on both sides. Quote Link to comment Share on other sites More sharing options...
analmux Posted October 4, 2008 Share Posted October 4, 2008 (edited) ... Edited October 10, 2008 by Analogue Multiplexer Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted October 4, 2008 Share Posted October 4, 2008 mux... but a source code without any comments... Quote Link to comment Share on other sites More sharing options...
Oswald Posted October 4, 2008 Share Posted October 4, 2008 I still dont get it why it is a good idea to have a screen in a game on atari which has les chars than a vic20 ?! Quote Link to comment Share on other sites More sharing options...
MaPa Posted October 4, 2008 Share Posted October 4, 2008 I still dont get it why it is a good idea to have a screen in a game on atari which has les chars than a vic20 ?! Are you pointing at that 24 bytes line width? It is mentioned just in case of that demo I linked here. It uses text mode with bigger characters, so only 20 (24 with hscroll) bytes per line. You can freely use any mode you want. For a game you would use charmode with 40 (48) bytes per line for example. Quote Link to comment Share on other sites More sharing options...
olavese@online.no Posted October 4, 2008 Share Posted October 4, 2008 Zone Ranger does not scroll... Seriously? Do I remember so wrong ... After you enter some zones ... I seem to remember flying through some "tunnels" in lack of a better word ... Hmmm ... I know I am getting old ... Oh, well Quote Link to comment Share on other sites More sharing options...
Shawn Jefferson Posted October 4, 2008 Share Posted October 4, 2008 mux... but a source code without any comments... It's difficult to follow other people's code sometimes with no comments, especially an optimized routine... That's why I was going from the source that Gauntman had posted. Also, I think the typo "warp" versus "wrap" comes from there. Speaking of that, what is the bug in that code that you guys had found? I'll take a look at the code you posted, Analog and see if I can figure it out. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted October 4, 2008 Share Posted October 4, 2008 Oswald... why using 20 bytes screens... well... artistic freedom... i know...you as vic2 child...you know only 40/38 chars screens plus colour ram... 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.