MORE, MORE CONT.... program changes and updates...

Hi Beth,

You are right, there is a space part to the game where you travel in a space ship and have to doc to a space station. Then you enter hyperspace with one of two or three types of ships to get to the wizard. This doesn't look too complicated but I will leave that for last.

I was able to create one of the towns in assembly just to see if I could do it but I don’t think it will be practical. I have a question regarding the towns and castles: Q. On map one, "There are 4 total maps in the game!" there are 8 towns and 2 castles and they all look different! If I keep this numbering throughout that would make 24 towns and 8 castles! I think they are all different but I'm not sure because I have been able to take a look at each one. The problem I see with using assembly is if I use the same data compression method as in the world map I will have a problem with needing more shapes then 15! I think because of this issue it does seem to be more practical to make the towns and castles in basic using a character generator and maybe text files. What do you think?

Would basic be more data on the disk then assembly?

This make sense when you talk about page flipping because then I would be using the low res graphics screen and the HGR2 screen would be available to me for page flipping. I still am a little vague on this page flipping process.   So to understand what you are saying: 

1. Show user front-buffer graphics screen -  “I awesome this is the main world map screen?”

2. Draw all terrain on back-buffer graphics screen – “What is back buffer graphics?”

3. Draw transportation at locations on back-buffer – “again, What is back buffer?”

4. Draw monsters at locations on back-buffer

5. Draw player in center tile of back-buffer

6. Switch user to be looking at back-buffer. Back-buffer is now front-buffer. Front is now back.

7. Goto 2.

Is the back buffer page 1 and front buffer page 2 graphics screens?

Also, if I am going to pass data back and forth from basic to assembly using POKE and PEEKs, Does this mean for example:  Let’s say I’m using X and Y for grid coordinates on the map and I need to have the character start at x=60, y= 35.  I get the impression that I would use the first page of memory like $1E and $1F for values stored in the game.  So if I set the following variables in my code would this be correct:

Row                 equ      $1E

Column            equ      $1F

Then in basic I could POKE the value 60 into $1E and 35 into $1F before I do the CALL statement and the main character would be all ready to start at a new location on the map correct?

This seems logical.

Thanks

Joe

+++++++++++++++++++++++++++++++++++++++++++++++++++

Hi Joe,

I think you have a lot more flexibility in how you handle the towns/castles. You’ve sketched out one idea, using the character generator and text files. I think that’s totally reasonable. You could load each one individually as needed.

The data itself won’t be any bigger. However, Basic is a big fat pig. It takes up space just to load the text that makes up the Basic. It takes up memory and CPU overhead to run the Basic interpreter. So from that perspective, you will take up more space on the disc and in memory using Basic. Hopefully that won’t be a problem! I don’t think it should be, it just comes down to how you structure things and that’s on you.

As to terminology, “front-buffer” and “back-buffer” are video pages 1 and 2. However, whichever one the user is currently seeing is always the front buffer. The other one (the one you always draw on) is the back buffer. So front and back alternate between pages 1 and 2. I’ll lay it out explicitly:

Game Frame 0 Render cycle: 

Front buffer – Visible to user – Screen 1 - black screen

Back buffer  - Not visible to user – Screen 2 – drawing Game Frame 0

Game Frame 1 Render cycle:

*flip frames*

Front buffer – visible to user – Screen 2 – has Game Frame 0 on it

Back buffer – not visible to user – Screen 1 – drawing Game Frame 1

Game Frame 2 Render cycle:

*flip frames*

Front buffer – Visible to user – Screen 1 – has game Frame 1 on it

Back Buffer – not visible to user – Screen 2 – drawing Game Frame 2

Etc.

As far as the Peek/Poke thing goes, you’re absolutely right. I’m not sure what address you want to use for your values (that’s up to you), but you have the right idea for communicating between the two.

-          Beth