rush6432

Hello everyone! Just trying to blit an image from on location to another and i have that working without issues, however is there such a way to allow the blitter to only copy the data as if the transparency flag were set (ignoring color 0,0,0) so that the image could be copied over to the original but not show the background?

Im esentially blitting a sprite to a larger bitmap and i'm having issues with the source image containing the black background still and when blitting this transfers over onto the destination bitmap.

Was curious if there was some option that was supposed to be set at the time of blitting to achieve this?

Just thought i'd report back here and say that it works Thanks for pointing out what needed to be changed. Very much appreciated.

collision:
    clr.w d0
    clr.w d1
    move.w OBJ1X,d0
    add.w OBJ1W,d0
    move.w OBJ2X,d1
    cmp.w d0,d1
    blt .none; if OBJ2X < (OBJ1X+OBJ1W) goto .none => should be if OBJ2X > (OBJ1X+OBJ1W) goto .none

    clr.w d0
    clr.w d1
    move.w OBJ1X,d0
    move.w OBJ2X,d1
    add.w OBJ2W,d1
    cmp.w d0,d1
    bgt .none; if (OBJ2X+OBJ2W) > OBJ1X goto .none => should be if (OBJ2X+OBJ2W) < OBJ1X goto .none

    clr.w d0
    clr.w d1
    move.w OBJ1Y,d0
    add.w OBJ1H,d0
    move.w OBJ2Y,d1
    cmp.w d0,d1
    blt .none; if OBJ2Y < (OBJ1Y+OBJ1H) goto .none => should be if OBJ2Y > (OBJ1Y+OBJ1H) goto .none

    clr.w d0
    clr.w d1
    move.w OBJ1Y,d0
    add.w OBJ1H,d0
    move.w OBJ2Y,d1
    cmp.w d0,d1
    blt .none; if OBJ2Y < (OBJ1Y+OBJ1H) goto .none (why do it again ? :p)

    clr.w d0
    clr.w d1
    move.w OBJ1Y,d0
    move.w OBJ2Y,d1
    add.w OBJ2H,d1
    cmp.w d0,d1
    bgt .none; if (OBJ2Y+OBJ2H) > OBJ1Y goto .none => should be if (OBJ2Y+OBJ2H) < OBJ1Y goto .none

    move.w #$FFFF,BG
    rts
    
.none:
    move.w #$0000,BG
    rts

 

"cmp" computes: destination - source => condition code.

To check if destination > source :

    cmp src, dst
    bgt   dst_greater_than_src

To check if destination < source :

    cmp    src, dst
    blt    dst_lower_than_src

 

AHhh. extra cpy of routine in there i did that this morning at around 7am with no coffee at work in 5 mins so i was going from memory what i had written at home.

THanks for the input and clearing that up. ill have to make some adjustments at home to the code and report back

So i quickly wrote a small bounding box collision setup somewhat here. having trouble getting it to work. am i doing something wrong thats totally obvious?? A second or third pair of eyes is greatly appreciated

(forgive the clr commands, just a bit picky on making sure registers are "clean" before use )

collision:

clr.w d0

clr.w d1

move.w OBJ1X,d0

add.w OBJ1W,d0

move.w OBJ2X,d1

cmp.w d0,d1

blt .none

clr.w d0

clr.w d1

move.w OBJ1X,d0

move.w OBJ2X,d1

add.w OBJ2W,d1

cmp.w d0,d1

bgt .none

clr.w d0

clr.w d1

move.w OBJ1Y,d0

add.w OBJ1H,d0

move.w OBJ2Y,d1

cmp.w d0,d1

blt .none

clr.w d0

clr.w d1

move.w OBJ1Y,d0

add.w OBJ1H,d0

move.w OBJ2Y,d1

cmp.w d0,d1

blt .none

clr.w d0

clr.w d1

move.w OBJ1Y,d0

move.w OBJ2Y,d1

