Wouldn't I eliminate most of my "fat pixel" issue if I simply converted to 320x200 or 320x240?
It would mean re-writing some code and graphics, but would probably look a lot better.
Baggers said...
Hi Ariba, was only a tiny change, so I used the last mins of my dinner time to mod it [noparse]:)[/noparse]
or mode with $40 for fat Y pixels, this will give you the 128x96 res, and 6K per display!
Thanks a lot, it works great
I hope you had not to forgo the dessert. If so, it was worth it. The pixels are now really fat.
With 128*128 and a hx of 27, I can now fill the whole PAL screen with no borders. With 8 kByte screen buffer!
OBC, can you post it? so I can see if I can find out what it is? [noparse]:D[/noparse]
edit: actually OBC, thinking about it it might not be fast enough at 5mhz·to do the 160 fat pixels, as it has to palettize 4 pixels before each waitvid.
OBC, spotted it straight away [noparse]:)[/noparse]
x_tiles = 10
y_tiles = 15
not
x_tiles = 40
y_tiles = 30
as it's fat pixels tiles, not like AIGeneric, and my other drivers.
Edit: just gonna get Coley to check on his demo board, to make sure timing is right, for my_hx, but display works now on 6Mhz, as it didn't before those two changes, to x_tiles and y_tiles.
Hey OBC, looks like it's not fast enough at 5Mhz to do 160 pixels wide, so you'll either have to go back to 8 x_tiles, or use the Hybrid setup with 6Mhz [noparse]:)[/noparse] so you can do 10 x_tiles.
Thanks for the efforts on this! I think I'm going to stay at 5mhz for now given the memory constraints as
well as the fact that I'm writing something that will be shared with other Propeller users.
I will attempt to get those graphics together and take you up on your offer to show me how to import them
cleanly.
Thanks again, this driver is absolutely super. [noparse]:)[/noparse]
Hi OBC,
Here's a mod to the·version of·PropMan demo from your thread, I've also fixed a bug in drawsprite
[noparse][[/noparse]code]
pub DrawSprite(n,x,y) | i · if spriteXSZ[noparse][[/noparse]n] AND spriteYSZ[noparse][[/noparse]n] ··· x &= 127····················· ' wrap any X given as it may be incrementing past the right side ··· repeat i from 0 to spriteYSZ[noparse][[/noparse]n] ' Q&D screen area write from sprite table ····· if spritemode[noparse][[/noparse]n] & 1 ······· bytefill(screen(x,y+i), $11+i+(i<<4), spriteXSZ[noparse][[/noparse]n]>>1) ····· else ······· bytemove(screen(x,y+i), @sprites[noparse][[/noparse](n*spriteSZ)+(i*maxXSZ)], spriteXSZ[noparse][[/noparse]n]>>1)
'Changed i*maxYSZ to i*maxXSZ as that's the length per scanline of sprite
[noparse][[/noparse]/code]
maxXSZ is now 4, as that's 8 fat pixels which is technically 16 thin pixels wide
the bmp is 16x256 and so is 8 fat pixels wide, and 16 sprites deep, when you change the pixels OBC, you need to make sure you edit them keeping them fat. otherwise it won't look like what you have drawn. ( this should probably be a setting on the sprite editor that trodoss is doing )
oh, and I think I need to get that sprite cog underway, because it's taking too long in spin to restore the background and save the new position, and draw the sprite, as you have to restore all the backgrounds then get all the new positions, then draw all the sprites.
edit: don't know why the code section hasn't worked [noparse]:([/noparse]
Thank you! Hopefully I'll have a good chance to play with this more tonight and over the weekend.
Couple questions:
1. Was the sprite file created with the same Bmp8Lite command as the charfont and background?
(I noticed that you renamed the extension of the char font.)
2. Can you translate the following for me so I can enlarge the sprites if I want to?
SpriteXSZ byte 6, 6, 6, 6, 6, 6, 4, 4, 4, 4, 4, 4, 4, 4, 8, 8
SpriteYSZ byte 9, 9, 9, 9, 9, 9, 8, 8, 8, 8, 8, 8, 8, 8,16,16
and yes, it should run at 6.25Mhz also [noparse]:)[/noparse]
OBC,
You're welcome mate, and have fun playing...
and answering your questions...
1. yes, the sprite file was created with the same bmp8toLite exe.
bmp8toLite PropSpr -amsbitmap16
the font was
bmp8toLite fatfont -amscharmap16
I didn't rename the char font file, it comes out as .chr as i used amscharmap
2. yeah, I can translate the numbers for you, in SpriteXSZ there are six 6 fat pixels for the ghosts, followed by eight 4 fat pixel "propman"s with two spare, and in SpriteYSZ there are six 9 pixel high ghosts, and eight 8 pixel high "propman"s with two spare [noparse];)[/noparse]
Baggers said...
2. yeah, I can translate the numbers for you, in SpriteXSZ there are six 6 fat pixels for the ghosts, followed by eight 4 fat pixel "propman"s with two spare, and in SpriteYSZ there are six 9 pixel high ghosts, and eight 8 pixel high "propman"s with two spare [noparse];)[/noparse]
Yup.. Clear as mud.. Just kidding! IIUC, there are two 8x16 black squares for additional sprites on the end.
Now I just need an editor which shows me fat pixels while I'm editing it so I can see what I'm doing
instead of "guess and count" under mspaint. Recommendations?
True, that would give you 'fat' pixel editing, but I think what OBC is after is editing a picture that is horizontally stretched (2:1)
OBC, other than a 'custom' app to edit in that mode, you might want to draw the image deliberately 'stretched,' and use Stretch/Skew back (50%) when you are ready to save the image.
Actually, the 'stretched' pixel format reminds me a lot of the old AGI (Adventure Game Engine) graphics that Sierra used to use in their earlier games. A lot of editors for the View/Pic resources would allow you to draw them 'stretched.' It might be possible to 'hack apart' the WinAGI "View" editor and turn it into the kind of thing you are looking for.
I have made a little Paint Application with this 16 color driver.
It's very preliminary, but most functions work.
It has a zoom mode, which lets you control every pixel exactly, i.e. for sprites [noparse];)[/noparse]
This version saves the picture as Text - HexDump to the PropTerminal in a format that can be inserted in a Spin DAT section (via Clipboard).
Loading of a picture is not implemented yet, but you can insert a HexDump also in the Paint-Spin code, so that it gets downloaded with the application.
The palette must be edited in the Spin source.
The functions should be self explaning, the default picture shows a little description of the icons. Just try theme out. For Line Rectangle, Circle and so on you need to press the right mousebutton for the endpoint.
The Flood-Fill works best if you click on a pixel left top of the area to fill. The recursion of the Fill algorithm is limited to spare RAM, so you need to fill big areas in several parts.
You need a PS/2 mouse. I don't know if a compatible Mouse driver for the Hydra exists.
Default setting is PAL with 128x112 Pixel (Drawing area 128x96). You can change that to NTSC but I'm not shure that NTSC allows 224 scan lines. If not you need to decrease the y_tiles by 1. Eliminate the + $40 at mode setting to get FAT pixels.
Not bad at all! I was twisting Baggers arm by email to support a small Windows APP which does .spr, but
having the ability to do this on the Propeller is even better. How about adding the ability to load/save them
as BMP. (I think Rayman has done the groundwork here..)
I'm still amazed by the speed in which this little driver is progressing. Neat stuff!
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:
- Supporting all BMP modes for easy data exchange is very code intensive
- Also for a 4Bit-only BMP, converting of the color-palette to BMP-format and vice versa is complex.
- To include it in the Spin source, you need to convert it again.
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:
- more than 1 picture in the same file (full pictures and sprites)
- perhaps some additions for a GIF like animation
Comments
Wouldn't I eliminate most of my "fat pixel" issue if I simply converted to 320x200 or 320x240?
It would mean re-writing some code and graphics, but would probably look a lot better.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
x_tiles = 10 '*16=256
y_tiles = 15 '*16=192
mode = 0
my_hx = 22+((mode&1)<<1)
if(x&1)
data[noparse][[/noparse]y*80+x>>1]:=(data[noparse][[/noparse]y*80+x>>1]&$f0)+c
else
data[noparse][[/noparse]y*80+x>>1]:=(data[noparse][[/noparse]y*80+x>>1]&$0f)+(c<<4)
OBC, were you able to get the 320x208 mode working?
Thanks,
Doug
I'm paying for my vacation day this week.. dearly.. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I tried:
x_tiles = 10 '*16=256
y_tiles = 15 '*16=192
mode = 0
my_hx = 17+((mode&1)<<1)
and got a color screen, but it doesn't look good, kindof messed up
It appears also that the PSOneLCD may be putting a border on the screen....wasting pixels for NTSC.
Post Edited (hinv) : 9/9/2009 3:41:57 PM GMT
well at 6Mhz, I used
x_tiles = 10' '*8fat=160
y_tiles = 15 '*16=240
mode = 0
my_hx = 17+((mode&1)<<1)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Thanks a lot, it works great
I hope you had not to forgo the dessert. If so, it was worth it. The pixels are now really fat.
With 128*128 and a hx of 27, I can now fill the whole PAL screen with no borders. With 8 kByte screen buffer!
Andy
good choice of res 128x128 lol
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Suggestions?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
what settings? did you use these?
x_tiles = 10' '*8fat=160
y_tiles = 15 '*16=240
mode = 0
my_hx = 17+((mode&1)<<1)
try changing my_hx to
my_hx = 22+((mode&1)<<1)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I also change the <<6 's to *80 in the plot command (4 of them)
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
edit: actually OBC, thinking about it it might not be fast enough at 5mhz·to do the 160 fat pixels, as it has to palettize 4 pixels before each waitvid.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
Post Edited (Baggers) : 9/10/2009 12:58:53 PM GMT
Here's my code in case I missed something. Maybe an upgraded xtal is in my future?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
x_tiles = 10
y_tiles = 15
not
x_tiles = 40
y_tiles = 30
as it's fat pixels tiles, not like AIGeneric, and my other drivers.
Edit: just gonna get Coley to check on his demo board, to make sure timing is right, for my_hx, but display works now on 6Mhz, as it didn't before those two changes, to x_tiles and y_tiles.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I'll see what Coley comes up with, as I had it set for your recommendations already. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Thanks for the efforts on this! I think I'm going to stay at 5mhz for now given the memory constraints as
well as the fact that I'm writing something that will be shared with other Propeller users.
I will attempt to get those graphics together and take you up on your offer to show me how to import them
cleanly.
Thanks again, this driver is absolutely super. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Here's the sprite set for PropMAN.
Thanks!
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Here's a mod to the·version of·PropMan demo from your thread, I've also fixed a bug in drawsprite
[noparse][[/noparse]code]
pub DrawSprite(n,x,y) | i
· if spriteXSZ[noparse][[/noparse]n] AND spriteYSZ[noparse][[/noparse]n]
··· x &= 127····················· ' wrap any X given as it may be incrementing past the right side
··· repeat i from 0 to spriteYSZ[noparse][[/noparse]n] ' Q&D screen area write from sprite table
····· if spritemode[noparse][[/noparse]n] & 1
······· bytefill(screen(x,y+i), $11+i+(i<<4), spriteXSZ[noparse][[/noparse]n]>>1)
····· else
······· bytemove(screen(x,y+i), @sprites[noparse][[/noparse](n*spriteSZ)+(i*maxXSZ)], spriteXSZ[noparse][[/noparse]n]>>1)
'Changed i*maxYSZ to i*maxXSZ as that's the length per scanline of sprite
[noparse][[/noparse]/code]
maxXSZ is now 4, as that's 8 fat pixels which is technically 16 thin pixels wide
the bmp is 16x256 and so is 8 fat pixels wide, and 16 sprites deep, when you change the pixels OBC, you need to make sure you edit them keeping them fat. otherwise it won't look like what you have drawn. ( this should probably be a setting on the sprite editor that trodoss is doing )
oh, and I think I need to get that sprite cog underway, because it's taking too long in spin to restore the background and save the new position, and draw the sprite, as you have to restore all the backgrounds then get all the new positions, then draw all the sprites.
edit: don't know why the code section hasn't worked [noparse]:([/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
Were you able to get it to work at 160fat by 240 running at 6MHz?
If so, what did you have to change?
Shouldn't it work at 6.25MHz also then?
Thank you! Hopefully I'll have a good chance to play with this more tonight and over the weekend.
Couple questions:
1. Was the sprite file created with the same Bmp8Lite command as the charfont and background?
(I noticed that you renamed the extension of the char font.)
2. Can you translate the following for me so I can enlarge the sprites if I want to?
SpriteXSZ byte 6, 6, 6, 6, 6, 6, 4, 4, 4, 4, 4, 4, 4, 4, 8, 8
SpriteYSZ byte 9, 9, 9, 9, 9, 9, 8, 8, 8, 8, 8, 8, 8, 8,16,16
Thanks again!
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
yes, I had it working at 6Mhz 160x240
x_tiles = 10' '*8fat=160
y_tiles = 15'3 '*16=192
mode = 0
my_hx = 17+((mode&1)<<1)
and yes, it should run at 6.25Mhz also [noparse]:)[/noparse]
OBC,
You're welcome mate, and have fun playing...
and answering your questions...
1. yes, the sprite file was created with the same bmp8toLite exe.
bmp8toLite PropSpr -amsbitmap16
the font was
bmp8toLite fatfont -amscharmap16
I didn't rename the char font file, it comes out as .chr as i used amscharmap
2. yeah, I can translate the numbers for you, in SpriteXSZ there are six 6 fat pixels for the ghosts, followed by eight 4 fat pixel "propman"s with two spare, and in SpriteYSZ there are six 9 pixel high ghosts, and eight 8 pixel high "propman"s with two spare [noparse];)[/noparse]
hope this clears things up [noparse]:D[/noparse]
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Yup.. Clear as mud.. Just kidding! IIUC, there are two 8x16 black squares for additional sprites on the end.
Now I just need an editor which shows me fat pixels while I'm editing it so I can see what I'm doing
instead of "guess and count" under mspaint. Recommendations?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Try these: View, Zoom, Show Grid & View, Zoom, Custom Size 800 percent.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
True, that would give you 'fat' pixel editing, but I think what OBC is after is editing a picture that is horizontally stretched (2:1)
OBC, other than a 'custom' app to edit in that mode, you might want to draw the image deliberately 'stretched,' and use Stretch/Skew back (50%) when you are ready to save the image.
Actually, the 'stretched' pixel format reminds me a lot of the old AGI (Adventure Game Engine) graphics that Sierra used to use in their earlier games. A lot of editors for the View/Pic resources would allow you to draw them 'stretched.' It might be possible to 'hack apart' the WinAGI "View" editor and turn it into the kind of thing you are looking for.
It's very preliminary, but most functions work.
It has a zoom mode, which lets you control every pixel exactly, i.e. for sprites [noparse];)[/noparse]
This version saves the picture as Text - HexDump to the PropTerminal in a format that can be inserted in a Spin DAT section (via Clipboard).
Loading of a picture is not implemented yet, but you can insert a HexDump also in the Paint-Spin code, so that it gets downloaded with the application.
The palette must be edited in the Spin source.
The functions should be self explaning, the default picture shows a little description of the icons. Just try theme out. For Line Rectangle, Circle and so on you need to press the right mousebutton for the endpoint.
The Flood-Fill works best if you click on a pixel left top of the area to fill. The recursion of the Fill algorithm is limited to spare RAM, so you need to fill big areas in several parts.
You need a PS/2 mouse. I don't know if a compatible Mouse driver for the Hydra exists.
Default setting is PAL with 128x112 Pixel (Drawing area 128x96). You can change that to NTSC but I'm not shure that NTSC allows 224 scan lines. If not you need to decrease the y_tiles by 1. Eliminate the + $40 at mode setting to get FAT pixels.
Have fun..
Andy
Not bad at all! I was twisting Baggers arm by email to support a small Windows APP which does .spr, but
having the ability to do this on the Propeller is even better. How about adding the ability to load/save them
as BMP. (I think Rayman has done the groundwork here..)
I'm still amazed by the speed in which this little driver is progressing. Neat stuff!
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Excellent stuff Ariba [noparse]:)[/noparse] if you need help with loading and saving BMP's let me know [noparse]:)[/noparse]
Also, I wonder if I could get my bmp8toLite converted to sphynx [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
At the moment I think about the right format.
With BMP I see many disadvantages:
- Supporting all BMP modes for easy data exchange is very code intensive
- Also for a 4Bit-only BMP, converting of the color-palette to BMP-format and vice versa is complex.
- To include it in the Spin source, you need to convert it again.
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:
- more than 1 picture in the same file (full pictures and sprites)
- perhaps some additions for a GIF like animation
Andy