Jump to content

MLdB

Members
  • Posts

    85
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    Netherlands

Recent Profile Visitors

5,686 profile views

MLdB's Achievements

Star Raider

Star Raider (3/9)

34

Reputation

  1. I've been developing UT2600 (Unreal Tournament for the Atari 2600) on and off for a couple of years now. Other things kept me from finishing the game. It's done, I think... What I really need is a lot of testing. The thing is: this is a 2 player game. If you are willing to help out (and have a friend to join you), I cannot promise to compensate you. But you will be mentioned on the website and in the manual, if UT2600 ever gets a physical release obviously. I will provide you with the latest binary and documentation and any further instructions you may need.
  2. Something I noticed: If $80 containes #1, then eor #1 will not prevent, but cause a zero. I'll take a closer look soon.
  3. 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?
  4. 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!
  5. 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.
  6. 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.
  7. 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)
  8. 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.
  9. 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.
  10. 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!
  11. 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.
  12. 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!
  13. 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.
  14. 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...
×
×
  • Create New...