add.w OBJ2H,d1

cmp.w d0,d1

bgt .none

move.w #$FFFF,BG

rts

.none:

move.w #$0000,BG

rts

all defined variables (OBJ1H,OBJ1W,OBJ2H,OBJ2W,OBJ1X,OBJ1Y, ECT ECT are all defined as words.)

the x and y locations of objects are directly tied to an objects position in the list and the height/width are defined elsewhere as words.

Seems like the bgt/blt commands are not working... or im just overlooking something stupid.

Basically it checks if its below or above on x and y axis to determine if its hitting the object and if it is it changes background from black to white

I did write this snippet quickly here so forgive any errors but i feel like i'm majorly overlooking the simplest thing here as to why it wont work.

Good to know there is a patch... I thought I was the only one that had this problem at first with the mini usb port falling off, but I guess not.... sent pics to Dan @ goatstore to see what he thinks... Sad part is i've only used the skunk a handfull of times (can count on two hands the amount of times if used it) and its broken already...

Sent Kskunk a pm and turns out there is no patch unfortunately.

Good to know there is a patch... I thought I was the only one that had this problem at first with the mini usb port falling off, but I guess not.... sent pics to Dan @ goatstore to see what he thinks... Sad part is i've only used the skunk a handfull of times (can count on two hands the amount of times if used it) and its broken already...

Glad you're up and running & cheers for the post.

So am i Figured someone else might be able to use the info in the future to help troubleshoot.

Now i just have to see if i can get my broken skunk 3 fixed.... mini usb connector literally CAME OFF when removing the mini usb cord. never been anything but carefull with my electronics. Quite dissapointed to say the least...

SebRmv has one IIRC, but he doesn't visit Jagware often.

I think i figured out how to get reliable transfers with the alpine and newer pc hardware. I setup a 2ghz machine with ubuntu so i could use the linux dev tools and make my own dev environment. Found that i kept getting stub communication errors when trying to transfer to the alpine using (using read, aread, fread). Made sure to have th rdb.rc file with all the .db files it calls in the same folder as wdb and rdbjag. Also set the pprot (parallel port rate of transfer) to 9 instead of the default 4. Also set my parallel port to "EPP" Instead of ECP Mode in the bios.

All calls using "fread" Seem to work without a errors and quite quick! FIgured it post here if anyone happens to have the same issue in the future.

You might want to try belboz's live CDs.

Seems to work ok

Got it to read stuff to the alpine but good god that thing is picky...

seems like any rom file or binary file i upload it dumps out with an illegal instruction which i KNOW is not the way these binary files are coded.

Not sure what is wrong. I do remember the last alpine i had never had issues like this. I also seem to be getting quite a bunch of errors when uploading (ie losing communication with the stub) Any suggestions?

Im sure someone else here has an alpine as well. If so please chime in with your thoughts

It looks like it suffers from the same problem as the other Jaguar PC tools from that era (e.g. madmac and aln) : they work fine under Windows 9x, Vista and Seven, but crash under Windows 2000 and XP. There's no real solution AFAIK, except maybe running it in a Windows 9x virtual machine, but I don't know if the parallel port communication would work correctly.

Thats what i thought. I did manage to get it to work on my windows 7 laptop which was odd, but i had no lpt port on that machine...

I like the idea of the linux route. if i cant get it working shortly, ill start looking into it. Rather run a good copy of linux if it comes down to it.

Does anyone have any information on which operating systems WDB.exe and rdbjag.exe are compatible with? Ive tried under windows xp only to receive a stack fault error from the program itself when trying to run it. Oddly enough it runs on my other computer with windows7 but it doesnt have a parallel port. Im assuming it works with windows95/98 without issues but id rather hear this from someone before tracking down a copy of that OS.

Dosbox doesnt seem to support LPT ports but the program does work under dosbox without a hitch.

Any suggestions or personal experiences anyone cares to share?