jbs30000

OK, I found a solution. Before Test1_STRIP_0 I put ORG $F100. Before Test1_STRIP1 I put ORG $F200, and so on. I thought that doing that would do the same thing as putting an align 256 before each data table, but apparently not.

Nevermind, I'm a moron.

OK, I did what you said, and it looks a lot better, but there is a line that goes across most of the top of the screen. I've been checking my code against what the tutorial and what you and RevEng have been saying, and it appears to match, but apparently I have done something wrong. If you, or somebody, wouldn't mind checking my code one last time I would really appreciate it. I'm sure it must be a tiny error. Thank you. I'll just post the program code, as the image code is what I posted with align 256 added before each data table. Test.asm

Just to add, I tried a SEG ORG $F100 which is exactly 256 bytes after the start of the kernel (the kernel ends at $F099). The screen look exactly like the screen in post 3.

Sorry, for some reason when I posted my second post, I didn't see this one. OK, so do I place the data in a specific location by using the SEG and ORG directives? Or maybe just ORG? Thank you.

Oh, and to make sure that it wasn't the image file that was the problem, I reused the image file that was displaying upside down and changed the code in the test program to display it right side up. It looks better, but it has some garbage on the top of the screen. I guess I'm having a hard time telling if it's the image or the code to display it.

Hi. Although I'm not new to programming, or even 2600 programming, I am new to 2600 asm programming. I've been following along with the tutorials made by Andrew Davie. They're fantastic and easy to follow. But I've come upon a strange problem. I'm on chapter 20, which is asymmetric playfields. I wrote code, OK, mostly copied code, to display my own 40x192 playfield. When I first ran the program the playfield was upside down, but otherwise displayed right. So I flipped the playfield, re-ran the FSB program to create playfield data and re-assembled the program. Now the image isn't quiet drawn correctly. Here is the upside down version and here is the right-side up version Here is the asm file Test.asm and if it will help, the image data Test1.asm Thank you.

Just a guess, but I'm guessing that switchleftb and switchrightb are bits, or at least they're acting like working with bits. What I mean is, you can't go if a{1}=b{1} for example, but you can go if a{1} then if !b{1}.

Thank you all. Using player2 instead of player1 and NUSIZ2 to flip the sprite works great.

Bump

I originally worded this pretty poorly, so let me try again. I made a program which displays a giant character made of two sprites. The character is facing left. To make him face right I swap the positions of sprites 0 and 1 and then use REFP0=8 and REFP1=8. Even though I found a thread which says that each sprite gets its own REFP the REFP1 didn't reverse the player1 sprite. I'm just curious if it's because REFP1 isn't implemented in the most recent DCP+ kernel, or if I need to type in something different. I tried _REFP1 but that's obviously not a command as the program doesn't compile right. Thank you.

