Jump to content
Opry99er

The Legend of Beryl Reichardt

Recommended Posts

Excellent, guys... thank you very much. :)

falcon, I seem to remember discussing this previously, but cannot recall the outcome of the conversation... my memory is terrible.

 

*currently I am using an AL subroutine (as you know) to scroll my screen and do all my quick-draws when returning from the menu screen, etc...

 

I do not imagine I will be able to retain this subroutine (in its current form) if I compile the program... is that correct?

 

I believe it only accesses the disk to load the world map into memory, and from there it simply uses the data from the lower 8 to do its business.

 

I know I could achieve similar speeds doing it all in XB and then compiling it, but I am just curious about how it would all work together.

 

Using the compiler would give me the ability to add the soundlists, but since the scroll uses the ISR, the two might be mutually exclusive.

  • Like 1

Share this post


Link to post
Share on other sites

Hi Owen:

How large is your map- I seem to remember it was 64 wide by 48 high?

Your player moves up, down, right, left. Does he move diagonally as well?

Sadly, Matt's custom A/L sub would not work with the compiler, but I think it can be done with compiled code once I know how you expect the program to work.

Share this post


Link to post
Share on other sites

Hey falcon... thanks for replying!

The full map is 72 high by 56 wide.

 

The viewport is 12 high by 28 wide.

 

This makes 12 total screens, 6 high by 2 wide.

 

Cardinal directions only, no diagonal.

 

When the player walks off the edge of the viewport, it scrollstile by tile until the next screen is fully drawn... I will post a short video here in a few showing precisely how it works currently.

Share this post


Link to post
Share on other sites

Hi Owen:

I see a way to do it, but there might be memory problems. Run your program, then break it with <Fctn 4>, print SIZE and tell me how much stack memory is free.

Thanks,

Harry

Share this post


Link to post
Share on other sites

will do! Twill be a bit before I can get to my terminal. I'll post it up tonight.

 

BTW, the game is not complete. Still adding battle engine. That will likely change STACK space and PROGRAM size significantly.

Share this post


Link to post
Share on other sites

OK, here are some numbers for you. You are using 1327 bytes of stack space (11840-10513=1327) assuming you are starting with the default 3 disk files available. XB256 has 8056 bytes of stack available (again with the default 3 disk files). The screen would have to be stored in VDP ram and is 4032 bytes long, so you would wind up with 2697 bytes of stack space available as things are written now (8056-4032-1327=2697). This should give you enough stack space for the remaining programming you need to do.

I would have to write a short A/L subroutine to add to XB256 that would be the equivalent of Matt's subroutine for scrolling the screen and then add that to the compiler. Before I spend any time on this, the thing to ask yourself is whether you can adapt your programming to the limitations of the compiler, and more importantly, if you can think outside the XB box so as to take advantage of the features that XB256 adds.

Share this post


Link to post
Share on other sites

Thank you for looking into this, falcon.

 

I need to take some time and re-DL the Developers Package, read all docs, re-read the thread content etc...

 

The issue is that each world varies in map size and each world is its own XB program. The viewport stays the same size, but some maps will be much smaller than this one and some nearly twice the size... Let me do some reading and some serious contemplating... Re-evaluating the goals and scope of the game may be in order.

 

Thanks again for giving this some thought.

Share this post


Link to post
Share on other sites

If you have a map that is twice as large then I don't see how this can work-you should be able to stuff it into low memory and use Matt's subroutines, but I think you'd run out of room using XB256.

Share this post


Link to post
Share on other sites

Yes, currently I have one world planned at 84x84. The map is drawn on graph paper but I have not done it in Magellan yet. This is not QUITE twice the size of the Forestia map, but certainly close enough to 7k.

 

As I said though... If I restructured my plans and downsized the maps, we might be in business.

 

Let me give this some thought.

 

Again, thanks falcon. :)

Share this post


Link to post
Share on other sites

Hi Owen:

If you gave up the fancy scrolling routine that scrolls 1 character at a time, and simply redrew each page of the map then this should be doable with standard XB256 and compiler options. You can save VDP in a compressed format. The compression algorithm is very simple but the screens should be about 50% smaller.

Share this post


Link to post
Share on other sites

Something to consider. :)

 

