MaxCoderz

http://www.geocities.com/jimm09876/83.html

This guy did some grayscale stuff, and I thought you guys might liek to see.

Also, I cannot log in because I haven't recieved my activation emial, Joe, if you read this, could you send it to yuengcheng@aol.com? Thanks

I've manually activated your account. Try to log in now

Wow, that is amazing!

Has anyone tested this on hardware? I wonder how it runs on non-SE.

It is incredibly fast on my 84+ SE...Very fast grayscale, probably the fastest I have seen. Only problem for me is one that occurs with other programs. Such as PhantomStar (Joe...I should have told you earlier), v4.0 of zDoom, and other games that use a different fastcopy. In the case of zDoom, the fastcopy routine from Venus was used, and that made the screen a bit jumpy. This is what occurs with PhantomStar and with James's greyscale games. So far, if you use IonFastCopy, or the gsCopyBuffer, the game should run fine on the 84+ SE...It has been tested and proven to fix the problem.

edit: just a mild flicker too.

This is SE only tech though?

These problems only occur on my 84+ SE...it seems to be the fastcopy. It's funny, it seems the 83's aren't as combatible with the 84's as everybody thought!

Some 84+ have a slower lcd. I've heared of very bad cases where the lcd was even about two times slower than 83/83+. There are a couple threads about this at detacheds.

Hmm, his routines use interlacing by bytes (like RIGview). Its faster but uglier then interlacing by pixel (like GPP)

But hey it's still grayscale right? Darn it! I wish my S.E. could work so I could see it.... looks interesting

wow. that's pretty darn cool.

W0W, that is really interesting! I wonder if this could be developed further?

Ok, moving screenshots actually move now. Looks awesome.

Well the author of the greyscale routines has just sent all this stuff and a DBZ movie into ticalc.org. The movie is pretty damn sweet!

What does interlacing by byte mean?

With RIGVIEW im pretty sure that it interlaces by byte by taking a byte from the first buffer and copying it to the screen then taking the next 2 from the next buffer and copying it to the screen, basically mixes them all up in one pass rather than switching between 2 complete buffers. This reduces flicker as each pass you change which bytes get displayed amoungst one another. A byte in the dark buffer will still get displayed 2/3 of the time and a byte in the light buffer will still get displayed 1/3 of the time, but it is not as consistant as showing the cokmplete buffer, so it is harder to distinguish ... thus harder to notice flicker.

Ducks GPP takes this further and interlaces by bits. It basically takes a mask and applys it to both buffers and the resultant byte is copied to the screen ... the mask changes all the time but it follows the same principal as before ... basically it will take 1/3 the info from the first buffer and mixes it with 2/3 the info from the second. The bits from each buffer change when you change the mask so the flickering is reduced greatly as you never really see a consistant portion of either buffer. This is all handled by the fastcopy routine. I believe it was Tijl Coosemans who originally came up with the idea of taking it to a bit level. Duck's implementation is so fine tuned that he managed to basically get all of this done within the wasted clock cycles of a fastcopy routine. An amazing achievement .

I hope that was understandable ... .