Jump to content
IGNORED

IntyBASIC Backtab Tiles Find and Change?


First Spear

Recommended Posts

I need each of the shapes to change as Backtab, not MOBs, so they will animate.

 

I think that the On Frame Gosub should do some kind of "visible GRAM" search to find the card "img1_cards" and then DEFINE "img2_cards" in its place, and then find "imgx_cards" and DEFINE "imgy_cards" in its place. Then go from "img2_cards" to "img3_cards" and "imgy_cards" to "imgz_cards" and then img3_cards" to "img1_cards" etc.

 

I don't think I want to test all 240 tiles for their DWORD value, I think it should just be some kind of swapping. But I don't see how to start.

 

Can anyone help me get a clue?

 

Thanks.

 

 

 


INCLUDE "constants.bas"
MODE 0,7,7,7,7
Wait
On Frame Gosub FindFlip
Wait

#flip = 1

DEFINE 0,1,img1_bitmaps_0
WAIT
SCREEN img1_cards,0,115,1,1,1

DEFINE 4,1,imgx_bitmaps_0
Wait
SCREEN imgx_cards,0,42,1,1,1

LoopMain:
Wait
#key = Cont
Goto LoopMain


FindFlip: Procedure

Return
End


ImageShow1: Procedure
DEFINE 0,1,img1_bitmaps_0
SCREEN img1_cards,0,25,1,1,1
Return
End


img1_bitmaps_0:
DATA $7E00,$4242,$4242,$007E
img1_cards:
DATA $0802

img2_bitmaps_0:
DATA $0000,$243C,$3C24,$0000
img2_cards:
DATA $0802

img3_bitmaps_0:
DATA $0000,$1800,$0018,$0000
img3_cards:
DATA $0802

imgx_bitmaps_0:
DATA $FF00,$FF00,$FF00,$FF00
imgx_cards:
DATA $0821

imgy_bitmaps_0:
DATA $FC00,$FC04,$FC00,$FC04
imgy_cards:
DATA $0821

imgz_bitmaps_0:
DATA $FC00,$7C00,$7C40,$FC00
imgz_cards:
DATA $0821

 

Link to comment
Share on other sites

Once all the card are loaded to backtab. The backtab memory address starts at $200 if I remember correctly. I made something in Kaboom that would take the backtab value and add it to change the foreground color of that card because I had an option that you can change the background color to 4 or 5 different colors.

 

Here's a source to give you some idea.

mode 0,0,0,0,0 'setting up the game to colorstack mode with black being in all 4 register

wait
if BDrop=0 then SKYcolor=3 else SKYcolor=9 'see if backdrop option been off, if it is off, then skycolor is gray
POKE $28,SKYcolor 'load skycolor to colorstack slot 1
POKE $29,BGcolor 'load bgcolor to colorstack slot 2
POKE $2A,$04 'load the sidewalk color to colorstack 3
cls 'clearscreen

if BDrop=1 then 'if backdrop option is on, load screen information and apply addition/subtraction to change FGcolor
SCREEN my_screen  

if BGcolor=5 then #AddColor=0 else #AddColor=-4 'I had 5 different choice, but dark green and black works best
'if BGcolor=11 then #AddColor=-4
'if BGcolor=1 then #AddColor=-4
'if BGcolor=14 then #AddColor=-1
'if BGcolor=15 then #AddColor=-4

for i=0 to 139 'for loop my favorite loop
#MCard=peek ($200+80+i) 'start at backtab 80. Backtab memory address start at $200.
#MCard=#MCard+#AddColor 'addition
poke $200+80+i,#MCard 'poke the result
next i
end if
if BDrop=0 then print at 60 color $2006," " 'put the advance colorstack blank card at this position

return
end

That's one way. But not really speedy during gameplay though. The other way is to update the GRAM card. If you have contingency gram card that only use for animation for example you want to use the GRAM card slot 56-63. Then you can upload the tile to the GRAM. Kinda hard for me to explain, In Tower Inferno game I'm making update the GRAM cards every frame. Example code:

