Primordial Ooze
-
Content Count
542 -
Joined
-
Last visited
Posts posted by Primordial Ooze
-
-
Link: click
There are some subtle differences lockup-bugs between this and Shark Attack."
Is that what causes the invisible walls?
Sincerely,
Primordial Ooze
-
I'm trying to fix Androman on the moon so it doesn't crash when you lose a life. I have managed to figure out that the code that sends the androman are in LB057. In that section is a loop that continuously jumps to other addresses and then loops continuously until the timer expires. However I've managed to get the timer to loop forever if i put a nop instruction in B1E7. Any hints would be greatly appreciated as I'm trying to figure this out myself.
Sincerely,
Primordial Ooze
-
I am working on coding the game section where when time expires the duck flies away by going up until it disappears. So far i have managed to code the timer and background changing color. If i make the player object fly to the top of the screen, it will simply wrap around and appear at the bottom. So my question is how would i make it so the player sprite doesn't appear or appear to have flown off? The latest build of my game can be found here. Any assistance would be greatly appreciated.
Sincerely,
Primordial Ooze
-
I'm in for 1 copy of the poster, PM sent.
EDIT: May have to cancel it, as i just realized i have no space to put it. Sorry for all the trouble I have caused.
-
Does anyone have a simple guide or any info on converting a 4k rom into batari basic's 8k bankswitching? From what I gather when 8k bankswitching is used the graphics are stored in the lower bank(bank 1) and the code is stored in the upper bank(bank 0). However I've read that when bankswitching occurs all previous rom data is lost, yet in batari basic when the graphics are bankswitched in the code remains as if it didn't the game would crash. Any assistance would be greatly appreciated.
Sincerely,
Primordial Ooze
-
I'm trying to reverse the sprite when it intersects the left or right boundry. Here is the code i am using:
sec lda #$08 sbc REFP0 sta REFP0
However it only seems to work once. Any assistance would be greatly appreciated.
Sincerely,
Primordial Ooze
-
lda DuckX ; load the ducks position clc ; clear carry adc DuckVX ; increment duck's x position by it's x velocity sta DuckX beq DoReverseDuckDX cmp #$98 ; does it intersect the right boundry? bcc SkipRightDuckVX ; if it doesn't then don't reverse it's x velocity DoReverseDuckDX lda DuckVX ; load the duck's v velocity eor #$FF ; reverse it sta DuckVX ; store it SkipRightDuckVX
Thanks Nukey Shay, i amaged to get it working with your code!
Sincerely,
Primordial Ooze
-
You can't subtract a variable from a constant in the same instruction (ldx 256-DuckVX). Also, the result was stored (stx DuckVX) whether or not the branch was taken...leading to problems if X was not already loaded beforehand.
Still Can't get it to work on both sides:
lda DuckX ; load the ducks position clc ; clear carry adc DuckVX ; increment duck's x position by it's x velocity sta DuckX bne SkipReverseDuckVX ; does it intersect the left boundry? lda DuckVX ; load the duck's x velocity eor #$00 ; negate it cmp #$98 ; does it intersect the right boundry? bcc SkipReverseDuckVX ; if it doesn't then don't reverse it's x velocity lda DuckVX ; load the duck's v velocity eor #$FF ; negate it sta DuckVX ; store it SkipReverseDuckVX
Any assistance would be greatly appreciated.
Sincerely,
Primordial Ooze
-
The comments had the cycle counts wrong...GRP1 was really hit on cycle 26 in the original post (which is still a little late).
PO:
When you perform WSYNC, the cycle count for the scanline begins at cycle 0, not 3. And $Absolute,Y addressing uses 4 cycles, not 5 (unless a page was crossed when accessing the data). Also keep in mind that branching instructions only use 2 cycles when they are not taken.
Since you have a little time left when bne ScanLoop occurs, you could move the initial LDA pf0data,y to happen before you do the WSYNC. That will shave off the 4 cycles needed to hit at 22 when GRP1 is stored.
Thanks, by the way i'm running into another problem trying to move the duck towards the right:
lda DuckX ; load the ducks position clc ; clear carry adc DuckVX ; increment duck's x position by it's x velocity cmp #$98 ; does it intersect the right boundry? bcs SkipReverseDuckVX ; if it does then don't reverse it's x velocity ldx 256-DuckVX ; otherwise reverse it's x velocity SkipReverseDuckVX sta DuckX ; store duck's new x position stx DuckVX ; store duck's new x velocity
Seems the duck doesn't want to budge. I have attached the latest source code and bin file for reference.
Sincerely,
Primordial Ooze
-
That will work for the players. I think you're writing PF0 too late, but that depends on what you're displaying there and if it really matters to your display if part of it is pushed down a line.
Really the best thing to do is move things around and try it out in Stella. Then rinse and repeat until you're happy with the results.
Well the top portion is unused at the moment so it doesn't matter for now. An artifact is showing though. When I move the crosshair to the top small blocks are being shown in an ooze like pattern. Not a big deal though as right now I'm trying to get stuff working.
Sincerely,
Primordial Ooze
-
According to your comments, GRP1 (the crosshairs) is updated on cycle 29 and GRP0 (the duck) is updated at cycle 12.
The visible screen starts a bit after cycle 22.
What if i moved stuff a bit so:
sta WSYNC ; (3 3) Wait for the previous line to finish lda pf0data,y ; (4 7)load pf0 data into the acumulator sta PF0 ; (3 10) and store it lda pf1data,y ; (5 15) load pf1 data into the acumulator sta PF1 ; (3 18) and store it lda pf2data,y ; (5 23) load pf2 data into the acumulator sta PF2 ; (3 26) and store it lda CrosshairBuffer ; (3 29) buffer was set during last scanline sta GRP1 ; (3 32) put it as graphics now cpy CrosshairY ; (3 35) compare crosshair's y position bne SkipActivateCrosshair ; (3 38) if it isn't 0 then jump to SkipActiveCrosshair lda #5 ; (2 40) otherwise load our accumulatior with the number of lines to draw sta VisibleCrosshairLine ; (3 43) and store it SkipActivateCrosshair
Was:
sta WSYNC ; (3 3) Wait for the previous line to finish lda CrosshairBuffer ; (3 6) buffer was set during last scanline sta GRP1 ; (3 9) put it as graphics now cpy CrosshairY ; (3 12) compare crosshair's y position bne SkipActivateCrosshair ; (3 15) if it isn't 0 then jump to SkipActiveCrosshair lda #5 ; (2 17) otherwise load our accumulatior with the number of lines to draw sta VisibleCrosshairLine ; (3 20) and store it SkipActivateCrosshair lda pf0data,y ; (4 24)load pf0 data into the acumulator sta PF0 ; (3 27) and store it lda pf1data,y ; (5 32) load pf1 data into the acumulator sta PF1 ; (3 35) and store it lda pf2data,y ; (5 40) load pf2 data into the acumulator sta PF2 ; (3 43) and store it
Would that work?
Sincerely,
Primordial Ooze
-
Does anyone know how i can contact the author to ask him personally or know if he is on these forums nowadays?
Sincerely,
Primordial Ooze
-
Yup, your Player1 is tearing because its being updated during on-screen cycles. Your choices to fix this are either to update it during horizontal blank cycles or look at using VDELP1.
If that is the case then why isn't the duck tearing as well?
Sincerely,
Primordial Ooze
-
Still an awesome game! Software means a small chance it can be copied and leaked.
Why would software be harder to copy then a jamma board? Assuming it doesn't have some type of licensing thingy all you would have to do is copy the executable and it's files.
Sincerely,
Primordial Ooze
-
It would be better if you posted a binary demonstrating the issue, but it sounds like shearing or tearing. It's caused by updating your player in the visible portion of the scanline.
Here you go, hope this helps.
Sincerely,
Primordial Ooze
-
I am getting a wierd effect when the player1 sprite is on the left side of the screen. For some reason the bottom is bumped up a bit on the bottom. I can't figure out why it's doing it. I am posting my code in hopes of someone figuring this out.
Any assistance would be greatly appreciated.
Sincerely,
Primordial Ooze
-
Update on this?
I reversed engineered duck hunt
Curious as to your version will handle
p.s
english isn't my native language
Sorry about the late reply, glad to see people are still interested in this
I'm redoing the controls so you can play using a joystick instead of using the rare XE Gun. I've busy with other stuff lately so i haven't worked on it for awhile, but you will be happy to know I'm am starting to work on it again. 
Sincerely,
Primordial Ooze
-
Is there some way to have disam display how much rom space remains everytime you compile your homebrew? I remember someone saying something allong the lines of:
echo "bytes free:" *-$F800
But thatonly produces garbage output. Any assistance in this matter would be greatly appreciated.
Sincerely,
Primordial Ooze
-
Player0 - P1 Bomberman, copied to P2 Bomberman
Player1 - CPU1 Bomberman, copied to CPU2 Bomberman
Missile0 - P1 bombs (copies up to x4), P2 bombs (copies up to x4)
Missile1 - CPU1 bombs (copies up to x4), CPU2 bombs (copies up to x4)
You mean having two sets of cordinates and drawing the same sprite twice from the two different coordinates?
Sincerely,
Primordial Ooze
-
I know about the sprite copy bit. Thing is it creates duplicates of the same sprite grouped together, not in different positions. Also as stated above, all the sprites have been taken leaving just the missles and ball object.
Sprite 1 = Bomberman
Sprite 2 = Enemy
Missle1 = Explosion
Missile 2 = Explosion
Ball = Bomb
Playfield = Blocks
Sincerely,
Primordial ooze
I didn't know they must be grouped together
I thought they only needed to act as one single sprite, moving together.
If it was only the second case, maybe mirroring the screen you could make one going from left to right and another on the contrary...
Of couse, even this could harm the gameplay...
Mirroring the playfield has no effect on the sprites themselves. I simply allows you to create half of the playfield, which is reflected for the other half of the playfield. Hope that made sense.
Sincerely,
Primordial Ooze
Thanks for the explanation.
Yes, it makes sense.
I need to study Atari programming a bit to be able to help with better ideas...
Sorry.
It's ok, was a very good just not possible due to the atari 2600's limitations.
Sincerely,
Primordial Ooze
-
I know about the sprite copy bit. Thing is it creates duplicates of the same sprite grouped together, not in different positions. Also as stated above, all the sprites have been taken leaving just the missles and ball object.
Sprite 1 = Bomberman
Sprite 2 = Enemy
Missle1 = Explosion
Missile 2 = Explosion
Ball = Bomb
Playfield = Blocks
Sincerely,
Primordial ooze
I didn't know they must be grouped together
I thought they only needed to act as one single sprite, moving together.
If it was only the second case, maybe mirroring the screen you could make one going from left to right and another on the contrary...
Of couse, even this could harm the gameplay...
Mirroring the playfield has no effect on the sprites themselves. I simply allows you to create half of the playfield, which is reflected for the other half of the playfield. Hope that made sense.
Sincerely,
Primordial Ooze
-
I know about the sprite copy bit. Thing is it creates duplicates of the same sprite grouped together, not in different positions. Also as stated above, all the sprites have been taken leaving just the missles and ball object.
Sprite 1 = Bomberman
Sprite 2 = Enemy
Missle1 = Explosion
Missile 2 = Explosion
Ball = Bomb
Playfield = Blocks
Sincerely,
Primordial ooze
-
Has anyone done a sokoban game for the Atari 2600 yet? I would imagine it's very possible with boulder dash being finished as we speak. If it hasn't been done yet, I would like to take a crack at creating it in assembly language.(...)
In Boulder Dash thread someone came with the idea of making Bomberman!
That's much more difficult but much more interesting, imho.
Just saying.
It's here.
Thing is how would it be done? With 2 sprites, 2 missiles and a ball, it would be difficult to do more then 1 roaming enemy at a time?
Sprite 1 = Bomberman
Sprite 2 = Enemy
Missle1 = Explosion
Missile 2 = Explosion
Ball = Bomb
Playfield = Blocks
Any assistance would be greatly appreciated.
Sincerely,
Primordial Ooze
you could make it pvp
my uneducated opinion.
You mean Bomberman vs Bomberman, that would be neat. Only problem left is how i would make the destroyable blocks, since there isn't any objects left to display them?
Sincerely,
Primordial ooze
-
Has anyone done a sokoban game for the Atari 2600 yet? I would imagine it's very possible with boulder dash being finished as we speak. If it hasn't been done yet, I would like to take a crack at creating it in assembly language.(...)
In Boulder Dash thread someone came with the idea of making Bomberman!
That's much more difficult but much more interesting, imho.
Just saying.
It's here.
Thing is how would it be done? With 2 sprites, 2 missiles and a ball, it would be difficult to do more then 1 roaming enemy at a time?
Sprite 1 = Bomberman
Sprite 2 = Enemy
Missle1 = Explosion
Missile 2 = Explosion
Ball = Bomb
Playfield = Blocks
Any assistance would be greatly appreciated.
Sincerely,
Primordial Ooze
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Multiple Sprites(Animation)
in Atari 2600 Programming
Posted
So far I have managed to get the duck to face the direction it is flying as opposed to moon walking. Now i want to make it so when the duck is "hit" it is shown as a different sprite. I know i need to add a new sprite as the Atari 2600 doesn't have a register for flipping a sprite vertically, but need help in coding the flipping of the different sprites. Any assistance would be greatly appreciated.
Sincerely,
Primordial Ooze