freshbrood Posted April 13, 2020 Share Posted April 13, 2020 (edited) 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 April 13, 2020 by freshbrood Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted April 13, 2020 Share Posted April 13, 2020 I wonder if the program by RevEng that I link to from this thread would be useful: atariage.com/forums/topic/289171-draw-sprites-on-your-atari-2600/ 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted April 13, 2020 Author Share Posted April 13, 2020 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. Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted April 13, 2020 Share Posted April 13, 2020 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 ? Quote Link to comment Share on other sites More sharing options...
freshbrood Posted April 13, 2020 Author Share Posted April 13, 2020 (edited) 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 April 13, 2020 by freshbrood Quote Link to comment Share on other sites More sharing options...
freshbrood Posted April 13, 2020 Author Share Posted April 13, 2020 (edited) 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 April 13, 2020 by freshbrood Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted April 13, 2020 Share Posted April 13, 2020 If it worked much like flipping playfield pixels i can't see why not TBH. Something like player0pixel 0 7 on For example reference I agree it would be very useful ? 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted April 13, 2020 Author Share Posted April 13, 2020 (edited) 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 April 13, 2020 by freshbrood Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted April 13, 2020 Share Posted April 13, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted April 13, 2020 Author Share Posted April 13, 2020 (edited) 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 April 13, 2020 by freshbrood 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted April 13, 2020 Share Posted April 13, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted April 13, 2020 Share Posted April 13, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted April 13, 2020 Author Share Posted April 13, 2020 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. Quote Link to comment Share on other sites More sharing options...
freshbrood Posted April 13, 2020 Author Share Posted April 13, 2020 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted April 13, 2020 Share Posted April 13, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted April 13, 2020 Author Share Posted April 13, 2020 (edited) Who would we talk to about this to hard code into the next update of bbasic? I think we all agree in theory it seems very plausible. Edited April 13, 2020 by freshbrood Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted April 13, 2020 Share Posted April 13, 2020 [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) 1 1 Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted April 13, 2020 Share Posted April 13, 2020 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. Quote Link to comment Share on other sites More sharing options...
KevKelley Posted April 13, 2020 Share Posted April 13, 2020 This is interesting, as I was just wondering about this when I was reading about the playfield variables and wondered if sprites had something similar. 1 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted April 14, 2020 Share Posted April 14, 2020 (edited) colors and graphics in RAM.bas Even if you just want to change one bit in the graphics, it's faster to update the whole byte like this instead of bit operations. Doesn't work in the DPC+ kernel yet. Edited April 14, 2020 by Lillapojkenpåön Quote Link to comment Share on other sites More sharing options...
orange808 Posted April 14, 2020 Share Posted April 14, 2020 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....... 1 1 Quote Link to comment Share on other sites More sharing options...
Sknarp Posted April 19, 2020 Share Posted April 19, 2020 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 3 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted April 20, 2020 Share Posted April 20, 2020 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 3 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 22, 2021 Author Share Posted January 22, 2021 Thank you so much RT! You guys are so good with responding. I'm just seeing this now. I live in the middle of nowhere with a terrible data connection. I will play around with this later. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.