TMR Posted July 2, 2003 Share Posted July 2, 2003 But why is the scrolling of the ANTIC smoother than on C64 VIC? They're pretty much the same unless you're doing a speed the ANTIC can't handle, like two and a half pixels a frame... Link to comment Share on other sites More sharing options...
emkay Posted July 2, 2003 Share Posted July 2, 2003 But why is the scrolling of the ANTIC smoother than on C64 VIC? They're pretty much the same unless you're doing a speed the ANTIC can't handle, like two and a half pixels a frame... I remember - back in time - I had a C128 for 14 days at home .... Games like Sanxion were played testet and compared with XL/XE games. We all saw the more in colors and heared the better Music. But everyone agreed, that the scrolling of the C128 was too harsh compared to the - soft like butter - scrolling of the XL that had a kind of analog touch... Link to comment Share on other sites More sharing options...
Sheddy Posted July 2, 2003 Share Posted July 2, 2003 OK guys, these ideas could be brilliant for static pics and maybe fairly low CPU usage games - what's the best way to get more colours with lots of software sprites, without sacrificing all the sprites too???... (not that I have anything particular in mind ) Link to comment Share on other sites More sharing options...
emkay Posted July 2, 2003 Share Posted July 2, 2003 Sheddy It would be nice to concentrate on the fixed picture creation. To answer your question: Only the fullscreen DLI will gain the most speed to any game. Therein it is possible to change colors, to multiplex PMg, to build timed screenmovement- and soundroutines... If it was truely possible to gain good assembler coders to create editing tools for a fullscreen DLI for pictures, it would be no problem to develop software in this way.... But, if there is no beginning ... there is no ending Link to comment Share on other sites More sharing options...
TMR Posted July 2, 2003 Share Posted July 2, 2003 I remember - back in time - I had a C128 for 14 days at home .... Games like Sanxion were played testet and compared with XL/XE games. We all saw the more in colors and heared the better Music. But everyone agreed, that the scrolling of the C128 was too harsh compared to the - soft like butter - scrolling of the XL that had a kind of analog touch... Hmm, i ran an 800XL and a breadbin C64 next to each other for a couple of years and i can't say that i noticed a difference... Link to comment Share on other sites More sharing options...
Bryan Posted July 2, 2003 Share Posted July 2, 2003 i'm only going by the sketchy research i did, feel free to check me but i've never seen anything in 160x192 scroll half a pixel on the Atari...? You are correct. You may only scroll by 1 160th at a time. -Bry Correct. But why is the scrolling of the ANTIC smoother than on C64 VIC? I don't know what the scrolling options are on the VICII, but I recall a lot of games flashing the first row of chars while scrolling on the 64, as if it had to scroll in blank space. Lemme get out my 64 book... Okay, you can clip off a left and right character (38 visible) to hide H scrolling. You can clip off the first or last row for V scrolling (24 visible). Your screen shrinks, it seems. On the Atari, any line of gfx can come from anywhere in memory, and full H & V overscan are supported. Not only can scrolling take place, but also any random amount of line duplication/reordering. Dropzone uses this trick to move the logo around and stretch it. -Bry Link to comment Share on other sites More sharing options...
Jetboot Jack Posted July 2, 2003 Author Share Posted July 2, 2003 Scrolling and most importantly video memory management are a lot more sophisticated on Atari than C64 -- much more flexible display structure and control... But back to making great static bitmap type pictures (well at least at first Sheddy)... I looked at several FLI and IFLI demos on a real C64 (its so ugly under emulation its not worth it) over the last couple of days -- gotta say its kinda flickery I'm not really sold on it now I see it... But the normal lotsa color stuff still looks really nice, except the colors are pretty grim as usual -- could this image be done with MCS on the 8bit I wonder??? I could see this with better color choice looking VERY good, but so many colors per line sTeVE Link to comment Share on other sites More sharing options...
emkay Posted July 2, 2003 Share Posted July 2, 2003 I could see this with better color choice looking VERY good, but so many colors per line Steve Where is the problem? You have 9 colors in MCS. With a fullscreen DLI you have up to 11 additional colors available (and more if needed). C64 has 16 real colors, that are shown in your picture. The ATARI can display about 20 Colors in a scanline and - as written before- the colors can be changed every scanline too. So you have the possibility to use 128 flicker free colors in a picture anyway. The most interesting thing is, that there would be pictures possible that can be build by 128 colors.... So you can create real chrome effects by the higher resolution and using the brightness variations horizontal and verticallly. Link to comment Share on other sites More sharing options...
TMR Posted July 2, 2003 Share Posted July 2, 2003 I don't know what the scrolling options are on the VICII, but I recall a lot of games flashing the first row of chars while scrolling on the 64, as if it had to scroll in blank space. Lemme get out my 64 book... A lot of games...? i can only think of a couple of very old titles off the top of my head and that certainly doesn't equate to a lot... Okay, you can clip off a left and right character (38 visible) to hide H scrolling. You can clip off the first or last row for V scrolling (24 visible). Your screen shrinks, it seems. Yup. On the Atari, any line of gfx can come from anywhere in memory, and full H & V overscan are supported. On the C64, horizontal overscan is done with sprites and very tricky to time (sideborders need cycle precise adjustments to the horizontal smooth scroll register on every rasterline the border is open) and it's only possible to put sprites in the upper and lower borders. Interestingly, the Commodore Plus/4 can put graphics in the upper and lower borders fairly easily and has no hardware sprites. Not only can scrolling take place, but also any random amount of line duplication/reordering. Dropzone uses this trick to move the logo around and stretch it. An FLD/FLI variant called FLP can do that on the C64, there are examples of flex effects running with FLI images or in the sideborders as well. Link to comment Share on other sites More sharing options...
Jetboot Jack Posted July 2, 2003 Author Share Posted July 2, 2003 Emkay, MCS gives 9 colors per scaline I thought, how does that get us 20??? If we were to horizontally multiplex the sprites and change their colors we could maybe get 13 colors per line, or attempt to do a midline color kernal to give us new colors in the playfield or use overlapping sprites to get 11 colors per line.... But this image uses more than that, look at this expanded line from the image: Link to comment Share on other sites More sharing options...
emkay Posted July 2, 2003 Share Posted July 2, 2003 Emkay, MCS gives 9 colors per scaline I thought, how does that get us 20??? If we were to horizontally multiplex the sprites and change their colors we could maybe get 13 colors per line, or attempt to do a midline color kernal to give us new colors in the playfield or use overlapping sprites to get 11 colors per line.... But this image uses more than that, look at this expanded line from the image: One scanline is build like: 0123456789012345678901234567890123456789 Bytes And you have the possibility to write programs in that time.... The first line has to be build after a WSNYC. After this WSYNC, every command has its exact timing to the scanline until the DLI is ended. So in the next line something similar like this is possible: 0123456789012345678901234567890123456789 LDA 0 STA$ LDA 2 STA $ LDA 4 STA $ .................|.................|..................| from here col 4 is available .................|.................|from here is color 2 available .................|from here color 0 is available On the real machine more colors or PLAYER positions are possible to change. Outside the viewable range (the border) it is possible to pre-change colors for the next line, and not to wait with a new WSYNC By gaining of the available 9 colors, it is not necessary to change the colors as often, than with only 4 colors and playerpositions can be set by blocks and the 5th color of the color font, can be used by inverting every 4x8 pixel. This looks complex, but pictures that are possible with a fullscreen DLI can be very much more complex. Link to comment Share on other sites More sharing options...
Jetboot Jack Posted July 2, 2003 Author Share Posted July 2, 2003 Yup, that's what I'm, driving at -- kick off a display then use tight timing loops, not DLI, to stuff colors into registers for midscanline changes etc... In effect a display kernal, I think its possible to change one color register every 16 pixels -- which would give 18 colors per scan line using PMG and playfield -- whether this would be limited to char mode or work in Antic E, I'm not sure... I've not programmed such a display, but is there someone here that would like to try, or help me out in trying such a thing?? sTeVE Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 2, 2003 Share Posted July 2, 2003 just to get it right... when doing simple overlaying PM gfx over an antic e screen... are you oversizing pms? with or without repositioning??? if i put an pm overlay over the entire screen i have to stretch the sprites 4 times via 53256f register... but if i do that... one PM pixel is 4 antic e pixels (one charsize)... and the player has it's color for 8 chars = 32 pixels... so how should be that possible??? even your LDA,STA needs a lot of time and as far as i can remember one colorclock = one CPU cycle? so if that's true than you are not able to change the colors + position quick enough??? ("multiplexing?") emkay, where the hell is your converter... hve Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 2, 2003 Share Posted July 2, 2003 Steve, if we can try to figure out more and more rules (for the converter) it gets more and more easy... and the PC would do the conversion for us... like TIP... you know trying to kickstart the project little bit... you know... one default picture we try to convert and then get more and more into the rules and the end would be then a "converter" doing all the stuff. but i am not good in math & picture convertion...so maybe on the net there are some sources for that??? (it's kind of dithering etc...) hve Link to comment Share on other sites More sharing options...
Bryan Posted July 2, 2003 Share Posted July 2, 2003 just to get it right... when doing simple overlaying PM gfx over an antic e screen... are you oversizing pms? with or without repositioning??? if i put an pm overlay over the entire screen i have to stretch the sprites 4 times via 53256f register... but if i do that... one PM pixel is 4 antic e pixels (one charsize)... and the player has it's color for 8 chars = 32 pixels... so how should be that possible??? even your LDA,STA needs a lot of time and as far as i can remember one colorclock = one CPU cycle? so if that's true than you are not able to change the colors + position quick enough??? ("multiplexing?") emkay, where the hell is your converter... hve I would imagine the way to do it is to put the players behind the display, having them only show through where COLBK is. Make them the right size to cover the areas needed. I'd probably move them whenever needed. And.. 2 Color clocks = 1 CPU cycle (worse than you thought!) -Bry Link to comment Share on other sites More sharing options...
Jetboot Jack Posted July 2, 2003 Author Share Posted July 2, 2003 As I understand MCS -- the PMG are set behind all other playfield registers, and set to a WIDTH and placed where needed, whatever is needed per line... Then perscaline we decide to position the PMG and instead of seeing 712 we see the PMG color, masked by the playfield (708-711), for resolution enhancing where needed, or we see 712... The KERNAL is the next step, changing one color register per X playfied bytes to increase the color resolution -- we could get a program to generate the tables for this (color register and change position AND PMG setting) by crunching the picture data according to our rules... sTeVE Link to comment Share on other sites More sharing options...
emkay Posted July 2, 2003 Share Posted July 2, 2003 this is funny Today I don't know how I made it, but the Manual-Screen of ADMIRANDUS switches one color 11 times. So it has 12 colors in one Gr.0 (ANTIC 2) line But to gain more switches why not trying to LDA LDY LDX in the range of the borders. This would be usefull to set a register temporarly to another color... STA $ STY$ STA $ I have calulated a size of about 6000 Bytes for such routines. This would be a fair amout, because a picture of 160*200 with 32 colors has 16000Bytes. A picture with up to 128 colors has on the ATARI about 14000Bytes. Link to comment Share on other sites More sharing options...
emkay Posted July 2, 2003 Share Posted July 2, 2003 As I understand MCS -- the PMG are set behind all other playfield registers, and set to a WIDTH and placed where needed, whatever is needed per line... Then perscaline we decide to position the PMG and instead of seeing 712 we see the PMG color, masked by the playfield (708-711), for resolution enhancing where needed, or we see 712... sTeVE This is correct Link to comment Share on other sites More sharing options...
Jetboot Jack Posted July 2, 2003 Author Share Posted July 2, 2003 Cool! So lets move on can we define an 18 color perline standard and the image here and make ti happen (only MUCH better) on the Atari? And 14K for a single picture is FINE, right now this is a demo type thing, maybe title screens! sTeVE Link to comment Share on other sites More sharing options...
emkay Posted July 2, 2003 Share Posted July 2, 2003 Cool! So lets move on can we define an 18 color perline standard and the image here and make ti happen (only MUCH better) on the Atari? sTeVE Please take care about the higher DMA of the first scanline of a charmode, and the used CHARBASE switching after all third charmodeline. In those lines you have one change less... And: Why doing colorweak C64 pictures when there are multiple times of colors available. I think a Car on the Street with trees and houses etc. would be much better..because of the "real" Car-Chrome and the Sun that shines from the high west direction onto our red Ferrari and the yellow sun is reflected by a resulting orange ... That would be possible! Link to comment Share on other sites More sharing options...
Jetboot Jack Posted July 2, 2003 Author Share Posted July 2, 2003 OK -- who is gonna come onboard to get this off the ground?? sTeVE Link to comment Share on other sites More sharing options...
ZylonBane Posted July 3, 2003 Share Posted July 3, 2003 Odd that in this entire thread, JD Potter's ColorView mode hasn't been mentioned once. Sure it's a bit shimmery, but an unconstrained 160x200x64-color display is nothing to turn your nose up at. Link to comment Share on other sites More sharing options...
Jetboot Jack Posted July 3, 2003 Author Share Posted July 3, 2003 I *think* I've seen ColorView stuff, it was quite flickery, can u point me to some good examples of this technique please -- maybe some ATR files sTeVE Link to comment Share on other sites More sharing options...
emkay Posted July 3, 2003 Share Posted July 3, 2003 Odd that in this entire thread, JD Potter's ColorView mode hasn't been mentioned once.Sure it's a bit shimmery, but an unconstrained 160x200x64-color display is nothing to turn your nose up at. I think the thread is build to make it possible to view Pictures like on C64 or better. All that has a resolution of 160*200 (and less) with less than 128 flickering colors is not worth to talk about....this time. 160*200 with 128 non flickering colors is - in fact - not possibe with the C64. And if we will try to use a flickermode like colorview again then with up to 16K colors.... Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 3, 2003 Share Posted July 3, 2003 yep. colorview/apacview etc... are 80x200xcolors with double or triple buffering and flicker very hard... or they used 80x100x256 but we want to increase resolution + reducing flickering... colorview lieves on in TIP... hve 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
Archived
This topic is now archived and is closed to further replies.