Jump to content
IGNORED

Using assembly in BBasic to edit p0 pixels?


freshbrood

Recommended Posts


 


 


 


 


 

In visual bataribasic, if I only wanted to change ONE pixel in a player sprite, for example:


 


 

  player0:

  %00000001

  %00000000

  %00000001

end


 

to


 

  player0:

  %00000000

  %00000000

  %00000001

end


 

How could I do using just an assembly insert without having to redraw the entire sprite? Is it possible?

 


 


 

Edited by freshbrood
Link to comment
Share on other sites

Thank you RT but I'm not worried about help with drawing graphics. I meant some kind of code that changes graphic pixels in game according to player actions.


 

 

 

For example, say instead of drawing an entire new sprite for player1, recycling the p0 sprite but adding or taking away a few particular pixels (i.e. add a hat, ponytail, one pixel turning on then off to simulate a blink, etc..)

 

 

 

I'm not sure if this is possible or would save any graphic memory if it was.
 

Link to comment
Share on other sites

3 minutes ago, freshbrood said:

Thank you RT but I'm not worried about help with drawing graphics. I meant some kind of code that changes graphic pixels in game according to player actions.


 

 

 

For example, say instead of drawing an entire new sprite for player1, recycling the p0 sprite but adding or taking away a few particular pixels (i.e. add a hat, ponytail, one pixel turning on then off to simulate a blink, etc..)

 

 

 

I'm not sure if this is possible or would save any graphic memory if it was.
 

Interesting, i wouldn't mind playing around with this in a test program. I am assuming you're wanting something like bit operators for the player graphics. Not sure if it's possible however i would like to think it is. Basically something like

if player0{7} then player0{7} = 0

Not sure how one would edit more the a single byte though, nevertheless it would be a great feature ?

Link to comment
Share on other sites

I think it would be an immensely useful feature that could potentially add "extra" graphics while saving graphic memory. I'm surprised no one has done this yet. For example I am making a Mortal Kombat clone, but due to limited memory I use the same body type for every character using const/playerhi/low, but only change the color when a new "fighter" is selected. It would look amazing if with that new color pallet, maybe just 2 more pixels could be drawn within the unused 0's in that sprite at that time, to maybe add a "pony tail" or hat. Those tiny, subtle differences combined with changed colors would give the illusion of an entirely new sprite, even though it's the same sprite every time with just a couple pixels turned on or off after the code reads the default sprite.

 

Edited by freshbrood
Link to comment
Share on other sites

I have no clue how you would or could implement that, I'm still learning bbasic and don't know any assembly... but it seems logical that some type of assembly code could read the raw basic data, starting at a particular player0: then add however many y coords and 0 through 7 x coords to land on a 0 or 1 within the sprite graphic, and toggle that on or off- without having to redraw an entirely new sprite or jump to another separate sprite.


 


 

I mean something similar to pfpixel, but instead p0pixel (label) x, y on


 

Where p0pixel is the built in routine syntax which then jumps to that label, then reads down stopping at the first player0: and counts the pixels down then across within that sprite.


 

Edited by freshbrood
Link to comment
Share on other sites

Yes exactly. I think the easiest way to implement it would be exactly like that- even if early limitations meant no bankswitching- it had to be used within that same bank, or there was a height limit on the sprite.
 

There are so many uses for it. Make sprites "vanish" into thin air as they disintegrate, shrink up (the opposite of decreasing p0height) have static NPC's constantly blink an eye, tap a foot, or open and close their mouth when they talk, etc.. That one tiny feature would make the graphics look amazing, both for static and animations.
 

Edited by freshbrood
Link to comment
Share on other sites

8 minutes ago, freshbrood said:

Yes exactly. I think the easiest way to implement it would be exactly like that- even if early limitations meant no bankswitching- it had to be used within that same bank, or there was a height limit on the sprite.
 

There are so many uses for it. Make sprites "vanish" into thin air as they disintegrate, shrink up (the opposite of decreasing p0height) have static NPC's constantly blink an eye, tap a foot, or open and close their mouth when they talk, etc.. That one tiny feature would make the graphics look amazing, both for static and animations.
 

Banks wouldn't be an issue with DPC+ as it reads the full 32k ROM rather then separate banks. I don't think it would be too hard to implement as the code would be very much like pfpixel code. The next question is, would anyone on the bB team have the enthusiasm to add such a feature. I know many of them are busy working on their own projects ect.

 

Personally i like the feature that much i would if i had the knowledge of the kernels. However i haven't cracked them open yet nor learnt how they work.

 

I really like the feature though and think it's worthy to be added to DPC+ atleast. I can think of multiple times i would use this rather then creating new sprites for simple animations.

  • Like 1
Link to comment
Share on other sites

I can't see why this couldn't become part of the base code for regular bbasic, without even needing to use DPC+. The only thing I can think of is it would have a limit of 0-7 for the x, and maybe 99?-0 for the y.



 



 

