Jump to content
IGNORED

WIP : Fast Eddie Returns!


Mik's Arcade

Recommended Posts

Here is a teaser on my next game project. It's coming along nicely, though I probably just jinxed myself. Haha.

 

I have encountered a very odd glitch that is really happening on some basic things.

 

I defined some BITMAPS and am simply trying to create a SPRITE that uses 2 GRAM cards using DOUBLEY, something I used a lot in Sasuke Vs Commander.

 

For some odd reason, I call the sprite with card 5, so it should use cards 5 and 6.  For whatever reason, it is using 4 and 5!  Anyone ever encounter this?

 

here are constants for the cards, easy peasy!

'Screen Bitmaps
CONST FB = $0802 + 0 * 8    ' Floor Bottom
CONST LL = $0802 + 1 * 8    ' Ladder Left Side
CONST LR = $0802 + 2 * 8    ' Ladder Right Side
CONST HL = $0802 + 3 * 8    ' Half Ladder Left Side
CONST HR = $0802 + 4 * 8    ' Half Ladder Right Side
'Pesky Bitmaps
CONST H1 = $0806 + 5 * 8    ' Hi Top Top
CONST H2 = $0806 + 6 * 8    ' Hi Top Bottom
CONST KE = $0807 + 7 * 8    ' Key
CONST PS = $0801 + 8 * 8    ' Pesky Sneaker
'Eddit Bitmaps
CONST E1 = $0805 + 9 * 8    ' Eddie 
CONST E2 = $1804 + 10 * 8   ' Eddie 

CONST MOB_LEFT = $0308      ' Hit + visible + hidden border, use in sprite X
CONST MOB_TOPN = $0108      ' Normal Size + hidden border, used in sprite Y
CONST MOB_TOPD = $0188      ' Sprite uses 2 GRAM cards + Normal Size + hidden border, used in sprite Y

 

 

Here are the defines, done correctly

CLS
MODE 0,0,0,0,0
DEFINE 0,5,screen_bitmaps
WAIT
DEFINE 5,4,peskies_bitmaps
WAIT
DEFINE 9,6,eddie_bitmaps
WAIT

 

 

Here are the sprites

 

'	   SPRITE 4, px(4) + MOB_LEFT, MOB_TOPD + py(4), H1   ' This does not work, instead of using 5 and 6, it uses 4 and 5       

	   SPRITE 4, px(4) + MOB_LEFT, MOB_TOPN + py(4), H1          
	   SPRITE 5, px(4) + MOB_LEFT, MOB_TOPN + py(4) + 8, H2   '  If I stack them on top of one another using 2 sprites, it works

I suspect I made a mistake in my definition for MOB_TOPD.   As you can see above, I want it to be DOUBLEY + (2x)Normal Size + Hidden Border, which I assumed is 

 

$0080

$0100

$0008

=====

$0188

 

did I use fuzzy math?  But still, I can't see how that could result in it using the wrong GRAM cards?

 

  • Like 3
Link to comment
Share on other sites

16 minutes ago, cmadruga said:

What is "hidden border"?

that's a good question, actually.  It was in Oscar's first book on the Monkey Moon game. I used that code I typed in a while back and used it to start this game as it uses a lot of the same functionality.  It appears to mask the game borders, ie where spites don't show.  I took the $0008 out of the constants and now the spites shift up 8 and go to the left 8 more spaces.  Odd.

 

That did not resolve my issue either. This is so weird.  I don't know enough to be an expert, but know enough to be dangerous....lol.

Link to comment
Share on other sites

7 hours ago, Mik's Arcade said:

For some odd reason, I call the sprite with card 5, so it should use cards 5 and 6.  For whatever reason, it is using 4 and 5!  Anyone ever encounter this?

When you use DOUBLEY for 16-line sprites, the first card must start on an even boundary: 0, 2, 4, 6, 8, 10 and so on. IIRC it even is mentioned in the manual.

  • Like 1
