Jump to content

playsoft

+AtariAge Subscriber
  • Content Count

    578
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by playsoft

  1. @pps is correct, it uses character mode, the screen is scrolled left and the background characters are updated to scroll right (at a lesser rate). The hardware features it uses are horizontal scrolling, screen flipping (so that one screen can be displayed while the other is computed) and character set flipping (to scroll the background characters). When you scroll a background character right it scrolls into the adjacent character. Say you have a row of characters containing AB (with spaces before and after). There are 3 different pairs of characters; (space, A), (A,B) & (B, space). To scroll them right you will need a scrolled character for each, XYZ, where X is space scrolling into A, Y is A scrolling into B, Z is B scrolling into space. Where the same pairs of characters are repeated in the background you can replace them with the same scrolled characters. In the attached example the (48x24 character) background contains 27 unique characters; after it has been converted for scrolling it contains 63 characters. 4 character sets are used. In character set #1 the background characters aren't scrolled right at all, in #2 by 1 pixel, in #3 by 2 pixels and in #4 by 3 pixels. In the attached example the screen scrolls left 1 pixel per frame and the character sets are swapped every other frame. Once the background characters have fully scrolled right and you want to reset back to character set #1, you need to recompute the screen. That takes a lot of CPU cycles because for every character in the screen buffer you need to look at the character in the foreground, if it is non-zero write it otherwise write the character from the background. That is where the screen flipping comes in, you break this down into small steps and work on the inactive screen so that it is ready for when you need to reset. In the attached example you have 8 frames before you need to reset, so it splits it down into a number of screen columns each frame. I think that is everything. For simplicity I generate the scrolled background and character set data on the PC but this could be done on the A8 which would reduce the amount of data held in the XEX file. The main limitation is that the foreground designs need to use whole characters, if you leave bits of foreground characters blank it breaks the illusion. scroll.zip
  2. playsoft

    Vcs ports

    The controls are mapped to the following 5200 keys: start = begin game 1 = 1 player game 2 = 2 player game 0 = toggle colour/monochrome * = left difficulty switch # = right difficulty switch miniature golf (5200).bin
  3. With a read breakpoint on the first byte which is different, using the first image posted it stopped here: (2409: 26, 88) A=00 X=59 Y=00 S=FB P=36 ( IZ ) 67EE: 31 72 AND ($72),Y [$9581] = $DC (2409: 26, 89) A=00 X=59 Y=00 S=FB P=36 ( IZ ) 67F0: 11 76 ORA ($76),Y [$89DB] = $03 (2409: 26, 94) A=03 X=59 Y=00 S=FB P=34 ( I ) 67F2: 91 74 STA ($74),Y [$2EFF] The byte is a mask. It looks like it is trying to set the two bottom bits (i.e. one pixel) leaving the rest of the byte unchanged, but the $DC mask results in a bit being cleared in the upper nibble. The mask value should be $FC, which it is in the second image. So it looks like someone altered it to correct the masks. I think it will only make a difference when things overlap on-screen and even then you may need a young man's eyesight to notice it.
  4. Thanks for posting the video, it was really nice to see someone making good progress in the game. Runner Bear was developed for both the A8 and 5200. It is an endless runner with characters from Crystal Castles. The A8 version was released on the 2020 New Year Disk and almost immediately a cracked version appeared with infinite fire power and continues together with a comment that the game was too hard. So rather than release the 5200 game straight away I started making some changes, adding more fire power and continues and making some of the jumps and enemies a little easier. It has taken a back seat while I do something else, but I'd made most of the changes I wanted to so it shouldn't take too long when I get back to it.
  5. That is identical to the PAL version, so it is not seeing the HZ_60 or NTSC flags. I define them on the command line (the -Wa means pass to the assembler, -DHZ_60=1 means define label HZ_60 with value 1): bin\cl65 -t atari -C bin\memory.cfg -Wa-DHZ_60=1 -Wa-DNTSC=1 main.s -o SHADES_NTSC.BIN In the code it uses these labels to select timer values and colours: .ifdef HZ_60 VBLANK_TIME = 50 OVERSCAN_TIME = 26 .else VBLANK_TIME = 83 OVERSCAN_TIME = 52 .endif .ifdef NTSC YELLOW = $10 BLUE = $90 GREEN = $C0 .else YELLOW = $30 BLUE = $B0 GREEN = $50 .endif block_colours: .ifdef NTSC .byte $AE,$BA,$C6,$C2,$D0,$90 .byte $3E,$3A,$36,$32,$30,$F0 .byte $5E,$5A,$56,$52,$50,$B0 .byte $9E,$9A,$96,$92,$90,$40 .byte $AE,$BA,$C6,$C2,$D0,$90 ; repeat of first .else .byte $5E,$58,$54,$52,$50,$B0 .byte $4E,$48,$44,$42,$40,$80 .byte $AE,$A8,$A4,$A2,$A0,$60 .byte $DE,$D8,$D4,$D2,$D0,$50 .byte $5E,$58,$54,$52,$50,$B0 ; repeat of first .endif .ifdef HZ_60 ldx #$03 .else ldx #$19 .endif : So for whatever reason it seems they are not getting passed down.
  6. About the only thing I can think of which is open to some interpretation by the assembler is when it decides to do zp or absolute addressing. My guess would be the Mac code takes a little longer and there was enough leeway in the 50Hz builds for it to have no effect, but not the 60Hz ones. I wouldn't mind seeing a Mac build, not to do a full analysis but just to see what the first difference is.
  7. Were the .bin files in the .zip stable? Assembling should have generated identical files, so would be interesting to see if they match.
  8. Thanks Phil, this was originally going to be an A8 game and my contribution to the 2017 New Year Disk. But when I started coding it seemed it could be done just as well on the VCS. Perhaps an A8 version for the 2021 NYD!
  9. Thank you - that was a good catch. I have created a topic for the game here. I have added some additional palettes with placeholder colour values. The source is included so hopefully you would be able to try them out or just post the values and I will include them, thank you.
  10. A few years ago I started a port of the iOS game Shades by UOVO which is a Tetris type game where you have to try and drop a block on another of the same shade so they merge to a darker shade: That it used luminance made it well suited to the 2600 but it was frustratingly hard to tell them apart and I abandoned it. However recently @Thomas Jentzsch hacked it to use different (but similar) hues to give more variance. Attached is the current WIP. @Karl G I've added 3 additional colour palettes and for testing you can step through them by pressing the trigger during the game. The colours are just placeholders for now, if you fancy playing around with these you will find them in build\colours.s. Each palette comprises 6 colours values, the 5 block colours (ordered bright to dark) plus the background colour. I use the ca65 assembler which is included so you should be able to rebuild by running build.bat in the build directory from the command prompt. Perhaps the colours could switch each time the speed increases? Currently there are 4 speeds; NOVICE starts at speed 1, NORMAL at speed 3 and EXPERT at speed 4. I thought the fastest speed was difficult enough but I'm getting better at playing it now and it needs to go faster and present more of a challenge once you get to around 3,000 points. shades_wip_1_5_2020.zip
  11. Thanks, I hadn't tried using different hue values. Initially I wasn't sure as it doesn't look quite as nice, but I got used to it after playing a while. It definitely helps distinguishing the blocks, which was my reason for not finishing it off, so... I've added a title screen and 3 difficulty modes which select the initial speed of the blocks. I didn't think the game needed to be any harder, so EXPERT mode plays as before, NORMAL is a little slower and EASY a lot slower (those two speed up after a while). You can abort a game by pressing Reset which takes you back to the title screen. The NTSC build uses the hacked colours, the PAL colours aren't changed. SHADES_NTSC.BIN SHADES_PAL.BIN SHADES_PAL_60.BIN
  12. A cut-down version of Crossniq+ looks like it should be possible.
  13. It's not a WIP - it's an old abandoned project (OAP?). If a title screen had been added it would have done that.
  14. One thing I noticed is that the volume is not protected against decrementing below 0. I changed: DEC FREQCNT,X ;REDUCE THE NUMBER OF FRAMES UNTIL NEXT DECAY BNE TUNNEXT ;IF WE AREN'T AT ZERO YET, DON'T DECAY LDA DCYSTOR,X ;RESET THE DECAY FOR THE NEXT COUNT STA FREQCNT,X DEC CTLVOL,X ;DECREMENT THE VOLUME LDA CTLVOL,X LDY TUNCHANNEL AND MUTEMASK,Y STA AUDC0,Y JMP TUNNEXT ;GO TO NEXT CHANNEL To: DEC FREQCNT,X ;REDUCE THE NUMBER OF FRAMES UNTIL NEXT DECAY BEQ DEC_VOLUME JMP TUNNEXT ;IF WE AREN'T AT ZERO YET, DON'T DECAY DEC_VOLUME LDA DCYSTOR,X ;RESET THE DECAY FOR THE NEXT COUNT STA FREQCNT,X LDA CTLVOL,X ;IF VOLUME ALREADY 0 DO NOT DECREMENT AND #$0F BEQ TUNNEXT DEC CTLVOL,X ;DECREMENT THE VOLUME LDA CTLVOL,X LDY TUNCHANNEL AND MUTEMASK,Y STA AUDC0,Y JMP TUNNEXT ;GO TO NEXT CHANNEL I'm not sure it affects timing, but it sounds cleaner to me, see what you think. strangerthings.s strangerthings.obx
  15. It's interesting that Shades by UOVO is no longer available in the AppStore but Mega Shades by Marstin is. The two games are extremely similar but not 100% identical; in Mega Shades the next block indicator does not morph into the block like it does in Shades. I think they are different developers as UOVO are (were) Danish but Marstin appears to be UK. Maybe UOVO sold the rights on?
  16. I did start programming the mobile game Shades by UOVO which is a Tetris type game where you have to try and drop a block on another of the same shade so they merge to a darker shade: Having colour shades makes it well suited to the VCS, but I did find it hard to distinguish them which is why I never finished it off. SHADES_NTSC.BIN
  17. That was about as much as I could improve the program as a port. Writing from scratch you would be looking at multi coloured sprites, the shield moving up and down (like the VCS) and some nice explosion effects. It would be an ideal game for the demo coders that make all those nice swirly effects.
  18. Look forward to it but there's no rush! I took a look at your Stranger Things and the muting code looked fine to me. I thought it sounded great and it wasn't obvious to me there was a timing issue?
  19. They look great Konstantinos but currently only the formation graphics can be animated though. For each software sprite, although there are only 2 frames for each design in the .bmp (upright and diagonal) they are rotated to make frames for all directions. These 8 frames are then pre-shifted for all 4 horizontal offsets. So you end up with 32 frames for each design @ 27 bytes each = 864 bytes. I have allocated RAM to allow 5 designs to be present on-screen at any one time: bee, butterfly, boss, captured player and one other. The extra one is used for the transforms - I call them all that although I think only half of them are actually transforms, the others just appear in the challenging stages. The code which rotates and pre-shifts the frames is split into steps that allow a transform to be loaded up seamlessly between waves. So currently 4320 bytes of RAM are used for the software sprite frames. I don't have enough free RAM (on the 5200) to double up all the frames; there is enough to double up just the diagonals but that won't leave much free and at this stage you want to keep a bit in reserve. There aren't any explosions for the player ships yet. Really the big unknown for me is the expanding formation and that is what I will look at when I get back to it later in the year.
  20. Seeing as no one else took up the reins I have worked on it over the past week. The final A8 version was supposed to have the last little bugs fixed but there were still a few in there. Probably the worst one can be seen towards the end of the video that BIGHMW posted; on levels where the shields rotate the shield characters often end up appearing on screen where they shouldn't be. There were half a dozen or so issues and I am confident I've fixed most of them, but there were a couple of one-offs where all I've been able to do is tentatively make a change that might help. The intro screen is the drawing from here yars_strike.bin
  21. The explosions use player graphics and there are 2 players available in that portion of the screen. You don't want to be using software sprites for them, as that will consume more CPU time. As there are only 2 players available I kept the number of frames relatively small (5 frames) so they are unlikely to be cut off early. The way it works is that the first enemy you shoot uses one player for the explosion, the second enemy uses the other player; if you shoot a third enemy it will use the same player that was being used for the first one. So if the first enemy was still exploding it will be cut off short. Obviously more frames = more memory too. That said it may be that cutting the explosion short wouldn't happen that much and it might not look so bad if the frames were designed in a certain way.
  22. Yes Konstantinos that's correct. If you want to play around with anything then extract the build folder and run build from the command line. The software sprites are in the .bmp file, the formation graphics in the .a4 and the PM graphics are all .apl. When drawing the software sprite frames I tried to use as many pixels as possible to make them look bigger on-screen than they really are! build.zip
  23. I was happy with my multiplexer in AtariBlast and being an original game I was able to minimise the amount of flicker by designing the sprite paths around it, but even then there were complaints! Some of the paths in the challenging stages of Galaga have all 8 sprites in the same vertical space for a fair amount of time during which you'd only be able to display a single sprite once in every four frames if using multicolour sprites; once every other frame if single colour. I really don't think it would be greeted with much joy...
  24. Also I think there is a difference between what is acceptable on the two systems. There would be significant savings in both memory and CPU time if you went the sprite multiplexer route instead of character sprites, but I don't think the flicker would be well received on the 5200/A8; the VCS has always had flickering sprites, so it's more acceptable there (although I remember when my Uncle brought VCS Pac-Man we thought we'd got a dud cart!).
×
×
  • Create New...