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

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...