Jump to content
Jagware
LinkoVitch

OP not drawing from 1st line

Recommended Posts

LinkoVitch    0

I have only just noticed this Developer section! OOPS! :)

 

anyway.

 

More playing and I am now drawing something a bit more exciting than a blank area of RAM on the screen, I have a 32x32 16bit RGB object. It displays fine, except that the OP seems to jump ahead about 6 lines into the object from the start address I am giving. If I pad the start of the object with 6 lines worth of nothing I get the object displayed correctly. Likewise if I adjust the object list routine to subtract 384 from the start address of the object it renders correctly.

 

I have checked the address of the data in RAM and compared this with the constructed object list and it all looks fine. I even tried tweaking the object list creation code to shift the address one bit more and one bit less to make sure I hadn't screwed up there and the broken gfx proved I hadn't.

 

I just tried with a 320x200 image and that also loses lines off the top. (I have vague memories of something like this way back in 2003.. but not looked at it in earnest :) )

 

any ideas?

Share this post


Link to post
Share on other sites
LinkoVitch    0

Don't know, I cannot test as neither seem to want to run on Windows 7.

 

I have hacked a work around in my list gen code. Takes the dwidth value of the object, shifts it left 3 bits and then multiplies it by 6, so far works. But seems really bizarre.

 

I guess you have never had this issue with your own object code?

Share this post


Link to post
Share on other sites
Matmook    1

Strange...

Perhaps a stupid question but who know ... Is your object on the top of the screen (0,0 for example) ?

If yes, I will look in the video init rout (VDB).

If no, have you more information please ? :)

Share this post


Link to post
Share on other sites
LinkoVitch    0

Not a stupid question at all.. although when the object was at the top of the screen I didn't notice it as it looked like it was just clipping off the top of the screen. When I moved it into the middle of the screen was when I noticed the top 6 lines were missing.

 

I checked and it seems to occur on different sized objects. I have a 320x200 image I used for testing which is a photograph, and I subtracted 6 lines worth from the start address before inserting it into the object list, and it showed 6 more lines at the top of the image too!

 

For the data portion of the bitmap object, all I am doing is masking off only the bits I need, so assuming the object address is in D0

 

and.l #$3FFFF8,d0

 

Then shifting it into position

 

lsl.l #8,d0

 

this will get combined with the rest of the long word with or.l before being written to RAM

 

I have dumped the object list that is built and checked it out with a programmers calculator to ensure the bits all make sense and reference the correct addresses. If the address is left as the actual address of the bitmap, 6 lines go missing. If I subtract 6 lines worth of data from the address then I get the full object.

 

A thought just occurred to me…

 

I recall reading somewhere that you have to have at least 2 objects in the object list or the OP can become upset, this is usually two branch objects at the start of the list that essentially frame the screen. My object list at the moment is just 2 16bit bitmap object and a stop object. Could it be something weird happening because I do not have the branch objects at the start perhaps?

 