if anim=0 then define 44,4 fireg2a:define alternate 23,1,nflame1
if anim=1 then define 44,4 fireg2b:define alternate 23,1,nflame2
if anim=2 then define 44,4 fireg2c:define alternate 23,1,nflame3
if anim=3 then define 44,4 fireg2d:define alternate 23,1,nflame4
if anim=4 then define 44,4 fireg2e:define alternate 23,1,nflame5
if anim=5 then define 44,4 fireg2f:define alternate 23,1,nflame6
anim=anim+1
if anim>5 then anim=0

define 44,4 is for the 2 seperate fire sprites and define alternate nflame are the animated tiles.


  • Like 1
Link to comment
Share on other sites

The way I do something like this in my games is to cycle the GRAM itself, not the BACKTAB.

 

I define something I call "animation objects," which are records containing information such as frame rate, sequence, frame number, etc. Each "animation object" is allocated a "GRAM block," which is a contiguous set of GRAM cards (in practice, it's just the card index and the length of the block).

 

I keep track of these "animation objects" in an array. In my game, this array is statically defined since I always animate the same set of objects, but it could just be in RAM.

 

As part of drawing the scene, BACKTAB cells (or MOBs, because it works the same for both) just point to these GRAM blocks allocated for "animation objects."

 

Anyhoo, on every frame, the animation engine iterates through the array and advances the sequences as necessary (accounting for the fractional frame rates). When a sequence advances to a new animation frame, it marks it as "dirty," meaning that we must update it's GRAM block on the next VBLANK interrupt.

 

This technique is very effective and efficient, and it is what allows Christmas Carol to animate objects so fluidly.

 

The biggest breakthrough was when I implemented the "dirty flag" mechanism -- all of a sudden I could animate everything without worrying about cycles and VBLANK periods. It turns out that, by adjusting different frame rates for each object, the number of objects that happen to actually change at the same time is vanishingly small. And in a worse case scenario when all objects happen to change at the same time (which happens exceedingly rare, if ever), the effect is just to skip a single frame for a few objects, which is barely noticeable. The objects are still visible, they just repeat their current animation frame, and will get corrected and back on track on the next one.

 

Like I said, I used this mechanism for MOBs as well as BACKTAB. The difference was only that the latter did not move. The MOBs had a separate kernel to move them around.

 

As for the "dirty flag," it's just a bitmap in a 16-bit word: each "animation object" in the array is represented by a bit, which when set means it is "dirty." The GRAM update loop just shifts this word into the Carry while incrementing a counter: if the Carry is set, we need to update, so we use the counter as an index into the object array to get the GRAM card data, source, destination, and count; then block-copy into GRAM. Et voilà.

 

Like I said, very efficient. :)

 

I see no reason why something like this could not be implemented in IntyBASIC. Unfortunately, I have no code to share, for my PC is still in the shop at the moment. I also suck at IntyBASIC, so others may be able to offer better insight into how to do it in that language.

 

I know that the technique is general enough that I have baked it into my P-Machinery v2.0 framework as a general animation engine.

 

I hope this is useful to someone...

 

dZ.

  • Like 3
Link to comment
Share on other sites

Interesting. Taking this to one more level of depth, is there a workable way to refer to different Labels/tables dynamically instead of hardcoding them by name with VARPTR?

 

 

This ties in with my other thread/question about "foreach", kind of.

 

The scenario:

  1. Having 30 tiles in ROM under 30 different IntyBASIC labels. Tiles are for BACKTAB, not MOBs.
  2. First 5 tiles represent "object A" in 5 animation positions, Second 5 tiles represent "object B", etc.
  3. Using DEFINE and SCREEN to display tiles 0 and 15 ("object A" and "object D") on two different playfield regions in their first animation positions.
  4. During game play, GRAM-swap "object A" 0/1/2/3/4 and "object D" 15/16/17/18/19 using ON FRAME GOSUB.

 