Link to comment
Share on other sites

8 hours ago, carlsson said:

When you use DOUBLEY for 16-line sprites, the first card must start on an even boundary: 0, 2, 4, 6, 8, 10 and so on. IIRC it even is mentioned in the manual.

Once again, Carlsson saves the day!  I must have been lucky in Sasuke because I didn't know this (or didn't remember) and it never came up.

 

When you say manual, which do you mean?  I could not find anything about this in Oscar's books (they could use a term index), nor on the Wiki pages.

 

Now that I've got some programming under my belt, I really need to start reading up some more.

Link to comment
Share on other sites

I mean the file manual.txt that comes with the compiler distribution. If I'm not mistaken, parts of it is reprinted at the back of Oscar's first book. Is there an IntyBASIC wiki somewhere that I have overlooked?

 

SPRITE index,x,y,f


 

The first parameter indicates the number of the MOB (0 to 7). Notice that if you use a constant the generated code will be faster. Sprites (MOBs) will be updated during the next frame.
    
X contains coordinate X (0-168)
bit 8 = Interaction (suggested always 1)
bit 9 = Visibility (suggested always 1)
bit 10 = Double size X
    
Y contains coordinate Y (0-95)
bit 7 = Draw 16-line sprite. (it should be aligned in even GRAM boundary 0/2/4/8 etc)
bits 9-8 = Scale 00= 0.5x, 01= 1x, 10= 2x, 11= 4x
bit 10 = X flip
bit 11 = Y flip
    
F contains color and card number.
bits 2-0 = Lower bits of color
bits 11-3 = Card number (0-255 for GROM, 256-319 for GRAM)
bit 12 = Upper bit of color
bit 13 = Change color stack.

Link to comment
Share on other sites

7 minutes ago, carlsson said:

I mean the file manual.txt that comes with the compiler distribution. If I'm not mistaken, parts of it is reprinted at the back of Oscar's first book. Is there an IntyBASIC wiki somewhere that I have overlooked?

 

 

 

There is not an IntyBasic Wiki, I was referring to the general Intellivision one.  But I will definitely review that manual.txt    There is always something new to learn.  This game is coming along fast...I might have a demo level to play soon

 

thanks again

Link to comment
Share on other sites

19 hours ago, Mik's Arcade said:

Once again, Carlsson saves the day!  I must have been lucky in Sasuke because I didn't know this (or didn't remember) and it never came up.

When you place your sprites first at the top of GRAM, it typically sorts itself out, and he problem never comes up.

 

19 hours ago, Mik's Arcade said:

When you say manual, which do you mean?  I could not find anything about this in Oscar's books (they could use a term index), nor on the Wiki pages.

The manual is in the last chapters in the first book.  It also comes with IntyBASIC.  It's also in the "Documents" folder of he SDK.


The even-card alignment for double-resolution sprites is also mentioned in the Intellivision Wiki, under the STIC discussion, and in the "stic.txt" file.

 

Quote

Now that I've got some programming under my belt, I really need to start reading up some more.

The manual is more of a reference guide on the language.  It is useful to review, because it explains the usage of the keywords and commands, as well as some limitations.

 

    dZ.

Edited by DZ-Jay
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

hey all -

 

Sorry to use this as a blog, and I know that I am rather new to this forum, but I'll be taking a little break.  Unfortunately, I'm not getting a good start to the new year and am getting separated. It's been a long time coming and now is the time.  I'm moving to a new apartment next week on a 14 month lease that is very close to the home so I can help my kids transition during this time.  Once we finalize things, I will most likely move somewhere else and start over.

 

I want to say that becoming a member of this community and making my first Intellivision game really helped me get through this rocky relationship.  I needed lots of hobbies to fill in the gaps, and I really enjoy making games and getting help from such an intelligent and supportive group of people here. I moved my family to NC over 6 years ago and the move was great for them and never worked out for me. Working from home and making no new friends plus COVID crap really strained things to the limit.

 

