Heaven/TQA Posted November 25, 2014 Share Posted November 25, 2014 I Will post end of next week the pc prototype. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 25, 2014 Share Posted November 25, 2014 (edited) basically it is midline displacement but the agorithm is working with so called nodes... so you have starting point+end point plus what Carpenter calls nodes... this nodes (0-255) for start and end point will produce 256 different "line types"... our researches show that they have different shapes for 0-63,64-127,128-191,192-255.... (sometimes like clouds, sometimes like canyons etc). maybe one level uses only few types... but our algorithm can produce all variants... basically what you can do is precalc several type of lines and with different lengths... check out the 65816 20Mhz accelerated video of RoF A8 on youtube and you see the "rounding errors" and the other short cuts... btw... I can not run your PC demo... got the DLL missing error even I downloaded http://www.microsoft.com/en-us/download/details.aspx?id=5555 on Win7 Pro 64bit? Edited November 25, 2014 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
R0ger Posted November 25, 2014 Author Share Posted November 25, 2014 The DLL is inside the archive, you just have to extract all, and then run, not just run from inside the archive. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 25, 2014 Share Posted November 25, 2014 na, got Visual Studio 2010 DLL missing... even I installed the runtime from MS. Quote Link to comment Share on other sites More sharing options...
R0ger Posted November 27, 2014 Author Share Posted November 27, 2014 (edited) So XXL sent me source code for old tests. I modified it to use my new line, and here are all 3 benchmarks (and zip with sources for the last one): So while old two lines did both around 300 lines per second, this new one does about 400. Also note that my old line (drsid15) uses only ORA to draw pixels, so it's not actually any much faster then Eru's line. eru15.xex drsid15.xex drsid2.xex drsid2.zip Edited November 27, 2014 by Dr.Sid 2 Quote Link to comment Share on other sites More sharing options...
+MrFish Posted November 29, 2014 Share Posted November 29, 2014 (edited) I'm not saying your routine isn't faster, but it looks to me like the average line length you're using is shorter, eh? Edited November 29, 2014 by MrFish Quote Link to comment Share on other sites More sharing options...
R0ger Posted November 29, 2014 Author Share Posted November 29, 2014 I'm not saying your routine isn't faster, but it looks to me like the average line length you're using is shorter, eh? It shouldn't be. It uses random numbers, so the test is not exactly the same, but on average it should even out. Quote Link to comment Share on other sites More sharing options...
emkay Posted November 29, 2014 Share Posted November 29, 2014 It shouldn't be. It uses random numbers, so the test is not exactly the same, but on average it should even out. Could you do changes that make all benchmarks doing the same? Also in Antic D /Gr.7? Quote Link to comment Share on other sites More sharing options...
R0ger Posted November 29, 2014 Author Share Posted November 29, 2014 Could you do changes that make all benchmarks doing the same? Also in Antic D /Gr.7? To make them draw the same lines I would have to use some predefined data. I don't thing it would differ much. As for Antic D I think that would be fairly easy, but what would be the point ? Quote Link to comment Share on other sites More sharing options...
emkay Posted November 29, 2014 Share Posted November 29, 2014 It's just for a better comparision. Eru's routines draw clean and big lines in all colours. "SID15" just draws everything up to yellow The last one draws no "black" and the lines look shorter. Mode "D" would give a "final" comparision... Quote Link to comment Share on other sites More sharing options...
R0ger Posted November 29, 2014 Author Share Posted November 29, 2014 Ok, I modified drsid15 to replace the color, and I added color 0 to drsid2. I still don't see why D mode would be better then E mode. Like this I don't have to modify original benchmark, which uses E mode. True, I should have slightly less edge in D mode, as lines would be shorter on average, and my patterns are better for long lines. drsid2b.xex drsid15b.xex Quote Link to comment Share on other sites More sharing options...
emkay Posted November 29, 2014 Share Posted November 29, 2014 Thanks. It's now more obvious that they do the same. Quote Link to comment Share on other sites More sharing options...
+MrFish Posted November 30, 2014 Share Posted November 30, 2014 (edited) You might be right MK; I didn't notice that it wasn't using color 0 -- as eru's was. It may have just given the illusion that the lines were shorter. Edited November 30, 2014 by MrFish Quote Link to comment Share on other sites More sharing options...
peteym5 Posted December 11, 2014 Share Posted December 11, 2014 http://atariage.com/forums/topic/211628-fast-line-drawing Hello Dr. Sid. I am glad to see someone else working on this fast line drawing thing. I also do the table thing. I did not do the 4 direction thing because I want to keep things a little more compact. You never know how much space you need for the rest of your game or graphics program. My approach was to use self-modifying code to change dec/inc instructions to go left or right with the line and always draw top to bottom. Not sure you did this, but I have a table for the low and high address for each row on the screen, mine is geared to a 40 column screen. I had each of my tables start at a top of a new page, so when changing color, you just have to set the high byte. Another trick was to process 2 or 4 points within the loops, but only one process for slope math. Maybe we can combine the techniques and make something that goes super fast. For anyone else reading this keep in mind this is not for any specific game. WarpLine4X.zip 1 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted December 11, 2014 Share Posted December 11, 2014 (edited) Xiaolin Wu's line algorithm next Would that actual 'work' in terms of looking right, even in gr.15 in 3 shades of one colour? Edited December 11, 2014 by Wrathchild Quote Link to comment Share on other sites More sharing options...
peteym5 Posted December 11, 2014 Share Posted December 11, 2014 One problem with anti-aliasing is that it would take up much more CPU and some suggested it will make the lines look fat giving the Atari 8-bit palette layout. The ideal is to create some super fast line drawing algorithms so we can probably make some games that are not normally possible on the Atari. Quote Link to comment Share on other sites More sharing options...
R0ger Posted December 27, 2014 Author Share Posted December 27, 2014 http://atariage.com/forums/topic/211628-fast-line-drawing Hello Dr. Sid. I am glad to see someone else working on this fast line drawing thing. I also do the table thing. I did not do the 4 direction thing because I want to keep things a little more compact. You never know how much space you need for the rest of your game or graphics program. My approach was to use self-modifying code to change dec/inc instructions to go left or right with the line and always draw top to bottom. Not sure you did this, but I have a table for the low and high address for each row on the screen, mine is geared to a 40 column screen. I had each of my tables start at a top of a new page, so when changing color, you just have to set the high byte. Another trick was to process 2 or 4 points within the loops, but only one process for slope math. Maybe we can combine the techniques and make something that goes super fast. For anyone else reading this keep in mind this is not for any specific game. Sorry for late reaction. I just didn't notice there is something new here. Anyway .. I took this Warp4x routine and placed it inside our old test. And it is basically same speed as my best version ! Now I have to really understand, how it works .. warp4x.xex Quote Link to comment Share on other sites More sharing options...
peteym5 Posted December 27, 2014 Share Posted December 27, 2014 How hard would it be to replace the slope math adc/sbc with dec to 0? Might save some clock cycles. Quote Link to comment Share on other sites More sharing options...
w1k Posted December 27, 2014 Share Posted December 27, 2014 on real HW not working Quote Link to comment Share on other sites More sharing options...
R0ger Posted December 27, 2014 Author Share Posted December 27, 2014 How hard would it be to replace the slope math adc/sbc with dec to 0? Might save some clock cycles. Not sure what you mean exactly .. Quote Link to comment Share on other sites More sharing options...
peteym5 Posted December 27, 2014 Share Posted December 27, 2014 (edited) The slope math inside the tall or wide loops.... LDA M1 ;99 ;3AW_WIDE_DELTA_RI=*+1 SBC #$FF ;101 ;7 STA M1 ;104 ;10 BCS AW_WIDE_SKIP ;107 ;13AW_WIDE_DELTA_CI=*+1 ADC #$FF STA M1 .... .... AW_WIDE_SKIP Replace with DEC M1 BNE AW_WIDE_SKIP LDA [new countdown value] STA M1 AW_WIDE_SKIP Problem is trying to figure out how much to count down from might take as much CPU or adding more tables that take up more memory. It is a theory I had been trying to work out, but I need to find a fast table division routine to make something like that work. Edited December 27, 2014 by peteym5 Quote Link to comment Share on other sites More sharing options...
R0ger Posted December 28, 2014 Author Share Posted December 28, 2014 Well .. that is exactly the part of the code I don't understand at all. I think I understand most of the rest, like the division into 4 shorter lines. It's hard to read when combined with self-modifying approach. What kind of algorithm is it ? Do you have some simpler code of the algorithm ? The division into 4 lines seems to be the trick behind the speed. On the other hand it produces some minor inacuracies along the line. At the moment corectness of the algorithm is important for my application (still secret, sorry ;-D), but I have to experiment with it a bit. Quote Link to comment Share on other sites More sharing options...
peteym5 Posted December 28, 2014 Share Posted December 28, 2014 Its a thought, maybe someone can get us a fast table division routine. Slope Math on the horizontal (Long Slope) is how many pixels it has to go before changing the row. On Vertical (Tall Slope), it would be how long it goes before changing column. Been trying to figure out a less CPU clock cycle alternative to do this. Quote Link to comment Share on other sites More sharing options...
R0ger Posted December 29, 2014 Author Share Posted December 29, 2014 I guess I don't know what this line means: AW_WIDE_DELTA_RI=*+1 I guess it's something very well known, but I'm just starting on Atari, so pls be patient with me Quote Link to comment Share on other sites More sharing options...
MaPa Posted December 29, 2014 Share Posted December 29, 2014 It's just label/equate to previous byte (current position-1) for self modify code I assume. 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.