A New twist on Pac Man?

[OX.]

C'mon TI programmers, help squeeze some extra memory so we can have power pills, this games looking really nice, would also be good if the ghost ai recognised when it crossed paths with pacman and goes into chase mode.

[1980gamer]

pOWER PELLETS ADDED...Kinda,

Loaded 730 BYTES remaining After running 42 BYTES.

 

I have squeezed a bit more, but it is very hard to add a single line of code now....

 

Okay, in Classic99 with overdrive on, you see the POWER Dots blink in equal time On/Off

You eat one and get 50 points also the ghosts turn blue for a period of time. This is a calculation of the level you are on.

When you near the end, the ghost change color from blue to grey to blue.... until they change back to original color.

 

In mirror mode, the dots are 10 points and provide no power!

 

OKAY, compiled, Don't get it? The dots are blank and do not blink? they should be visible for half of the siren sound or everyother chomp.

Also, the blue/gray color shift is to fast to see. I think I have enough room to tweak that with existing code.

 

Can I debug and see the value of char(132) ??? I cannot even add a display at currently!

 

New files called power-c and power.txt

 

Gene

DSK2.zip

[1980gamer]

Had a thought... Can I poke sprite colors? CALL POKE(xxxxx,5) VS. CALL SPRITE(#2,........) I only want to change the color.

Currently I have to get the current position of each sprite and plug that in to the sprite routine...

 

On the C64 I had a book of all the addresses and this worked great, but I don't know about the TI99?

 

Gene

[sometimes99er]

You should be able to change the color of, for example, sprite #1 like this,

 

CALL COLOR(#1,5)

[TheMole]

This sounds like it's shaping up to be a cool game, but I can't run it right now (no TI, nor emulators on my mac and little time to get things working). Any chance of a couple of screenshots for those of us keeping tabs on things from work?

[+Vorticon]

Very nice so far! I really like the concept I noticed that Pacman dies when he tries to eat blue monsters after ingesting a power pellet, and I assume that this will be fixed eventually.

Regarding saving memory space, I thought that using multi-statement lines did help squeeze a few extra bytes. Please correct me guys here. If that is correct, then there are plenty of opportunities in the program for line concatenation.

[senior_falcon]

Yep, multi statement lines save a bit of memory. Also, your character definitions can be combined. Instead of CALL CHAR(96,"STRING1")::CALL CHAR(97,"STRING2"), etc. you can CALL CHAR(96,"A 64 BYTE LONG STRING") which defines 4 characters with one string.

[1980gamer]

CALL COLOR(#1,5)

Thanks! This save 15 bytes per sprite (minimmum) I can maybe LOOP the changes now and save more?

 

How did I not know this?????

 

I'll also try to get some screen shots up tonight.

 

Gene

[1980gamer]

Yes, I do a few multi lines, but it is so much harder to read.

I started as only multi-line,

if k=1 then x=-1 :: if k=2 then x=1 ....

But compiling requires true branching, if k=3 then y=-1 has to be if k=3 then 1000

So unless a group of lines is really tightly grouped, I don't think I'll put them together. ( but this may help )

 

CHAR def's. I'll have to do some calc's but I have many chars with no data at the bottom of the char.

ie a DOT can be "0000001818" I don't need the last 6 bytes, but if I group them, I would need the six additional zero's

unless it is the last char in the set. I am certain, if I pre-thought out char def's, this would have worked well.

 

Kinda late in the game now. However, The redifned R can go... It is a tetris rip-off. (didn't mean to) someone else pointed it out.

Oops...

 

Yes, you cannot eat the BLUE ghost's yet. Didn't have room. But you all have given a few new ideas to get some space back.

 

Thanks to all for the help and push.. as well a some great tools that made this even close to a game.

Gene

[senior_falcon]

Gene, you have developed this to an amazing level. It all works very nicely, with good response to the keyboard, sound, etc. One problem that you may run into soon is memory limitations on the compiled code. Load the program and you can then do a SIZE to see how much memory remains. (To get an accurate size in XB you need to RUN the program and break it, then do the SIZE - This would probably also be a good idea in the compiled program.) Anyway, you're down to around 1.5K of memory left. Not sure what happens when you run out of room, but this gives me some motivation to rearrange my memory usage with the compiler.

[senior_falcon]

Hi Gene:

I did a little testing for memory usage in the ARCADE version:

Lines 1140 to 1210 - you can save 180 bytes by combining the definitions into 64 character long strings and replacing the :: REM left, etc. with ! lrdu

Lines 1270 to 1300 - you save 55 bytes by combining the character definitions into one long string, even with the extra zeros that you need.

Lines 5960 to 6060 - you can save 180 bytes by combining the four CALL COLORs in each line so there is only one CALL COLOR in each line, plus it will run a little faster in the compiled code and a lot faster in the XB code. This saves a total of 415 bytes and is just some of the low hanging fruit - I'm sure you can save more memory with some work.

 

6090 IF INT(LNG/LVL)=LNG/LVL THEN 6110 - This will always go to 6110 in the compiled code. Is that what you want?

 

It's pretty easy to check the memory usage using Classic 99. In the text editor, copy the lines you want to test. In XB click on Edit, then Paste XB. Type SIZE and make a note of the available memory. Consolidate the lines, then type SIZE again and compare to see if there is any savings.

[1980gamer]

Hi Gene:

I did a little testing for memory usage in the ARCADE version:

Lines 1140 to 1210 - you can save 180 bytes by combining the definitions into 64 character long strings and replacing the :: REM left, etc. with ! lrdu

Lines 1270 to 1300 - you save 55 bytes by combining the character definitions into one long string, even with the extra zeros that you need.

Lines 5960 to 6060 - you can save 180 bytes by combining the four CALL COLORs in each line so there is only one CALL COLOR in each line, plus it will run a little faster in the compiled code and a lot faster in the XB code. This saves a total of 415 bytes and is just some of the low hanging fruit - I'm sure you can save more memory with some work.

 

6090 IF INT(LNG/LVL)=LNG/LVL THEN 6110 - This will always go to 6110 in the compiled code. Is that what you want?

 

It's pretty easy to check the memory usage using Classic 99. In the text editor, copy the lines you want to test. In XB click on Edit, then Paste XB. Type SIZE and make a note of the available memory. Consolidate the lines, then type SIZE again and compare to see if there is any savings.

 

Wow, that some deep digging! I did pick a bunch of low hanging fruit as well! Got enough room to put a little bit of ghost eating together.

Here is a non-crashing but still buggy version. Blinking dots still not working well, but you can now eat the ghosts.

They go home instantly and will release shortly after power runs out.

score is lame... 200,400,600,800 I am drawing a blank! 200x1, 200x2, 200x3 these should double.. 2,4,8,16 it is binary adding, but my mind is mush!

 

I have a little room left, but am way to tired to continue tonight. Been a bit sick since Saturday.

 

6090 IF INT(LNG/LVL)=LNG/LVL THEN 6110 I'll take a look.... this is Lenght (how long the chomp sound is) divided by the Level

So starting out, 90/1 , 89/1 , 88/1 and yes, like a brick... it hits me! 85/1 , 84/2, 83/2 is the first chance.

 

OKay. just looked at what I was doing... LVL should increase +1 every 6th time LNG decreases.

Wow, this is terrible. Sadly, I knew what I was thinking. I was think 15 to 1 not 1 to 15.

I will need to figure out a new way to increase level as length decreases.

 

90:15 or 6:1 ddddddummmmmy 6090 IF INT(LNG/6)=LNG/6 THEN 6110 89/6 hmm TI doesn't have Modulo does it?

this INT(LNG/6)=LNG/6 could be LNG%6=0

 

Thanks for digging!

Gene

 

OH Power2-c or power2 for the xb version.

DSK2.zip

[1980gamer]

here are some screen shots. OUTLINED graphics are the backside of the maze.

Gene

[senior_falcon]

I found another 2700+ bytes for you. In ARCADE, lines 220 to 690 contain the characters that make up the screen. Each of those is a valid ASCII character that can be entered from the keyboard. Get rid of those and instead have 24 DATA statements, each of which has a 24 byte long string containing the characters that make up the screen. Set up a loop to read those strings and then use CALL LINK("DISPLY"...) to put them on the screen.

 

BTW, this game is fiendish! I finally was able to clear the screen!

Edited March 15, 2013 by senior_falcon

[1980gamer]

I found another 2700+ bytes for you. In ARCADE, lines 220 to 690 contain the characters that make up the screen. Each of those is a valid ASCII character that can be entered from the keyboard. Get rid of those and instead have 24 DATA statements, each of which has a 24 byte long string containing the characters that make up the screen. Set up a loop to read those strings and then use CALL LINK("DISPLY"...) to put them on the screen.

 

BTW, this game is fiendish! I finally was able to clear the screen!

 

I am trying to squeeze about 10 more bytes right now!

I don't know how to do the call link stuff, never used these commands????

Anyway, I have added a bunch of stuff to the ghost chasing! Fixed scoring, Display the 200, 400, 800 , 1600 at the location of the coinc,

fixed a couple of bugs with dots being missed when eating a ghost. etc....

 

I squeezed 1.5k before starting and now.... so close! I guess no extra men!

 

I need a few bytes!!!!

 

I'll post shortly... Or in the AM. it is midnight and I still cannot compile in overdrive! At least I can do some of it fast...

Gene

[1980gamer]

Here is the latest TEXT version. Compiling now... But will put it up in the AM.

Also added a pause/sounds when eating ghosts.

 

AND....Extra Man after clearing a screen. MAX of 5 extras at a time. ( screen size limit )

 

Gene

POWR.txt

[senior_falcon]

I am trying to squeeze about 10 more bytes right now!

I don't know how to do the call link stuff, never used these commands????

Anyway, I have added a bunch of stuff to the ghost chasing! Fixed scoring, Display the 200, 400, 800 , 1600 at the location of the coinc,

fixed a couple of bugs with dots being missed when eating a ghost. etc....

 

I squeezed 1.5k before starting and now.... so close! I guess no extra men!

 

I need a few bytes!!!!

 

I'll post shortly... Or in the AM. it is midnight and I still cannot compile in overdrive! At least I can do some of it fast...

Gene

Gene, you have to do something that I absolutely hate to do - read the manual! Follow the recipe on page 9 of the manual concerning C-EXTRAS. Load the extra routines, then try them out one routine at a time. There is no memory penalty for using these-they are build into the compiler.

[sometimes99er]

I've converted the lines 220 to 690 for you. Extract the file below, place in DSK1, and then use MERGE DSK1.MAGE. Text file also included for copy and paste.

 

 

 

The code below is only a visual clue. Number of spaces is messed up.

 

220 FOR I=0 TO 5::READ T$::DISPLAY AT(1+I*4,1):T$;::NEXT I
300 DATA "abbbbbbbbbppbbbbbbbbbc	  f}}}}}}}}}ff}}}}}}}}}f	  f}ac}abbc}ff}abbc}ac}f	  f}de}dbbe}de}dbbe}de}f"
310 DATA "f}}}}}}}}}}}}}}}}}}}}f	  f}ij}k}ibbppbbj}k}ij}f	  f}}}}f}}}}ff}}}}f}}}}f	  dbbc}nbbc}ff}abbm}abbe"
320 DATA "   f}nbbe}de}dbbm}f		    f}f}}}}}}}}}}f}f		 bbbe}l}abbxxbbc}l}dbbb		  }}}f	  f}}}"
330 DATA "bbbc}k}dbbbbbbe}k}abbb		 f}f}}}}}}}}}}f}f		    f}f}abbbbbbc}f}f		 abbe}l}dbbppbbe}l}dbbc"
340 DATA "f}}}}}}}}}ff}}}}}}}}}f	  f}ic}ibbj}de}ibbj}aj}f	  f}}f}}}}}}}}}}}}}}f}}f	  nj}l}k}ibbppbbj}k}l}im"
350 DATA "f}}}}f}}}}ff}}}}f}}}}f	  f}ibbobbj}de}ibbobbj}f	  f}}}}}}}}}}}}}}}}}}}}f	  dbbbbbbbbbbbbbbbbbbbbe"

Edited March 15, 2013 by sometimes99er

[unhuman]

You might be able to build the maze strings with some sort of compression to save space. Since there are so many }'s & b's in the maze, perhaps you could pack the character with a repetition count.... Changes your data format, of course.

 

I got a similar suggestion when I ran out of memory in bloxo-ti-z... I ran out of memory after about 8 levels. Once I converted, the rendering code + the levels, I was able to pack in 31 levels in the same memory.

Edited March 15, 2013 by unhuman

[1980gamer]

"Gene, you have to do something that I absolutely hate to do - read the manual! Follow the recipe on page 9 of the manual concerning C-EXTRAS. Load the extra routines, then try them out one routine at a time. There is no memory penalty for using these-they are build into the compiler."

I have read the manual a couple of times...The problem is RECALL! Or Understanding/comprehension of what I read... I am more of an example type guy. Show me it in actual use and I get it!

So in the speed up section. You say you don't do floating point math. My logic wants this to work,, 5910 IF INT(LNG/6)=LNG/6 THEN 5930 but I know it does not.

Well, testing in XB it does I cannot think of a way to make this work?

 

Sometimes99er-- I dropped in your maze replacement..... I now have over 2K free space!

I have to admit, I was shocked that it works properly. ( what I mean is thought Display At didn't allow 32 chars per row? )

But the maze looks great and seems to play perfectly fine!

 

What a great space saver! To bad Megellan doesn't save in this format. Well, I should say I have only used the XB option.

 

Thanks for the help!

Gene

[sometimes99er]

Sometimes99er-- I dropped in your maze replacement..... I now have over 2K free space!

I have to admit, I was shocked that it works properly. ( what I mean is thought Display At didn't allow 32 chars per row? )

 

Great.

 

I was going to use CALL LINK("DISPLY" as Harry suggested, but then I discovered that your maze is positioned within the middle 28 characters and then we can of course just use the good old DISPLAY AT.

 

What a great space saver! To bad Megellan doesn't save in this format. Well, I should say I have only used the XB option.

 

Last month I expanded Magellan to both take VDP dumps from Classic99, but also to export screens in DISPLAY AT and CALL LINK("DISPLY" compatible formats. Link here.

 

[sometimes99er]

So in the speed up section. You say you don't do floating point math. My logic wants this to work,, 5910 IF INT(LNG/6)=LNG/6 THEN 5930 but I know it does not.

Well, testing in XB it does I cannot think of a way to make this work?

 

Try this instead

 

5910 IF INT(LNG/6)*6=LNG THEN 5930

 

[senior_falcon]

I've tweaked the code in sometimes99er's post 68 to gain 74 more bytes of memory. Instead of having one long string per DATA statement, I divided it into 4 strings and removed the extra spaces in the line and modified the code to display 24 lines instead of 6. This is attached and can be merged in just like sometimes99er's code.I suggested CALL LINK("DISPLY") because the program printed the lines starting at column 1. Sometimes99er saw that the first two characters were always a space, meaning the display really starts at column 3 which is why DISPLAY AT works.

 

I have been thinking about using the ideas Unhuman suggested to make a simple compression routine to include in XB256 which would then go into the compiler. Take the string "ABCDEFGGGGGGGGHIJKLMNNNNNNNN". This is 28 bytes long. Compressed it would look like this: "6ABCDEF-8G6HIJKLM-8N" which is 18 bytes long. The numbers are counters and are characters with ASCII's of 6 and F8. A positive counter does not repeat and a negative counter repeats. In the above example, the routine would print the 6 characters ABCDEF, then print G 8 times, then print the 6 characters HIJKLM and finally print N 8 times.

 

I was picturing this as writing directly to VDP memory anywhere (not just to the screen) using something like VREAD and VWRITE. That way character definitions could also be compressed.

MAGE1.zip

[1980gamer]

Hello all,

Having display driver issues...

But here is the latest version. Need some play testing and bugs reported!

 

With all the extra room, I am thinking intermissions now.... But lets flush this out!

Blinking properly and corrected color of power pellets.

 

Length of chase time seems a bit random... though it is not? What do you think?

 

let me know what you find!

 

Thanks,

Gene

VER1-C.zip

[OX.]

was thinking .. If you manage to get the maze graphics compression sorted out - how about different mazes for each level or at least 2 or 3 different mazes that the game cycles through while increasing the speed/difficulty as the levels advance.

Edited March 17, 2013 by OX.