I present another update, and I'm really proud of this one. It still is only on the one screen but there are some improvements. After you jump on the turtle, you can push him (to the left or right). Just like in Super Mario Bros jumping on an upside down turtle won't make him go upright again like in my first demo. There's a power-up brick you can jump up into and a mushroom pops up. Touching the mushroom will make you large. You'll notice some bugs. Here they are, and the reason behind them. The mushroom doesn't move. This will be fixed when DPC+ has pfread. When you jump on the turtle you might bounce a few times. In general Mario jumping and falling needs to be worked on. Again, I will when I can use pfread. After flipping the turtle upside down you can push it, but after touching it you have to quickly move in the other direction or you'll die (or shrink if you're large). When you push the upside down turtle it doesn't move fast like in the original game. Both 3 and 4 are because the routine I'm using for moving the turtle is not the actual code that I'll use for the game. It's only for the demo and will be fixed in the actual game. Anyway, I'm proud because even though this is only one screen, this is way more than I accomplished on my attempt using the regular bB kernal. Main.bas.bin Main.bas

OK, take players 0 and 1. If player 0 ends horizontally before player 1 starts, or if it starts after player 1 ends then there's no collision. The same thing goes vertically. Otherwise, there's a collision. For example, pretend players 0 and 1 are 8x8 squares. If player0x=0 and player0y=0 then horizontally and vertically player0 is 0 to 7, so if player1x is 8 or greater or player1y is 8 or greater, then there's no crash. Obviously that's a big, "Well duh!," so here's my code. There might be a better way to code this, but here's how I do it. First, my temp variables dim TempA=t dim TempB=u dim TempC=v dim TempD=w dim TempE=x Now the crash code. I go to this if collision(player0, player1) is true. If player 0 and 1 collide then TempE[0]=1. If player 0 and 2 crash then TempE[1]=1, etc... Mario_Enemy_Crash TempA=player0x+7 if Mario_is_Large then TempB=player0y+15 else TempB=player0y+9 TempE=0 Mar_Crash_1 TempC=player1x+7: TempD=player1y+11 if TempA<player1x||player0x>TempC then goto Mar_Crash_2 if TempB<player1y||player0y>TempD then goto Mar_Crash_2 TempE{0}=1 Mar_Crash_2 TempC=player2x+7 if Enemy1_is_a_Turtle then TempD=player2y+12 else TempD=player2y+9 if TempA<player2x||player0x>TempC then goto Mar_Crash_3 if TempB<player2y||player0y>TempD then goto Mar_Crash_3 TempE{1}=1 Mar_Crash_3 TempC=player3x+7: TempD=player3y+9 if TempA<player3x||player0x>TempC then goto Mar_Crash_4 if TempB<player3y||player0y>TempD then goto Mar_Crash_4 TempE{2}=1 Mar_Crash_4 TempC=player4x+7: TempD=player4y+9 if TempA<player4x||player0x>TempC then return if TempB<player4y||player0y>TempD then return TempE{3}=1 return

I found a perfect way to detect which sprites are colliding with each other. Now that I've done that I'll add power-up bricks to the demo.

If anybody can tell me why my collision detection routine doesn't work all the time I'd really appreciate it. For this post I'm adding REMs that aren't in the program just in case anybody doesn't know what what I'm doing. For this example we'll assume I pushed 12 player2y player2x. 12 is the height of a turtle. Mario_Crash rem stack should have height, Y pos, X pos rem All sprites have a max of 8 pixels wide. TempB holds player player2x TempA=player0x+7: pull TempB: TempC=TempB+7 rem TempD = player2x to player2x+7 for TempD=TempB to TempC rem If any player2 pixel has the same x position as any player0 pixel then check for y position match. if TempD>=player0x&&TempD<=TempA then goto Check_Y next rem The other two values on the stack aren't going to be used, but they still need to be pulled. pull TempA: pull TempA rem Since player2 is in front of or behind player0 then return that the sprites aren't touching. TempE=False: return rem Now check the y positions. This is pretty much the same process as checking the x positions. Check_Y if Mario_is_Large then TempA=player0y+15 else TempA=player0y+9 pull TempB: pull TempC: TempC=TempC+TempB for TempD=TempB to TempC if TempD>=player0y&&TempD<=TempA then TempE=True: return next TempE=False: return Now, Mario touching the plant always works, but Mario touching the turtle doesn't always work. Here's some of the code for when Mario touches the turtle. Again, I've added REMs for this post so you know what I'm trying to accomplish. Turtle_Collision if !Mario_is_Falling then goto Common_Collision_Options rem if Mario is falling, then he flips the turtle upside down or rightside up. if !Turtle_UpsideDown then Turtle_UpsideDown=True else Turtle_UpsideDown=False rem Get the upside down or right-side up sprite for the turtle. if Turtle_UpsideDown then gosub Turtle_U bank5 else gosub Turtle_A bank5 rem Since Mario was falling, stop the fall and make him jump up 8 pixels. Mario_is_Falling=False: Mario_is_Jumping=True: player0y=player0y-1 rem Shrink_Timer makes Mario invincible while it is >0. In the main routine it gets reduced by 1 until it reaches 0. Jump_Height=8: Shrink_Timer=24 return And finally, if Common_collision_Options is called then if Mario is large he's shrunk and given some Shrink_Timer time. If Mario is small, then he dies.

It shouldn't be needed once the DPC+ kernel has pfread. Using that I can check in front of Mario to see if he walks into a pipe, above Mario to see if he jumps up into a brick, and below Mario to see if he lands on a brick, pipe, or the floor.

I'll mention one more thing. In the old version of the game I was working on, I wasn't too sure how I would have Mario jump up and hit bricks that contained power-up items. But with 10 sprites in DPC+ this will no longer be a problem. I have the last four sprites dedicated to power-up bricks. Mario jumps up, a collision with one of the sprites is registered, and it gives a power-up item. Actually though, I think I wrote myself into a corner. I may have to turn the brick into the power-up item rather than have the item rise up from the brick. But at least I can differentiate between regular bricks and power-up bricks. Edit: Oh, and let me know if anything should be changed. I mean, there's not much in the demo, but if you'd like the turtle to move faster for example, or you have a better looking cloud or pipe design for example, then let me know. I am going to keep Mario's speed the same.

Update * Please check out post #9 for a new and better demo, thank you. * Update OK, you really can't do much, but here is a small demo of the DPC+ Super Mario game I'm working on. The sprites are all by PAC-MAN-RED because he makes sprites way better than I do. Right now you can walk through the pipes. This will be fixed when pfread is implemented. There's no scrolling like in my other version because I need to wait until pfscroll is implemented. Pressing the fire button when walking makes you walk fast. And right now when you jump or fall you can control Mario as if he was walking. This will be fixed later. Touch the plant and you will die and the game resets. As for the turtle Koopa...there are some glitches, but running into him head first should kill you, and jumping on him will turn him upside down, and jumping on him again will turn him right-side up. Main.bas.binMain.bas

My final post about this. Disregard what I've been saying. I've done lots of tests and it doesn't work as simply as I thought. Depending on where the collision occurs, sometimes a collision between player0 and player2 registers as a collision between player0 and player2, other times it registers as a collision between player0 and player1. I guess for now checking the x and y positions of sprites to see if there's any overlap is the way to go. At lease for bB version 1.1d.

I just discovered something else. If you check for a collision between player0 and players 2-9 you'll get an accurate reading. If you check for a collision between player0 and player1, then any collision between player0 and players 1-9 will cause a collision and you'll have to narrow it down by doing other collision checks between player0 and players 2-9. Or check for other collisions first and place (player0, player1) last.

How does temp4 work? I tried playing around with it but I don't quiet get it I guess. Thanks.

Any idea of when pfread will be implemented? I could really use that. pfscroll would be nice too, but I'd love to have pfread. Is it harder to program than pfpixel?

Two programs I studied This one uses a missile - u=(missile1y-7)/8 : v=(missile1x-13)/4 This one a sprite - a=(player1x-13)/4 : b=(player1y-1)/8 Try one of those. It may help.

OK, I settled on using single defs for each attribute. def True=1 def False=0 def Mario_is_Large=a{0} def Mario_has_FirePower=a{1} My main goal is to have other people (as well as I) be able to look at the code, and with little to no REM statements easily know what's going on because there's going to be a lot of code and it could get confusing easily if it's not immediately clear what the code does. Mario_is_Large=False isn't the best way to say that Mario is small, but it works.

The way it will work is that Mario starts out with a{0}=0. When he gets a mushroom then a{0}=1. I want to express that in English so that the program is easy to read. So far I'm just going with the consts since I read on Random Terrain's board that you can have 500 of them.