Shop OBEX P1 Docs P2 Docs Learn Events
PROJECT: PropMAN (rewrite in the works) — Parallax Forums

PROJECT: PropMAN (rewrite in the works)

Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
edited 2009-12-02 15:16 in Propeller 1
Bagger's new 16 color driver has me back in the game creation seat.

I'm not sure what will happen first: A playable game, or run out of memory. [noparse]:)[/noparse]

PropMAN isn't exactly playable, *yet* as I'm working out the rule sets ahead of
the game play this time. (Less frustrating) but there is some sprite action and
you can see where things are going..

Hopefully, I'll have enough memory for the [noparse]:baddies:[/noparse] when I get done putting
in the movement rules. [noparse]:)[/noparse]

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Visit the: The Propeller Pages @ Warranty Void.

Post Edited (Oldbitcollector) : 11/30/2009 3:48:16 AM GMT
«1

Comments

  • trodosstrodoss Posts: 577
    edited 2009-09-08 02:44
    @OBC,
    Looks like it will be a great project!

    [noparse][[/noparse]Edit:] I Tried Gear, but it does not render the 'fat pixel' graphics...Oh well. I might see if I can snap a screen shot tomorrow from my LCD TV (unless you can get a quick snap shot).

    The 'fat pixel' graphics driver that Baggers came up with is a lot of fun. I would think that you could make it 'fit' memory-wise, with a little creative 'wrangling.'

    Post Edited (trodoss) : 9/8/2009 3:06:34 AM GMT
  • hinvhinv Posts: 1,255
    edited 2009-09-08 04:40
    Hey OBC,

    It looks real good.

    Take Care,
    Doug

    For some reason, I cannot upload the picture I just took. It says over and over again connection reset in firefox, or connection broken in konqueror.

    Post Edited (hinv) : 9/9/2009 12:20:57 AM GMT
  • BaggersBaggers Posts: 3,019
    edited 2009-09-08 09:00
    OK, looks great [noparse];)[/noparse]

    although a tip I'd suggest using prtchr(ch,x,y,c,b) when updating dots, as you're printing a string there, when you don't need the extra overhead since the string is just "." anyway [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

    ·
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2009-09-08 09:46
    Shall I oblige with a screenshot then?

    *Peter*
    640 x 321 - 143K
  • BaggersBaggers Posts: 3,019
    edited 2009-09-08 10:21
    OBC, ( and anyone else )·I've added a fatprint(s,x,y) and fatprtchr(ch,x,y) and fatfont.chr to change the font, alter the BMP, remembering pixels should be fat, and grab with the bmp8toLite.exe by typing·:-

    bmp8toLite fatfont -amscharmap16

    I'll do a faster background charmap routine when I get chance [noparse];)[/noparse]

    Baggers.



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2009-09-08 14:02
    @Gang: Thanks for the "Kudo's"

    It might be a bit before it's actually playable. (I'm betting Baggers could have whipped this out in a single day. [noparse]:)[/noparse]

    @Peter: Thanks for posting that screenshot!

    @Baggers: Wow. Very nice font addon! I was hoping someone was working on that!
    I'll be replacing my existing . and # characters with something from that next.

    I'll do some more on this tonight after work.
    I've had a chance to sleep on the code and have some ideas of further memory reduction.

    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    New to the Propeller?

    Visit the: The Propeller Pages @ Warranty Void.
  • FredBlaisFredBlais Posts: 380
    edited 2009-09-08 14:11
    Great, I always felt that the hydra was missing pac-man [noparse];)[/noparse]
    Cool to see that hydra game development is regaining activity!
  • BaggersBaggers Posts: 3,019
    edited 2009-09-08 16:46
    Anytime Jeff [noparse];)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

    ·
  • trodosstrodoss Posts: 577
    edited 2009-09-08 18:40
    FredBlais said...
    Cool to see that hydra game development is regaining activity!
    I noticed that too, and it is indeed a cool thing!
    Leave it to Baggers to have something magic up his sleeve [noparse];)[/noparse]
    There are a few games emerging using the Hydra graphics engines, which is also exicitng!·
  • BaggersBaggers Posts: 3,019
    edited 2009-09-08 18:41
    Yeah, always good to see new games spawning [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

    ·
  • JT CookJT Cook Posts: 487
    edited 2009-09-09 04:43
    Memory will be the thing to watch out for. I would store as much of the graphics as possible as 1bpp to save as much memory as you can.

    I also made a Pacman game a few months ago for a different unit.
    www.youtube.com/watch?v=Q4_Ng7bkmGs
    (The bug with the ghost getting stuck has been fixed)
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2009-09-09 13:04
    @JT

    Very polished! I've got a lot of work to do to get this project to that level!

    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    New to the Propeller?

    Visit the: The Propeller Pages @ Warranty Void.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2009-09-12 18:06
    I've uploaded the latest copy of the demo to the top of this thread...

    I need some advice from the wizard game creators here..

    I need to create movement rules to keep propman and ghosts from
    overrunning the blue walls of the game board. I have a couple
    methods in mind, but I suspect they will use more memory than
    I have left.

    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    New to the Propeller?

    Visit the: The Propeller Pages @ Warranty Void.
  • CounterRotatingPropsCounterRotatingProps Posts: 1,132
    edited 2009-09-12 23:52
    Jeff / OBC

    not a game wizard by any means, but just glancing at the Font_ATARI file - are the walls in there? Or made in the UpdateDOTS in PropMAN_demo?

    One way to detect objects intersecting is to use bounding boxes. But if the walls are like say $11 in Font_ATARI, lines 168-175, then all you need to do is grab the first non-zero row or column (of your 'mover' propman, ghost, any moving object), then AND it with the wall section.

    If you get a '1' then bounce back, or just don't move - or whatever is appropriate.

    Not sure about the speed factor here - you could brute force scan through the whole mover and the space it's traversing - the wall would yield the "1"... it would be real fast in PASM.

    does this make sense?

    - H

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • JT CookJT Cook Posts: 487
    edited 2009-09-13 14:10
    I haven't pulled out my Hydra to try this out yet, but this is what I used, and from a CPU and memory standpoint, they are both friendly.

    The maze is setup as (I think) 24x20 grid with each tile as 8x8 pixels. Each tile was considered either a wall tile or a floor tile. I would also have two dots that we use to check collision, where the dots are positioned depending on the direction. Example: if a sprite is moving up, then the two dots would be on the upper left and upper right to check for walls infront of me.

    So after we give the two dots X/Y screen coordinates, we then do some binary shifting. Divide each one by 8, and now the X/Y values can be matched up with the tile map.

    Example: One of the two dots has an X value of 97, and Y value of 13.
    X/8 (or X>>3) = 12 Y/8 (or Y>>3) = 1
    So we lookup at our tilemap 12,1 and check to see what kind of tile we use.

    What I always do is keep a new X/Y value, and an original X/Y value. So lets say we are moving are sprite along and we hit a wall. Well our new X/Y value has our sprite inside a wall, so then what we do is copy the original X/Y value and that will put our sprite in right before the moment we went into the wall.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2009-09-13 15:40
    The problem is that the game board is simply a graphic, nothing else.

    I have a feeling what I'm going to have to do is calculate the coordinates of where the hero and ghosts are
    allowed to move and keep track of where they are.

    I should be able to fit that well into the memory I have left. (hopefully)

    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    New to the Propeller?

    Visit the: The Propeller Pages @ Warranty Void.
  • JT CookJT Cook Posts: 487
    edited 2009-09-13 16:34
    I'd say setup a tile map in memory. This will save you a bunch of headaches of trying to figure out if it is a wall or not. As far as memory is concerned, you might be even, esp if you have a Smile ton of code trying to figure out the collision.

    You can also have the tile map really small by making each tile a bit and store 8 horizontal tiles in a byte.

    Thats my 2 cents smilewinkgrin.gif
  • CounterRotatingPropsCounterRotatingProps Posts: 1,132
    edited 2009-09-14 17:51
    Oldbitcollector said...
    The problem is that the game board is simply a graphic, nothing else.

    Oh, well then, I was one step ahead of JT's suggestion. Right, break it down into tiles/sections - when I wrote an ASCII based
    "graphic" game, each ascii code could be used to represent a character (ala. the old "Rogue" UNIX game) or represent a wall or object. If you use JT's suggestion, then storage is smaller - and might be 1/8 the size.

    > I have a feeling what I'm going to have to do is calculate the coordinates of where the hero and ghosts
    > are allowed to move and keep track of where they are.

    Not necessarily - you can "tokenize" this - for example you could use two bits (four values) to represent permissible territory.
    Say the Propman can't go through walls, but ghosts could, that would give you all you need:

    00 = no one through
    01 = ghosts through, Propman not
    10 = (fun option) Propman through, Ghosts not (It's the Propman "escape hatch" [noparse]:)[/noparse]
    11 = Solid wall, no one through.


    You can also reduce much of the·board·and object locations·to bit mapping - including the graphs and the collision tests, as JT suggests. An object is just a 'bit' traversing the graphic map (which is also just a bit array) So instead of one big graphic image of the game board or maze, you create several 'maps'. One is the "is there an object here'·array - simply made·of one bit for one object (0=empty space, 1=occupied space).·For the user-visible objects, you have an·array of chars (or bytes, or words, or whatever you need) for the map - there is a one-to-one correspondence between the number of "space" bits and the number of possible positions in your graphic. This way you can loop through both with a single index, just shift or multiply (scale) the bit loop count to match the size of the graphic array.· You could use the video buffer to hold the presence of the object both for display. Then it's easy to move left or right - you just bit shift. Up and down could be done that way to if you made your game board's sides a mulitple of 2 (e.g. 64).

    If you want to keep that graphic smaller, you can tokenize the objects and use a lookup table

    eg:
    0000 = floor (graphic)
    0001 =·right wall
    0010 =·bottom wall
    0100 = top wall
    1000 = left wall

    If you want to get really tricky, and skip the lookup table, you could directly index into the correct prop font for that image - so that 4-bit token of the board structure objects could be ordered to shift or multiple or AND into the prop font.



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    Post Edited (CounterRotatingProps) : 9/14/2009 5:57:04 PM GMT
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2009-09-15 01:52
    Yesterday I start calculating the positions of the walls by moving the hero around and recording the locations
    of the walls from a serial terminal. I'm not pleased with the movement as a result.

    So I will be ditching the (nice looking) graphic which is the board and moving toward 8x8 tiles which will
    represent the board itself. This may push me back to a complete re-write with Pototahead's new 8x8 driver
    as I will want smooth movement with the tiles.

    I'll wait until I see his driver develop a little more and see if I can adapt it.

    In the meantime, it looks like this driver is more suited toward a side-scroller.
    (See my Moon Patrol demo in the thread for Bagger's driver.)


    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    New to the Propeller?

    Visit the: The Propeller Pages @ Warranty Void.
  • JT CookJT Cook Posts: 487
    edited 2009-09-15 03:45
    Well it all depends on how the map is setup. If the map you drew for that was symmetrical, then you could still divide it up evenly and create a collision map in memory. Or you can create a new pac map and make sure the tiles line up evenly so you can make a collision map in memory to reference.

    The thing about most of video games from the 80s is they used a tilemap and sprite rendering system since memory was at a premium. If you are looking for a good driver you should check the graphics driver used for Donkey Kong or the COP driver from the Hydra kit.
  • CounterRotatingPropsCounterRotatingProps Posts: 1,132
    edited 2009-09-15 15:48
    > So I will be ditching the (nice looking) graphic which is the board and moving toward 8x8 tiles which will
    > represent the board itself. This may push me back to a complete re-write with Pototahead's new 8x8 driver
    > as I will want smooth movement with the tiles.

    If you chop up the existing graphic into 8x8 tiles, and dump those out fast enough, won't the end result will look the same, free of jitter?

    Can you post a link to the thread or OBEX where Doug (patatohead) has this driver --- search (and my brain) are pretty lame somedays [noparse]:)[/noparse])

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • Agent420Agent420 Posts: 439
    edited 2009-09-15 16:05
    > The thing about most of video games from the 80s is they used a tilemap and sprite rendering system since memory was at a premium.

    +

    > If you chop up the existing graphic into 8x8 tiles, and dump those out fast enough, won't the end result will look the same, free of jitter?



    I would think that many of the same limitations of the 80's are similar to those encountered now with the Prop (the primary difference being an entire system has been shrunk to the size of one chip).

    For backgrounds like Pac Man, it seems like there are really only a handful of unique tiles needed (straight, corners, etc)...· Certainly more resource efficient than dedicating an entire memory space to a bitmap.

    As for collision maps, depending on application, I have even used bit level flagging within variables to represent allow/deny for the game board; 32 longs would provide a 32x32 array of representation.




    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • CounterRotatingPropsCounterRotatingProps Posts: 1,132
    edited 2009-09-15 16:49
    Yup

    > I would think that many of the same limitations of the 80's are similar to those encountered now with the Prop

    The folks here who do the emulators would know this well ... wondering what the raw mips of yore compaired to the Prop of today are. (I know MIPS is not really that useful, but it at least gives a sense.)

    Weren't those 80's procs running like in the 100kHz clock range? (I used to repair video games back then, but have forgotten most of the stuff [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • Agent420Agent420 Posts: 439
    edited 2009-09-15 17:06
    Fwiw, some original Pacman hardware info here.
    The CPU is a Z80 clocked at 3.072 MHz. The game ROM takes 16K at the beginning of the address space, followed by 2K of video memory and 2K of RAM for game use.
    
    
    The display supports a resolution of 224x288 pixels that are actually 8x8 characters arranged in a 28x36 matrix. This allows the video to work with just 2K of RAM, 1K for video information and 1K for color information. The video and color RAM have a [url=http://www.ascotti.org/programming/pie/video_memory.htm][u][color=#0000ff]very peculiar arrangement[/color][/u][/url] with some extra locations that are not visible on the screen.
    

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • VIRANDVIRAND Posts: 656
    edited 2009-09-18 16:38
    I've always wondered exactly what the rules for the ghosts in pacman were.

    I do recall intentionally glitching at least 2 home versions of pacman and getting a result
    where alpha characters were left behind by them so they could back track, seemed to me
    they probably changed two tile bits in a way that they didn't usually affect the character displayed
    and maybe there were 4 characters for dots and spaces. I think the alpha left behind by monsters in
    the glitched mode was HIJK if there were no dots there. I suppose that's how they retreated when
    they were blue and when they somehow decided their normal rules wouldn't catch the pac man.
    (Represented previous direction and I think were removed when retreating; a convenient
    alternative to having multiple stacks, and seemed used like arrow shaped bread crumbs, I think.)
    I don't think that they had pre-programmed "patterns" since there may not have been enough
    memory and the appearance of patterns was a side effect of changing speeds after each screen.

    Ghost rules are
    Something I'd be interested in looking up, or maybe disassembling a ROM. When I wrote
    me a pacman, I drew the maze on graph paper, then redefined characters and arranged them
    into the maze, and had a very dumb rule involving the difference in sprite coordinates and
    not going thru walls which usually made ghosts wait in corners a lot and not know about
    going through the tunnels on the sides.

    The 256th maze bug was interesting but I never saw it except first in a videogame magazine
    in 1983, and now on youtube. Apparently the ghosts expect wall characters where they should be,
    and there are not enough dots to eat on the halfscreen so there is a maximum score by eating
    every fruit and ghost until that last maze, first done in the late 1990's. One ghosts rule
    is obviously preferring turns as it goes around in the same 4 tiles on the missing half of last maze.
  • VIRANDVIRAND Posts: 656
    edited 2009-09-18 16:51
    QUOTE:"The folks here who do the emulators would know this well ... wondering what the raw mips of yore compaired to the Prop of today are. (I know MIPS is not really that useful, but it at least gives a sense.)

    Weren't those 80's procs running like in the 100kHz clock range? (I used to repair video games back then, but have forgotten most of the stuff [noparse]:)[/noparse]"

    It's MIPS that matter, Mhz does not correspond, and MIPS varies a lot with cycles per specific instruction. Z80 had
    usually 1 Mhz but 2,4,8 Mhz versions existed. Z80 probably did just over 100 KIPS per Mhz IIRC 8 cycles per NOP,
    where it was like 300 KIPS per Mhz for 6502s and 6800s were also slower since they divided the clock by 4.
    (typical for 6800 to use 3.5-4 Mhz crystal for 0.9 to 1.0 Mhz and less than 300 KIPS.)
  • AntoineDoinelAntoineDoinel Posts: 312
    edited 2009-09-20 21:41
    Hi OBC

    long time not logging due to work and bad health...


    If you haven't seen it already, try this link:

    http://home.comcast.net/~jpittman2/pacman/pacmandossier.html

    there are very detailed info on pacman internals, including the ghost movement logic.

    Ciao
    Alessandro
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2009-09-22 01:51
    @Alessandro

    Thank you! There is much information there which will help!

    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    New to the Propeller?

    Visit the: The Propeller Pages @ Warranty Void.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2009-11-30 03:43
    Gearing up to get back into this project!

    Switching to Potatohead's improved 8x8 driver allowing me to create a more precise map.

    Almost finished with a little Christmas game using the same driver in 20x22 character mode.
    440 character positions should be enough to do a clean pacman clone.

    Spyhunter return in the works as well.

    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    New to the Propeller?

    Visit the: The Propeller Pages @ Warranty Void.
  • trodosstrodoss Posts: 577
    edited 2009-11-30 15:21
    Switching to Potatohead's improved 8x8 driver allowing me to create a more precise map.

    Almost finished with a little Christmas game using the same driver in 20x22 character mode.
    440 character positions should be enough to do a clean pacman clone.
    Interesting choice--certianly you can make it work for what you want to do.

    When I get time I need to finish/post a few projects.··Joust for one...and then "Mythic Adventure," a·game I had started before the new Potatohead 8x8 driver had been created.··It·could likely be 'retrofitted' to that driver.

    [noparse][[/noparse]Edit:] Also, great to hear that Spydriver is still in the works [noparse];)[/noparse]




    Post Edited (trodoss) : 11/30/2009 4:45:00 PM GMT
Sign In or Register to comment.