Right now, I don't have the energy to be creative and work on anything but I will be back.  I will certainly have a LOT more time on my hands soon enough once I am settled in and get past this grieving state.  I'll probably still lurk and comment from time to time but have yet been able to focus on writing any code.

  • Like 1
  • Sad 6
Link to comment
Share on other sites

12 minutes ago, Zendocon said:

Sorry to hear what you're going through.  We're here to help when you're back to coding again.

 

Meanwhile, I'm on the mend from Covid and happy to be returning to health.  I couldn't work on anything for the past few weeks.

sheesh, glad to hear you are on the mend.  COVID has gotten so many people; My brother and both my parents got through it, my aunt is still getting over it 4 weeks in.  It's really screwing this planet up.

 

 

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

ok, I'm starting to dust off my programming brain, and stumped already...lol. I guess not all the cobwebs have been shaken out.

 

I'm trying to figure out the code Oscar uses for Monkey Moon (in his first book) to climb up and down ladders.  I get what he is doing but the math isn't working for me. Actually, my math should be even easier because I don't even have sloped platforms.  My platforms are flat so the Y-coordinate is always the same.

 

The gist of his code (page 52) is using the X and Y coordinate to make calculations to determine of the player happens to be moving over a card that features the ladder.  I get this, but it's not working right for me.

 

 

        IF d = 1 THEN                               ' Going up a ladder
             IF ed_y % 16 = 0 THEN                  ' Over floor
	   		    x = (ed_x + 4) / 8
                y = ed_y / 8
                IF #backtab(y * 20 + x) = LR THEN
                     ed_y = ed_y - 1
                     ed_state = 2
                END IF
                IF #backtab(y * 20 + x) = LL THEN
                     ed_y = ed_y - 1
                     ed_state = 2
                END IF

 

My ladders are bigger than in Monkey Moon and use 4 cards for the top right and left, and bottom right and left.

 

In my case, ed_y = 88 when we start on the bottom floor.   So, right off the bat the math doesn't work, ie  88 % 16 is NOT zero.  But, the funny part is the code still executes.  But of course, now all the number are messed up so the calculation of the backtab is not detecting LR and LL properly.  It is actually not that far off, so it kind of works...

 

As an example, the first LL and LR are cards 223 and 224  (row 11, columns 3 and 4), or (x,y) = (24,88) and (32,88).  The book talks about getting a sqaure that identifies the valid area to move up, and in this case I would say that should be when X is between 26 and 30 

 

any thought on this? I clearly need to redo the math since my platform and ladder scenarios are different. Are there any more elegant ways to go about this problem?

 

thanks

 

 

  • Like 1
Link to comment
Share on other sites

On 1/31/2022 at 2:40 PM, Mik's Arcade said:

ok, I'm starting to dust off my programming brain, and stumped already...lol. I guess not all the cobwebs have been shaken out.

 

I'm trying to figure out the code Oscar uses for Monkey Moon (in his first book) to climb up and down ladders.  I get what he is doing but the math isn't working for me. Actually, my math should be even easier because I don't even have sloped platforms.  My platforms are flat so the Y-coordinate is always the same.

 

The gist of his code (page 52) is using the X and Y coordinate to make calculations to determine of the player happens to be moving over a card that features the ladder.  I get this, but it's not working right for me.

 

 


        IF d = 1 THEN                               ' Going up a ladder
             IF ed_y % 16 = 0 THEN                  ' Over floor
	   		    x = (ed_x + 4) / 8
                y = ed_y / 8
                IF #backtab(y * 20 + x) = LR THEN
                     ed_y = ed_y - 1
                     ed_state = 2
                END IF
                IF #backtab(y * 20 + x) = LL THEN
                     ed_y = ed_y - 1
                     ed_state = 2
                END IF

 

My ladders are bigger than in Monkey Moon and use 4 cards for the top right and left, and bottom right and left.

 

