I bet you could use 16-color bitmaps directly pretty easily...
You just need to either process the palette info, or specify the palette to be what you want...
If you look at my i.e., "PSM_SerialControl" you can find some code for processing them from SD.
But, you could just as easily embedd them in your app, if they're small...
High saturated colors can't well combined with others (all the colors with 8 or F as low nibble). The F-nibble colors are
theoretically not allowed because there is no room for the color-carrier modulation. They are not included in Chips graphics_palette.spin.
But sometimes there is no alternative to high saturated colors (i.e for red), then only a trial with different combinations work.
Rayman
I looked at your PSM_SerialControl code. I see the LCD needs RGB data, this makes the conversion simple. But the
Propeller TV colors are more chroma and intensity, than RGB, and this translation needs a lookup table (3 bytes for every propeller color). For loading a BMP an optimal color palette must be calculated (the right 16 colors out of 2^24) and then every color must be compared again this palette to find the best matching one. I will see how much code is necessary for that.
Ariba said...
I plan to add Load and Save to an SD card. At the moment I think about the right format. With BMP I see many disadvantages:
Is it not much better to have the raw palette and pixel data with a preceding little header? This can be loaded directly into the Propeller RAM without converting anything. And you can also include it directly into a Spin source with the file command. And defining my own format allows some usefull additions:
The main advantage is to be able to save to a format that other graphics apps could handle.· PCX might be an viable option.· Unfortunately, like BMP, it has a lot of variations, so while it might be possible to save a file which could be loaded, the external app may save a file your app couldn't handle without a lot of code.
However, a raw save has a lot of advantages as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObExForum
OnePinTVText driver: ObExForum
This can draw and edit 128x96 and 128x192 pixel pictures in 16 colors. (128x192 in 2 parts)
The colors are now editable, and the whole palette can be saved to SD card (*.PAL)
Bitmaps can be loaded and saved to SD card in the same RAW data format, that Baggers converter produces (*.BIT).
There is just not enough remaining RAM for implementing a BMP converter.
But with Bagges tool you can convert 8bit BMPs to a .BIT and palette file, and then edit with my App.
The resulting pictures are normally included in a Spin source and for that you need this RAW format anyway.
It's also possible to save only the first 24 rows instead of the full picture. This is for Sprite bitmaps.
The ZIP contains also a (very) short description of the functions.
This code uses the combined Mouse and Keyboard driver. With this driver the mouse or keyboard stuck sometimes for
a little moment, but it was the only way to fit the code into the Memory.
For a next version I plan to use the SD card to temporary store pixeldata, this should free a lot of memory, and more
function will be possible. But this needs a lot of changes...
Hi OBC, yeah I'm back [noparse]:D[/noparse] had a rest now, after getting the demo done for TGS [noparse]:D[/noparse]
and I'm working on a surprise app for Ken to show at the show in Eindhoven. [noparse]:)[/noparse]
I'm betting I'm going to have to move forward to 96mhz or 100mhz to get the speed I'm going
to need to finish this game. Sorry guys, the next update will require a faster crystal. [noparse]:)[/noparse]
Hi, fezmonkey, I'm glad you like the driver [noparse]:)[/noparse]
How to make your own colours is quite easy, there is about 86 colours, high nibble is the hue, and the low nibble is the brightness, but brightness less than 8 are b&w, so all hue's with brightness less than 8 are b&w, ranging from black at $02 ( anything less than $02 isn't a good number, as it sends a value below the 0.3v and makes the tv think a sync signal is being sent, and can disrupt the display ) so $02 to $07 is black to white in grey scale, and then brightness of $08 and $0f are saturated colours, brightness $09 is really dark, so then then you have a brightness from $0a to $0e so 5*16 hues + 2to7 so roughly 86 colours for this driver, you do have more choice with the $08 and $0f colours, so have a play with them, there is an app, that puts all the colours on screen for the prop, but I can't remember where it is, it was in Andre's Hydra book iirc, and I believe the sources have been released.
anyway, three of the colours are $02 in that demo, as they weren't needed in that particular palette, hence the two blacks at the end, you can use them for your own if you wanted to keep with the first 14 that is. lol
Sorry if that's a bit confusing, but I've had some bad news today, a good friend of mine, and Legend of the ZX Spectrum days Jonathan Smith ( Joffa Smiff to his friends ) died at 10:30 this morning, so I've been a bit shocked by the news.
All is going just great with the exception of one thing...maybe someone can help.
I am trying to move a sprite on the screen and to do so, I am clearing the screen then drawing everything in every loop. As expected, this is causing flickering. A double buffer would be nice but I am not able to fit double buffer in memory! Strange as the buffer is 12K so I should be able to fit 2 but I guess the code is taking the rest of the memory.
I have looked at other sprite drivers out there but I am not finding one that I could understand (or fit my needs) so I am trying to work something with this driver.
Is there anything I can do to eliminate flickering? Or somehow fit 2 buffers in there?
Update: I added this
vsync ''this is what I added
longfill(screen(0,0),0,128*192/2/4)
DrawSprite(0)
and now it is no longer flickering but man it got so much slower!
Post Edited (fezmonkey) : 6/26/2010 4:57:46 PM GMT
You said in earlier posts something about using a lower resolution to allow double buffering. Did you get it to work? This is also good because the pixels are not square now!
Maybe this would also solve all my other problems I had in the last post.
One question, how many sprites I can add before I can run into problems? I am not talking about memory. I am talking about the time we have to draw sprites in the vsync.
I will be happy with 32 but 64 would be fantastic!
What software did you use to create the sprites?
Post Edited (fezmonkey) : 6/26/2010 8:41:06 PM GMT
The sprites are created with the little paint program from the previous page of this thread.
I don't think you can have such a lot of sprites with the technik of my demo. If you draw all sprites right after the
CopyBuffer call, and draw the most top sprites first, then you can have maybe 10 or so. If you have many sprites at the
bottom of the screen it can be more (they must be written to the video buffer before the TV driver picks theme from the
buffer, for later scan lines you have more time).
It is working fine with 16 sprites but not more. I am trying to make an option to flip the sprite (horizontally or vertically) but I know nothing when it comes to propeller assembly. Do you think you can help me by changing tour sprite driver to flip the sprite. For example, we could use the highest bit in x as an option to flip the sprite horizontally and use the highest bit in the 7 as an option to flip the sprite vertically. What do you think?
Flipping the sprites while writing theme to the screen is certainly possible, but needs a total rewrite of the Sprite Assembly routine.
As you can see from the date of the demo, I've done this 7 month ago and now I'm busy with a totally different project.
I just have not the time at the moment to go back into this driver, sorry.
It is not so easy to do, because every byte holds 2 pixels, and you can't just draw the bytes in revers order. Also clipping needs to be done different.
I got it all down but I am stuck at a little thing. Maybe Andy is the best one to answer this question?
I am trying to load sprites but it is not working!
c := 0'sprite index
repeat i from 0 to (16*16/2)-1
byte[noparse][[/noparse]@spr_data][noparse][[/noparse](c*(16*16/2))+i] := 3
in "spr_data" you have 4 sprites, how are they in memory? I would expect the code above to make the whole sprite color 3 but instead I get every other pixel colored for the first 2 rows on the 4 sprites.
I guess my main questions is, how do I fill in the sprite data for one of the 4 sprites in "spr_data"?
fezmonkey, the reason you're getting every other pixel coloured, is because you're writing 3 to the byte, and it's a 4bit video mode, therefore you need to write to each nibble, eg $33
The sprites are mapped side by side in a normal screen bitmap. 8 Sprites fit in one "spriterow" every spriterow is 16 pixels in height. This picture should make it clear:
Every Byte holds 2 pixels (one in each nibble), like Baggers said, this makes it a bit complicated. So 1 pixelrow has 64 bytes.
The first 8 bytes are from Sprite 0 the next 8 bytes from Sprite 1 and so on.
I've chosen this scheme, because you can draw Sprites exactly like the Background picture with the same Draw program.
Because I use only 4 Sprites in the demo, I stored only the top part, that is: only 1 "spriterow" (a 128x16 pixels bitmap) which are 1024 bytes. If you need more than 8 sprite definitions, you can just add another row of sprites. Up to 6x8=48 Sprites fit in a full 128x96 bitmap.
Neat. The Atari 8-bit computers used almost the exact wide pixels on the GTIA display chip for 16 simultaneous colors out of a palette of 256. There was a 16 hue, constant luminance mode, a 16 luminance single color mode and a 9 register color of your choice mode.
What a cool project!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Talbot
New Market, MD, USA
Comments
You just need to either process the palette info, or specify the palette to be what you want...
If you look at my i.e., "PSM_SerialControl" you can find some code for processing them from SD.
But, you could just as easily embedd them in your app, if they're small...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Very nice app!
I had started working on something similar, but you beat me to it [noparse];)[/noparse] I think I will instead keep working on 'font' editing.
Keep up the great work!
--trodoss
Post Edited (trodoss) : 9/14/2009 4:05:08 PM GMT
in the attached Moon Patrol demo?
Thanks
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Try this palette:
High saturated colors can't well combined with others (all the colors with 8 or F as low nibble). The F-nibble colors are
theoretically not allowed because there is no room for the color-carrier modulation. They are not included in Chips graphics_palette.spin.
But sometimes there is no alternative to high saturated colors (i.e for red), then only a trial with different combinations work.
Rayman
I looked at your PSM_SerialControl code. I see the LCD needs RGB data, this makes the conversion simple. But the
Propeller TV colors are more chroma and intensity, than RGB, and this translation needs a lookup table (3 bytes for every propeller color). For loading a BMP an optimal color palette must be calculated (the right 16 colors out of 2^24) and then every color must be compared again this palette to find the best matching one. I will see how much code is necessary for that.
Andy
http://forums.parallax.com/showthread.php?p=809933
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
However, a raw save has a lot of advantages as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
This can draw and edit 128x96 and 128x192 pixel pictures in 16 colors. (128x192 in 2 parts)
The colors are now editable, and the whole palette can be saved to SD card (*.PAL)
Bitmaps can be loaded and saved to SD card in the same RAW data format, that Baggers converter produces (*.BIT).
There is just not enough remaining RAM for implementing a BMP converter.
But with Bagges tool you can convert 8bit BMPs to a .BIT and palette file, and then edit with my App.
The resulting pictures are normally included in a Spin source and for that you need this RAW format anyway.
It's also possible to save only the first 24 rows instead of the full picture. This is for Sprite bitmaps.
The ZIP contains also a (very) short description of the functions.
This code uses the combined Mouse and Keyboard driver. With this driver the mouse or keyboard stuck sometimes for
a little moment, but it was the only way to fit the code into the Memory.
For a next version I plan to use the SD card to temporary store pixeldata, this should free a lot of memory, and more
function will be possible. But this needs a lot of changes...
Andy
Sorry I've been quiet for a while, got a demo for Tokyo coming up on 24th, so mega busy, I'm not ignoring this thread, just don't have time.
Ariba,Looks good, can't wait to have a play in about 9 days.
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Just thought I'd give this thread a little nudge and see if we can bring you back soon?
[noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
and I'm working on a surprise app for Ken to show at the show in Eindhoven. [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Here's a fix to your moon patrol demo, with comments on where/why it was going wrong for you.
God it's good to be back on the prop [noparse]:D[/noparse] lol
Jim.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
I'm betting I'm going to have to move forward to 96mhz or 100mhz to get the speed I'm going
to need to finish this game. Sorry guys, the next update will require a faster crystal. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I have a simple questions. Where do these numbers come from? I am trying to figure out how to make my own colors.
palette byte $02,$07,$28,$8d,$ba,$1a,$db,$3d,$8f,$5f,$3f,$5b,$d8,$04,$02,$02
Also, any reason on why 3 of the colors are $02?
How to make your own colours is quite easy, there is about 86 colours, high nibble is the hue, and the low nibble is the brightness, but brightness less than 8 are b&w, so all hue's with brightness less than 8 are b&w, ranging from black at $02 ( anything less than $02 isn't a good number, as it sends a value below the 0.3v and makes the tv think a sync signal is being sent, and can disrupt the display ) so $02 to $07 is black to white in grey scale, and then brightness of $08 and $0f are saturated colours, brightness $09 is really dark, so then then you have a brightness from $0a to $0e so 5*16 hues + 2to7 so roughly 86 colours for this driver, you do have more choice with the $08 and $0f colours, so have a play with them, there is an app, that puts all the colours on screen for the prop, but I can't remember where it is, it was in Andre's Hydra book iirc, and I believe the sources have been released.
anyway, three of the colours are $02 in that demo, as they weren't needed in that particular palette, hence the two blacks at the end, you can use them for your own if you wanted to keep with the first 14 that is. lol
Sorry if that's a bit confusing, but I've had some bad news today, a good friend of mine, and Legend of the ZX Spectrum days Jonathan Smith ( Joffa Smiff to his friends ) died at 10:30 this morning, so I've been a bit shocked by the news.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Yes this is a very nice driver, one of my favorites!
You can get the color numbers from the "Graphics_Palette.spin" that comes with the PropellerTool (see Examples/Library/)
Andy
I am trying to move a sprite on the screen and to do so, I am clearing the screen then drawing everything in every loop. As expected, this is causing flickering. A double buffer would be nice but I am not able to fit double buffer in memory! Strange as the buffer is 12K so I should be able to fit 2 but I guess the code is taking the rest of the memory.
I have looked at other sprite drivers out there but I am not finding one that I could understand (or fit my needs) so I am trying to work something with this driver.
Is there anything I can do to eliminate flickering? Or somehow fit 2 buffers in there?
Update: I added this
vsync ''this is what I added
longfill(screen(0,0),0,128*192/2/4)
DrawSprite(0)
and now it is no longer flickering but man it got so much slower!
Post Edited (fezmonkey) : 6/26/2010 4:57:46 PM GMT
You said in earlier posts something about using a lower resolution to allow double buffering. Did you get it to work? This is also good because the pixels are not square now!
Maybe this would also solve all my other problems I had in the last post.
http://forums.parallax.com/showthread.php?p=851724
It does not really use double buffering but has a fast Assembly Sprite routine.
Andy
Very sweet. This is perfect for what I need.
One question, how many sprites I can add before I can run into problems? I am not talking about memory. I am talking about the time we have to draw sprites in the vsync.
I will be happy with 32 but 64 would be fantastic!
What software did you use to create the sprites?
Post Edited (fezmonkey) : 6/26/2010 8:41:06 PM GMT
The sprites are created with the little paint program from the previous page of this thread.
I don't think you can have such a lot of sprites with the technik of my demo. If you draw all sprites right after the
CopyBuffer call, and draw the most top sprites first, then you can have maybe 10 or so. If you have many sprites at the
bottom of the screen it can be more (they must be written to the video buffer before the TV driver picks theme from the
buffer, for later scan lines you have more time).
Andy
It is working fine with 16 sprites but not more. I am trying to make an option to flip the sprite (horizontally or vertically) but I know nothing when it comes to propeller assembly. Do you think you can help me by changing tour sprite driver to flip the sprite. For example, we could use the highest bit in x as an option to flip the sprite horizontally and use the highest bit in the 7 as an option to flip the sprite vertically. What do you think?
As you can see from the date of the demo, I've done this 7 month ago and now I'm busy with a totally different project.
I just have not the time at the moment to go back into this driver, sorry.
It is not so easy to do, because every byte holds 2 pixels, and you can't just draw the bytes in revers order. Also clipping needs to be done different.
Andy
I got it all down but I am stuck at a little thing. Maybe Andy is the best one to answer this question?
I am trying to load sprites but it is not working!
c := 0'sprite index repeat i from 0 to (16*16/2)-1 byte[noparse][[/noparse]@spr_data][noparse][[/noparse](c*(16*16/2))+i] := 3in "spr_data" you have 4 sprites, how are they in memory? I would expect the code above to make the whole sprite color 3 but instead I get every other pixel colored for the first 2 rows on the 4 sprites.
I guess my main questions is, how do I fill in the sprite data for one of the 4 sprites in "spr_data"?
Thanks in advance
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
The sprites are mapped side by side in a normal screen bitmap. 8 Sprites fit in one "spriterow" every spriterow is 16 pixels in height. This picture should make it clear:
Every Byte holds 2 pixels (one in each nibble), like Baggers said, this makes it a bit complicated. So 1 pixelrow has 64 bytes.
The first 8 bytes are from Sprite 0 the next 8 bytes from Sprite 1 and so on.
I've chosen this scheme, because you can draw Sprites exactly like the Background picture with the same Draw program.
Because I use only 4 Sprites in the demo, I stored only the top part, that is: only 1 "spriterow" (a 128x16 pixels bitmap) which are 1024 bytes. If you need more than 8 sprite definitions, you can just add another row of sprites. Up to 6x8=48 Sprites fit in a full 128x96 bitmap.
Hope this helps
Andy
What a cool project!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Talbot
New Market, MD, USA
It was to make an Amstrad CPC style display.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·