Jump to content

MLdB

Members
  • Content Count

    83
  • Joined

  • Last visited

Community Reputation

29 Excellent

About MLdB

  • Rank
    Star Raider

Profile Information

  • Gender
    Male
  • Location
    Netherlands

Recent Profile Visitors

4,697 profile views
  1. I'm with Dionoid on this one, but it's entirely up to you of course 😄 I'm curious if there is a specific motivation for the constant speed?
  2. Thanks! Was literally just going to ask about the possibility of this exact feature when I saw your name under this thread and got curious. Would be an amazing feature!
  3. You need one timer variable per event that you want to delay and one frame counter variable if you need to delay one or more events for more than 256 frames. For the case you describe, let's name these variables framecounter and deathseqtim (for death sequence timer). Once every frame you do: inc framecounter Before an enemy enters the screen you make sure to clear the death sequence timer: lda #0 sta deathseqtim ; as long as deathseqtim is 0, the enemy is still alive When an enemy is killed you do: lda #DEATHSEQDURATION ; duration of sequence in frames. sta deathseqtim ; a non-zero value indicates the enemy died. Now as long as an enemy (alive or dead) is on screen, you do: lda deathseqtim beq SkipDeathSeq ; Remember that 0 means the enemy is still alive. ; deathsegtim is non-zero, the enemy has died. lda #DEADENEMYCOLOR sta COLUP0 ; Or "sta enemy_sprite_color" if needed ; You only need the next three lines if the death sequence should take longer ; than 256 frames. It enables you to have the timer count down only on every ; 2nd, 4th, 8th, etc frame. lda framecounter and #%00000001 ; Count down on even frames only, as an example bne SkipDeathSeq dec deathseqtim bne SkipDeathSeq ; The sequence timer ran out, remove the enemy from the screen. ; (insert whatever you do to remove the enemy) SkipDeathSeq: Different combinations of values for DEATHSEQDURATION and the value used to and the framecounter with, will result in different durations for the sequence. My values here decrement the timer every even frame meaning the 30 counts will expire in 60 frames or 1 second. The timing will be very stable, just a single frame of max difference because of the low value for the and.
  4. I guess it will be high first in, so low is first out as 6502 is little endian, expecting the low byte to be read first.
  5. zp is short for Zero Page, meaning any variable in RAM ($80-$FF). jmp (zp) will jump to the address stored in ram locations zp and zp+1 (16 bits combined)
  6. Miraculously It will fail whenever the value stored at address FOREST (or TREEHOUSE) changes between the time it was written to variable XYZ and when it is loaded back in from XYZ and compared to the value stored at address FOREST again.
  7. I'm a bit confused. The game runs and enemies flash white when hit. My fist guess is that you noticed some flashes are shorter than others. This is what I believe you are doing (based on a quick look at your code): When an enemy is hit, set it's color to white until timer is a chosen value (8 in snippet, 1 in main.asm), after which the enemy is removed from the game. But the time it takes for timer to get to that number after an enemy is hit is not constant, because you do not reset its value when the enemy is hit. timer is instead incremented every frame (?) and simply loops from 1 - 9. I also noticed a lot of lines like these: cmp TREEHOUSE and ldx FOREST Did you mean: cmp #TREEHOUSE and ldx #FOREST here as these are constants and not labels? If I'm not mistaken, these lines currently are instructing the Atari to compare the accumulator against the current value of spritecolourptr and load into X the current value of spriteprt instead of the values of TREEHOUSE and FOREST.
  8. Please supply your code here and explain your purpose. If we know what you are trying to achieve (and why), we could probably help you out!
  9. Also if you meant the physical reset button on the console (instead of resetting by turning the console off and back on), this is just a regular button. The Atari does not know how to 'reset', the programmer needs to check for a press and release of the button and program the reset manually. In UT2600 the reset button takes you back to the main menu, it does not reset the game. I also use the content of the RAM before I clear it to seed my pseudo random number generator.
  10. Yes. Personally, I find it very hard to choose between predetermined or random behaviour. I really like that every step in the game can be referenced by timecode. Different 'paths' can be explored and easily explained. The predetermined behaviour indeed provides a 'standard game' where scores can be compared. Also it creates the illusion that the game world is, in a sense, real... But on the other hand, it would be a shame not to include the random (or dynamic) option, which gives you a unique experience everytime you play. I'm not always determined enough to go through the same first 100-something steps again everytime I die. There's a difference between "Maybe this time I'm gonna make that jump" and "Maybe this time I won't have to make that jump". And there's a mood to fit each of them. Fantastic game/adaptation by the way! Really love the animation, controls, music and challenge!
  11. I'm an idiot, thanks for your swift reply Andrew. But I see that I forgot to mention that I want dasm to write the location to the binary, so my map editor can read it from the binary file at a known location (like the interrupt and program start locations are always at FFFC-FFFF (if I'm not mistaken) I'd like my table addresses to be included somewhere in a predetermined location but have dasm account for the bank they are in, ignoring Atari's usual 4K addressing limitation.
  12. For my project I want to include the locations of a couple of tables in the final binary. I want to be able to allow editing (for a mapeditor coded separately in js) the data inside the binary without dis- or reassembling. Naturally if I write "word LABEL", dasm will insert the location of the label within the addressable 4K (F000-FFFF), it would be trivial (I think) for dasm to report the real location of the label within the binary (from 0000-[EOF]), but as I cannot think of any real uses for such a feature apart from my own, I'm afraid it will not exist yet...
  13. Essentially it's doing a long division, shifting the most significant bits of the dividend through the carry into the accumulator until the latter is bigger than the divisor. The way 'we' do long divisions is the same: looking at the most significant digits of the dividend and dividing those by the divisor (binary systems have the advantage that the quotient of each step is always 1 or 0 (each digit of the solution) instead of 0-9 as in our decimal system, so there's no division involved only a single subtract) After subtracting the divisor from the accumulator the carry is 1, but if the subtract was skipped, the carry is 0. The carry is then rolled into the solution, which may even be the same variable that is used for the dividend, shifting the dividend out and the solution in. This is exactly what you do with long divisions: adding digits to the end of the solution, shifting the other digits into their eventual correct place (eg thousands, hundreds, tens, ones)
  14. I've been updating my solution over the past days, shaving off a couple of cycles every edit. I will test my solution to see if it works as it should and post some cycle counts to compare it to the other solutions. (These are cycle counts, obviously, not answers ) 0/1 = 243 128/8 = 161 128/128 = 49 255/2 = 229 255/4 = 199 255/8 = 169 255/16 = 139 255/32 = 109 255/64 = 79 255/128 = 49 255/1 = 259 255/3 = 223 255/7 = 191 255/15 = 163 255/31 = 133 255/63 = 105 255/127 = 77 255/255 = 49 Edit: I wanted to test the other solutions as well, but could not get them to execute properly (yet) on the emulator I used. I noticed however that Zack's solution probably has a small error in it:
×
×
  • Create New...