During game play, the animated "object A" and "object D" need to be swapped out with another object at random (B or C or E or F).

 

I want to avoid having many deeply nested IF...THEN statements. I think that will be a performance killer and hard to read later.

 

Instead of doing something like this:

if anim=0 then define 44,4 fireg2a:define alternate 23,1,nflame1
...
...
...

I want to do something like this, where the label used in the DEFINE has a dynamically-generated name, so the program can call another function without the name being hardcoded. Is there some VARPTR magic that can be done?

DIM #gramTileToShow(2)
#gramTileToShow(0) = "A"
#gramTileToShow(1) = "D"
...
... ' code is running and then Object B needs to show where Object A used to display
#gramTileToShow(0) = "B"
...
...
On Frame Gosub Code:
...
#newLabelName = "Object" + #gramTileToShow(0) 
#newLabelNameAlt = "ObjectAlt" + #gramTileToShow(0) 
if anim=0 then define 44,4 #newLabelName:define alternate 23,1,#newLabelNameAlt
' Now the define would be for "ObjectB" and "ObjectAltB"
' and the words of data for those objects would be used for GRAM swap/cycle.


I am of course open to doing this completely differently. In the end, what I really want is a way to cycle a small set of BACKTAB tiles that are visible on the screen, and change that set programmatically so tiles that are not on screen don't have to participate in GRAM change.

 

 

(I am submitting all of this to Nanochess in case he wants to include it in a future IntyBASIC release in "samples")

 

Thanks!

Edited by First Spear
Link to comment
Share on other sites

Not sure of what you want really because the specs changed along your post, I understood "objects made of 30 tiles", with parts made of "5 tiles".

 

IntyBASIC will keep things contiguously so you need to include your tiles in a sequence.

 

If each object is 30 tiles and you want to display 5 tiles, the definition in the ON FRAME procedure is simple enough:

 

 

    IF proceed_to_animate_two_objects THEN
        DEFINE 0,5,VARPTR object_tile_sequence((object1 * 6 + frame1) * 5 * 4)
        DEFINE ALTERNATE 5,5,VARPTR object_tile_sequence((object2 * 6 + frame2) * 5 * 4)
    END IF

 

Note the enable variable 'proceed_to_animate_two_objects' because effectively you cannot use DEFINE/DEFINE ALTERNATE while this code is in effect.

 

The final multiplication * 4 is because the size of each bitmaps is 4 words. Note the two small multiplications that are optimized by IntyBASIC.

Link to comment
Share on other sites

Sorry. I knew it would be hard for me to explain - if I could explain it well, I would understand it enough to do it. :)

 

There are 6 objects. Each object has 5 frames of animation.

 

I want to GRAM swap object 0 (tiles 0-4) in a loop, and also object 3 (tiles 10-14) so it appears that there are two objects animating on the screen.

 

I want to then click a button or disc, and randomly replace object 0 with another object, and rotate through the 5 tiles that make the animation.

 

 

Thanks.

 

 

 

Not sure of what you want really because the specs changed along your post, I understood "objects made of 30 tiles", with parts made of "5 tiles".

 

IntyBASIC will keep things contiguously so you need to include your tiles in a sequence.

 

If each object is 30 tiles and you want to display 5 tiles, the definition in the ON FRAME procedure is simple enough:

    IF proceed_to_animate_two_objects THEN
        DEFINE 0,5,VARPTR object_tile_sequence((object1 * 6 + frame1) * 5 * 4)
        DEFINE ALTERNATE 5,5,VARPTR object_tile_sequence((object2 * 6 + frame2) * 5 * 4)
    END IF

Note the enable variable 'proceed_to_animate_two_objects' because effectively you cannot use DEFINE/DEFINE ALTERNATE while this code is in effect.

 

