playsoft
-
Content Count
524 -
Joined
-
Last visited
-
Days Won
2
Posts posted by playsoft
-
-
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.
-
1 hour ago, Karl G said:Has anyone else had luck assembling this? I was able to, but the 60Hz versions have unstable screens. I'm on a mac though, so I built my own version of cc65 instead of using the included version.
Were the .bin files in the .zip stable? Assembling should have generated identical files, so would be interesting to see if they match.
-
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!
-
1
-
-
On 4/29/2020 at 9:23 PM, Thomas Jentzsch said:/signed
Found a small bug: The sound is not stopped when you leave a game early.
Thank you - that was a good catch.
On 4/29/2020 at 11:18 PM, Karl G said:Having switchable color schemes might be a nice future feature as well. Here's one possibility that I was playing around with:
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.
-
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.
-
9
-
1
-
-
On 4/27/2020 at 11:10 AM, Thomas Jentzsch said:Attached is an NTSC version with hacked colors. That one should work better, I hope.
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...
On 4/27/2020 at 11:37 PM, ZeroPage Homebrew said:This is great Thomas! It makes the colours a LOT easier to distinguish without taking too much away from the difficulty of matching and correctly stacking. All that's left is to be able to reset the game without power cycling.
- James
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.
-
6
-
2
-
-
On 4/23/2020 at 6:36 AM, PitfallHarry77 said:Wow!! Thanks playsoft - that is awesome!! I have been playing Shades on my phone after your recommendation. I will really enjoy it on the Atari so thank you. I have found another good one that might work on Atari on the Nintendo Switch called Crossniq+. You can play two player and it is addictive and fans of the genre will enjoy it. Possibly too many colours going in different directions but would be good if it works. It is also a little like Multicross which I enjoy on the phone.
A cut-down version of Crossniq+ looks like it should be possible.
-
6 hours ago, ZeroPage Homebrew said:It's not a WIP - it's an old abandoned project (OAP?).
5 hours ago, bluswimmer said:This shades game is pretty neat! Would like to play an Atari version with better RNG (as it stands the seed appears to be the same each time with no manipulation of the seed).
If a title screen had been added it would have done that.
-
1
-
-
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 CHANNELTo:
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 CHANNELI'm not sure it affects timing, but it sounds cleaner to me, see what you think.
-
1
-
-
12 hours ago, PitfallHarry77 said:Shades looks awesome and I would love to try it out. You don’t have a PAL version by any chance.
Yes, attached is the PAL build.
-
3
-
1
-
-
17 hours ago, devwebcl said:Cool !, I always thought that was a very feasible game for 2600
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?
-
1
-
-
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.
-
2
-
-
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.
-
1
-
-
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?
-
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.
-
1
-
-
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
-
8
-
-
6 hours ago, kiwilove said:Here is the problem with the sprite frames - if you look at the diagonal frames of the central sprites used - on the left hand side - you can see how difficult it is to get them looking 'normal' in their diagonal direction.
sprite_frames.bmp 32.12 kB · 3 downloads
I think Paul has done an exceptional job with this 'test' - a big improvement over the first one.
I do hope that whoever going to work on this conversion - do take note of how the original explosion(s) are done - and how they can be better improved upon - so that the whole project looks pretty darn neat - and finally in the words of Edmund Hillary - that we can knock this bastard off - and it's good to know that various people are quite willingly to lend a helping hand (and ear) to assist.
Harvey
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.
-
1 hour ago, TIX said:Are those the actual sprite dimensions used in this test ?
They are wider than 8 pixels ! probably because they are software sprites ??
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!
-
1
-
-
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...
-
3
-
-
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!).
-
It looks absolutely stunning 👍
-
1
-
1
-
-
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
-
1
-
-
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
-
1
-
-
2 hours ago, Synthpopalooza said:I for one would love seeing Galaga on 5200 or 8-bit. If 2600 can do it, why not us?
Thoughts on sound ... WSG by Namco has 3 sound channels. I'd do this:
1 16 bit channel: Alien death sounds.
8-bit channel ... ship firing, ship destroyed
8-bit channel ... aliens swooping, tractor beam sounds
$Cx in 16 bit will exactly nail some of those alien death sounds. 😁
Look forward to hearing them!
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Shades (Atari 2600)
in Homebrew Discussion
Posted
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.BINIn 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.