In my case, ed_y = 88 when we start on the bottom floor.   So, right off the bat the math doesn't work, ie  88 % 16 is NOT zero.  But, the funny part is the code still executes.  But of course, now all the number are messed up so the calculation of the backtab is not detecting LR and LL properly.  It is actually not that far off, so it kind of works...

 

As an example, the first LL and LR are cards 223 and 224  (row 11, columns 3 and 4), or (x,y) = (24,88) and (32,88).  The book talks about getting a sqaure that identifies the valid area to move up, and in this case I would say that should be when X is between 26 and 30 

 

any thought on this? I clearly need to redo the math since my platform and ladder scenarios are different. Are there any more elegant ways to go about this problem?

 

thanks

 

 

In the book, the line "IF (player_y % 16) THEN" detects whether the sprite is on top of a girder.  This is done because the "player_y" variable is only updated when going up and down a ladder, and ladders are 16 pixels (2 cards) tall.  By extension, the distance between girders is 16 pixels (the full length of a ladder).

 

So the value starts at 80, which is divisible by 16, and so the result of "80 % 16" is zero -- flat on the first girder.  As the player goes up the next ladder, the "player_y" value is incremented one pixel at a time.  During that time, the result of "player_y % 16" will return the remainder of the division, which will not be zero.

 

Once the player completes the climb up to the next girder (or down to the previous one) -- that is, once player_y increments or decrements by 16 whole pixels -- he will be back on the flat surface of a girder and the "player_y" will again be divisible by 16 (i.e., player_y % 16 = 0).  (Also, because the girder itself is 4 pixels tall, the code adjusts the final step by four pixels in order to align "player_y" to the card boundary, even though the player is only half-way through the card on top of the girder.)

 

All of that works in Monkey Moon because the girders are aligned at card boundaries every 16-pixels, or 2 cards.  If your ladders are bigger than two cards, then you may need to adjust the formula.  Four cards high would be 32-pixels, so perhaps you need to check for "(ed_y % 32)".  Remember, the "16" in "player_y % 16" is because that is the distance between girders.

 

Let me know if any of this helps.

 

     -dZ.

Edited by DZ-Jay
  • Thanks 1
Link to comment
Share on other sites

2 hours ago, DZ-Jay said:

If your ladders are bigger than two cards, then you may need to adjust the formula.

I'm certain this is the issue.   I actually originally tried ed_y % 8.   But, now that your explanation clears up exactly what the code does I can figure it out, thanks.

 

I plan on spending a LOT more time coding this year and am hoping to crank out a couple of games.

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

Man, this place is turning into my personal blog, sorry about that.

 

This year has been terrible for me so far, starting with me getting separated. Then, last Saturday, I got a frantic call from my mother telling me that my oldest brother Phil suddenly passed away in his sleep.  He didn't really have any health issues other than being a bit overweight, and had been out the previous night with his wife just fine. Apparently, he must have had some sort of blockage and went into cardiac arrest. His wife woke up at 4AM because he was making noises and she knew right away something was up. He never made it to the hospital and they pronounced him dead in the ambulance.

 

I last spoke to my brother on Valentine's day. He called me and spoke to me for an entire hour knowing what a tough day that would be for me. It was a great call and I at least feel blessed to have that hour with him, not knowing it would be the last time we spoke. He got a kick out of my Sasuke game. On my bartop machine, I got a favorite of his installed on it called Ataxx. When he would visit, he would play that game a lot.  Might make a good Intellivision port...hmm

 

I spent all week in the New England area visiting friends and family, some I have not seen in over 7 years. I'm home now, but it's been really tough living alone. I'm looking to find some outdoor hobbies and need to find new friends. All I have here in NC now are my kids and I can't leave them. 

 

Hopefully I will find the will and the motivation to pick up the programming soon.  I did work out a method for cleanly defining zones to trigger climbing up and down ladders and just have to plug in the logic and test. 

 

 

  • Sad 3
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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