The final multiplication * 4 is because the size of each bitmaps is 4 words. Note the two small multiplications that are optimized by IntyBASIC.

Link to comment
Share on other sites

Perhaps it would be easier if instead of talking in technical terms of algorithms (since, as you say, you don't know how to describe the effect you want), you would explain it in terms of game "logical" objects, and game world effects. Then we could see how to best implement that on IntyBASIC.

 

So, let me see if I understand. Your game has something like 30 animated objects, of which two are displayed at a time. Each one should cycle through 5 animation cells.

 

These game objects are rendered on BACKTAB, not as MOBs, which is where your challenge comes in.

 

Is this accurate so far?

 

Also, is it accurate to say that the reason you contrast it with MOBs is because you think you could do this easily with sprites, but the BACKTAB animation is what is throwing you off?

 

If the answer to that second question is true, then let's consider what is the difference between them. What does the MOB have that you feel you lack when working with the BACKTAB?

 

In my opinion, the most likely feature is the "object" record. Each MOB has a record with a color, a GRAM pointer, and position, etc. In contrast, you treat each BACKTAB object as just a cell, but are missing the rest of the information.

 

The solution is to create "fake" object records. That's what I tried to describe in my post above: an array of "animation objects," each with the necessary information to track and animate them. This could include the animation and GRAM information, as well as their BACKTAB position (by address it by cell coordinates) and game state.

 

You can then iterate through this array and animate the objects as necessary, or address them via pointers, in a similar way that you would do for MOBs.

 

When the objects move out of the screen or are replaced by other objects, just mark the old ones as "disabled" and "enable" the new ones, so that the next iteration of your animation loop processes them accordingly.

 

Does this help? Am I anywhere near understanding what you are trying to accomplish? :)

  • Like 1
Link to comment
Share on other sites

Then you don't need to use ON FRAME GOSUB. (BTW if each object is 5 tiles, object 3 cannot be 10-14 but 15-19)

 

 

object_number_1 = 0
object_frame_1 = 0
object_number_2 = 3
object_frame_2 = 0
' This code expects the GRAM cards already rendered in screen.
WHILE your_code_has_not_ended
    DEFINE 0,1,VARPTR object_tiles((object_number_1 * 5 + object_frame_1) * 4)
    DEFINE ALTERNATE 1,1,VARPTR object_tiles((object_number_2 * 5 + object_frame_2) * 4)
    WAIT
    object_frame_1 = (object_frame_1 + 1) % 5
    object_frame_2 = (object_frame_2 + 1) % 5
    IF cont1.button THEN
        IF debounce = 0 THEN
            object_number_1 = RANDOM(5)
            debounce = 10
        END IF
    END IF
    IF debounce <> 0 THEN debounce = debounce - 1
WEND
 
  • Like 1
Link to comment
Share on other sites

not to capture the thread, but how does DEFINE ALTERNATE do compated to the Normal DEFINE?

The DEFINE statement requires contiguous range of BITMAPs. DEFINE ALTERNATE was created to allow a bit more flexibility so you can update two different ranges of GRAM (as long as it is 16 cards or less total)

Link to comment
Share on other sites

Comments inline - thanks!

 

