Jump to content
Sign in to follow this  
petit chou

Ready to tear my hair out trying to debug this - please help?

Recommended Posts

Hey, all,

 

I've been working on my own implementation of a halfwidth alphabet printer for my current project, a roguelike for the INTV. I am having an incredibly difficult time trying to diagnose an error I'm having in the stub program I intend to turn into my halfwidth print routine, and I could *really* use some help. The program is about 65 lines (not including the INCLUDEd data file full of BITMAP statements) and is attached to this post in a .zip file along with a compiled binary.

 

The problem is somewhere in the math routines in my FOR loops -- it's pushing the right half of my text display ahead in the buffer a little too far, but I can't for the life of me figure out why. Any help you could give me would be so very greatly appreciated.

 

Thank you so much in advance.

 

petit chou - alphabet test.zip

Share this post


Link to post
Share on other sites

The issue I think is this:

(WRITE_LOC * 2)

Everywhere you use that, it'll shift you down by 4 rows for odd letter positions.

 

You really want to use something more like (WRITE_LOC AND -2) * 2.

Edited by intvnut

Share this post


Link to post
Share on other sites

The issue I think is this:

(WRITE_LOC * 2)

Everywhere you use that, it'll shift you down by 4 rows for odd letter positions.

 

You really want to use something more like (WRITE_LOC AND -2) * 2.

 

If I could hug you through the internet I would squeeze the stuffing out of you. Thank you SO much.

Share this post


Link to post
Share on other sites

 

If I could hug you through the internet I would squeeze the stuffing out of you. Thank you SO much.

 

Certainly!

Share this post


Link to post
Share on other sites

You could probably optimize further. I haven't tested, but I think this works too, for example:

.

            IF WRITE_LOC % 2 THEN
                ' Write right hand
                #LEFTROWS  = #DISPLAYBUFFER((WRITE_LOC * 2) - 2 + J) AND $F0F0
                #RIGHTROWS = ALPHABET((#LETTERBUFFER(I) * 4) + J) AND $0F0F
                #DISPLAYBUFFER((WRITE_LOC * 2) - 2 + J) = #LEFTROWS + #RIGHTROWS   
            ELSE
                ' Write left hand
                #LEFTROWS  = ALPHABET((#LETTERBUFFER(I) * 4) + J) AND $F0F0
                #RIGHTROWS = #DISPLAYBUFFER((WRITE_LOC * 2) + J) AND $0F0F
                #DISPLAYBUFFER((WRITE_LOC * 2) + J) = #LEFTROWS + #RIGHTROWS   
            END IF

.

And, of course, you could optimize quite a bit further (still by staying within IntyBASIC), but I'm not sure how important it is.

Edited by intvnut

Share this post


Link to post
Share on other sites

You could probably optimize further. I haven't tested, but I think this works too, for example:

.

            IF WRITE_LOC % 2 THEN
                ' Write right hand
                #LEFTROWS  = #DISPLAYBUFFER((WRITE_LOC * 2) - 2 + J) AND $F0F0
                #RIGHTROWS = ALPHABET((#LETTERBUFFER(I) * 4) + J) AND $0F0F
                #DISPLAYBUFFER((WRITE_LOC * 2) - 2 + J) = #LEFTROWS + #RIGHTROWS   
            ELSE
                ' Write left hand
                #LEFTROWS  = ALPHABET((#LETTERBUFFER(I) * 4) + J) AND $F0F0
                #RIGHTROWS = #DISPLAYBUFFER((WRITE_LOC * 2) + J) AND $0F0F
                #DISPLAYBUFFER((WRITE_LOC * 2) + J) = #LEFTROWS + #RIGHTROWS   
            END IF

.

And, of course, you could optimize quite a bit further (still by staying within IntyBASIC), but I'm not sure how important it is.

 

That's much cleaner - thank you! I was just trying to get something up and working before worrying about optimizing it, although faster would probably be better. Right now it takes ~1/10th of a second to print a line, which is acceptable for this particular case (it's a roguelike - nothing is happening all that quickly) but would be nice to have faster for sure.

 

I am having some really bizarre things happen to me if I use the routine to write a full row of text on the bottom -- I don't know if it's good ol' Intellivision quirkiness, an implementation issue in jzintv, something weird with the SCROLL statement or what. If I use BORDER and SCROLL the last two rows of the text in screen location 238 get eaten, but if I comment them out the problem goes away. Also there are strange graphical artifacts that seem to be happening if I write to screen location 239.

 

I've attached a .zip file with the modified source (not with your optimizations yet, unfortunately) and the offending statements. Would you mind to take a look at them and toss me some ideas as to what might be going on?

 

Thanks a ton -- you're amazing.

petitchou - display weirdness.zip

Share this post


Link to post
Share on other sites

There's not enough time in a frame to update 20 cards, that's why. :-) BORDER and SCROLL probably eat into that time. The manual even calls it out:

.

    Note there is an approximate limit of loading 18 GRAM cards per frame
    (measured with emulator in NTSC mode)

    This limit is reduced to 16 GRAM cards per frame when using the music player
    (PLAY statement)

.

You can break this up into two DEFINE statements separated by a WAIT:

.

    DEFINE 0,10,#DISPLAYBUFFER
    WAIT
    DEFINE 10,10,VARPTR #DISPLAYBUFFER(10*4)

.

A quick test suggests that works.

Edited by intvnut

Share this post


Link to post
Share on other sites

There's not enough time in a frame to update 20 cards, that's why. :-) The manual even calls it out:

.

    Note there is an approximate limit of loading 18 GRAM cards per frame
    (measured with emulator in NTSC mode)

    This limit is reduced to 16 GRAM cards per frame when using the music player
    (PLAY statement)

.

You can break this up into two DEFINE statements separated by a WAIT:

.

    DEFINE 0,10,#DISPLAYBUFFER
    WAIT
    DEFINE 10,10,VARPTR #DISPLAYBUFFER(10*4)

.

A quick test suggests that works.

 

I feel very silly for missing that. Thank you so much, again!

Share this post


Link to post
Share on other sites

 

I feel very silly for missing that. Thank you so much, again!

 

I only noticed it because I had to look it up to see what it did. :-) I've written probably a page of IntyBASIC total so far, mostly trying to break the compiler, spot-checking things, or tweaking existing code. ;-)

Share this post


Link to post
Share on other sites

 

I feel very silly for missing that. Thank you so much, again!

 

I think we ALL get caught on this one, at one point or another. I've now forced myself into the habit of breaking up DEFINEs into 16 card blocks (which works out nicely into 4 blocks, or 64 cards total). The worst was when I followed the manual, was using 18 cards per DEFINE - and then weeks later added MUSIC. Suddenly all my graphics were broken! What the hell? So now I just enforce max 16 per WAIT, and problem solved :D

Share this post


Link to post
Share on other sites

That's another reason for an IntyBasicLint program in my opinion. On my list....

 

 

 

I think we ALL get caught on this one, at one point or another. I've now forced myself into the habit of breaking up DEFINEs into 16 card blocks (which works out nicely into 4 blocks, or 64 cards total). The worst was when I followed the manual, was using 18 cards per DEFINE - and then weeks later added MUSIC. Suddenly all my graphics were broken! What the hell? So now I just enforce max 16 per WAIT, and problem solved :D

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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...