player0pixel, __Standsprite, 7 97 off



 



 



 

__Standsprite

   player0:

  %00000001

  %00000000

  %00000000

end



 

would result in turning that single 1 to a 0 and make the sprite invisible. (assuming the default height is set to 99)

I would think it would be temporary read only, like setting the direction each time within the loop.
 

 


 

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

1 hour ago, freshbrood said:

Thank you RT but I'm not worried about help with drawing graphics. I meant some kind of code that changes graphic pixels in game according to player actions.

 

RevEng puts the sprite in RAM, then you can fiddle fart with it in whatever way you want. You don't have to draw in it. A sprite in ROM can't be changed, so it has to be put in RAM.

  • Like 1
Link to comment
Share on other sites

ypos could be limited to 255 from 0 @ top to whatever the programmer desires further down the sprite. That way the full sprite length can be utilized as per normal functionality. This would allow for "scrolling" sprites to be changed on the fly using code for pixel flipping rather then a sequence of animated sprite data.

 

So for instance you could have "player0pixel 7 200 flip" and have that sprite move upward meaning when the 200th line makes an appearance bit 7 on line 200 would be active. For the next complete scroll the programmer could have the pixel deactivated. This would give the illusion much like scrolling playfield does.

 

Either way this would open many possibilities

  • Like 1
Link to comment
Share on other sites

22 minutes ago, Random Terrain said:


 

I wasn't talking about my program, I was talking about the original RevEng program it was based on. He puts the sprite in RAM, then you can fiddle fart with it in whatever way you want. A sprite in ROM can't be changed.

Yeah I certainly do not know enough to fiddle fart with it. I was thinking maybe it just creates a temp copy in ram only for that one drawscreen command then goes right back to reading the default rom sprites unless that command is used again. It would only temporarily change the sprite. And maybe it could only be used for one sprite at a time as per ram, instead of changing multiple sprites at once. That would be an amazing implementation into the core bbasic program if possible.
 

Link to comment
Share on other sites

25 minutes ago, TwentySixHundred said:

ypos could be limited to 255 from 0 @ top to whatever the programmer desires further down the sprite. That way the full sprite length can be utilized as per normal functionality. This would allow for "scrolling" sprites to be changed on the fly using code for pixel flipping rather then a sequence of animated sprite data.


 

So for instance you could have "player0pixel 7 200 flip" and have that sprite move upward meaning when the 200th line makes an appearance bit 7 on line 200 would be active. For the next complete scroll the programmer could have the pixel deactivated. This would give the illusion much like scrolling playfield does.


 

Either way this would open many possibilities

At the very least you could have a village full of different and unique NPC's, almost countless, using the same default sprite that has temporarily altered pixels inside each shop or house you enter.
 

Link to comment
Share on other sites

Here is a semi-related post:

 

https://atariage.com/forums/topic/273720-if-there-was-unlimited-ram-how-good-could-a-2600-game-get/?do=findComment&comment=3923960

Quote