Perhaps it would be easier if instead of talking in technical terms of algorithms (since, as you say, you don't know how to describe the effect you want), you would explain it in terms of game "logical" objects, and game world effects. Then we could see how to best implement that on IntyBASIC.

So, let me see if I understand. Your game has something like 30 animated objects, of which two are displayed at a time. Each one should cycle through 5 animation cells.

These game objects are rendered on BACKTAB, not as MOBs, which is where your challenge comes in.

Is this accurate so far?

 

Yes, basically. There are 6 objects, each object has 5 tiles to represent a frame of animation. The objects can appear in any of the 240 available tile areas on the screen. There can be more than one of the same object on the screen, all animating at the same rate.


Also, is it accurate to say that the reason you contrast it with MOBs is because you think you could do this easily with sprites, but the BACKTAB animation is what is throwing you off?

 

Not exactly. I just wanted to be explicit about the need to use BACKTAB for the animated tiles.

 

 

If the answer to that second question is true, then let's consider what is the difference between them. What does the MOB have that you feel you lack when working with the BACKTAB?

In my opinion, the most likely feature is the "object" record. Each MOB has a record with a color, a GRAM pointer, and position, etc. In contrast, you treat each BACKTAB object as just a cell, but are missing the rest of the information.

The solution is to create "fake" object records. That's what I tried to describe in my post above: an array of "animation objects," each with the necessary information to track and animate them. This could include the animation and GRAM information, as well as their BACKTAB position (by address it by cell coordinates) and game state.

You can then iterate through this array and animate the objects as necessary, or address them via pointers, in a similar way that you would do for MOBs.

When the objects move out of the screen or are replaced by other objects, just mark the old ones as "disabled" and "enable" the new ones, so that the next iteration of your animation loop processes them accordingly.

Does this help? Am I anywhere near understanding what you are trying to accomplish? :)

 

You are pretty near. The animation should happen throughout the whole game (thus my ask around ON FRAME GOSUB). If a new object should show on the screen, one of the objects should be swapped out, and another should show in its place. If there are 7 of the same object, they would all be swapped out with 7 of the new object.

 

 

Link to comment
Share on other sites

I don't know if I got the right idea, I made a MOB/#BACKTAB animation demo. It only uses GRAM cards, and DATA for animation, and, an offset to "reset" the index variable (the demo just restarts the animation). For example, MyAnim: DATA SPR03,SPR04,SPR05,SPR04,SPR05,SPR04,-6 '--go back 6 "frames"


