tebe Posted January 18, 2004 Share Posted January 18, 2004 in next version SaveXEX, SaveASM ignored headers repaired option: Load Colors, Save Colors, Load Sprites, Save Sprites Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 18, 2004 Share Posted January 18, 2004 oops... i totally forgot emkay's & schmutz's nazgul intro which were 1st than my turrican one... sorry for claiming #1... Quote Link to comment Share on other sites More sharing options...
Schmutzpuppe Posted January 18, 2004 Share Posted January 18, 2004 oops... i totally forgot emkay's & schmutz's nazgul intro which were 1st than my turrican one... sorry for claiming #1... lol, no problem Quote Link to comment Share on other sites More sharing options...
analmux Posted January 18, 2004 Share Posted January 18, 2004 error found... 1st you have to load your .g2f file... then press "save" button to save the 3 data files, scr, fnt and tab... then save the xasm-compatible source file in the "save as" dialog... now it works... if you tick on the adresses where you might want to have the data tables located then graph2fnt will put XL headers in the data files.... so...that's why my screens looked messed up... simply because they where all shifted by 6 bytes caused by the file header... That's what I thought a long time ago: see this link: http://www.atariage.com/forums/viewtopic.p...ghlight=#417043 ----- mux Quote Link to comment Share on other sites More sharing options...
analmux Posted January 19, 2004 Share Posted January 19, 2004 Heaven, your demo works fine on real XL PAL (see screenshot), nice work. It actually looks very smooth on a real machine, and it doesn't roll (like emkay's/schmutz's demo) ----- mux Quote Link to comment Share on other sites More sharing options...
raster/c.p.u. Posted January 20, 2004 Share Posted January 20, 2004 just a quick throwing together...i've taken RMT turrican track, RMT player source, graph2fnt source + emkay's turrican pic and this is the result... have fun... i've included the xasm source codes so you can see how i have implemented & included the RMT file... Hi Heaven! Good work! But I made some cosmetical changes only: * Later rev2 version of Turrican RMT module (stripped module exported). * Appropriate rmt_feat.a65 created. * Special (19.1.2004) rmtplayr.asx with 4 types of STEREOMODE * STEREOMODE=2 => compile RMTplayer for 4 tracks stereo L1 R2 R3 L4 (There is standard 4 generators used on standard Atari, but 2 left and 2 right generators used on Atari with stereo upgrade.) (Without any unsafe stereo detection. ) * Missing org $6900 added into turrican.asx (music routine was on bad location and overwrited some RMT module data. * Turrican.obx (25274 bytes) packed to Turrican.xex (16645 bytes). Enjoy it! Greetings, raster/c.p.u. turi2rs.zip Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 20, 2004 Share Posted January 20, 2004 cool... Quote Link to comment Share on other sites More sharing options...
raster/c.p.u. Posted January 20, 2004 Share Posted January 20, 2004 cool... You can add some trasparent scrolltext over bottom part of the picture now. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 20, 2004 Share Posted January 20, 2004 thanks raster... emkay did a great job in converting the pic... it's like with the elf pic... 1st you think there are just DLIs but when loading into g2f 3.6 and switching off the pm gfx you see how poor it would look without... but scroller should be possible on the 1st 16 scanlines... as the PM gfx start at the top of the castle... Quote Link to comment Share on other sites More sharing options...
tebe Posted January 20, 2004 Share Posted January 20, 2004 http://g2f.atari8.info instruction in polish language, but some picture with english text Quote Link to comment Share on other sites More sharing options...
Dracon Posted January 21, 2004 Share Posted January 21, 2004 As for above address, it doesn't work... But this is a good one! Well, adding some screenshots with description was a cool idea, indeed!! But I hope somebody will translate the whole manual into English one day... And now special info for all non-Polish G2F users: Remember about so called 'dirty lines' that appear every 8th line of screen when doing midline changes - they should be covered with some sprites' data at best. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 21, 2004 Share Posted January 21, 2004 thanks drc for the info... but should we not call the "dirty lines" like on c64 "bad lines" if i remember that phenomenon correct? Quote Link to comment Share on other sites More sharing options...
analmux Posted January 21, 2004 Share Posted January 21, 2004 thanks drc for the info... but should we not call the "dirty lines" like on c64 "bad lines" if i remember that phenomenon correct? Well, 'bad lines' on c64 gives more flexibility in coloring a picture, as 'dirty lines' gives a handicap every first charmode rasterline. GED techniques don't work in the 'dirty line'. ----- mux Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 22, 2004 Share Posted January 22, 2004 @ guys from cosine... can you remember this: i have done some "meditation" with g2f and tried to play around with it... here we are... sorry i am not very good in it... i used GED+ mode but atari800win seems not to show the pic correct... can someone please check on real hardware? i am not able to do it at the moment for myself... cosine.zip Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 22, 2004 Share Posted January 22, 2004 bigger... Quote Link to comment Share on other sites More sharing options...
starraider Posted January 22, 2004 Share Posted January 22, 2004 On the Atari it looks exactly like on the emulator.....It has those green and blue colors that look kinda odd.... Quote Link to comment Share on other sites More sharing options...
TMR Posted January 22, 2004 Share Posted January 22, 2004 Woohoo, someone's ported my stuff and it wasn't me for a change! =-) Quote Link to comment Share on other sites More sharing options...
Fröhn Posted January 23, 2004 Share Posted January 23, 2004 but should we not call the "dirty lines" like on c64 "bad lines" if i remember that phenomenon correct? Well, 'bad lines' on c64 gives more flexibility in coloring a picture, as 'dirty lines' gives a handicap every first charmode rasterline. GED techniques don't work in the 'dirty line'. 'bad lines' on c64 are the same as those 'dirty lines' on xl. the only difference is that xl doesn't have badlines on bitmap graphics, while c64 has and uses that extra data for color blocks. if you use charmode, it's the same on c64 and xl. Quote Link to comment Share on other sites More sharing options...
analmux Posted January 23, 2004 Share Posted January 23, 2004 but should we not call the "dirty lines" like on c64 "bad lines" if i remember that phenomenon correct? Well, 'bad lines' on c64 gives more flexibility in coloring a picture, as 'dirty lines' gives a handicap every first charmode rasterline. GED techniques don't work in the 'dirty line'. 'bad lines' on c64 are the same as those 'dirty lines' on xl. the only difference is that xl doesn't have badlines on bitmap graphics, while c64 has and uses that extra data for color blocks. if you use charmode, it's the same on c64 and xl. I don't know what you're talking about. In the context of graphics enhancement, (more) badlines on c64 badlines are generated by a special kernel or raster interrupt to give a higher coloring flexibility, so on c64 badlines are USEFUL. Dirty lines on A8bit don't give us more flexibility. GED (or midscanline setcolorchanges) relies heavily on the DMA scheme of the graphicsline. GED is simply NOT POSSIBLE on dirty lines, and destroys the effect. But indeed on both machines dirty/bad lines cause a total halt of the CPU, but on atari badlines are NOT associated with color enhancement. see this link (FLI) http://www.studiostyle.sk/dmagic/gallery/gfxmodes.htm ----- mux Quote Link to comment Share on other sites More sharing options...
emkay Posted January 23, 2004 Author Share Posted January 23, 2004 I don't know what you're talking about. In the context of graphics enhancement, (more) badlines on c64 badlines are generated by a special kernel or raster interrupt to give a higher coloring flexibility, so on c64 badlines are USEFUL. Dirty lines on A8bit don't give us more flexibility. GED (or midscanline setcolorchanges) relies heavily on the DMA scheme of the graphicsline. GED is simply NOT POSSIBLE on dirty lines, and destroys the effect. But indeed on both machines dirty/bad lines cause a total halt of the CPU, but on atari badlines are NOT associated with color enhancement. see this link (FLI) http://www.studiostyle.sk/dmagic/gallery/gfxmodes.htm ----- mux When I had my "first visions" on MCS ... I suggested to use the possibilities of creating a more colorful screen for games incl. the possibilities of "Block movement" for really fast Softwaresprites. In addition it is possible to use screen ranges and that is the benefit of the bad line on the A8. On C64 the badline reads the colors for its color cells... Summary: MCS aka G2F is the best way on A8 to create cool gaming screens... If you want to create the highest possible color-resolution for images on the A8 without interlace and with always full cpu usage without any gaming abilities you are allways welcome to use the gr. 7 with a fullscreen DLI+PM "underlay"... Quote Link to comment Share on other sites More sharing options...
analmux Posted January 23, 2004 Share Posted January 23, 2004 We can see a similarity between exploiting the multiple badlines per 8 scanline block on c64 (FLI) and KONOP's mode on Atari (gr.9/10/11 in 80*48 resolution). Both modes are generated by writing back to the vertical line counter (vscroll on atari and $D011 on C64). Maybe the inventor of KONOP's mode was inspired by FLI. ...but, back now to the discussion... @ emkay You should be glad you've inspired me to have the same visions about game graphics enhancement, so don't be afraid, I'm working on it. I'm experimenting with the charmode + MCS + softwaresprite idea. The "Graviton"-game I'm developing will make full use of this: Antic 4 screen. PM quad-width underlays. Multiple fonts in vertical partitions/zones of the screen. Prerolled softwaresprites. It must be the fastest way (though it would need much memory). I even found a way to use pseudo-PMbases, to speed up PM movements. Just be patient for the first smartfont demos, I'm still very busy with studying, but I can hardly wait to start writing the demo. ----- mux Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 27, 2004 Share Posted January 27, 2004 new version 3.6.5 out now! http://g2f.atari8.info/ Quote Link to comment Share on other sites More sharing options...
Fröhn Posted January 28, 2004 Share Posted January 28, 2004 I don't know what you're talking about. In the context of graphics enhancement, (more) badlines on c64 badlines are generated by a special kernel or raster interrupt to give a higher coloring flexibility, so on c64 badlines are USEFUL. Dirty lines on A8bit don't give us more flexibility. GED (or midscanline setcolorchanges) relies heavily on the DMA scheme of the graphicsline. GED is simply NOT POSSIBLE on dirty lines, and destroys the effect. But indeed on both machines dirty/bad lines cause a total halt of the CPU, but on atari badlines are NOT associated with color enhancement. the term "bad line" was invented before people knew about the possibility to do FLI with them. it was established when people were doing raster bars and other raster effects, which on c64 are always based on synchronous cpu programming. it was quickly noticed that the timing wasnt the same on all rasterlines, but on every 8th rasterline there was a lot of clock cycles missing. people started to call these lines "bad lines". what i want to say: the term "bad line" has the same meaning as your term "dirty line" because it simply discribes the missing of cpu cycles. missing cpu clock cycles + video chip dma access for char matrix data = bad line/dirty line. Quote Link to comment Share on other sites More sharing options...
analmux Posted January 28, 2004 Share Posted January 28, 2004 I don't know what you're talking about. In the context of graphics enhancement, (more) badlines on c64 badlines are generated by a special kernel or raster interrupt to give a higher coloring flexibility, so on c64 badlines are USEFUL. Dirty lines on A8bit don't give us more flexibility. GED (or midscanline setcolorchanges) relies heavily on the DMA scheme of the graphicsline. GED is simply NOT POSSIBLE on dirty lines, and destroys the effect. But indeed on both machines dirty/bad lines cause a total halt of the CPU, but on atari badlines are NOT associated with color enhancement. the term "bad line" was invented before people knew about the possibility to do FLI with them. it was established when people were doing raster bars and other raster effects, which on c64 are always based on synchronous cpu programming. it was quickly noticed that the timing wasnt the same on all rasterlines, but on every 8th rasterline there was a lot of clock cycles missing. people started to call these lines "bad lines". what i want to say: the term "bad line" has the same meaning as your term "dirty line" because it simply discribes the missing of cpu cycles. missing cpu clock cycles + video chip dma access for char matrix data = bad line/dirty line. Yeah, I knew you would get back on me Whatever man, I don't really care how to call it (bad or dirty line), of course they are based on the same phenomenon on different machines, you're right. But I thought we were talking about graphics and color enhancement, and THEN the two concepts are very different, as on one machine it's an advantage and on the other it's a disaster. Maybe we should call it the 'advantage line' on c64 and the 'disaster line' on a8bit. ....but let's not spoil this thread ----- mux Quote Link to comment Share on other sites More sharing options...
Fröhn Posted January 29, 2004 Share Posted January 29, 2004 But I thought we were talking about graphics and color enhancement, and THEN the two concepts are very different, as on one machine it's an advantage and on the other it's a disaster. Maybe we should call it the 'advantage line' on c64 and the 'disaster line' on a8bit. what you do is color splits to enhance colors. this also has been done on C64 (look at 1988/1989 c64 demos) and ofcourse the badlines are no advantage then. but there are ways to suppress them on C64, maybe you can also find ways on atari. a good example: one year camelot 3/camelot (part is called: "- free det dur -") 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.