Hello,
This is the result of mixing colorset1 and colorset2. On the Dragon screen, the colors are darker, the photo doesn't do justice to the result screen.
So we get 16 colors at the same time, and they are 16 different colors on the real thing.
cheers
pere
Switching graphic pages
Re: Switching graphic pages
I like the mixed colour sets even more. It should be possible to make some nice looking landscape images with those colours.
As you say, there's some work to convert images for display. I suppose something like photoshop could be used to do a colour depth reduction to the new palette.
As you say, there's some work to convert images for display. I suppose something like photoshop could be used to do a colour depth reduction to the new palette.
Stew
Re: Switching graphic pages
hello sorchard,
my first try on switching three screen images has given as result an incredibly fast flickering on the real Dragon.
Maybe this results too slow ...
Do you think that it is mandatory to switch pages on every HSYNC? The more pages to switch the less frames we get.
Maybe it could be done freely without synchronisation ... seems dangerous but one never knows.
I use Irfanview to reduce dimensions (down to 256 x 192) and lower the number of colors. It creates BMP files not too big.
The BMP format is straightforward, in fact I have a Java app (building it,not yet finished) but it already reads the header, the colors table and shows this info.
Now I will add a bit of analysis to convert the BMP data to SG24 (was my first idea)
Each byte in the BMP has the color of two Dragon pixels, so two bytes contain the color info that must be packed in a SG24 byte (allowing only one color)
The greatest difficulty will be how to assign each BMP color to one of the Dragon SG24 (the one that best suits the final image).
Its a matter of time to get some results
cheers
pere
my first try on switching three screen images has given as result an incredibly fast flickering on the real Dragon.
Maybe this results too slow ...
Do you think that it is mandatory to switch pages on every HSYNC? The more pages to switch the less frames we get.
Maybe it could be done freely without synchronisation ... seems dangerous but one never knows.
I use Irfanview to reduce dimensions (down to 256 x 192) and lower the number of colors. It creates BMP files not too big.
The BMP format is straightforward, in fact I have a Java app (building it,not yet finished) but it already reads the header, the colors table and shows this info.
Now I will add a bit of analysis to convert the BMP data to SG24 (was my first idea)
Each byte in the BMP has the color of two Dragon pixels, so two bytes contain the color info that must be packed in a SG24 byte (allowing only one color)
The greatest difficulty will be how to assign each BMP color to one of the Dragon SG24 (the one that best suits the final image).
Its a matter of time to get some results
cheers
pere
Re: Switching graphic pages
I'm not sure how successful it would be without sync as you would no longer be in control of when each frame is displayed. The base address can only change once per frame but the colour set can change anywhere so you could end up with some very strange results.
SG24 has got me thinking... What if one frame had one half of the pixels and the other frame had the other half of the pixels. You would then have 64x192 colour resolution. (But not as bright as solid colours)
SG24 has got me thinking... What if one frame had one half of the pixels and the other frame had the other half of the pixels. You would then have 64x192 colour resolution. (But not as bright as solid colours)
Stew
Re: Switching graphic pages
That sounds nice, but isn't really SG24 a text mode?
I mean, can you switch pages for that mode?
I mean, can you switch pages for that mode?
Re: Switching graphic pages
@robcfg
switching pages should be simply telling the SAM what is the first RAM address to be used, so POKEing $FFC6-$FFD2 will set the desired first byte.
Well, that is how I hope it will work ... wait and read!
If not done it will begin at $400 overwriting the DOS area
@sorchard
I will give mixing two SG24 screens a try, one for the left 4 bits of every byte in a row and the other with the right ones ... the problem is that we are going to mix a color with black and I suspect that the color will get too darkened.
The switcher will be much the same as the one used for 2 identical colorsets of PMODE3 just changing the mode.
The hardest part will be filling the two screens in some way that lets us compare colors (darkened and normal)
I mean that the red color in a position that has red in both images will be 'clearly' red, but a neighbour block that has black on the other screen will show up far different, very dark.
Lets say that we will be working in fact with: black, 8 original colors and 8 darkened ones.
So, if we want to have two different colors in a byte, red and blue for instance, we will always get them darkened. If they were in different bytes they could be the normal ones.
Do you see any way to get around this problem?
Hope to have something running before the week-end.
Will let you know the results ... better I will upload some screenshots
cheers
pere
switching pages should be simply telling the SAM what is the first RAM address to be used, so POKEing $FFC6-$FFD2 will set the desired first byte.
Well, that is how I hope it will work ... wait and read!
If not done it will begin at $400 overwriting the DOS area
@sorchard
I will give mixing two SG24 screens a try, one for the left 4 bits of every byte in a row and the other with the right ones ... the problem is that we are going to mix a color with black and I suspect that the color will get too darkened.
The switcher will be much the same as the one used for 2 identical colorsets of PMODE3 just changing the mode.
The hardest part will be filling the two screens in some way that lets us compare colors (darkened and normal)
I mean that the red color in a position that has red in both images will be 'clearly' red, but a neighbour block that has black on the other screen will show up far different, very dark.
Lets say that we will be working in fact with: black, 8 original colors and 8 darkened ones.
So, if we want to have two different colors in a byte, red and blue for instance, we will always get them darkened. If they were in different bytes they could be the normal ones.
Do you see any way to get around this problem?
Hope to have something running before the week-end.
Will let you know the results ... better I will upload some screenshots
cheers
pere
Re: Switching graphic pages
@robcfg
Sorry I didn't answer your very first question.
The semigraphic modes allow the user to mix colored blocks with characters, yes.
But the way to show a char in those modes is tricky 'cause you have to POKE the very same ASCII value in 12 bytes one under the other (columnwise)
This opens another window. You can mix parts of different chars in the same 12 vertical bytes, so with a lot of luck and studying the way
they are made, you could have strange but nice combinations ... always green coloured, of course as SG8,12,24 don't have the color change possibility.
cheers
pere
Sorry I didn't answer your very first question.
The semigraphic modes allow the user to mix colored blocks with characters, yes.
But the way to show a char in those modes is tricky 'cause you have to POKE the very same ASCII value in 12 bytes one under the other (columnwise)
This opens another window. You can mix parts of different chars in the same 12 vertical bytes, so with a lot of luck and studying the way
they are made, you could have strange but nice combinations ... always green coloured, of course as SG8,12,24 don't have the color change possibility.
cheers
pere
Re: Switching graphic pages
hello,
talking to spanish collegues about mixing screen images, I have written there that I would really like to mix a PMODE3 with a SG24 so that despite SG24 would force 8 bits in the same byte to be the same color, then the PMODE3 could be used to distinguish between them easily without the annoying effect of the black color (I hope), we could expect to get some 9x4 = 36 different colors ...
This will be next one after the 2xSG24 mix
How to prepare the two screens is going to be a nightmare ... but it must be tried
cheers
pere
PS a lot of a ideas, projects and not time enough for all of them
talking to spanish collegues about mixing screen images, I have written there that I would really like to mix a PMODE3 with a SG24 so that despite SG24 would force 8 bits in the same byte to be the same color, then the PMODE3 could be used to distinguish between them easily without the annoying effect of the black color (I hope), we could expect to get some 9x4 = 36 different colors ...
This will be next one after the 2xSG24 mix
How to prepare the two screens is going to be a nightmare ... but it must be tried
cheers
pere
PS a lot of a ideas, projects and not time enough for all of them
Re: Switching graphic pages
Perhaps just try all darkened colours first, to see what the higher resolution looks like. It sounds like a difficult job to make an optimal screen with dark and bright colours combined.pser1 wrote:So, if we want to have two different colors in a byte, red and blue for instance, we will always get them darkened. If they were in different bytes they could be the normal ones.Do you see any way to get around this problem?
I know what you mean. I'm learning new things all the time, so my list of things to try gets ever longer...pser1 wrote:PS a lot of a ideas, projects and not time enough for all of them
Stew
Re: Switching graphic pages
Other than be sure to select PAL or NTSC according to how well it corresponds to your PC's display, no (usually NTSC will be the better choice there).pser1 wrote: @sixxie
Do you know of any hidden XRoar parameter that could be tweaked to get rid of the unbearable flickering while switching pages
with the program I uploaded inside an VDK image?
In a real Dragon64 works flawlessly, its nice to see 10 colors on a PMODE3 image (no movement at all)
Sadly the ability to set the host refresh rate is beyond SDL 1.2 (and probably most other toolkits), and even if it were not, the emulated refresh rate will never quite match, unless forced to (no code for that yet though, everything syncs to the audio device).
BTW, sounds like you might be interested in some of linville's earlier postings here: http://vdgtricks.blogspot.ae/