Orion_ Posted September 20, 2006 Report Share Posted September 20, 2006 I actually have some strange problem with the blitter, in my triangle filler routine. the point is, when I'm blitting too much triangle, some lines are not displayed :/ then the whole triangle, making hole in my 3D object :/ the firsts triangles are always correctly displayed and then the other are not, I and think this is in direct relation with the number of triangle, because If I display less triangle it works great. and I got a bug like that using the blitter before, while erasing the screen, I still didn't figure out why I cannot erase more than 320x205 pixels at one time using one blitter call :/ even If I specify to erase 320x240, the blitter will stop before. does anyone know why ? and how to correct that ? Link to comment Share on other sites More sharing options...
Matthias Posted September 20, 2006 Report Share Posted September 20, 2006 Hello! while erasing the screen, I still didn't figure out why I cannot erase more than 320x205 pixels at one time using one blitter call :/ even If I specify to erase 320x240, the blitter will stop before. does anyone know why ? and how to correct that ? I run into the same problem ;-) I don't have the docs at hand (nor a source-code) but the solution is, that your height*width needs to be less than 65536 (range is $0-$ffff) because both values are combined in a 16bit-register. But i think you can use a trick and tell the blitter to fill 2 or 4 pixels during the same step ( like 240 lines of 160 "DoublePixels"). Perhaps i can come up with a better description tomorrow... Best regards Matthias Link to comment Share on other sites More sharing options...
GT Turbo Posted September 21, 2006 Report Share Posted September 21, 2006 I don't have the docs at hand (nor a source-code) but the solution is, that your height*width needs to be less than 65536 (range is $0-$ffff) because both values are combined in a 16bit-register. Yes that's why i was thinking, thanks for your info Mathias GT Link to comment Share on other sites More sharing options...
SebRmv Posted September 21, 2006 Report Share Posted September 21, 2006 because both values are combined in a 16bit-register. Ah interesting. I did not notice the first time the "16 bit" ! Another thing which is badly documented then. Link to comment Share on other sites More sharing options...
Orion_ Posted September 21, 2006 Author Report Share Posted September 21, 2006 SCPCD found how to correct the bug, I should have use the A1_STEP register and the UPDA1 command. Link to comment Share on other sites More sharing options...
Matthias Posted September 21, 2006 Report Share Posted September 21, 2006 Hello! I don't have the docs at hand (nor a source-code) but the solution is, that your height*width needs to be less than 65536 (range is $0-$ffff) because both values are combined in a 16bit-register. But i think you can use a trick and tell the blitter to fill 2 or 4 pixels during the same step ( like 240 lines of 160 "DoublePixels"). Ok, meanwhile i have seen that i was wrong when saying that width and height will be put into a 16bit-register, but my trouble was related to the proper setting up of the registers and the understanding of how the blitter works. To clear (or fill) a contigous area like a whole screen you can either think of this screen as a 2-dimensional object (width, height) , or as a 1-dimensional object of length "width*height". You can use the Jagaur-blitter for both versions, but the latter (the 1-dimensional) will only work as long as width*height are less than $10000. Here is some 68k-code i use to clear 2-dimensional areas in my applications/games: . . move.w #320,screenwidth move.w #208,screenheight move.l #PITCH1|PIXEL16|WID320|XADDPIX,screenflags . move.l #myfirstscreen,d0 jsr Clear16bitscreen . move.l #mysecondscreen,d0 jsr Clear16bitscreen . ;******************************************************************* Clear16bitscreen: ; Point A1BASE to the data move.l d0,A1_BASE; destination-address move.l screenflags,d0 or.l #XADDPIX,d0 move.l d0,A1_FLAGS ; Set the pixel point to 0,0 move.w #0,d0 ; y swap d0 move.w #0,d0 ; x move.l d0,A1_PIXEL ; Set fractional pixel pointer move.w #0,d0 ; y swap d0 move.w #0,d0 ; x move.l d0,A1_FPIXEL ; Set up the step size to ; -screenwidth in x and ; 1 in y move.w #1,d0 ; y swap d0 move.w screenwidth,d0 neg.w d0 move.l d0,A1_STEP ; Set up the fractional step size to 0 in x ; 0 in y move.w #0,d0 ; y swap d0 move.w #0,d0 ; x move.l d0,A1_FSTEP ; Set up Counters register move.w screenheight,d0; y swap d0 move.w screenwidth,d0; x move.l d0,B_COUNT ; Put some data (0s to clear the screen) in the blitter for it to write ; This is a cheat I am using all 0 so there is ; no need to word swap move.l #0,d0 move.l d0,B_PATD move.l #0,d0 move.l d0,B_PATD+4 ; Now Turn IT ON !!!!!!!!!!!!! ; NO SOURCE DATA ; NO OUTER LOOP ; Turn on pattern data ; Allow outer loop update move.l #PATDSEL|UPDA1,d0 move.l d0,B_CMD .waitforblitter: move.l B_CMD,d0 ; wait till blitter has finished its work andi.l #1,d0 beq .waitforblitter rts Bye! Matthias Link to comment Share on other sites More sharing options...
Symmetry of TNG Posted September 21, 2006 Report Share Posted September 21, 2006 That is your standard atari example.. and it shows in theory how it should be set up yes.. but as you can se there are allot of places where it can be optimised. (will not go into that though). I just wanted to say that you should all take some time to dig into the blitter info and trye to understand what is going on. It is not like your 68K clrscreen rout nor the falcons blitter.. it is one of the coolest chips in the jaguar =) ..(and the buggiest... which shows that Atari was consistent with Jin&Jang The fact that it is in pixelformat is what makes it so easy to understand once you get the hang of it. This is also important when you take a step up and start to interleave screens & Z-buffer in 3d code (for example). having anything else than a pixel representation will sincerely mess up your mind ...but if you use a pixel rep. then you just have to add a "pitch" value to blitter&op flags and thats it! (almost).... and then you have 3 interleaved phrasescreens (2screen+1zbuffer ...OR for example spite data/gfx if you want to optimise your "non OP 2D engine"). So i mean understanding the blitter is a good thing. --regarding "dropouts" in poly drawing: if you set up the blitter to always draw in pixelmode... and you still have the problem then the problem is probably something else.. (calcs, clipper, or perhapps faulty pixelmode setup rout)... But if you trye to use phrasemode blitting to draw your scanlines then you most probably have a phrasealignment issue... some cases are impossible to draw in phrasemode.. and either you get problems or you have to switch to pixelmode ...thats just how it is.. and to get a glitch free rout you need to take care of it "by hand"... enough talk for now =) cheers 2 all blitter fans Link to comment Share on other sites More sharing options...
SebRmv Posted October 6, 2006 Report Share Posted October 6, 2006 SCPCD found how to correct the bug, I should have use the A1_STEP register and the UPDA1 command. which one ? ok, so I played (again) a bit with the blitter and I found two bugs: - the first one is that contrary to the Atari documentation I have, a value of 0 for one of the B_COUNT registers is not 65536. I believed that for example $10000 would be 1*65536 but instead it is just 1 ! The work around I have found is to put $28000 instead of $10000 to clear 2*32768 = 65536 words -the second one which is more problematic but which might be related to one of Orion_'s bug is that I have noticed that when clearing a buffer with the blitter, it happens that somewhere in the buffer it is not cleared. The problem is that it seems completely random. I will investigate a bit more this evening and maybe post an interesting piece of code for all of us. Link to comment Share on other sites More sharing options...
Symmetry of TNG Posted October 6, 2006 Report Share Posted October 6, 2006 just a quick reply. I get the feeling that the blitter is not quite understood here =) ....If i get time this weekend i will trye to show some basics. to put $28000 to clear 2*32768 os not a "workaround" its the way it is supposed to be! since b_count is (ycount<<16|xcount) ...working in a window fasion.. the blitter will clear xcount pixels (32768. inner loop) ...then step back with A-step pixels in x direction.. step A1Ystep in y direction (outer loop) and then reenter the inner loop.. ...?... no that made no sence at all =) sorry its friday afternoon, micro holiday! =P and I will post some stuff later explaining better. Last thing though.. I have never ever had the problem of a clrscreen missing pixels... so you must be dooing something backwards... but keep Hacking all of a sudden you find a usefull bug ;P cheers Link to comment Share on other sites More sharing options...
SebRmv Posted October 6, 2006 Report Share Posted October 6, 2006 just a quick reply. I get the feeling that the blitter is not quite understood here =) ....If i get time this weekend i will trye to show some basics. to put $28000 to clear 2*32768 os not a "workaround" its the way it is supposed to be! since b_count is (ycount<<16|xcount) ...working in a window fasion.. the blitter will clear xcount pixels (32768. inner loop) ...then step back with A-step pixels in x direction.. step A1Ystep in y direction (outer loop) and then reenter the inner loop.. ...?... no that made no sence at all =) sorry its friday afternoon, micro holiday! =P and I will post some stuff later explaining better. Last thing though.. I have never ever had the problem of a clrscreen missing pixels... so you must be dooing something backwards... but keep Hacking all of a sudden you find a usefull bug ;P cheers no, no I understand it is not a workaround. I had already the idea of doing that. I just said that the sentence of Jag_v8.pdf page 75 which said that "The counters both accept values in the range 1 to 65536 (encoded as 0)" is false: the value 0 does not encode 65536 ! for the clear bug, it appears at byte 55028 or 57076 in my case (I have noticed that thanks to my alpine) I would be pleased if others could do the test and try to clean a buffer that is larger than say 60000 bytes and see if the buffer is entirely cleared (just write a check loop) Link to comment Share on other sites More sharing options...
SebRmv Posted October 6, 2006 Report Share Posted October 6, 2006 ok, the clear bug (or better said the fill bug) seems to be fixed by clearing A1_CLIP !! thanks to Orion_, fredifredo & the coder of AvP Link to comment Share on other sites More sharing options...
Symmetry of TNG Posted October 7, 2006 Report Share Posted October 7, 2006 =) Well I would say that the statement is 100% true.. but.. to take mathematical terms the statement "does not commute" =) ....ie 65536 encodes as 0 (since the 1bit set bit will be above the word length & hence will be skipped & value ends up beeing 0) ...They did not say the other way around was true... ie "0 encodes as 65536)...zero is zero.. ...(note: zero^2 is also still zero Ahh.. ok the a1_clip thing.. well that is forbidden territory 4 shure.. (kind of took that as default since it is explained everywhere in the devman ;P --but it is interesting to hear exactly where it happens... Its funny how stable Tempest2K is considering it uses the clip function ALLOT!.. but i guess it can be used ASLONG as you follow ataris rules when not using it!... (then clear the clip function!") If you use the clip function, you will have to set it to zero everywhere you dont use it!.. but my point is that one should not clear a buffer in that way (ie bcount, y=1, x=maxvalue) eventhough it works as long as the memory is linear and the buffer is not bigger than 32768 pixels... but rather use the "window" fashion... stepx,stepy,widthofwindow and so on... it always works, you can clear whatever you want (smaller square part of window, phrase interleaved windows, make "clr-effects" by for example first clearing even, then odd lines.... and so on) phr interleaved screens WILL one day be usefull to all of you anyhow.. so its better to get used to it (example: even in a 2D shooter you can interleave screens,objects with sprite data!... that way there will be less memory pagefaults when acessing the sprite data..... clearing every 3rd phrase in a chunk of memory is then easy donw with the blitter using the step functions...) if someone is interested I might still do some examples..???.... (so people dont have to reinvent the weel for each thing..!...? just trying to be nice/helpful. /Sym Link to comment Share on other sites More sharing options...
Zerosquare Posted October 7, 2006 Report Share Posted October 7, 2006 (note: zero^2 is also still zero )I don't like that comment Its funny how stable Tempest2K is considering it uses the clip function ALLOT!Why do I have the feeling you've played with the Alpine's debugger a lot ? Link to comment Share on other sites More sharing options...
Symmetry of TNG Posted October 8, 2006 Report Share Posted October 8, 2006 I don't like that comment Why do I have the feeling you've played with the Alpine's debugger a lot ? if you can mathematically proove me otherwise I will change the statement ;P ..was speaking strictly mathematical offcourse! No actually i never got it working (except 68K part) ...that is actually an "educated guess" based on blitter knowhow and how I would have done the same effect myself... No if I am to debugg/dissassm something I move the code to my falcon and use DevPac.... its the only debugger i know & like.. which is a terrible jobb if it is a bigger-than-floppy file hence I usually never debugg... its just a matter of wrighting correct code from the start... which is a piece of cace on the jaguar *joke* Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now