Jump to content
IGNORED

I've gone and lost the plot on DEFINE


Mik's Arcade

Recommended Posts

Ok, I'm getting myself really confused.

 

I have several different 'screens' in my game, each of which use different BITMAPS.  I didn't notice any issues as a few of the screens don't anything, they are display only so.

 

But, I don't know what to make of this now that I am programming the second "playable" screen.

 

On the main screen, I define the following.

DEFINE 0,16,gamescreen_bitmaps_0 
DEFINE 16,16,gamescreen_bitmaps_1
DEFINE 32,4,gamescreen_bitmaps_2 
DEFINE 36,9,sasuke_bitmaps        
DEFINE 45,7,ninja_bitmaps        
DEFINE 52,4,commander_bitmaps

 

So, this uses 56 out of the maximum 64 cards.

 

As you can see, Sasuke uses 36-45.   So, the main screen uses these numbers.

 

On the bonus screen, I define the following

DEFINE 0,15,boss_bitmaps_0
DEFINE 15,9, sasuke_bitmaps
DEFINE 24,12, commander_bitmaps
DEFINE 26,10, bonus_bitmaps

 

I'm working under the assumption that every time I invoke CLS, this wipes out all the BITMAPS defined, right?

 

I want to reuse the logic I already have to make Sasuke move and shoot on the bonus screen.

 

In the move_sasuke GOSUB procedure, the Sasuke sprite is: 

SPRITE 7, HIT + VISIBLE + sx, DOUBLEY + max_y, $0801 + 38 * 8 ' Moving right

It uses the defined BITMAP 38 (and 39 since I am using DOUBLEY)

 

But, as you can see, Sasuke is now DEFINED using 15-24 

 

I was prepared to create a variable called card_num (or something) to assign 38 for the main screen and 17 for the bonus screen and then change the GOSUB to be

SPRITE 7, HIT + VISIBLE + sx, DOUBLEY + max_y, $0801 + card_num * 8 ' Moving right

 

But, when I called up the screen, it is working fine as is. How can that be?

 

What am I missing?  Am I just overwriting the first 36 with the new DEFINES and the other cards at 36-56 stay there?

 

If so, I feel like I should be doing a proper cleanup each time I want to reset these because I can see this causing a problem at some point?   Like I said, I assume CLS was wiping them all out. 

 

thanks

 

PS....getting so close to being done!!! Once I get this loop complete, I just need to polish up and add music and a few more sound effects!!  Exciting!!

 

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

47 minutes ago, cmadruga said:

CLS just clears the screen, it does not wipe GRAM where the bitmaps are defined.

 

So a new DEFINE will overwrite the previous one for the same GRAM position.

Ok, thanks for confirming that it only overwrites what is there.  I can work around this.

I will probably just swap the ninja_bitmaps with the sasuke_bitmaps in the main screen.

 

Main loop 

DEFINE 0,16,gamescreen_bitmaps_0 
DEFINE 16,16,gamescreen_bitmaps_1
DEFINE 32,4,gamescreen_bitmaps_2 
DEFINE 36,7,ninja_bitmaps        
DEFINE 43,9,sasuke_bitmaps        
DEFINE 52,4,commander_bitmaps

 

Then, I won't even need to define SASUKE and COMMANDER BITMAPS again and they will always be between 43-56

 

The bonus screen will then look like:

Bonus loop

DEFINE 0,15,boss_bitmaps_0
DEFINE 15,10, bonus_bitmaps

 

Is there a way to just wipe all the values? Would that be a better practice?  Either way, this will work and will take  just a couple minutes to update the card numbers

 

thanks again

 

Link to comment
Share on other sites

"Wiping" the GRAM really has no benefits that I can think of. 

 

I like your idea to reserve/standardize the range used for Sasuke and Commander bitmaps. 

I do similar things as well, and normally reserve the upper positions to sprite bitmaps.

If you can map sprites always to the same positions, it's one less thing to worry about.

Edited by cmadruga
  • Like 1
Link to comment
Share on other sites

6 minutes ago, cmadruga said:

"Wiping" the GRAM really has no benefits that I can think of. 

 

I like your idea to reserve/standardize the range used for Sasuke and Commander bitmaps. 

I do similar things as well, and normally reserve the upper positions to sprite bitmaps.

If you can map sprites always to the same positions, it's one less thing to worry about.

Yes, I need to standardize that range. I will most likely be adding more stuff to the bonus_bitmaps so there will be more than 10.  I'm going to attempt to make a few colorful sprites for a change. Everything up to this point is a solid color. 

Link to comment
Share on other sites

3 minutes ago, cmadruga said:

If you can map sprites always to the same positions, it's one less thing to worry about.

