Is the raster effect (quick palette switch) useless?
Moderators: BigEvilCorporation, Mask of Destiny
-
- Very interested
- Posts: 158
- Joined: Sat May 12, 2012 7:37 pm
- Location: Ukraine
Is the raster effect (quick palette switch) useless?
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.
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.
-
- Interested
- Posts: 35
- Joined: Tue Sep 06, 2011 2:16 am
- Location: /dev/sa0
- Contact:
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:
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.
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.
-
- Very interested
- Posts: 158
- Joined: Sat May 12, 2012 7:37 pm
- Location: Ukraine
Actually the best results I get using just the main method not the horizontal interruption.
P.S. This one really impressive:
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.
P.S. This one really impressive:
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.
-
- Interested
- Posts: 35
- Joined: Tue Sep 06, 2011 2:16 am
- Location: /dev/sa0
- Contact:
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.greatkreator wrote:Actually the best results I get using just the main method not the horizontal interruption.
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
-
- Very interested
- Posts: 158
- Joined: Sat May 12, 2012 7:37 pm
- Location: Ukraine
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?
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?
-
- Interested
- Posts: 35
- Joined: Tue Sep 06, 2011 2:16 am
- Location: /dev/sa0
- Contact:
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.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 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.
-
- Very interested
- Posts: 158
- Joined: Sat May 12, 2012 7:37 pm
- Location: Ukraine
-
- Interested
- Posts: 35
- Joined: Tue Sep 06, 2011 2:16 am
- Location: /dev/sa0
- Contact:
Well, here ya go:
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]
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]
You will find out in all due time... (DUN DUN DUUUUN)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?
-
- Very interested
- Posts: 158
- Joined: Sat May 12, 2012 7:37 pm
- Location: Ukraine
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.
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.
-
- Interested
- Posts: 35
- Joined: Tue Sep 06, 2011 2:16 am
- Location: /dev/sa0
- Contact:
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.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.
I'm gonna try finding some image and slicing it into 8 pixel slices and seeing where that gets me.
-
- Very interested
- Posts: 158
- Joined: Sat May 12, 2012 7:37 pm
- Location: Ukraine
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.
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.
-
- Interested
- Posts: 35
- Joined: Tue Sep 06, 2011 2:16 am
- Location: /dev/sa0
- Contact:
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.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.
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
-
- Very interested
- Posts: 158
- Joined: Sat May 12, 2012 7:37 pm
- Location: Ukraine
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.
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.
-
- Interested
- Posts: 35
- Joined: Tue Sep 06, 2011 2:16 am
- Location: /dev/sa0
- Contact:
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.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.
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