Jump to content

playsoft

+AtariAge Subscriber
  • Content Count

    564
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by playsoft

  1. 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?
  2. 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
  3. 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.
  4. 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?
  5. 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.
  6. 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
  7. 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.
  8. 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
  9. 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...
  10. 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!).
  11. Looks great, opens the door to using the 822 in games! (print maps etc...). Strange, my 822 seems to need the $4C in my test program; with Aux1 set to $00 there's no printer output at all, just farting noises; with it set to $4E I get normal text output, not bitmap. Paul
  12. I don't know if this will help but I disassembled the code from the owner's manual to see what it was doing. Basically if you send a SIO Put with Aux1 set to $4C ('L' for Line perhaps) then instead of printing the 40 bytes as characters it prints a single line of 240 pixels (the last 10 bytes are not used - although you do seem to have to send them). The attached test.s continually prints lines of random data out on the 822: The code in the owner's manual prints the screen out sideways; I attach the disassembly for that which I've commented but haven't done anything else with. Paul test.s test.xex commented.s
  13. Look forward to hearing them!
  14. Yes I've set the build up to generate two versions. I am working on something else at the minute, so will see if I get back to it after that.
  15. They are really good. Obviously it might be quite a while before they are used, but I've pulled them into the player alongside the start tune. I'll keep it organised with anything you post.
  16. I've not tried the other ones at 30Hz yet. I took the 60Hz SAP files and created new 30Hz ones from them by leaving out every other set of register values. They all sound much of a muchness to me and I didn't notice any difference resending the data again. I don't think I hear that glitch but it might be more noticeable with headphones - I don't have any but I will connect my A8 up to my hifi tomorrow and see if I can hear anything.
  17. Yes that sounds great. synth_5200.bin
  18. I've not tried resending the last data, will give it a go. What was going to be my final experiment was to take the 60Hz SAP, remove half the samples for 30Hz playback and spread the decoding effort over 2 frames (half the channels on the odd frames, the rest on the even). The start tune LZSS went from 751 bytes to 461. I'm probably not the best to compare how they sound as my hearing hasn't improved with age... Edit: both of these now repeat the last data when the registers aren't updated. jaden_5200_30.bin jaden_5200_50.bin
  19. I think I removed the right ones! It's now playing on just the 64K channels. synth_5200.bin
  20. To convert from RMT to SAP-R I export the RMT to a XEX and then record the SAP-R in Altirra. When doing this it makes a difference whether Altirra is configured for PAL or NTSC; in PAL it records the audio registers 50 times a second but in NTSC it's 60 times resulting in a bigger file. I did this for all of Jaden's RMT files, making PAL and NTSC versions of the SAP-R files and then compressing them with LZSS -8: RMT FILES LZSS PAL FILES LZSS NTSC FILES 205 Galaga - Challenging Stage.rmt 96 challenging_pal.lzss 102 challenging_ntsc.lzss 144 Galaga - Extra Life.rmt 74 extra_life_pal.lzss 87 extra_life_ntsc.lzss 292 Galaga - High Score.rmt 291 high_score_pal.lzss 372 high_score_ntsc.lzss 147 Galaga - Insert Coin.rmt 37 insert_coin_pal.lzss 42 insert_coin_ntsc.lzss 670 Galaga - Perfect!.rmt 319 perfect_pal.lzss 570 perfect_ntsc.lzss 309 Galaga - Results.rmt 283 results_pal.lzss 356 results_ntsc.lzss 366 Galaga - Start.rmt 598 start_pal.lzss 751 start_ntsc.lzss 2,133 bytes 1,698 bytes 2,280 bytes I generated 2 versions of the build with the start tune - the 60 version uses the NTSC data, the 50 version uses the PAL data but skips the playback routine 1 frame in every 6 to correct the speed for NTSC. The advantage of the 50 version is that the data is smaller but I think you can hear a slight difference between the two. jaden_50.xex jaden_60.xex
  21. 👍 I will rebuild the demo tomorrow with the updated file.
  22. Haha I thought you intended that distortion! If you play your file in RMT there's no distortion but if you export it as an Atari executable you get the distortion (you can try it, just select "file -> export as" and choose XEX). I think the distortion is caused by having the volume too high in the instrument envelope. I changed it from FEDC to 7654, exported it to a XEX and it sounded fine.
  23. I generated builds using the two tunes. There's not really much in it, Synthpopalooza's is slightly smaller and requires less cpu cycles although it is not as consistent. I did try the sap/lzss process on Synthpopalooza's but it did not compress as well as Jaden's, presumably because of the 16-bit values. jaden_5200.bin synth_5200.bin
×
×
  • Create New...