Jump to content
Jagware
Sign in to follow this  
Orion_

Blitter Again

Recommended Posts

Orion_    1

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 ?

Share this post


Link to post
Share on other sites
Matthias    0

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

Share this post


Link to post
Share on other sites
GT Turbo    5
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 ;)

Share this post


Link to post
Share on other sites
SebRmv    2
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.

Share this post


Link to post
Share on other sites
Matthias    0

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

Share this post


Link to post
Share on other sites

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 ;)

Share this post


Link to post
Share on other sites
SebRmv    2
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
SebRmv    2
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)

Share this post


Link to post
Share on other sites
SebRmv    2

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 :D

Share this post


Link to post
Share on other sites

=)

 

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

Share this post


Link to post
Share on other sites
Zerosquare    10
(note: zero^2 is also still zero ;) )
I don't like that comment :lol:

 

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 ? :shifty:

Share this post


Link to post
Share on other sites
I don't like that comment :lol:

 

Why do I have the feeling you've played with the Alpine's debugger a lot ? :shifty:

 

:P 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* :)

Share this post


Link to post
Share on other sites
Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×