Is the raster effect (quick palette switch) useless?

For anything related to VDP (plane, color, sprite, tiles)

Moderators: BigEvilCorporation, Mask of Destiny

greatkreator
Very interested
Posts: 158
Joined: Sat May 12, 2012 7:37 pm
Location: Ukraine

Is the raster effect (quick palette switch) useless?

Post by greatkreator » Mon Jul 30, 2012 2:33 pm

It has been spent quite a lot time trying to get the raster effect (quick palette switch while the current frame rendering) work for displaying at least static images.
But the "best" results have unacceptable quality.
Noises, flickering, different pixel width.
Is that effect useless in general?
Is it only suitable for demos or some very special images that hide its drawbacks.
But I still have a little hope that someone has been lucky to get it work.
Otherwise I wouldn't ask this question.

tristanseifert
Interested
Posts: 35
Joined: Tue Sep 06, 2011 2:16 am
Location: /dev/sa0
Contact:

Post by tristanseifert » Mon Jul 30, 2012 2:45 pm

It is useful, and when done right will work perfectly fine. Don't set your HInt t o something excessive like every 4 lines - if you have much processing going on, it may not get processed by the 68k for a while. You also have limited time to transfer colours, realistically only 16 during active display. You can still use the effect with it's limits relatively well - Here's an example of how I used it to highlight a menu item:

Image

Do observe those CRAM dots - I fixed them by delaying the HInt by a small loop of no-ops.

The effect is nice when you get it to work, but often you need to pay special attention to have your art work with it, as well as not expecting excessive transfer capacities during HInt.

The code for it has to be incredibly optimised, hand written assembly. If you're using C, I'd recommend you write the interrupt handler in assembly. That's not a problem for me as I always write in assembly (=V) but if you're using SGDK or something that may be the cause of your flickering problems.
Last edited by tristanseifert on Mon Jul 30, 2012 2:52 pm, edited 1 time in total.

greatkreator
Very interested
Posts: 158
Joined: Sat May 12, 2012 7:37 pm
Location: Ukraine

Post by greatkreator » Mon Jul 30, 2012 2:50 pm

Actually the best results I get using just the main method not the horizontal interruption.

P.S. This one really impressive:
Image

But still "special" and "niche". The image has been created to use the raster effect but not the raster effect has been used to show an image.
Last edited by greatkreator on Mon Jul 30, 2012 3:20 pm, edited 2 times in total.

tristanseifert
Interested
Posts: 35
Joined: Tue Sep 06, 2011 2:16 am
Location: /dev/sa0
Contact:

Post by tristanseifert » Mon Jul 30, 2012 3:15 pm

greatkreator wrote:Actually the best results I get using just the main method not the horizontal interruption.
It's all a matter of how fast you re-load the palettes - The faster, the better. A hand-written piece of assembly like the following would probably work if it's given a few lines of valuable processing time.

Code: Select all

HInt_Counter EQU $FF0000

HInt:
		movem.l	d0-d1/a0-a1, -(sp)

		lea		$C00000, a0

		move.b	HInt_Counter, d0
		lsl.w	#4, d0
		lea		ColourTable(pc, d0.w), a1
		
		move.l	#$C0000000, (a0)	; address to load to 
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)
		move.w	(a1)+, (a0)

		addq.b	#1, HInt_Counter
		cmp.b	#$15, HInt_Counter
		blo.s	@continue
		
		move.b	#0, HInt_Counter

@continue:
		movem.l	(sp)+, d0-d1/a0-a1
		rte
		
ColourTable:
		; ...put your colours here... the code is written for transferring 16 colours per interrupt
I haven't tested it, but it should work. I've got the colour writing loop unrolled to save the CPU overhead of a loop.

greatkreator
Very interested
Posts: 158
Joined: Sat May 12, 2012 7:37 pm
Location: Ukraine

Post by greatkreator » Mon Jul 30, 2012 3:23 pm

Have you tried this on real hardware?
A huge amount of similar code has been written last few months.

If I would have at least 16 colors per each 40 tile line without any disgusting artifacts and other drawbacks I would be very happy.

By the way what hardware/flash-cartridge do you use to put the code in sega?

tristanseifert
Interested
Posts: 35
Joined: Tue Sep 06, 2011 2:16 am
Location: /dev/sa0
Contact:

Post by tristanseifert » Mon Jul 30, 2012 3:51 pm

greatkreator wrote:Have you tried this on real hardware?
A huge amount of similar code has been written last few months.

If I would have at least 16 colors per each 40 tile line without any disgusting artifacts and other drawbacks I would be very happy.

By the way what hardware/flash-cartridge do you use to put the code in sega?
I'm gonna write a little test ROM demonstrating this effect - probably something incredibly lame like squares of various colours that have a different one every, say, 32 pixels.

I also think you mean 40 pixel line - 40 tiles is more than the height of the screen. I use the Everdrive currently - but I'm going to replace that with something more powerful soon.

greatkreator
Very interested
Posts: 158
Joined: Sat May 12, 2012 7:37 pm
Location: Ukraine

Post by greatkreator » Mon Jul 30, 2012 4:04 pm

I mean 16 colors per 40 tiles width x 1 tile height horizontal tile-line.

I use Everdrive as well and like it very much.
Just interesting what powerful features do you need that it lacks?

