OBC, there ya go mate, have a butchers,
PS, i've not done anything with the space character ( AS_VIEWED ) not sure what you've done with that on AI
anyway, have fun.
two routines
print( s , x , y , c , b )
s=string, x=x pixel, y=y pixel, c=colour, b=background colour(-1=transparent background)
and
prtchr( ch , x , y , c , b )
same again, but ch=character to print.
Hi OBC, sorry about that, the aspx is just a renamed zip extension for transparency. I just sent it back in the same format my linux machine saw it in. It doesn't seem to care what the extension is as it examines the file header itself to ascertain the file type anyway.
I have now updated the software so that it draws the sprites in a synchronized manner so they can overlap each other (I was getting to that Baggers )
Rather than updating the original link I am feeding this out piecemeal as I believe that it's a useful teaching aid to see how a program evolves and why things are done the way they are. A beautifully polished PASM object is usually too nice (or awkward) to unwrap but all the hack code that led up to it makes it more understandable and therefore reusable.
Peter, go for scalable fonts then [noparse]:)[/noparse] I was going to go for 16 colour thin fonts, like the score digits in the MrHeli.bmp [noparse];)[/noparse]
Jeff, looks good mate, don't think we have a pacman game for prop, ( except on Zicog cp/m machines [noparse]:D[/noparse] )
@Peter,
Have to agree with Baggers that 16 color "thin" fonts would be a great "next step." A 4x8 font should look good. How are you going to keep score on Mr Heli without it? [noparse];)[/noparse]
OBC, The only other "Pac Man" that I know of were example program(s) in the Hydra book, so would probably be the first actual one for the prop. I could add 16 color support in the FontGenerator program if you plan on using it for graphics.
I noted an interesting artifact, in this revised version of my pacman demo, I had to
double up some of my verticle lines. I've included the source graphic in the attached zip.
Note, this is non-playable version at this point.
I've switched to using sprites instead of redefined characters.
Gonna need some sprite collision.. [noparse]:)[/noparse] Any suggestions on how to define the movement limitations?
Gonna need some sprite collision.. [noparse]:)[/noparse] Any suggestions on how to define the movement limitations?
OBC
I was playing around with a few more features in between my real work and so sprite collision and animation was one of them. I am still testing these routines and they are partially working but I am also playing around with some other more general methods. I am not a game programmer and other than a rough brickout game on an ARM chip I can't say I have even touched a sprite thing before, so it's all new territory! Not sure how things like this are typically done but I'd rather find out afterwards than before, it's more fun.
The method I am using at the moment is a brute compare boundaries (x,y,xsize,ysize) but there are some optimizations that I am thinking of. Also the sprite needs animation tables for different effects so I may look at virtual sprites that are linked to real sprites but maintain their own variables.
But I'm supposed to be working on font rendering too
The RestoreShadow routine had a Q&D which is commented out in your version but take a look at the last version I posted. Basically it needs to know that it shouldn't restore if it hasn't been drawn yet which is what happens at initialization. Just uncomment the first line of the routine to do a Q&D as it is unlikely that you would draw a sprite from 0,0 coordinates. As the routines are refined a more comprehensive sprite method will be used as mentioned beforehand.
Here is the current version that I am testing though I have been bogged down in other work. From this point I would probably start to implement a new sprite method and tie in collision and animation with that. The Collide routine was just a quick and buggy hack that will be totally replaced then.
@OBC - these routines do the global screen restore, make shadows, and draw sprites so that there are no glitches with moving objects.
Hi all, I've updated OBC's PropMan demo by adding a 16colour fat pixel font 4x8 ( well 3x8 with gap ) each char takes 16bytes and I've only included 64 as with that res, you pretty much won't get decent upper/lower font lol, which also saves memory, as it's 1K for the font. there are lots of empty·chars in the fatfont.bmp to give you room to add special chars also.
Hi all, I've updated OBC's PropMan demo by adding a 16colour fat pixel font 4x8 ( well 3x8 with gap ) each char takes 16bytes and I've only included 64 as with that res, you pretty much won't get decent upper/lower font lol, which also saves memory, as it's 1K for the font. there are lots of empty·chars in the fatfont.bmp to give you room to add special chars also.
Very nice font!
You might be able to get it down to 1 long per char (4 bits per horizontal line), which would be 96 longs if it was a single color font, but 1k for a 96 char font is not bad at all.·
LOL!· True about an upper/lower char font at that resolution.· I guess if you are going for the 'Retro Atari' look you could use them.
Baggers said...
Hi All, again [noparse]:)[/noparse]
Here it is, ( yes OBC, I did say it was soon lol )
It's my graphics converter, which converts 8bit bmp images to raw binary files, depending on what settings you use.
...
Any troubles with it, get me on here, and post your bmp, so I can try it, and explain what you forgot, or what I didn't allow for lol.
Baggers,
I was looking at the generated .pal file(s), and even on the sample file included (with the app) and·it looks like some of the values are a bit off from what are used in the palette:
How difficult would it be to make a 320x240 16 color fat pixel driver?
It would use up 19200 bytes for the frame buffer, and would look real nice on my PSOneLCD and also be real nice for a commodore emulator.
Hi hinv, it's easy to convert this driver to 320x240, I did it 256x192 because I wanted to keep the memory size to that of graphics, btw, C64 was 320x200, also it wasn't always fat pixel, the main c64 font was thin pixels.
I've played with this bitmap driver last night, and I like it very much [noparse]:)[/noparse] Thanks Baggers !
For PAL mode I had to change this:
my_hx = 22+((mode&1)<<1) in the CON section to
my_hx = 22+((mode&1)<<2)
So you get 22 for NTSC and 26 for PAL, otherwise there was no stable PAL picture (with 5MHz crystal on ProtoBoard).
Then I tried to make a 128 x 96 version, but had no success. This would need only 6 kByte for the screen buffer, which
allows double buffering. The pixels are more square, and the resolution is high enough for many games.
I changed the y_tiles to 6, this was easy, but doubling the pixel heigth was not possible. I changed #1 to #2 where the_vx
was hardcoded in the Assembly part, and I tried to disable interlacing, but nothing worked.
I removed the _vx code, as the ptr gets incremented each time it reads a word for 4 pixels, so that it wraps, I'll do a mod, so you can have it 128x96 also then, and post.
Why am I having so much trouble getting sprites to look correct?
I've found that if I position them too close to each other they tend to look crunched.
I finally (by trial and error) found that I had to position them vertically to get them to appear
correctly so I could use the MakeSprite command. Yet it doesn't look like you have
this problem at all with the character file. (thanks BTW)
Thanks for the 320x200 mode! It'll make ripping backgrounds from C64 spyhunter a LOT easier. [noparse]:)[/noparse]
Jeff, the Character file, is because the bitmap is 256x16, each 8x8 is a char ( fat pixel 4x8 )
also, you can grab them in a tall bmp, if you put your sprites on a screen for me, I'll organise them to another bmp, and tell you how to grab them with bmp8tolite, and then you can change
Comments
/me runs off to play...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
PS, i've not done anything with the space character ( AS_VIEWED ) not sure what you've done with that on AI
anyway, have fun.
two routines
print( s , x , y , c , b )
s=string, x=x pixel, y=y pixel, c=colour, b=background colour(-1=transparent background)
and
prtchr( ch , x , y , c , b )
same again, but ch=character to print.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
*Peter*
This time I have uploaded the file as a ZIP.
Scalable fonts was my next little play but see who beats me to it!
*Peter*
I'm not sure if redefined characters should be used in this manner.
I suspect if I continue on this track, I may need to grab a bottle of Aspirin.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Rather than updating the original link I am feeding this out piecemeal as I believe that it's a useful teaching aid to see how a program evolves and why things are done the way they are. A beautifully polished PASM object is usually too nice (or awkward) to unwrap but all the hack code that led up to it makes it more understandable and therefore reusable.
@OBC - I'll try out your code shortly
*Peter*
Here's a flash video of Mr Heli flying along with other sprites.
pbjtech.com/propeller/Mr%20Heli.avi
*Peter*
Jeff, looks good mate, don't think we have a pacman game for prop, ( except on Zicog cp/m machines [noparse]:D[/noparse] )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Have to agree with Baggers that 16 color "thin" fonts would be a great "next step." A 4x8 font should look good. How are you going to keep score on Mr Heli without it? [noparse];)[/noparse]
OBC, The only other "Pac Man" that I know of were example program(s) in the Hydra book, so would probably be the first actual one for the prop. I could add 16 color support in the FontGenerator program if you plan on using it for graphics.
double up some of my verticle lines. I've included the source graphic in the attached zip.
Note, this is non-playable version at this point.
I've switched to using sprites instead of redefined characters.
Gonna need some sprite collision.. [noparse]:)[/noparse] Any suggestions on how to define the movement limitations?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
I was playing around with a few more features in between my real work and so sprite collision and animation was one of them. I am still testing these routines and they are partially working but I am also playing around with some other more general methods. I am not a game programmer and other than a rough brickout game on an ARM chip I can't say I have even touched a sprite thing before, so it's all new territory! Not sure how things like this are typically done but I'd rather find out afterwards than before, it's more fun.
The method I am using at the moment is a brute compare boundaries (x,y,xsize,ysize) but there are some optimizations that I am thinking of. Also the sprite needs animation tables for different effects so I may look at virtual sprites that are linked to real sprites but maintain their own variables.
But I'm supposed to be working on font rendering too
*Peter*
(Not playable yet, but dots abound and sprites are moving)
Minor issues to work out.. Like why my dots aren't disappearing fast enough..
Question for Peter & Baggers:
Can you guys tell me why I'm loosing my top-left corner when using the MakeSprite commands?
Thanks
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
The RestoreShadow routine had a Q&D which is commented out in your version but take a look at the last version I posted. Basically it needs to know that it shouldn't restore if it hasn't been drawn yet which is what happens at initialization. Just uncomment the first line of the routine to do a Q&D as it is unlikely that you would draw a sprite from 0,0 coordinates. As the routines are refined a more comprehensive sprite method will be used as mentioned beforehand.
*Peter*
@OBC - these routines do the global screen restore, make shadows, and draw sprites so that there are no glitches with moving objects.
*Peter*
@Peter, added your new routines.. Much better!
Gave the game it's own thread in the Hydra/Gaming forum.
PropMAN
http://forums.parallax.com/showthread.php?p=838967
A nice way to spend a day off. Thanks guys!
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
This new video format looks great, and doesn't scroll on my PSOne LCD like AiGeneric does.
Thanks,
Doug
http://forums.parallax.com/showthread.php?p=838967
hinv, thanks!! and I'm glad it's working on the LCD without scroll [noparse]:D[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
You might be able to get it down to 1 long per char (4 bits per horizontal line), which would be 96 longs if it was a single color font, but 1k for a 96 char font is not bad at all.·
LOL!· True about an upper/lower char font at that resolution.· I guess if you are going for the 'Retro Atari' look you could use them.
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
NYC Area Prop Club
Prop Forum Search (Via Google)
·
I was looking at the generated .pal file(s), and even on the sample file included (with the app) and·it looks like some of the values are a bit off from what are used in the palette:
The first 16 characters that I am seeing in hex in the file are:
11 37 28 8d ba 1a db 3d 8f 5f 3f 5b d8 14 11 11
It looks like the $02 , $04,· and $07 are getting turned into $11, $14, and $37 respectively.
Was the intent to use the generated .pal file directly (via an include file) in an application?· If not, then it may not be an issue.
--trodoss
Post Edited (trodoss) : 9/8/2009 4:47:58 PM GMT
trodoss, yeah, I noticed that too, I'll have a look at that next. thanks [noparse];)[/noparse] as I also was gonna use the generated pal file.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Note to self: Move the PropMAN code outside of the actual driver tonight and move the driver into
the OBJect section.
I love the speed of development on this one! Keep the momentum going gang!
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
How difficult would it be to make a 320x240 16 color fat pixel driver?
It would use up 19200 bytes for the frame buffer, and would look real nice on my PSOneLCD and also be real nice for a commodore emulator.
Thanks,
Doug
for 320x200 use
x_tiles = 10
y_tiles = 13
mode = 0
my_hx = 17+((mode&1)<<1)
for 320x240 use
x_tiles = 10
y_tiles = 15
mode = 0
my_hx = 17+((mode&1)<<1)
You'll have to change the y<<6 in the plot routines, to *80
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
For PAL mode I had to change this:
my_hx = 22+((mode&1)<<1) in the CON section to
my_hx = 22+((mode&1)<<2)
So you get 22 for NTSC and 26 for PAL, otherwise there was no stable PAL picture (with 5MHz crystal on ProtoBoard).
Then I tried to make a 128 x 96 version, but had no success. This would need only 6 kByte for the screen buffer, which
allows double buffering. The pixels are more square, and the resolution is high enough for many games.
I changed the y_tiles to 6, this was easy, but doubling the pixel heigth was not possible. I changed #1 to #2 where the_vx
was hardcoded in the Assembly part, and I tried to disable interlacing, but nothing worked.
Any ideas, how this can be done?
Andy
I removed the _vx code, as the ptr gets incremented each time it reads a word for 4 pixels, so that it wraps, I'll do a mod, so you can have it 128x96 also then, and post.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
or·mode·with $40 for fat Y pixels, this will give you the 128x96 res, and 6K per display!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
Question:
Why am I having so much trouble getting sprites to look correct?
I've found that if I position them too close to each other they tend to look crunched.
I finally (by trial and error) found that I had to position them vertically to get them to appear
correctly so I could use the MakeSprite command. Yet it doesn't look like you have
this problem at all with the character file. (thanks BTW)
Thanks for the 320x200 mode! It'll make ripping backgrounds from C64 spyhunter a LOT easier. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
also, you can grab them in a tall bmp, if you put your sprites on a screen for me, I'll organise them to another bmp, and tell you how to grab them with bmp8tolite, and then you can change
byte Sprites[noparse][[/noparse]16*maxYSZ*maxSprites]
to
Sprites file "Sprites"
Obviously moving it from the VAR section and into the DAT section.
Then you won't need to use the make sprite func also.
PS, yeah I thought you'd like the 320x200 lol [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·