Unfortunately I am at work at the moment and have no access to my code or Jag :(

 

thanks

Share this post


Link to post
Share on other sites
Matmook    1
I recall reading somewhere that you have to have at least 2 objects in the object list or the OP can become upset, this is usually two branch objects at the start of the list that essentially frame the screen. My object list at the moment is just 2 16bit bitmap object and a stop object. Could it be something weird happening because I do not have the branch objects at the start perhaps?

 

Yes, you must have 2 branch object to inform the OP to not draw :

- before VDB

- after VDE

 

It could be that ... Here is the piece of code I use (not sure the comments are good ...) :

 

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; create initial branch object
; a1 : addess of stop object
; a0 : current op list pointer 
op_create_branch:	
movem.l 	d0-d4,-(sp)

move.l	a1,d2						; compute next object link
make_op_link	d2,d3	
clr.l	d0
or.l	d2,d0	

; create first branch objet
; branch if VC > a_vde 
; stop displaying sprite if VC reach the bottom
; of the (visible) screen	
move.l  #(BRANCHOBJ|O_BRLT),d1  	; VC < VDE
move.w  a_vde,d4                	; for YPOS
or.l	d3,d1						; Do LINK overlay
lsl.w   #3,d4                   	; Make it bits 13-3
or.w    d4,d1

move.l	d0,(a0)+					; store object
move.l	d1,(a0)+

; create second branch objet
; branch if VC < a_vdb 
; stop displaying sprite if VC is less than the begin 
; of the (visible) screen
move.l  #(BRANCHOBJ|O_BRGT),d1  	; VC > VDB
move.w  a_vdb,d4                	; for YPOS
or.l	d3,d1						; Do LINK overlay
lsl.w   #3,d4                   	; Make it bits 13-3
or.w    d4,d1

move.l	d0,(a0)+					; store object
move.l	d1,(a0)+

movem.l (sp)+,d0-d4	
rts	
_op_create_branch:	 

.macro	make_op_link
andi.l	#$3FFFF8,\1		; Ensure alignment/valid address
move.l	\1,\2
lsr.l	#8,\1
lsr.l	#3,\1
swap	\2
clr.w	\2
lsl.l	#5,\2
.endm

 

Share this post


Link to post
Share on other sites
LinkoVitch    0

Cheers Matmook.

 

I will give that a whirl, having some working branch object code to look over may help me fix my own too :D (wrote some for VDB and VDE areas but it isn't working properly so I was lazy and skipped ahead as I wanted to play :) )

 

I'll see if that fixes this weird 6 line thing and report back too.

 

thanks for your help.

Share this post


Link to post
Share on other sites
Tyrant    0

It is probably that you're missing the branch objects and it thus starts drawing 6 lines before it should (I'm guessing the OP doesn't reset VC until it gets to VDB, therefore it starts drawing those 6 lines with the old VC which was at the bottom of the screen).

 

However, you should also check to make sure that your bitmap data is phrase aligned.

Share this post


Link to post
Share on other sites
LinkoVitch    0
It is probably that you're missing the branch objects and it thus starts drawing 6 lines before it should (I'm guessing the OP doesn't reset VC until it gets to VDB, therefore it starts drawing those 6 lines with the old VC which was at the bottom of the screen).

 

Its not drawing early, it draws at the right time, just that the data it is drawing is starting 6 lines into the object, so the top 6 lines are missing. The object is also in the middle of the screen.

 

However, you should also check to make sure that your bitmap data is phrase aligned.

 

It is, the object appears correct and not skewed. I am going to try as Matmook suggested and see if he OP is simply having a hissy fit due to the lack of VDB/VDE branches.

 

Hopefully find out tonight, assuming I can pull myself away from my planned tasks :)

Share this post


Link to post
Share on other sites
Tyrant    0

When I said "drawing" I didn't necessarily mean displaying. I think what's happening is that the vertical count doesn't reset quite as quickly as it should, and so you re-create the object at the start of the vertical blanking period, and the op "draws" 6 lines of it (while the beam is shut off so nothing reaches the screen) before VC resets to being less than the height of the object. Part of that drawing process is of course to reduce the height by a line and increase the data pointer by a line, meaning that when it starts up again it continues from where it left off before.

 

Edit: another quick fix solution might be to just add 12 (6 * 2) to the line on which you fire the VBL interrupt.

Share this post


Link to post
Share on other sites
LinkoVitch    0
Yes, you must have 2 branch object to inform the OP to not draw :

- before VDB

- after VDE

 

It could be that ... Here is the piece of code I use (not sure the comments are good ...) :

 

No, I can say it definitely IS that :D

 

Hope you are attending AC2011, so I can thank you with beers :)

 

Looks like your branch ordering at the start is the opposite way around to mine, but also has highlighted another bug in my own. Having a working list to go from will be a big help in fixing my own code so its a double whammy :D

 

Thanks again.. now ONWARDS! :D

Share this post


Link to post
Share on other sites
LinkoVitch    0

Just for giggles, the bug in my branch making code?

 

The second branch object, for some reason I had shifted the YPOS field 2 bits instead of 3! so it was getting an object code of type 7! The OP wasn't too happy with that it would seem :D otherwise it seems to work :D YAY!

Share this post


Link to post
Share on other sites
Matmook    1
Hope you are attending AC2011

Sure ! AC2011 is the place to be !!! :wub:

so I can thank you with beers :)

I don't drink alcohol but I would be very happy to try an unknow Low-alcohol beer ! :lol:

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.


×