Bryan Posted June 17, 2003 Share Posted June 17, 2003 [Let's have a look on my prefered picture (using 6 colors): The colors are made by: 708 -> black 709 -> yellow 710 -> grey 711 -> orange 712 -> red 704-707 -> green (made by PMg behind the playfield) 712 is the Background 710 & 711 can be switched by character invert ( higher than 127) 708-711 filters the resolution of the PMg. red, blue and grey are made by using PMg violett is made by font inversion The picture uses 8 colors do you get it now? Okay, but according to the screenshots these pictures don't seem to be mixing any new colors. They use the colors in the palettes, some dithering, and the players to alter the background colors in places. Where does the undetectable color mixing (GTIA 'bug') come into play? -Bry Link to comment Share on other sites More sharing options...
emkay Posted June 17, 2003 Share Posted June 17, 2003 Check out the Fu Kung forum emkay - it's for 2600, ... Sorry, this is a viewable nonsense for me. Normal interlace is one thing...but this????? Link to comment Share on other sites More sharing options...
emkay Posted June 17, 2003 Share Posted June 17, 2003 Okay, but according to the screenshots these pictures don't seem to be mixing any new colors. They use the colors in the palettes, some dithering, and the players to alter the background colors in places. Where does the undetectable color mixing (GTIA 'bug') come into play? I made/converted this pictures a long time ago and didn't get any advantage to the technique. So you have only the "real" colors available. Maybe this will help out: Take a look at the "Spieler" Scoreboard. I used a displaylist with changing mode e/f/e/f etc. So the colors are made by ANTIC e and for the "hires" ANTIC F is used. Please take care about the color in hires is depending on the background. It is black, so the resulting color is grey. By changing of blue/grey/blue/grey etc. here I got a "hires" color font. Please compare the "0000" with the original colorfont "INFO". BTW: Take a look at the pointers ... they are hires with two colors....by the same way . Link to comment Share on other sites More sharing options...
Sheddy Posted June 17, 2003 Share Posted June 17, 2003 Can you post the pic as a .gif or .tiff emkay? ...We can't see the details of the clever stuff you've done because of the jpeg artifacting Thanks Link to comment Share on other sites More sharing options...
emkay Posted June 17, 2003 Share Posted June 17, 2003 Can you post the pic as a .gif or .tiff emkay? ...We can't see the details of the clever stuff you've done because of the jpeg artifacting Thanks It is not neccesary. The picture has the detail you need to view the effect. Perhaps... how it is done, you may see on the Emulator... The picture is a snapshot of my XL via a PC framegrabber card. On a monitor it will not be any sharper. Link to comment Share on other sites More sharing options...
Sheddy Posted June 17, 2003 Share Posted June 17, 2003 Just didn't want people to think you're cheating by using the anti-aliasing that jpeg images end up with Here's a .gif of the relevant bit from the emulator. Link to comment Share on other sites More sharing options...
ZylonBane Posted June 17, 2003 Share Posted June 17, 2003 So "Chronocolour interleaved " = ColorView? Yep, same technique. There are quite a few still images he's done that you can download. Considering the low resolution of the 2600 and that it can only generate 8 colors this way, the results are surprisingly good. Whole thing got started in this thread (just skip over page 4). Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 17, 2003 Author Share Posted June 17, 2003 emkay... this is a technical milestone... but to be little bit provocative (?)... does the game benefit from the tec stuff/screendesign you have invented? imho not... so all afford you have put into this one screen (in technical meaning) is from my point of view far beyond what would be necessary to get the same impression by the target audience... as nobody from the general public will realise how much hard work it was... that's why i do not code anymore but give design input... as done with numen... i had tons of source code with "weird" effects which my TQA guys kicked as it's not good looking enough... doesn't matter how good it was coded... but please don't take this personal... your technique could be used smart & clever on status bars etc... but i don't see this CPU consuming (i might be wrong...) tricks usable in a game...(except title screen f.e.) same goes with MCS and all other multicolor tricks... for games... i don't see that... as f.e. space harrier you would need to manipulate antic e + the player/missle area so at least double amount of data... and in combination with DLIs your engine gots slower and slower... but i see your stuff for strategic games, etc... but not for more? hve Link to comment Share on other sites More sharing options...
TMR Posted June 17, 2003 Share Posted June 17, 2003 i had tons of source code with "weird" effects which my TQA guys kicked as it's not good looking enough... doesn't matter how good it was coded... What a waste of routines - put them all together and release for gawds sake, there's no point in leaving them to rot! =-) but please don't take this personal... your technique could be used smart & clever on status bars etc... but i don't see this CPU consuming (i might be wrong...) tricks usable in a game...(except title screen f.e.) i s'pose they're good for puzzle games... Link to comment Share on other sites More sharing options...
emkay Posted June 17, 2003 Share Posted June 17, 2003 Heaven wrote: >emkay... this is a technical milestone... but to be little bit provocative (?)... does the game benefit from the tec stuff/screendesign you have invented? Ofcourse it does. It fits more to the eyes of People outside the ATARI-world than other games are still doing. It has color it has style and it was very much fun to do this. Only by doing development in this way, the 8-bits would have lived many years longer on the commercial market. >same goes with MCS and all other multicolor tricks... for games... i don't see that... as f.e. space harrier you would need to manipulate antic e + the player/missle area so at least double amount of data... and in combination with DLIs your engine gots slower and slower... Games like Space Harrier are better done the way Sheddy does. But Sheddy does waste much CPU Time by his routines, that are a real 3D-Engine.... a very fast imho .... this could be done by tricking (like on C64) very much faster. With the MCS as a rudimentary standard, you may just enhance it by DLI and using of scrolling with multiplexed players.... and a spriteroutine that fits to the non-linear fontscreen. MCS was thought as a standard to make C64 conversions. May I suggest you: It is a harder way to create something new, than to remake anything. MCS and the ADMIRANDUS-Screen ( including some development tools) is built by my own. Only some graphics are used that were available this time by public domain... How much People are TaQuart? How long does it take for a Demo? Please note, if I had found some good Programmers in ~1991 the Software I wanted to do was at hand today. Including "The Last Ninja" and "Turrican". But the Games had to be there in 1992 and not today ... And BTW: My Job has nothing to do with programming, graphic- or soundcreation and I didn't know people in personal who are able to do this in profession... So it was hard, but it was fun And due to my fulltime Job I had to do , and the "walls" I was talking to I gave up all Softwaredevelopment on the XL/XE. At last: 1988 I asked a programmer in ABBUC to create programs like RMT to create sounds like in "slow" and 2003 Raster made it possible.... And now I am asking myself: Why is that all so slow after all? At the current development-speed Turrican will be available in approximate 200 years Link to comment Share on other sites More sharing options...
Bryan Posted June 17, 2003 Share Posted June 17, 2003 I made/converted this pictures a long time ago and didn't get any advantage to the technique. So you have only the "real" colors available. Maybe this will help out: Take a look at the "Spieler" Scoreboard. I used a displaylist with changing mode e/f/e/f etc. So the colors are made by ANTIC e and for the "hires" ANTIC F is used. Please take care about the color in hires is depending on the background. It is black, so the resulting color is grey. By changing of blue/grey/blue/grey etc. here I got a "hires" color font. Please compare the "0000" with the original colorfont "INFO". Can you post the Spieler binary? -Bry Link to comment Share on other sites More sharing options...
emkay Posted June 18, 2003 Share Posted June 18, 2003 Can you post the Spieler binary? The game itself is called ADMIRANDUS. "Spieler" belongs only to the Scoreboard itself. And...No, I don't have any sources to post, because some of my discs are lost/defective. Link to comment Share on other sites More sharing options...
emkay Posted June 18, 2003 Share Posted June 18, 2003 @Sheddy How much DLIs/colorchanges are you doing in Space Harrier ? Link to comment Share on other sites More sharing options...
Sheddy Posted June 18, 2003 Share Posted June 18, 2003 @Sheddy How much DLIs/colorchanges are you doing in Space Harrier ? Only one colour gets changed on each DLI. The amount of DLI's varies from stage to stage. Some of the stages like stage 1 only have about 10 DLI's, stage 3 now has just over 40. What makes you curious??? PS regarding 3d engine...I do cheat horribly wherever possible Hardly any real 3d calculations are going on. Normally the "scenery" (things on the ground like trees, bushes etc. and rocks in the air) have one division calculation on their x position. y position is all table driven. Nearly all the aliens run in 2d, only some bosses have 3d when I can't fiddle it in 2d to look right :wink: Link to comment Share on other sites More sharing options...
emkay Posted June 18, 2003 Share Posted June 18, 2003 Only one colour gets changed on each DLI. The amount of DLI's varies from stage to stage. Some of the stages like stage 1 only have about 10 DLI's, stage 3 now has just over 40. What makes you curious??? How much does it influence the speed of the game between 10 and 40 DLIs? With approximatly 40 DLIs it would be possible to multiplex PMs .... maybe .... to create Jump and Run Game platforms for the "Hero"(*) to stand above. * The Hero could be made by a character-based Softwaresprite Link to comment Share on other sites More sharing options...
Sheddy Posted June 21, 2003 Share Posted June 21, 2003 How much does it influence the speed of the game between 10 and 40 DLIs? With approximatly 40 DLIs it would be possible to multiplex PMs .... maybe .... to create Jump and Run Game platforms for the "Hero"(*) to stand above. * The Hero could be made by a character-based Softwaresprite OK - that could be fun! Why don't you have a go, and post a proof of concept in the programming forum? The DLIS do affect the speed a fair bit. Here follows a rough calculation: Approx cycle count per NTSC frame = 1,790,000 / 60 = 29833 cycle count per DLI (assuming a WSYNC) = 114 cycles for 40 DLIS = 114 * 40 = 4560 4560/29833 = 0.153 or about 15% of the total processor time if I did the math right That doesn't factor in any DMA fetches though Link to comment Share on other sites More sharing options...
emkay Posted June 21, 2003 Share Posted June 21, 2003 The DLIS do affect the speed a fair bit. Here follows a rough calculation: Approx cycle count per NTSC frame = 1,790,000 / 60 = 29833 cycle count per DLI (assuming a WSYNC) = 114 cycles for 40 DLIS = 114 * 40 = 4560 4560/29833 = 0.153 or about 15% of the total processor time if I did the math right That doesn't factor in any DMA fetches though Did you made tests about colorchanging in one Scanline? a simple 'lda 0 sta col lda a sta col ' shows a longer color line at the beginning of a scanline. The more the scanline goes to the end of the scanline, the shorter is the color-line.... This means, that the DMA of the ANTIC acts more at the beginning of a scanline as at the end... For a programmer this means : Use the DLI not only to change one color Too much CPU Time will be wasted. The only good thing is: while WSYNC happens the DMA happens partial too. So you don't lose ANTIC DMA & DLI-Time in full addition Depending on yours, let's make a simple calculation too In fullscreen ANTIC DMA cost 30% of CPU Time. A full DLI uses 114 cycles 114cycles -30% =79,8 cycles So 79,8 cycles of available cycles for the program are used for the DLI including WSYNC. Depending on the used Mode, the resulting cycles are more or less. You may correct me if I am totally wrong Link to comment Share on other sites More sharing options...
Sheddy Posted June 22, 2003 Share Posted June 22, 2003 Actually emkay, I think we may both be wrong! I think the 114 cycles per scan-line already allows for DMA? Maybe someone else can confirm that, without us having to plough through the hardware manual? reasoning as follows: the Atari is designed to do one clock cycle per colour clock. There are 160 colour clocks in a normal size screen. The most Antic can fetch is 40 bytes every line (normal mode), and Player/Missiles have to fetch 5 bytes. 160 - 40 - 5 = 115, is darn near 114. Surely that can't just be a coincidence? Ah, I forgot the Display list also has to be included. Once that is set up for normal screens it will take only 1 byte per line. If that's right, I think the figure of 15% of stolen cycles is fairly accurate. Just to confuse things further - memory refresh also has to happen, but I don't remember how many cycles it steals - I'm sure it's more than just 1 per scan-line though! I've also tried to think what useful work could be done instead of waiting for WSYNC - but I've not come up with anything useful, except more colour changes, etc. EG Time slicing code has too much overhead Link to comment Share on other sites More sharing options...
emkay Posted June 22, 2003 Share Posted June 22, 2003 Sheddy wrote: Actually emkay, I think we may both be wrong! I think there is something more wrong about the calculation belonging to ANTIC and his CPU-Time stealing.... But I think, I am right in my thoughts....When ANTIC DMA is enhanced by Hi-Res or 5-color charmode and hires PMg , the time that is truely lost by WSYNC is less than by using a mode of lower resolution.... .... I hope it is possible to follow my logic Link to comment Share on other sites More sharing options...
Bryan Posted June 22, 2003 Share Posted June 22, 2003 Actually emkay, I think we may both be wrong! I think the 114 cycles per scan-line already allows for DMA? Maybe someone else can confirm that, without us having to plough through the hardware manual? reasoning as follows: the Atari is designed to do one clock cycle per colour clock. There are 160 colour clocks in a normal size screen. The most Antic can fetch is 40 bytes every line (normal mode), and Player/Missiles have to fetch 5 bytes. 160 - 40 - 5 = 115, is darn near 114. Surely that can't just be a coincidence? Ah, I forgot the Display list also has to be included. Once that is set up for normal screens it will take only 1 byte per line. If that's right, I think the figure of 15% of stolen cycles is fairly accurate. Just to confuse things further - memory refresh also has to happen, but I don't remember how many cycles it steals - I'm sure it's more than just 1 per scan-line though! I've also tried to think what useful work could be done instead of waiting for WSYNC - but I've not come up with anything useful, except more colour changes, etc. EG Time slicing code has too much overhead There are 228 color clocks per scan line (160 visible in Normal PF). The CPU runs at 1 cycle every 2 color clocks, so you have 114 cycles (228/2)_before_ DMA, which can steal up to 80 consecutive cycles (all of them in the visible area of the screen - 160 color clocks) on the 1st line of a row of text. After the 1st row, the characters are read from Antic's internal buffer. In gr.0, just try changing COLBK after a DLI & a WSYNC (putting you at line 0 of a text row) and moving the change point across the screen with NOP's. You'll notice that it jumps from the left border to the right with just 1 NOP. This is because DMA can consume up to ALL of your cycles in that area (not even RAM refresh happens on this line) leaving you with the 34 cycles in the borders, minus the DL and Player reads. 114 total cycles, and 80 of those are in the Playfield and are lost = 34. of those 80, 40 are used for reading character numbers and are cached, and 40 are used for reading the 1st line of character graphic data. For the next 7 lines of the text, the DMA load is about half of the available time: 40 cycles for reading the 2nd+ line of character graphic data. In a line doubled mode, fortunately, Antic reads the 2nd copy of the line from an internal buffer so it can save you a lot of CPU time. Any mode that displays 160 pixels by 4 colors will steal 40 cycles on the 1st line it is displayed on. Hope this helped... -Bry Link to comment Share on other sites More sharing options...
Sheddy Posted June 22, 2003 Share Posted June 22, 2003 Yep, you guys are right. Thanks for straightening me out on that. Should have checked my facts before shooting my mouth off! Strange how I got to 114 though. Link to comment Share on other sites More sharing options...
tjlazah Posted July 3, 2003 Share Posted July 3, 2003 I am hoping this project gets done soon!! This port is great... -TjLaZah Link to comment Share on other sites More sharing options...
Bryan Posted July 3, 2003 Share Posted July 3, 2003 a simple 'lda 0 sta col lda a sta col ' shows a longer color line at the beginning of a scanline. The more the scanline goes to the end of the scanline, the shorter is the color-line.... This means, that the DMA of the ANTIC acts more at the beginning of a scanline as at the end... Oh yeah, the reason Antic steals more cycles at the beginning of a line is because that's when it does the RAM refresh cycles. -Bry Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.