How would one handle moving sprites that use #backtab instead of using the typical MOBs?  For instance, I want to have an asteroid field (say 3-10 of them) that need to move horizontally.

Link to comment
Share on other sites

1 minute ago, SpaceHunter said:

How would one handle moving sprites that use #backtab instead of using the typical MOBs?  For instance, I want to have an asteroid field (say 3-10 of them) that need to move horizontally.

You need predefined bitmaps that reflect each frame of their movement.

Then you basically update the screen as needed with those bitmaps.

 

If you have GRAM to spare, you can just DEFINE all those frames once.

If not, you will have to DEFINE them as needed before updating the screen.

  • Like 1
Link to comment
Share on other sites

5 minutes ago, cmadruga said:

If not, you will have to DEFINE them as needed before updating the screen.

Thanks, seems reasonable, but how would go about to clean up the mess that is left when the sprite has moved?

 

Maybe something like...

 

d = sprite position


#backtab(d) = 0

#backtab(d+1) = $0800 + SPR_WHITE + (DEF13 + 0) * 8
 

Link to comment
Share on other sites

6 minutes ago, SpaceHunter said:

Thanks, seems reasonable, but how would go about to clean up the mess that is left when the sprite has moved?

 

Maybe something like...

 

d = sprite position


#backtab(d) = 0

#backtab(d+1) = $0800 + SPR_WHITE + (DEF13 + 0) * 8
 

I do this in my game.....I just reference the card I originally used to define the screen.

 

This code below handles a bullet that moves down the screen along the y-axis

 

 

        IF d THEN
            #backtab(d) = gamescreen_cards(d)     ' This writes the original color of the card
            IF d >= 200 THEN
                d = 0
            ELSE
                d = d + 20
                #backtab(d) = $0801 + 51 * 8         ' now the bullet moves to the next card below it
            END IF
            nb(c) = d
        END IF

 

 

I hope this helps....

Edited by Mik's Arcade
  • Like 1
Link to comment
Share on other sites

3 minutes ago, SpaceHunter said:

Thanks, seems reasonable, but how would go about to clean up the mess that is left when the sprite has moved?

 

Maybe something like...

 

d = sprite position


#backtab(d) = 0

#backtab(d+1) = $0800 + SPR_WHITE + (DEF13 + 0) * 8
 

Something like that would work if you are moving them 8 pixels at a time. That will make them pop from one position to another, which is not as great looking.

 

If you want finer movement, you will have to update positions d and d+1 with different frames until the asteroid has completely moved to d+1.

  • Like 1
Link to comment
Share on other sites

16 hours ago, Mik's Arcade said:

Ok, thanks for confirming that it only overwrites what is there.  I can work around this.

I will probably just swap the ninja_bitmaps with the sasuke_bitmaps in the main screen.

 

Main loop 

 

 

 

Did you put WAIT in between DEFINE?  The last DEFINE in that list will occur at interrupt, which will load only the commander_bitmaps

 

Do,
DEFINE 0,16,gamescreen_bitmaps_0
WAIT
DEFINE 16,16,gamescreen_bitmaps_1

WAIT
DEFINE 32,4,gamescreen_bitmaps_2
WAIT
DEFINE 36,7,ninja_bitmaps       
WAIT
DEFINE 43,9,sasuke_bitmaps      
WAIT
DEFINE 52,4,commander_bitmaps
WAIT

Link to comment
Share on other sites

18 hours ago, Mik's Arcade said:

But, as you can see, Sasuke is now DEFINED using 15-24 

If you're using the DoubleY, I recommend use even number GRAM_SLOT example: DEFINE 16-25.  One of my very early mistake back I was starting.  It worked in Nostagia, but it didn't work in jzintv, which is a lot more accurate emulator.

Link to comment
Share on other sites

33 minutes ago, Kiwi said:

If you're using the DoubleY, I recommend use even number GRAM_SLOT example: DEFINE 16-25.  One of my very early mistake back I was starting.  It worked in Nostagia, but it didn't work in jzintv, which is a lot more accurate emulator.

Interesting, I will keep this in mind, thanks.

 

I'm going over the all the DEFINES in my code right now to organize them based on the knowledge I gained in this thread.

 

Also - I do put WAIT after every DEFINE.  I didn't show that in the code snippet when I pasted it in this thread.  I get some pretty weird results otherwise....haha. 

Link to comment
Share on other sites

18 hours ago, SpaceHunter said:

how would go about to clean up the mess that is left when the sprite has moved?

In the software sprites I have designed, I made those one position wider than the graphic, so there always would be empty space behind it in the direction it moves. The drawback is that you can't get software sprites too close to eachother. There may be more and better methods to do this.

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