I like the scroll, but background music may just be more important... :) It will take some consideration.

 

That said, I am very curious about the compression you're talking about. Karsten mentioned compressing my maps earlier in this thread (I believe) but I was not, at that point, ready to do anything like that.

 

Tell you what... Let me finish the tasks at hand (completed LOAD/SAVE routines, battle engine) and then I will look at my disk access. SAVE/LOAD are done using DV disk files, so that feature should work perfectly with the new compiler functionality. I currently use RELATIVE file access for inputting bits of text from disk throughout the game (which isnt possible with VARiable format, IIRC) and I will come to a decision based on all that.

 

Cool to know I have the options here... Thank you for your Developers Package, once again.

Share this post


Link to post
Share on other sites

If you gave up the fancy scrolling routine that scrolls 1 character at a time, and simply redrew each page of the map then this should be doable with standard XB256 and compiler options. You can save VDP in a compressed format. The compression algorithm is very simple but the screens should be about 50% smaller.

I'm not sure why you would want to drop scrolling like that. You got the window routine and the scroll characters in different directions routines. Loading the map and finding your way around is more or less something that has to be done anyway.

 

Maybe one could get away with only loading data for the new viewport, - like one viewport on screen, calculate what to load (a viewport), then "scroll" between the two (scroll the loaded one into view).

 

:)

Share this post


Link to post
Share on other sites

I'm not sure why you would want to drop scrolling like that. You got the window routine and the scroll characters in different directions routines. Loading the map and finding your way around is more or less something that has to be done anyway.

It isn't that I want to drop scrolling; I'm just not convinced it will work well in this application. Here's the problem:

The map is 56 wide x 72 high. You could make a 72 element array to hold the lines that comprise the map. Let's say the first 12 lines of the left side of the map are on the screen and you want to scroll up. No problem, CALL LINK("SCRLUP") will do the trick, then CALL LINK("DISPLY",22,3,SEG$(MAP$(13),1,28) will fill in the line at the bottom of the map. (Or you could use DISPLAY AT) Loop 12 times. But the game also scrolls to the right or left. The scroll is easy enough, CALL LINK("SCRLLF") will do it. But filling in the blank vertical line is tougher, requiring something like: FOR I=1 TO 12::CALL HCHAR(I+10,30,ASC(SEG$(MAP$(I),29,1))::NEXT I. This might be OK when compiled-I haven't tested to see.

The other problem is memory. Owen is talking about some large maps, and I don't think there is enough room for the map and the program. There might be if it is saved in a compressed format which would save about 50%, but then you cannot easily find your way around in the string using SEG$.

@Owen:

Relative file access should be possible if someone wants to write it. RUNTIME7 has the disk routines with more comments than I usually use. I believe that an XB program using relative files would compile correctly, so it's just a matter of expanding the disk routines.

 

(edit) I just tested screen scrolling using compiled code and it is fast enough to look good. The memory limitations are still a concern

Edited by senior_falcon

Share this post


Link to post
Share on other sites

Well, now with disk routines, the map could be saved off to disk. In my head, you store the entire map rows (all columns) in memory, but you could use disk files to seek to a line and load that on the fly for vertical scrolling. Performance may suck, though.

 

As far as compression, maybe more of compaction. You could certainly store multiple things in a byte. For example, for a given line, you could:

 

First 3 bits: number of times to repeat the character (up to 8 )

Next 5 bits: character ID: 32 unique values.

 

Since there are a lot of repetitions in a line, this saves a ton of memory. It's a similar approach that I used in bloxortiz. The only caveat is that re-drawing each line is a bit more complicated and certainly would affect your map drawing.

 

I don't remember the specifics of it, but the amount of memory I saved with pretty ridiculous.

 

You could also make the routine variable, but that may waste a bit... So, you'd have:

 

First bit: indicator (of how many bits to use for repetition (say 0=3 and 1=5)

Next 3 or 5 bits: repetitions (up to 8 or 32)

Next 4 or 2 bits: character id

 

The above approach could give you more flexibility (and characters) if you only allow characters to be drawn by bitness (making bit 1 a page of characters).

 

Since you draw a lot of trees and a lot of grass, it may be great to use the bit 1 variant to draw more of those.

Edited by unhuman

Share this post


Link to post
Share on other sites

I just tested screen scrolling using compiled code and it is fast enough to look good.

Good. What I kinda expected, from the speed I remember when using your excellent compilers. ;)

 

