[TI ASM] Which greyscale package to use

[Kozak]

I know there's Duck's greyscale package but also a new better acclaimed package by some other guy. Can someone tell me which one I should use? I am doing some small projects for fun but I want to use the best technology.

Edit kv83: Added tag! Please use this in the future!

[Dwedit]

If you want your program to run slowly as tar, use a grayscale library.
Otherwise, design your own code to alternate planes every third frame.

[Jim e]

well unless some other guy is lord henry, I guess your talking about me.
http://calcwebzine.com/revsoft/phpBB2/v ... m.php?f=11
Theres already more than ducks package, but still need the large clipping sprite routine. Mine can drop in place of his and still work, so if you started with GPP, it's quick to replace with RGP.
I've done fast smooth scrolling, and made a pretty advanced mapper(not included). I guarantee it does better than "slowly as tar"
If you have SE than your in for real treat. The point of mine was to offer optimised routines and save as many tstates as possible and offer flawless quality for SEs but it can run on 83 by defineing.

[tr1p1ea]

You should investigate and have a shot at writing your own routine Kozak. I have it down to 70 clocks between writes atm.

[Liazon]

Umm... well after looking at Kingma's package and API's greyscale source code, it has come to my attention that there are differences between 83+ and 83+SE that will affect greyscale.

Now I'm confused as to how to go about writing my own interrupt based routine that like Dwedit said,

code to alternate planes every third frame

I thought if you wanted really simple 4 level gs, maybe not perfect, you just need to write a custom interrupt that switches planes every 3 planes. I'm not exactly sure how you switch planes though. At first I thought you allocated memory at savescreen or appbackupscrn for a second greyscale buffer, and then you use some routine and ldir to switch the contents of the two buffers. I'm not exactly sure how to go about switching buffers. Is there a command that will force all sprite routines to write to a certain buffer? Is that really it, or am I oversimplifying?

[Timendus]

I think you should take a look at how you interact with the display driver. It's not a simple matter of switching buffers, because the buffer at savesscreen is not equal to the screen, it's only a buffer. You have to send the contents of it to the screen, so if you want to change between buffers you'd probably best change the routine that sends that buffer to the screen.

And Maarten; Jim's routines are faster, smaller, and don't require a frequency setting. That makes the choice pretty simple

[ssartell]

So if you wanted to write your own I'm assuming you'd have to go through the LCD driver instead of using just a b_call() right? Is it faster to use the b_call() to load the buffer into the LCD or would it faster to write your own routine in general?

[Liazon]

Try IonFastCopy. Correct me if I'm wrong, but I think it's faster than the bcall(_copygrbuf)

Perhaps I'll edit FastCopy so I can switch the addresses that starts copying from. That means I'll have to understand how it works of course

Then I could use a custom interrupt (mode 2?) and the interrupt changes what buffer is being copied from and then runs fastcopy.

But that means that whatever is but into the dark and light planes show up real time. That is to say, as soon as I copy them to the buffer, they appear on the screen. Flickering!!!! *gasp*dies. Unless I used plotscreen as the dark plane, savescreen as the light plane, and appbackupscrn as the temporary plane. But that'd be slow right? And isn't one of them used for text shadow?

I dunno, but that's my gameplan for writing my own interrupt based 4 level greyscale right now. I think I need serious help though

[Spencer]

Page flipping typically isn't used on the 83+ series because the processor can't access the same RAM as the display (rather, it's accessed through out's to the display driver).

This flickers since it's too slow, so the best methods use rotating masks to merge the buffers in the same ratio they'd appear using page flipping, but at the same time preventing obvious page changes.

[ssartell]

I don't want to use ION or any shell for that matter. I just want to know if b_call(_GrBufCpy) would be faster than a fairly efficient routine.

I don't really get your last post spencer...

[Dwedit]

If, for some very strange reason, you hate shells, just take ionfastcopy out of ionf.z80. But why wouldn't you want to use a shell?

[ssartell]

Experience mainly. The more I do on my own, the better I get.

[Timendus]

Perhaps I'll edit FastCopy so I can switch the addresses that starts copying from. That means I'll have to understand how it works of course

Then I could use a custom interrupt (mode 2?) and the interrupt changes what buffer is being copied from and then runs fastcopy.

But that means that whatever is but into the dark and light planes show up real time. That is to say, as soon as I copy them to the buffer, they appear on the screen.

Bingo. Add a dithering method using masks to make it flicker less, and you have Duck's/Jim's greyscale package, except for all the sprite routines and such of course...

[tr1p1ea]

You may want to use double buffering as well. Copy everything to the inactive buffers then either switch pointers or copy them to the active buffers (the ones used by the interrupt routine).

[ssartell]

which ones are used by the interrupts?