The good thing about more RAM is that you might have room for all sprites to be in RAM instead of having them stuck in ROM. For example, the shields in Space Invaders are in RAM, so you can shoot pieces out of them. You can do fancy things with your sprites if they are in RAM, not just let the player damage them. You could have interchangeable parts so it will look like the game has a nearly unlimited number of sprite variations (have the game use controlled randomness to switch out various horizontal sections and colors of the sprites). You could even allow the player to select a character by cycling through styles of hats, shirts, pants, and shoes (similar to how it's done in Strawberry Shortcake: Musical Match-ups).

 

More RAM would also mean that the programmer could have more variables. For example, batari Basic programmers go from 26 variables to over 74 when they switch to Superchip RAM. If we had even more RAM mixed with a DPC+ style kernel, we'd have pretty graphics and possibly hundreds of variables to use for keeping track of things and making more complex games. Imagine making a large adventure game where the location of every item is remembered and non-player characters could have multiple variables that keep track of their personalities and moods. Are they kind or evil or somewhere in between? Are they sad or angry? Peaceful or aggressive? Atari 2600 games could have non-player characters that are more realistic and complex than most players ever thought possible. All we need is more RAM and a new kernel.

 

  • Like 1
Link to comment
Share on other sites

[This isn't the same thing, but I had high hopes for years about wiggling sprites and Pitfall vines.]

 

Here is part of a post by batari from 2008:

 

https://atariage.com/forums/topic/122024-64k-bb-games/?do=findComment&comment=1483436

Quote

I have what I'm calling "vectors" working in the standard kernel, but need to add compiler support for them. By "vector," I mean you are able to turn a missile into a line or an arc connecting two points, for example like the Pitfall vines. Or you can also use a missile as a "fake player" by varying the width, or you can shift a player object per line to make it look more interesting, like the cows in Stampede or the dolphin in Dolphin. The only drawback to this is the HMOVE "comb" at the left edge of the screen, but there seems to be no way around that.

 

Wiggling sprites or wriggling sprites and Pitfall vine missiles were never added. Here's more from batari in 2010:

 

https://atariage.com/forums/topic/169278-looking-for-a-post-by-batari-about-wriggling-sprites/?do=findComment&comment=2094491

Quote

IIRC, I think I had trouble getting the "wiggling sprites" to fit properly with all of the assembly directives in the standard kernel, and doing something like a vine would have required a ton of data - i.e. a table for every possible frame, as opposed to Pitfall which calculated the vine within the kernel. I tried to implement a calculated vine like that but could not make it work. I'll look into it again someday.

 

Maybe after our alien overlords give us all Star Trek-like replicators and do away with the need to work your fingers to the bone to make money, some assembly language programmers will jump in for the fun of it and add so many new features to batari Basic that it might make your head explode from the extreme joygasm.

 

 

Related quote:

 

"We do it because we can, 'cause we know how. We do it whether people remember us or not, in spite of the fact that there's no shiny reward at the end of the day…other than the work itself."

~ 'Angel' from the TV series Angel (S5:E6)

  • Like 1
  • Haha 1
Link to comment
Share on other sites

37 minutes ago, freshbrood said:

I was thinking maybe it just creates a temp copy in ram only for that one drawscreen command then goes right back to reading the default rom sprites unless that command is used again. It would only temporarily change the sprite..

That's the difference with DPC+ over the standard kernels as the graphics data only needs to be set once and doesn't need to be updated every frame. Im sure making a change to individual bit's of sprites wouldn't be much different from pfpixel as it's preloaded into the melody RAM (DPC+). That means rather then altering ROM (which you obviously can't) you can however alter RAM which DPC+ uses.

Link to comment
Share on other sites

ARM function calls are more expensive than manipulating the memory on the 6507 side.  I'm not sure playerpixel on and off would be practical.  The 4k data limit is a mirage, so you're better off just using sprites.

 

I think a vine can be done by manipulating the start and height pointers on a tall sprite and hitting REFPx.

 

...X....

...X....

...X....

...X....

...X....

..X.....

.X......

X.......

 

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

The answer is, like mentioned a few times, to use the sprite pointers to point to  set of contiguous RAM, you can then simply change the RAM to edit the pixels that are on/off. I had posted some examples when I was trying different ways of saving space while working on ATAX-ATAX

Quote

 rem EXAMPLE ONE
 rem drawing an arrow to player0 sprite in ROM
   player0:
   %00000000
   %00010000
   %00111111
   %11111111
   %00111111
   %00010000
   %00000000
end
 
 rem EXAMPLE TWO
 rem using RAM s-y
 s=0 : y=0 :  player0pointerhi=0
 t=16 : x=16
 u=63 : w=63
 v=255
 player0pointerlo = $E9
 player0height=7

 

 rem EXAMPLE THREE
 rem using ram s-y and in ASM
 asm
 lda #0
 sta s
 sta y
 sta player0pointerhi
 lda #7
 sta player0height
 lda #16
 sta t
 sta x
 lda #63
 sta u
 sta w
 lda #233
 sta player0pointerlo
 lda #255
 sta v
end

All three examples result in the same sprite. In example two or three, if you change any of the values of s-y you'll change that row of the sprite, for example I use the number "16" for two rows of the sprite but you could easily express this as "%00010000" if that is easier for you to visualize. To add a pixel to the end you could change it to 17 or %00010001

  • Like 3
Link to comment
Share on other sites

On 4/18/2020 at 9:58 PM, Sknarp said:

In example two or three, if you change any of the values of s-y you'll change that row of the sprite, for example I use the number "16" for two rows of the sprite but you could easily express this as "%00010000" if that is easier for you to visualize. To add a pixel to the end you could change it to 17 or %00010001

 

I adapted an example program from the bB page based on your second example. Pressing the fire button randomly changes two rows of the RAM sprite.

 

Here's the .bin file to use with your favorite emulator:

ex_move_ram_sprite_2020y_04m_20d_0549t.bin

 

Here's the .bas file:

ex_move_ram_sprite_2020y_04m_20d_0549t.bas

 

 

   dim _Sprite_Row_7 = a
   dim _Sprite_Row_6 = b
   dim _Sprite_Row_5 = c
   dim _Sprite_Row_4 = d
   dim _Sprite_Row_3 = e
   dim _Sprite_Row_2 = f
   dim _Sprite_Row_1 = g
   dim _Sprite_Row_0 = h


   player0pointerhi=0
   player0pointerlo = $D4
   player0height=8

   _Sprite_Row_0 = %00111100
   _Sprite_Row_1 = %01111110
   _Sprite_Row_2 = %11011011
   _Sprite_Row_3 = %11111111
   _Sprite_Row_4 = %10111101
   _Sprite_Row_5 = %11000011
   _Sprite_Row_6 = %01111110
   _Sprite_Row_7 = %00111100

 

 

 

 

  • Like 3
Link to comment
Share on other sites

  • 9 months later...

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