The memory limitations are still a concern

Yes, I understand. And as I think you hinted, there's probably many different ways to attack this. Again, I would think it's like a "separate" issue (with or without scrolling). ;)

Share this post


Link to post
Share on other sites

Just about to put the SAVE/LOAD routines to bed. They work just fine... But the implementation is a little bulky and sloppy for my tastes... But it works.

 

From the LOAD program, user selects which game slot he wishes to LOAD. The selection (1,2 or 3) is then saved onto another file on disk ("TMPLOD")... Then the main game program is started. At the top of the main game program, an OPEN #2: DSK1.TMPLOD is exexuted, then the value stored in that location is inputted into the program.

 

There is a line or two of code there that loads the selected gamefile based on the TMPLOD value, thereby loading all variable values and String variable values (the loaded game stuff) from one of the 3 save-slot files (called GSL1,GSL2, and GSL3 respectively.)

 

SAVING is much easier, as it happens on-demand and the game program can open and save values directly.

Edited by Opry99er

Share this post


Link to post
Share on other sites

Current SAVE code as it pertains to ONE save slot:

 

 

 

 

    OPEN #1:"DSK1.GSL1",VARIABLE
    FOR X=1 TO 4
    FOR Y=1 TO 2
    PRINT #1:HP(X,Y):MP(X,Y):NDIS(X,Y)
    NEXT Y
    NEXT X
    FOR X=1 TO 4
    PRINT #1:XP(X):LEV(X):CL$(X):ATK(X):DEFN(X):MATK(X):MDEF(X):ARM$(X):WEP$(X):STAT$(X):MN(X):CN$(X):STAT(X)
    NEXT X
    PRINT #1:GLD:HPO:MPO:ELI:SCR:QSTAT
    CLOSE #1

And the LOAD routine

     OPEN #1:"DSK1.PLAYDATA",VARIABLE  !this is the line that will vary based on which "slot" the player selects
     FOR X=1 TO 4
     FOR Y=1 TO 2
     INPUT #1:HP(X,Y),MP(X,Y),NDIS(X,Y)
     NEXT Y
     NEXT X
     FOR X=1 TO 4
     INPUT #1:XP(X),LEV(X),CL$(X),ATK(X),DEFN(X),MATK(X),MDEF(X),ARM$(X),WEP$(X),STAT$(X),MN(X),CN$(X),STAT(X)
     NEXT X
     INPUT #1:GLD,HPO,MPO,ELI,SCR,QSTAT
     CLOSE #1

 

  • Like 1

Share this post


Link to post
Share on other sites

Had to add a few variables... Since the player will start in different locations upon LOAD, I had to specify which screen to load at startup and the X,Y coordinates of the PC.

 

I ended up writing a separate program for modifying the SAVE/LOAD values in my slot files. It loads the current values from disk, then returns to "command mode" where I can enter the new values or modify existing ones... Then it saves them all back to the file in the correct order. I need only modify the actual in-game LOAD routine to accept the new values.

 

Works very well... I should have a new version for testing very soon. Once all this is done (probably tonight) I will plug in my encounter routine and it will be on to the battle engine... Something I have been playing with, but have not spent "real" time on yet.

  • Like 3

Share this post


Link to post
Share on other sites

I have not posted to this thread in 4 years... but the time has come.  A few updates for now, and then perhaps later this week I will post a new video.

 

