MemberAtarian
-
Content Count
388 -
Joined
-
Last visited
Posts posted by MemberAtarian
-
-
I like how the OP used music from my favorite heavy metal band, Iron Maidien. The song heard in the above video(s) is from their album Fear of the Dark, which is a personal favorite of mine.
The OP did a fantastic job recreating the song on the Atari 2600!
For those interested, heres the actual song by Iron Maiden:
[irl]
[/url]Thank you, I always feel that my weakness is the sound part of programming, I have no good ear for tones.
-
It can be done in bB, but only with the standard kernel, with a lot of playfield manipulation.It has one disadvantage: It eats up CPU cycles fast.
-
Thanks, and yes it has a lot in common will all those "Don't touch anything, everything will kill you" style of game.
"Don't touch anything, everything will kill you", you should call this game "Australia", it has a big spider anyway!
-
Have a lot of common with both games and really love it! That spider is just amazing.-
1
-
-
I put the CheckMouse in bB code in bank8, outside the kernel, now it's working fine.
-
Aha, I see. Sorry, I misunderstood what was happening in CheckMouse, I see now that it is only an in-between code that jumps into your actual code.
As I said, this was only in answer to the question of "how would it be done in assembly?". I don't know exactly how it's done in bB, but I wanted to make sure you understood how it actually works behind the scenes.
I would give a longer response, but I have to head to work in a few minutes.
Dunno why it happens, sometimes is seems like its nearly working, but goes off. It's not restarting, but the screen freezes. I tried it even with the exact locations in the ROM, starting with $F, because it's rorg-ed, but the result was the same.
Krystof told me not to do bankswitch in the middle of an important kernel, maybe he is right, but my code is just too long to translate into assembly (or just copy it out from the temp output assembly of bB and copy it to the kernel), it gives "branch too long".
Anyway, my bB code is like this:
if switchleftb then goto SetAmiga1 SetAtariST1 if !joy0up && !joy0down then goto Dir1 if joy0up && !joy0down then goto Dir2 if joy0up && joy0down then goto Dir3 if !joy0up && joy0down then goto Dir4 SetAmiga1 if !joy0right && !joy0down then goto Dir1 if joy0right && !joy0down then goto Dir2 if joy0right && joy0down then goto Dir3 if !joy0right && joy0down then goto Dir4 Dir1 if !a{0} && !a{1} then a{2} = 0 : goto NewWay if a{0} && !a{1} then a{2} = 1 : a{3} = 0 : goto TO1 if !a{0} && a{1} then a{2} = 1 : a{3} = 1: goto TO1 if a{0} && a{1} then a{2} = 0 : goto NewWay TO1 a{0} = 0: a{1} = 0: goto Dir Dir2 if a{0} && !a{1} then a{2} = 0 : goto NewWay if a{0} && a{1} then a{2} = 1 : a{3} = 0 : goto TO2 if !a{0} && !a{1} then a{2} = 1 : a{3} = 1 : goto TO2 if !a{0} && a{1} then a{2} = 0 : goto NewWay TO2 a{0} = 1: a{1} = 0: goto Dir Dir3 if a{0} && a{1} then a{2} = 0 : goto NewWay if !a{0} && a{1} then a{2} = 1 : a{3} = 0 : goto TO3 if a{0} && !a{1} then a{2} = 1 : a{3} = 1 : goto TO3 if !a{0} && !a{1} then a{2} = 0 : goto NewWay TO3 a{0} = 1: a{1} = 1: goto Dir Dir4 if !a{0} && a{1} then a{2} = 0 : goto NewWay if !a{0} && !a{1} then a{2} = 1 : a{3} = 0 : goto TO4 if a{0} && a{1} then a{2} = 1 : a{3} = 1 : goto TO4 if a{0} && !a{1} then a{2} = 0 : goto NewWay TO4 a{0} = 0: a{1} = 1 Dir if player0x>1 && a{2} && a{3} then player0x=player0x-2 if player1x<152 && a{2} && !a{3} then player0x=player0x+2 NewWay if switchleftb then goto SetAmiga2 SetAtariST2 if !joy0left && !joy0right then goto Dir5 if joy0left && !joy0right then goto Dir8 if joy0left && joy0right then goto Dir7 if !joy0left && joy0right then goto Dir6 SetAmiga2 if !joy0left && !joy0up then goto Dir5 if joy0left && !joy0up then goto Dir8 if joy0left && joy0up then goto Dir7 if !joy0left && joy0up then goto Dir6 Dir5 if !a{4} && !a{5} then a{6} = 0 : goto Gotos if a{4} && !a{5} then a{6} = 1 : a{7} = 0 : goto TO5 if !a{4} && a{5} then a{6} = 1 : a{7} = 1 : goto TO5 if a{4} && a{5} then a{6} = 0 : goto Gotos TO5 a{4} = 0: a{5} = 0: goto DirX Dir6 if a{4} && !a{5} then a{6} = 0 : goto Gotos if a{4} && a{5} then a{6} = 1 : a{7} = 0 : goto TO6 if !a{4} && !a{5} then a{6} = 1 : a{7} = 1 : goto TO6 if !a{4} && a{5} then a{6} = 0 : goto Gotos TO6 a{4} = 1: a{5} = 0: goto DirX Dir7 if a{4} && a{5} then a{6} = 0 : goto Gotos if !a{4} && a{5} then a{6} = 1 : a{7} = 0 : goto TO7 if a{4} && !a{5} then a{6} = 1 : a{7} = 1 : goto TO7 if !a{4} && !a{5} then a{6} = 0 : goto Gotos TO7 a{4} = 1: a{5} = 1: goto DirX Dir8 if !a{4} && a{5} then a{6} = 0 : goto Gotos if !a{4} && !a{5} then a{6} = 1 : a{7} = 0: goto TO8 if a{4} && a{5} then a{6} = 1 : a{7} = 1: goto TO8 if a{4} && !a{5} then a{6} = 0 : goto Gotos TO8 a{4} = 0: a{5} = 1 DirX if player0y>11 && a{6} && a{7} then player0y=player0y-2 if player0y<87 && a{6} && !a{7} then player0y=player0y+2 GotosSo I'm using the variable bits of "a" (it's just a memory address), a{0} and a{1} for the two sensors of horizontal movement, a{2} if movement will be done, a{3} for direction (if 0, +, if 1, -), a{4} and a{5} for vertical sensors, a{6} if movement should be done and a{7} for direction.
I read the sensors, load the previous state, compare it and decide if the wheels were rolled, then save the actual sensor states.
lda SWCHA lsr lsr lsr lsr and #%11 ldy lastTrack sta lastTrack eor NextTrackTbl,y beq .down eor #%11 bne .endTC .up: ... .down: ... .endTC ... NextTrackTbl .byte %01 .byte %11 .byte %00 .byte %10Tom sent me this code template, but I only understand half of it. And it's incompatible to what I do.
-
I even tried the code that is in the temp assembly bB, so I guessed it would work.
sta temp7 lda #>(.SetupMouse-1) pha lda #<(.SetupMouse-1) pha lda temp7 pha txa pha ldx #3 ; number of bank you want jmp BS_jsr ; this is at the end of bank8, every jump is going there
And it's not working either. :/ And it does not seem like a wrong bank error as that would make strange glitches, but is just simply reboots the system.
-
I have never used bB, but I do know how bankswitching works in assembly. The thing about bankswitching is that the bank is switched as soon as the hotspot address is accessed.
Think of it like a clipboard with a stack of pages representing each bank. You can only see one page at a time. The program counter marches through the program, like if you were using your finger to keep track of where you were reading. If you happen to access the addresses from $FFF4 to $FFFB, before you can even finish your sentence, the page you are reading will instantly change to another one (a bankswitch happens). Your finger doesn't move, it keeps pointing to wherever you left off on the last page, and you keep on reading like nothing happened.
So if I have something like this...
lda #64 ; finish doing something important sta foo nop $FFF6 ; switch to bank 3 - IMPORTANT: switch happens instantly! jsr bar ; jump to the subroutine - IMPORTANT: this never happens!...the JSR never actually happens, because as soon as $FFF6 is accessed, we magically jump to bank 3 and continue on.
This is where the problem is happening. Your banks aren't lining up with each other, so when you switch banks, you end up in the wrong place.
There are many methods of fixing this, and the easiest is to simply have a list of all the "bridges" to labels you want to be able to access from other banks, like this: (the 8bitworkshop example you linked above called this type of thing a "trampoline")
goto_foo nop $FFF4 ; switch to bank 1 jmp foo ; jump to "foo", which is in bank 1 goto_bar nop $FFF6 ; switch to bank 3 jmp bar ; jump to "bar", which is in bank 3 goto_etc nop $FFF9 ; switch to bank 6 jmp etc ; jump to "etc", which is in bank 6You then put this code in all the banks, at exactly the same spot in every bank, usually at the front. This way, no matter which bank you are in, you can simply do a jmp goto_foo, and that will jump to the table, which is exactly the same in every bank. So when the bankswitch happens, it won't cause a crash.
Keep in mind that this only works with JMP statements, not JSR's. If you wanted that, it would be a bit more complicated. You would have to keep track of which bank you came from, and where you were inside the bank, typically by pushing this information to the stack and then pulling it out when you returned.
This is how you would do it in assembly. I'm not exactly sure how you would do something like this in bB, you might want to start another thread in the batari Basic Forums.
One super-easy solution, which might actually be best, since your CheckMouse routine is so short, would be to put a copy of CheckMouse in both banks. Then you wouldn't need to do any bankswitching at all.
Oh my, there is so many things wrong with this. :/
First, I told you, illegal 'nop' is not working with bB. I would do that if I could, I tried NOP $1FF_, NOP $FFF_, even these with STA, LDA, BIT, but none of them works.
Second, "CheckMouse" is in bank8 (as the drawscreen loop of bB), it's just the beginning, the real thing is SetupMouse in bank3, and it's more than 1K (it's reading the mouse sensors and takes a lot of space), I can't just copy it into "Checkmouse" (after converting it to assembly, of course) or bank8 will be full and I won't have any space left for sprites. Another thing with bB that every sprite information is in bank8, because it has to be in the same bank as the drawing.
-
Hi guys, you know, I make a TBS game for the VCS in bB and I have to check the mouse sensors very often. I do it 8 times during overscan and 2 times in vblank now. But there is the "drawscreen" part that is only accessable in assemby, modifing the kernel. I calculated the cycles, so it's not the cause of the problem: First, I do this code where I want to do the checking:
lda #8 bit SWCHB BNE .skipping LDA e AND #32 BEQ .skipping JSR CheckMouseThis checks if the bw switch is set to 1 and the fifth bit of 'e' variable is set to 1 (it means you are in a loop that allows you using the mouse), and if it's ok, it goes to CheckMouse. Checkmouse looks like this:
CheckMouse LDA e ORA #16 STA e LDY #<$1F lDA #>$F6 LDX #2 JMP .SetupMouse .backback rtsIt's an F4 cartridge, and mouse checking is in the 3rd bank of code. I set the fourth bit of 'e' to 1, so in bB code I will know when to jump back here. So this should jump to label "SetupMouse" in bank3.
In bB code I tried a lot of methods, simple "goto backback bank8", the "fake rts" method that was written in Hugg's book (https://8bitworkshop.com/v3.2.0/?=&file=examples%2Fbankswitching&platform=vcs)
pha tya pha lda $1FF4,x rtsAnd of course the more logical
asm LDY #<$1F lDA #>$FB LDX #7 JMP .backback endBut none of them is working, it crashes and starts the ROM from the beginning. Even if I put the ASM under "SetupMouse". There was a version I made with very complicated way in vblank with a lot of jumps and that way, the assembly jump and basic code goto back worked, but the scanline number was too high and if I changed .SetupMouse to anything else, it crashed and as I put a goto for bank4 in vblank and a goto to go back, it crashed as well, so I wanted to find a simple method to fix this, but nothing is working, crashing the game as soon I set bw to 1.
Can you tell me how I should do a proper bankswitch is asm?
I read about 'illegal' opcodes and 'illegal' nop method for bankswitching, but bB, unlike DASM, can't use them.
-
I like that you're bringing this game to the 2600. There are 2 things that stand out to me, one that you probably can't fix, but one that you probably can (not listed in that order).
1) The game looks like Choplifter, but doesn't feel like it because of the lack of momentum in the chopper's movement. Yes, there's a delay in liftoff, but everything else is so rigid, it doesn't feel like Choplifter. I had put off saying anything because I thought maybe it was just part of it being a work in progress, but it's definitely something I hope you can correct before it's truly final.
2) The way the buildings pop into the screen. I know you said in a previous post that you were pretty much out of rom space, and this would probably require drawing more sprites for progressive appearance of the buildings, so it's probably not an issue you can fix.
3) This one's not a complaint, but more of a what-if. You said you completely removed all playfield, and this would probably also require more rom space than you have left, but it would really be nice to see the playfield used for mountains in the background.
Anyway, the game is looking good and it's impressive to see it done in bB. (I do like the title music btw). I really hope you can add momentum to the movement though.
1. Maybe this one can be fixed, but sounds really hard. It would require complete rewrite of the movement, I don't know if I have any free variables for that.
2. It would require cutting down parts of the sprite and yeah, adding one sprite would make bank 8 go to minus.
3. I meant by removing the playfield that there is not a single line of code in the kernel that is about drawing the playfield. I erased it and put there the code for the background (in the multisprite kernel, the background is a fixed color). And you cannot scroll the playfield in the multisprite kernel, because it's mirrored, unlike the standard kernel.
-
Not add, but remove
I too played both Choplifter and Airwolf a lot on the C64, and both games mean a lot to me. And I'm very happy with your '2600-port of Choplifter..... except for the title music.
So don't get me wrong here; I'm just giving you feedback on what I think of the title music.
IMO using the title music from Airwolf in your port of Choplifter doesn't do it any good. And the tune is very off-key, which makes me want to skip it right away.
My suggestion is to do the same as Sega's port of the game: just play some rotor- and cannon sounds in the title screen.
Anyway, I'm happy that this game is finally available for the '2600!
Unfortunately, the TIA was not designed to make music on it, if you open the sound editor in Batari Basic, you will see that it really don't have most of the notes, so it's really hard to make it precise. And of course, the most annoying waveform, the "pure" is the only one that has 1,5 octaves that is precise, the cool Atari "bass" is leaked like a big roll of cheese.
-
Looks and plays really nice; great job!
The title music I don't like however: it is off-key and basically belongs to another helicopter game (Airwolf).
What if - just like the title screen of the Sega port - you just play the helicopter rotor-sound and sometimes the sound of the cannons?
See https://youtu.be/cGCSzPMj_70?t=93
Anyway, you did an amazing job with this port. But I hope this isn't the final version yet :-)
What should I add?
I got a suggestion about sky colors, but I had to change the kernel so there is no playfield, but background color rows and those are fixed. I don't have any space left in bank 8 either, maybe 90 bytes, that is not enought for a 3 frame animation.I know that Airwolf had his own game, I played it a lot on the C64, but I was thinking of music that has a connection to helicopters, there was Medicopter 117, but I'm sure only EU people know it, and there's a finnish song by the childmetal band "Hevisaurus", called Hevicopteri, but I couldn't find any readable tabs for it.
And most people liked the Airwolf theme becaused they watched it as a child a lot.
-
After half years, I decided to get this project back with my improved programming skills, I made this night the title screen. I'm pretty sure that the song is familiar to you.
I was a big WarCraft and StarCraft fan in my young ages and I really love the strategy game of Don Daglow for the Intellivision, so I decided to make a TBS for the Atari 2600, probably the very first strategy game for the system.At my first attempt, I had problems with the playerscore minikernel and even with the multisprite kernel, but I managed to learn how to use the kernel (even modding it) and of course, I modded the minikernel as well, so, here we go!
The game will support Atari ST mouse control if you have one!
-
1
-
-
-
I think these will be the final versions of noone would find any errors.
-
2
-
-
Wasted 7 hours in assembly.
I removed every single PF related stuff from the kernel and added a table based BK drawing, so there is no black border in the game. Unfortunately, this makes the "day to night" idea impossible, because that would turn the grass into some really weird color. The COLUPF is now free, so I could make the tank's ball white.
-
There is no playfield, but background graphics. 7 hours wasted for assembly.
-
1
-
-
I never got far in background color multi sprite experimentation. Mostly due to fear/uncertainty/denial regarding whether it'd work in the multi kernel framework. Also sprite position affects bands of color in the playfield which is distracting. Sometimes the color of rows change for mysterious reasons.
I'd consider altering one of the score kernels to have a different (say, green) background color and pretend that is the green grass the player is standing on.
UPDATE: I guess I should note that this is just my experience. *I* could be using the kernel mod wrong (or have a goofy environment that doesn't like it.)
I changed the kernel last night, it took me 6 hours.
I removed every part that contained PF and replaced it with a table of color rows, so now there is no background border around. -
I just wondered, I have seen a code that can make the background multi colored in ms kernel. Is there any trick to make the pf colored? (for example, make a black frame around, but have green grass at the bottom?
-
I would say game is near to be finished, hope the bugs won't appear (sometimes the sound is not the best and the counter for extra life is a bit off). I checked for days, there shouldn't be any scanline issues.
So, as I mentioned, you get an extra life for every 1000 points. At the beginning, it's really easy to get! I added two enemies, one of them is from the original game, the airplane, fast and annyoing, you get a lot of points for killing it, because it's nearly impossible. The other one is from Defender, the alien is after the people you saved and grabs one. You can save the poor thing if you shoot down the alien and get him in air!
-
1
-
-
Hi
Thanks for your suggestion, the last version I added to the post (2018-10-07b) now includes the option to mute the music if Left Difficulty is set to A
Reminds me as I programmed my first game, simple concept with a lot of different rooms. I absolutely love it, especially the seaweed/tentacle part!
-
rem batari Basic Program rem created 2018.10.05. 20:28:39 by Visual bB Version 1.0.0.568 set romsize=4k set tv = ntsc player0x=70: player0y=60 Arrow player0: %000110 %101110 %111100 %111111 %111110 %111100 %111000 %110000 %100000 end if player0x<15 then player0x=15 if player0x>138 then player0x=138 if player0y<10 then player0y=10 if player0y>88 then player0y=88 SSSS if !joy0up && !joy0down then goto Dir1 if joy0up && !joy0down then goto Dir2 if joy0up && joy0down then goto Dir3 if !joy0up && joy0down then goto Dir4 Dir1 if !a{0} && !a{1} then a{0} = 0: a{1} = 0: a{2} = 0 : a{3} = 0 : goto Dir if a{0} && !a{1} then a{0} = 0: a{1} = 0: a{2} = 1 : a{3} = 0 : goto Dir if !a{0} && a{1} then a{0} = 0: a{1} = 0: a{2} = 1 : a{3} = 1 : goto Dir if a{0} && a{1} then a{0} = 0: a{1} = 0: a{2} = 0 : a{3} = 0 : goto Dir Dir2 if a{0} && !a{1} then a{0} = 1: a{1} = 0: a{2} = 0 : a{3} = 0 : goto Dir if a{0} && a{1} then a{0} = 1: a{1} = 0: a{2} = 1 : a{3} = 0 : goto Dir if !a{0} && !a{1} then a{0} = 1: a{1} = 0: a{2} = 1 : a{3} = 1 : goto Dir if !a{0} && a{1} then a{0} = 1: a{1} = 0: a{2} = 0 : a{3} = 0 : goto Dir Dir3 if a{0} && a{1} then a{0} = 1: a{1} = 1: a{2} = 0 : a{3} = 0 : goto Dir if !a{0} && a{1} then a{0} = 1: a{1} = 1: a{2} = 1 : a{3} = 0 : goto Dir if a{0} && !a{1} then a{0} = 1: a{1} = 1: a{2} = 1 : a{3} = 1 : goto Dir if !a{0} && !a{1} then a{0} = 1: a{1} = 1: a{2} = 0 : a{3} = 0 : goto Dir Dir4 if !a{0} && a{1} then a{0} = 0: a{1} = 1: a{2} = 0 : a{3} = 0 : goto Dir if !a{0} && !a{1} then a{0} = 0: a{1} = 1: a{2} = 1 : a{3} = 0 : goto Dir if a{0} && a{1} then a{0} = 0: a{1} = 1: a{2} = 1 : a{3} = 1 : goto Dir if a{0} && !a{1} then a{0} = 0: a{1} = 1: a{2} = 0 : a{3} = 0 : goto Dir Dir if player0x>16 && a{2} && a{3} then player0x=player0x-2 if player0x<137 && a{2} && !a{3} then player0x=player0x+2 if !joy0left && !joy0right then goto Dir5 if joy0left && !joy0right then goto Dir6 if joy0left && joy0right then goto Dir7 if !joy0left && joy0right then goto Dir8 Dir5 if !a{4} && !a{5} then a{4} = 0: a{5} = 0: a{6} = 0 : a{7} = 0 : goto DirX if a{4} && !a{5} then a{4} = 0: a{5} = 0: a{6} = 1 : a{7} = 0 : goto DirX if !a{4} && a{5} then a{4} = 0: a{5} = 0: a{6} = 1 : a{7} = 1 : goto DirX if a{4} && a{5} then a{4} = 0: a{5} = 0: a{6} = 0 : a{7} = 0 : goto DirX Dir6 if a{4} && !a{5} then a{4} = 1: a{5} = 0: a{6} = 0 : a{7} = 0 : goto DirX if a{4} && a{5} then a{4} = 1: a{5} = 0: a{6} = 1 : a{7} = 0 : goto DirX if !a{4} && !a{5} then a{4} = 1: a{5} = 0: a{6} = 1 : a{7} = 1 : goto DirX if !a{4} && a{5} then a{4} = 1: a{5} = 0: a{6} = 0 : a{7} = 0 : goto DirX Dir7 if a{4} && a{5} then a{4} = 1: a{5} = 1: a{6} = 0 : a{7} = 0 : goto DirX if !a{4} && a{5} then a{4} = 1: a{5} = 1: a{6} = 1 : a{7} = 0 : goto DirX if a{4} && !a{5} then a{4} = 1: a{5} = 1: a{6} = 1 : a{7} = 1 : goto DirX if !a{4} && !a{5} then a{4} = 1: a{5} = 1: a{6} = 0 : a{7} = 0 : goto DirX Dir8 if !a{4} && a{5} then a{4} = 0: a{5} = 1: a{6} = 0 : a{7} = 0 : goto DirX if !a{4} && !a{5} then a{4} = 0: a{5} = 1: a{6} = 1 : a{7} = 0 : goto DirX if a{4} && a{5} then a{4} = 0: a{5} = 1: a{6} = 1 : a{7} = 1 : goto DirX if a{4} && !a{5} then a{4} = 0: a{5} = 1: a{6} = 0 : a{7} = 0 : goto DirX DirX if player0y>11 && a{6} && a{7} then player0y=player0y-2 if player0y<87 && a{6} && !a{7} then player0y=player0y+2 if joy0fire then COLUBK=$1e: COLUP0=$00 else COLUBK=$80: COLUP0=$0e if b{0} then return PF0=%11111111 b{0} =1 drawscreen b{0} =0 goto Arrow vblank goto SSSSOkay, I scan the mouse in vblank as well, now it's a lot better! The only problem I can't do it during drawscreen without hacking the kernel assembly.
-
4
-
-
Hi guys. I just realized this week that you can use the ST Mouse with the VCS and I was amazed, so I got one and started coded (I use bB). I disassembled the mouse, so I could figure out how it determinates movement of the ball.
So the joy0up and joy0down are the horizontal way of movement, so let's take the example. I understand that there is a rotation, for one way, it's 00 >> 01 >> 11 >>10 and 00 >> 10 >> 11 >> 01 for the other direction.
So I made my code:
if !joy0up && !joy0down && !a{0} && !a{1} then a{0} = 0: a{1} = 0: a{2} = 0 : a{3} = 0 : goto Dir if !joy0up && !joy0down && a{0} && !a{1} then a{0} = 0: a{1} = 0: a{2} = 1 : goto Dir if !joy0up && !joy0down && !a{0} && a{1} then a{0} = 0: a{1} = 0: a{3} = 1 : goto Dir if joy0up && !joy0down && a{0} && !a{1} then a{0} = 1: a{1} = 0: a{2} = 0 : a{3} = 0 : goto Dir if joy0up && !joy0down && a{0} && a{1} then a{0} = 1: a{1} = 0: a{2} = 1 : goto Dir if joy0up && !joy0down && !a{0} && !a{1} then a{0} = 1: a{1} = 0: a{3} = 1 : goto Dir if joy0up && joy0down && a{0} && a{1} then a{0} = 1: a{1} = 1: a{2} = 0 : a{3} = 0 : goto Dir if joy0up && joy0down && !a{0} && a{1} then a{0} = 1: a{1} = 1: a{2} = 1 : goto Dir if joy0up && joy0down && a{0} && !a{1} then a{0} = 1: a{1} = 1: a{3} = 1 : goto Dir if !joy0up && joy0down && !a{0} && a{1} then a{0} = 0: a{1} = 1: a{2} = 0 : a{3} = 0 : goto Dir if !joy0up && joy0down && !a{0} && !a{1} then a{0} = 0: a{1} = 1: a{2} = 1 : goto Dir if !joy0up && joy0down && a{0} && a{1} then a{0} = 0: a{1} = 1: a{3} = 1 : goto Dir Dir if player0x>15 && a{3} then player0x=player0x-1 if player0x<138 && a{2} then player0x=player0x+1So joy0up sets a{0} and joy0down set a{1}, if it's the same as it was in the previous turn, there is no movement, if it's changed, depending on that rotation, the cursor have to move. I would do the same with the vertical movement.This could work, but it only does if you are really careful with moving the mouse, else, it nudges back and forth. Can you tell we what I should change?-
1
-
-
WoW, nice one!
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Dystopia (Utopia-like Turn Based Strategy for the 2600)
in Homebrew Discussion
Posted
As you can see, I made some progress on the game. You get a menu first where you can set if you want to play against another player or the computer, and, of course, how much money you get, how many steps and turns you have. I spent many days with the code for the mouse, nearly even doing it entirely in assembly, but it got too complicated at some point. You may say that the mouse is a bit too sensitive, because it reads it twice during overscan, one during vblank and 3 times during the drawscreen and if you are moving it more gently, it won't jigger around. It's not a fast paced game anyway. Of course, you can use the joystick, if you want to, but even ST and Amiga mouse is compatible (or the equal trackball).
Here will come the hard part, coding the drawing of the buildings and ships, it will be a nightmare for sure.