tristanseifert
Interested
Posts: 35
Joined: Tue Sep 06, 2011 2:16 am
Location: /dev/sa0
Contact:

Post by tristanseifert » Mon Jul 30, 2012 4:45 pm

Well, here ya go:

Image

That's a picture off of the actual hardware(Yeah, sorry about the quality) of the code I wrote, which loads a new entire palette line each 8 pixels — note the CRAM dots, which are mostly visible on the bottom two lines of colour. It should be self explanatory, but if not, tell me and I'll try my best to explain it to you.

Get the ROM here and a zipball of the source here.[/url]
greatkreator wrote:I mean 16 colors per 40 tiles width x 1 tile height horizontal tile-line.

I use Everdrive as well and like it very much.
Just interesting what powerful features do you need that it lacks?
You will find out in all due time... (DUN DUN DUUUUN)

greatkreator
Very interested
Posts: 158
Joined: Sat May 12, 2012 7:37 pm
Location: Ukraine

Post by greatkreator » Mon Jul 30, 2012 4:55 pm

Thank you very much for your reply and test.

You cannot even imagine how many such images I have seen for last few months (: Each time I thought I was close to get the result but... you know the outcome.

Such test square-filled images are done in few minutes. Not a problem.
The problem is to get a meaningful image. Ideally of course a photo image.

tristanseifert
Interested
Posts: 35
Joined: Tue Sep 06, 2011 2:16 am
Location: /dev/sa0
Contact:

Post by tristanseifert » Mon Jul 30, 2012 4:59 pm

greatkreator wrote:You cannot even imagine how many such images I have seen for last few months (: Each time I thought I was close to get the result but... you know the outcome.

Such test square-filled images are done in few minutes. Not a problem.
The problem is to get a meaningful image. Ideally of course a photo image.
The problem with doing that is that there simply isn't any tools out there that'll quantatise each 8 pixel tall line as a separate art, palette and map.

I'm gonna try finding some image and slicing it into 8 pixel slices and seeing where that gets me.

greatkreator
Very interested
Posts: 158
Joined: Sat May 12, 2012 7:37 pm
Location: Ukraine

Post by greatkreator » Mon Jul 30, 2012 5:05 pm

Just try to put 16 colors per tile to invoke "them".

sega16
Very interested
Posts: 251
Joined: Sat Jan 29, 2011 3:16 pm
Location: U.S.A.

Post by sega16 » Mon Jul 30, 2012 5:15 pm

You should look at direct color it reloads a new color every other pixel.
viewtopic.php?t=1203 I tried the sega cd version on my television and see no such dots. Also I wrote a good converter for direct color that makes importing an image a click away http://sega16.x10.mx/directcolor.html
Also if you want to do water like sonic the hedgehog does you can simply set the hblank interrupt to what line you want the water to appear on.

tristanseifert
Interested
Posts: 35
Joined: Tue Sep 06, 2011 2:16 am
Location: /dev/sa0
Contact:

Post by tristanseifert » Mon Jul 30, 2012 5:28 pm

sega16 wrote:You should look at direct color it reloads a new color every other pixel.
viewtopic.php?t=1203 I tried the sega cd version on my television and see no such dots. Also I wrote a good converter for direct color that makes importing an image a click away http://sega16.x10.mx/directcolor.html
Also if you want to do water like sonic the hedgehog does you can simply set the hblank interrupt to what line you want the water to appear on.
Nope - that direct colour mode sucks massive balls if you want to do something else during the CPU time instead of wasting it all on displaying an image, especially if you don't have the Sega CD. As for the dots - they happen when you write to CRAM, but since you're writing the BG colour they're not visible, only when there's another colour at the pixel where the access was tried.

Also, if he'd wanted water, I'm sure he'd have stated that, not that he wants to reload a colour every 8 pixels. =V

greatkreator
Very interested
Posts: 158
Joined: Sat May 12, 2012 7:37 pm
Location: Ukraine

Post by greatkreator » Mon Jul 30, 2012 6:02 pm

Why are you so tough to the direct colour mode (:

I am ok to spend all the 100% of performance to show a still image.
Actually I need exactly that.

Do you know a way to overcome those CRAM artifacts?

You are reading my mind - I don't need any water (: reload colours per each 8 pixels is quite enough for me. If I would need the sonic water I would without fail for sure request it.

tristanseifert
Interested
Posts: 35
Joined: Tue Sep 06, 2011 2:16 am
Location: /dev/sa0
Contact:

Post by tristanseifert » Mon Jul 30, 2012 6:11 pm

greatkreator wrote:Why are you so tough to the direct colour mode (:

I am ok to spend all the 100% of performance to show a still image.
Actually I need exactly that.

Do you know a way to overcome those CRAM artifacts?

You are reading my mind - I don't need any water (: reload colours per each 8 pixels is quite enough for me. If I would need the sonic water I would without fail for sure request it.
Oh - if that's the case, give me a little time and I'll have a demo up for you using direct colour mode. The CRAM artefacts shouldn't be a problem with direct colour, but outside of it you just have to write the colour during horizontal or vertical blanking, not active display.

As for why I'm so harsh on it - I don't like the idea of using most of the CPU time to draw the display - I write complex code that needs all the time I can get, but that's just me. =P

Post Reply