4 years ago I designed the save/load routines that allow the player to save and load games to one of three available game "slots" on disk.  It was a major step, because the player could then do some stuff, save progress, and then return to the game later (I'm sure you all know how saved games in an RPG work, but allow me to vamp for a moment.  :) ). I had to make some decisions as I worked my way through the world, and began implementing the story elements of the game into the gameplay.  Keep in mind that this is a very linear-style game..... things have to happen in a certain order so that other things can happen.  (You need X item so you can enter Y cave, etc).

 

I made a decision to allow "saving" only at one pre-designated cave in the first world, and you could not save just "anywhere."  There are many reasons for this decision that aren't important right now... but it's what I did.  The saving worked beautifully, and all pertinent values were written to disk as I had hoped they would be.  The problem came when I re-loaded the saved game from disk.  Upon loading, the screen did some crazy stuff, blinked out, and froze the machine.  I checked my code again, and everything in my save and load routines was fine.  Something else was happening, and I couldn't get it figured out.  See the video below.  

 

MX and MY are the map screens to be loaded (top left is 1,1. Etc)

 

 

 

 

So.... I tried hundreds of fixes, banged my head against a wall, etc.  Then I just started working on back story and lore... eventually writing a backstory game called Markus of Marinus, which is the back-story of the Markus the Valiant character who appears in this game.  

 

Since the bug kind of halted work on the coding of the game, most of what I have been doing has been map work, story work, battle engine work, etc...  Then a few months ago, I talked with adamantyr about the issue and we started looking at it from a different perspective.  The issue was not how I was saving and loading game data, it was how the assembly subroutine was interpreting my MX and MY values.  Without getting into a ton of details, with adamantyr's help, we were able to squash the bug, and saving/loading works beautifully now.  (Thanks Adam!)

 

i will be updating the game document and posting a new video soon...  

 

Right now, you can play the first world from start to finish, all quest items and plot lines are in place.  The only thing I'm lacking right now is a fully implemented battle engine, and some of the story text associated with the quest.  :)

 

Hope to get back to steady work on this one in 2020.  It's been way too long.

 

Edited by Opry99er
  • Like 11

Share this post


Link to post
Share on other sites

I see someone got revitalized by the Chicago Faire events! All this awesome geekiness is contagious 😄

  • Like 5

Share this post


Link to post
Share on other sites

To be honest, it was a message I got from adamantyr a week ago that got me revitalized.  He told me his RPG is close to completion.

 

So, I got a SAMS card, a TIPI on the way, and started dusting off the old maps and code of my own game.... just to see if it still had any life left.  :) 

 

I was very disappointed this year when I couldn't make the Friday event.  Kind of killed the weekend for me, and Saturday was less impactful than it would have been had I been able to participate in the full Monty.

 

but it was great seeing all my friends again.  :) 

  • Like 8

Share this post


Link to post
Share on other sites
On 11/4/2019 at 8:17 AM, Opry99er said:

The issue was not how I was saving and loading game data, it was how the assembly subroutine was interpreting my MX and MY values.

Uh, not very fair to leave us hanging as to what the bug was... 😉

  • Haha 1

Share this post


Link to post
Share on other sites
18 hours ago, matthew180 said:

Uh, not very fair to leave us hanging as to what the bug was... 😉

Ahhh, apologies!  The assembly routine relies on values to render the screen, MX and MY (these are the actual screens we scroll to... 1,1 is the top left screen--labeled as MD01 in the source.  There are 10 screens in this world).  When I saved my party on another screen, the value for the map to be scrolled was showing as MD01 when it should have been MD06.  This value is held in the variable called "CURLOC" or "current location".  My assumption was that the MX and MY values were immediately taken into account when you started the game, and this is what determined which chunk of map data was loaded.  I was correct to a point... that's exactly how the subroutine determines what map to scroll to while playing... but NOT at startup.  MD01 is hard coded into the source.

 

Since the subroutine was hard coded to START at MD01, any other value caused the screen to scroll downward, looking for that correct value of 1 (which it never reached).  That's what crashed the game repeatedly.

 

All we did was create an offset for this world that allowed us to bypass the hard CURLOC value when we started up the game after it was saved on a different screen.

 

When we originally set the subroutine up, there was no cause to start on any other screen, but as the game developed and caves were put in place, etc., it became necessary to start the game up at a different locations from time to time, and this is what caused the crash.... the assembly routine was never meant to start anywhere other than MD01.

 

So, there was no "bug" per se (as the subroutine functioned exactly as it was designed to function from the start)... but the demands I was placing on the subroutine changed, and the routine was not designed to deal with these specific changes.  It became a "bug" within the context and framework of what the game has evolved INTO.

 

It can be fixed in the source code as well, but for now we just addressed it in the XB code.  I will likely need to fix it more permanently in future levels.  :) 

Edited by Opry99er

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...