The demo also defines an animation master data list (it's possible to pick animations at random). IntyBasic insists that "DATA VARPTR Label2(0) - VARPTR Label1(0)" is not a constant, so it's done at runtime.


Animation.zip

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

Similar ask: I have GRAM location 11 with an image in it, already DEFINEd. It may or may not be visible on the screen (it may or may not be in #BACKTAB). If it is visible (ie, is in BACKTAB), then I want to re-DEFINE it with another shape in ROM. If it is not visible, then I do not want to spend CPU time doing the redefinition.

 

This does not sound like a lot of CPU work for a single shape, but I will have to do it for about 14 shapes (not all contiguous in GRAM), and am doing it in ON FRAME GOSUB which I want to code as tightly as possible.

 

Thanks.

 

 

 

 

 

I don't know if I got the right idea, I made a MOB/#BACKTAB animation demo. It only uses GRAM cards, and DATA for animation, and, an offset to "reset" the index variable (the demo just restarts the animation). For example, MyAnim: DATA SPR03,SPR04,SPR05,SPR04,SPR05,SPR04,-6 '--go back 6 "frames"
The demo also defines an animation master data list (it's possible to pick animations at random). IntyBasic insists that "DATA VARPTR Label2(0) - VARPTR Label1(0)" is not a constant, so it's done at runtime.

 

Link to comment
Share on other sites

Similar ask: I have GRAM location 11 with an image in it, already DEFINEd. It may or may not be visible on the screen (it may or may not be in #BACKTAB). If it is visible (ie, is in BACKTAB), then I want to re-DEFINE it with another shape in ROM. If it is not visible, then I do not want to spend CPU time doing the redefinition.

 

This does not sound like a lot of CPU work for a single shape, but I will have to do it for about 14 shapes (not all contiguous in GRAM), and am doing it in ON FRAME GOSUB which I want to code as tightly as possible.

 

Thanks.

 

If your #BACKTAB data is from a large map, maybe a mini-map (look-up table) in cart ROM can do the job? I can't think of a good approach. Maybe the mimimap should cover 20x10, combine the surrounding 4? ...Maybe it's easier updating all 14 definitions, but, at least 4 at a time.

Link to comment
Share on other sites

Can you not use counters for the 14 GRAM characters, so each time you plot one the corresponding counter is increased, instead of combing through BACKTAB? Perhaps I'm misunderstanding your objective but I would consider something like that if you have 14 bytes (8-bit variables) to spend.

Link to comment
Share on other sites

For example, I have a ball drawn in GRAM location 7 (using DEFINE to get the bitmap into GRAM). The ball is drawn on BACKTAB, it is not a MOB.

 

I want to create an animation effect by re-DEFINE the shape in GRAM 7 with the ball in a slightly different position within the tile. After a moment, I want to re-DEFINE again. I only want to animate when the thing in GRAM location 7 is visible in the 14x8 play area. If GRAM 7 is not in the BACKTAB visible area, I do not want to incur the CPU penalty of re-DEFINE a shape that the player cannot see.

 

What is a good tactic for doing that?

 

Thanks.

 

Can you not use counters for the 14 GRAM characters, so each time you plot one the corresponding counter is increased, instead of combing through BACKTAB? Perhaps I'm misunderstanding your objective but I would consider something like that if you have 14 bytes (8-bit variables) to spend.

Link to comment
Share on other sites

For example, I have a ball drawn in GRAM location 7 (using DEFINE to get the bitmap into GRAM). The ball is drawn on BACKTAB, it is not a MOB.

 

I want to create an animation effect by re-DEFINE the shape in GRAM 7 with the ball in a slightly different position within the tile. After a moment, I want to re-DEFINE again. I only want to animate when the thing in GRAM location 7 is visible in the 14x8 play area. If GRAM 7 is not in the BACKTAB visible area, I do not want to incur the CPU penalty of re-DEFINE a shape that the player cannot see.

 

What is a good tactic for doing that?

 

Thanks.

 

 

Each BACKTAB has at least 2 bits which are not touched by the STIC or EXEC, so they are free to use. You could mark the "hidden" positions by setting one of these bits, then only update the GRAM for objects which are in positions without that bit set.

 

This would work, but would require you to scan the entire background every time to look for the words. Perhaps you can be pro-active and keep an array of all the GRAM cards you need to update and use that instead. As you switch the state of BACKTAB cells on and off, you make sure to update the entry in your "GRAM array" for the card it uses.

 

There may be better ways, though... :ponder:

Link to comment
Share on other sites

I would use a variable named "my_thing" to signal the existence of the thing or things instead of searching the whole screen.

 

No way a whole searching of screen could be fast.

 

That's what I meant by the "GRAM Array," since you would have to store the state of all GRAM cards that need updating. Depending on the number of them, you could get away with bit-twiddling a single 16-bit word.

 

That is basically what I do in P-Machinery and in Christmas Carol: keep a 16-bit status word that represents the "Dirty Flag" of each GRAM animated block (whether tied to a MOB or to BACKTAB). Then it's easy to just shift-and-branch to iterate through them and skip the "off" ones. My animation engine takes care of setting the "Dirty Flag" corresponding to a particular object when the card needs changing.

 

-dZ.

  • Like 1
Link to comment
Share on other sites

I might be barking up the wrong forest here. My idea is to use three arrays gc for state counter of each GRAM and corresponding gx and gy to hold its position. However I realize as I'm writing this that I'm limiting myself to 16 BACKTAB cards, each holding an unique GRAM plus that in my example, neither are moving.

 

I tried to use some dynamic stuff like VARPTR, arrays that hold pointers to other segments but I didn't get it to get past the compiler so I had to try something else. Probably most of this is irrelevant to the asked question.

 

 

  REM Count GRAM and update only those on scren

  MODE 1:BORDER 7,0:WAIT

  DIM gx(16), gy(16), gc(16) : REM Keep track of up to 16 GRAMs

  FOR i=0 TO 15:gc(i)=0:gx(i)=0:gy(i)=0:NEXT
 
  CLS:FOR i=0 TO 11:PRINT AT i*20 COLOR $2600,"                    ":NEXT

loop:
  FOR i=0 TO 15
    IF gc(i)>0 THEN
      IF gc(i)>7 THEN
        gc(i)=0
        PRINT AT gx(i)+gy(i)*20," "
      ELSE
        IF gc(i)=1 THEN DEFINE i,1,state2
        IF gc(i)=2 THEN DEFINE i,1,state3
        IF gc(i)=3 THEN DEFINE i,1,state4
        IF gc(i)=4 THEN DEFINE i,1,state5
        IF gc(i)=5 THEN DEFINE i,1,state6
        IF gc(i)=6 THEN DEFINE i,1,state7
        WAIT

        REM DEFINE i,1,state1+(gc(i)*16):REM VARPTR graph(gc(i))
        gc(i)=gc(i)+1
      END IF
    ELSE
      IF RANDOM(10)>7 THEN
        gx(i)=RANDOM(20)
        gy(i)=RANDOM(12)
        gc(i)=1
        POKE 512+gy(i)*20+gx(i),gc(i)*8+$2e00
        DEFINE i,1,state1:WAIT
       END IF
     END IF
  NEXT
  GOTO loop

REM graph:
REM  DATA state1, state2, state3, state4, state5, state6, state7

state1:
  BITMAP "00000000"
  BITMAP "00000000"
  BITMAP "00000000"
  BITMAP "00011000"
  BITMAP "00011000"
  BITMAP "00000000"
  BITMAP "00000000"
  BITMAP "00000000"

state2:
  BITMAP "00000000"
  BITMAP "00000000"
  BITMAP "00011000"
  BITMAP "00111100"
  BITMAP "00111100"
  BITMAP "00011000"
  BITMAP "00000000"
  BITMAP "00000000"

state3:
  BITMAP "00000000"
  BITMAP "00011000"
  BITMAP "00111100"
  BITMAP "01111110"
  BITMAP "01111110"
  BITMAP "00111100"
  BITMAP "00011000"
  BITMAP "00000000"

state4:
  BITMAP "00011000"
  BITMAP "00111100"
  BITMAP "01111110"
  BITMAP "11111111"
  BITMAP "11111111"
  BITMAP "01111110"
  BITMAP "00111100"
  BITMAP "00011000"

state5:
  BITMAP "00011000"
  BITMAP "00111100"
  BITMAP "01111110"
  BITMAP "11100111"
  BITMAP "11100111"
  BITMAP "01111110"
  BITMAP "00111100"
  BITMAP "00011000"

state6:
  BITMAP "00011000"
  BITMAP "00111100"
  BITMAP "01100110"
  BITMAP "11000011"
  BITMAP "11000011"
  BITMAP "01100110"
  BITMAP "00111100"
  BITMAP "00011000"

state7:
  BITMAP "00011000"
  BITMAP "00100100"
  BITMAP "01000010"
  BITMAP "10000001"
  BITMAP "10000001"
  BITMAP "01000010"
  BITMAP "00100100"
  BITMAP "00011000"
  • Like 1
Link to comment
Share on other sites

Hmmmm... good idea :) also needs to be pretty optimized

Actually , the trick is realizing that all computations can be done outside the critical path, to get everything ready for the GRAM update. The test-and-copy loop is the part that needs to optimized, the rest is done outside the ISR context, during the regular game loop.

 

That's why I use a 16-bit status word: you SARC then branch out on no carry to skip. It's pretty neat, and the results are proven by Christmas Carol's animations, which run at 60 Hz, with variable animation rates, updating up to 12 individual animated objects at once.

 

In practice, the dirty flag sort of ensures that not many objects are updated at the same time, since they are only updated when absolutely needed.

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