Nukey Shay Posted June 16, 2019 Share Posted June 16, 2019 City test: PF currently does not move. I need to dig up a bit more free space to fit the tables in. Since planet_state is always equal to planet_vector, I used that redundant byte to hold a new variable pptr. This would be the index for the city gfx so that it is scrollable (increase or decrease by 4 outside the kernel). During the kernel, this pointer is increased by 1 every 4th scanline in the 16 that display the city. PF collisions are ignored on frames it is displayed (so the lasers still function properly). May be a little wonky at the moment... Defendr2.asm Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted June 20, 2019 Author Share Posted June 20, 2019 (edited) On 6/16/2019 at 12:51 AM, Nukey Shay said: City test: PF currently does not move. I need to dig up a bit more free space to fit the tables in. Since planet_state is always equal to planet_vector, I used that redundant byte to hold a new variable pptr. This would be the index for the city gfx so that it is scrollable (increase or decrease by 4 outside the kernel). During the kernel, this pointer is increased by 1 every 4th scanline in the 16 that display the city. PF collisions are ignored on frames it is displayed (so the lasers still function properly). May be a little wonky at the moment... Defendr2.asm 238.58 kB · 1 download Looking through it and comparing. One thing I found in your demo code was that before the DEY before LF42A, these lines are needed otherwise the stars on the first iteration of index Y of play area will be more like lines instead of dots (STA NUSIZ1 is not though): AND #$F0 ;2 STA CTRLPF ;3 Still going through the rest to see how to apply, clean it up.... Edited June 20, 2019 by rallyrabbit Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted June 20, 2019 Author Share Posted June 20, 2019 On 6/16/2019 at 12:51 AM, Nukey Shay said: City test: PF currently does not move. I need to dig up a bit more free space to fit the tables in. Since planet_state is always equal to planet_vector, I used that redundant byte to hold a new variable pptr. This would be the index for the city gfx so that it is scrollable (increase or decrease by 4 outside the kernel). During the kernel, this pointer is increased by 1 every 4th scanline in the 16 that display the city. PF collisions are ignored on frames it is displayed (so the lasers still function properly). May be a little wonky at the moment... Defendr2.asmFetching info... Nice changes, I am working through what you did vs I did now. It's close. Right now with the original code (where I no longer show mountains), Stella is indicating that it is outputting at a solid 60hz. However, once I've started adding changes (mine and your) I start seeing some random points where it drops to 59hz or up to 61hz. It isn't constant, but I also haven't isolated the exact situations causing it either. Once I get that sorted i'll post another assembly file. Also, how do you assembly you source? Every time I attempt it is 2 bytes too big. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted June 21, 2019 Share Posted June 21, 2019 Check a report after assembling to see where your error occurs...Dasm creates a perfect 8192-byte file. On 6/20/2019 at 10:42 AM, rallyrabbit said: One thing I found in your demo code was that before the DEY before LF42A, these lines are needed otherwise the stars on the first iteration of index Y of play area will be more like lines instead of dots (STA NUSIZ1 is not though): AND #$F0 ;2 STA CTRLPF ;3 You gotta resize the ball after the scanner is drawn (the ball is the player's blip). I did that in the empty scanline at LF3C4. Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted June 26, 2019 Author Share Posted June 26, 2019 On 6/21/2019 at 6:21 PM, Nukey Shay said: Check a report after assembling to see where your error occurs...Dasm creates a perfect 8192-byte file. You gotta resize the ball after the scanner is drawn (the ball is the player's blip). I did that in the empty scanline at LF3C4. I wasn't assembling with -f3. Strip out those two bytes and it was ok. All right. I am not sure I 100% get all your changes just yet, but it used the bulk of how you were doing the Draw City routine and how to call it and where to jump out. I smoothed it a bit with a different algorithm off the frame counter to make the flickering a little faster (every other frame). I used the byte for the inviso units for the pointer. But I retained all the planet state and planet vector that existed before (that's part of what I don't quite get in what you did). I was having the data from PF0/1/2 bleed through to the top of the next frame. So I cleared PF0/1/2 at the end of LF53B before it switches to bank 0 after a frame is complete. Now, one oddball thing I cannot figure out is that your code, the humans can survive when the ship flies (scrolling) left to right. In my, the humans get detroyed when they hit a building. I am not entirely sure why, that's what I've been debugging for the past two days. Then I have a code exception on planet destruction that I have to work out too, but I think I know what that problem is. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted June 27, 2019 Share Posted June 27, 2019 PF is the same as lasers, the game considers them to have been shot by you (gotta skip the CXP0FB collision check when the city is displayed). Scrolling city added, still needs to be synced with player movement. Currently not enough space to do 20 pixels horizontally, so I used 10 here. Defendr2.asm Def2.bin Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted June 27, 2019 Author Share Posted June 27, 2019 I worked out that problem. I am still having some issues. I didn't adopt your change to the planet_state and planet_vector, so I am having some trouble living with what I adopted. That's my next hurtle before I start trying to plan out the rest of the changes. Your City routine is interesting, it wasn't the way I was going to approach it, but gosh, yours is way more optimized than what I sketched out. Back to work, hope to have something a bit more ready next week. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted June 29, 2019 Share Posted June 29, 2019 Space wave display glitch fixed (I had to go back to the 5/11 file). City scrolling fixed (uses the star positioning as the basis instead). Might be a couple artifacts left over in the cityscape. Almost there... Defendr2.asm Def2.bin Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted July 2, 2019 Author Share Posted July 2, 2019 I think I found a problem and worked out a solution for a slight glitch in your demo routine. If the Index Y enters the city routine at 0x1, it'll decrement to 0xFF in the routine and general either cause an overflow in the screen (TIA) control or jumps into non-code area abnormally (depends). I solved that, but seems that you fixed it as well. So, cool either way. One question on some syntax you use: LF407: ;66 LDA #$FF ;2 68 .byte $2C ;4 72 LF400: ;58 LDA (object_color_vector),Y ;5 63 The line ".byte $2C" On the surface this looks like RAM storage space. But, on execution from the LDA to the LDA for the color, $2C seems to be intrepretted as an opcode (instruction) but stella jumps over it. WHat's this syntax instructing to do here? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 2, 2019 Share Posted July 2, 2019 Skipping over the next 2 bytes of code. This saves 1 byte (if using BNE or BMI), or 2 bytes (if using JMP). So the opcode for BIT $abs, CMP $abs, or triple-NOP does the same job only using 1 byte for the opcode itself. I used BIT (opcode value $2C), as the register flags didn't matter here anyway. If branching leads to LF405 or LF407, the program loads A with immediate value $FF then does BIT $9FB1 (the interpretation of LDA(ind),y opcode and object_color_vector's equate as an absolute address). What's at $9FB1? Who cares? The important thing is to skip the LDA (object_color_vector),y instruction Use the opcode for triple-NOP (byte value $0C) if the program needs the state of status flags AND registers unchanged. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 2, 2019 Share Posted July 2, 2019 BTW the color value $FF is used on all lines not displaying an enemy (since it's missile sprite shares the same color register). Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted July 2, 2019 Author Share Posted July 2, 2019 On 6/29/2019 at 3:22 AM, Nukey Shay said: Space wave display glitch fixed (I had to go back to the 5/11 file). City scrolling fixed (uses the star positioning as the basis instead). Might be a couple artifacts left over in the cityscape. Almost there... Defendr2.asm 237.55 kB · 0 downloads Def2.bin 8 kB · 2 downloads Sir this is incredible. I was trying to use a single graphics set and bit shift may way through it, which was taking way too many cycles. I had to free up enough contiguous space, but this is way more optimized. I also was kicking off the draw by doing the framecounter & 0x01 to lead to a branch, where the LSR and Branch actually saves a cycle. So, I need to clean up the graphics I want to use and test a bit and add in some other play code that I want to implement that is pretty straight forward. This leads into the last question, do you know where the game scales the speed of the enemies based on the current playing wave? Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted July 2, 2019 Author Share Posted July 2, 2019 13 hours ago, Nukey Shay said: Skipping over the next 2 bytes of code. This saves 1 byte (if using BNE or BMI), or 2 bytes (if using JMP). So the opcode for BIT $abs, CMP $abs, or triple-NOP does the same job only using 1 byte for the opcode itself. I used BIT (opcode value $2C), as the register flags didn't matter here anyway. If branching leads to LF405 or LF407, the program loads A with immediate value $FF then does BIT $9FB1 (the interpretation of LDA(ind),y opcode and object_color_vector's equate as an absolute address). What's at $9FB1? Who cares? The important thing is to skip the LDA (object_color_vector),y instruction Use the opcode for triple-NOP (byte value $0C) if the program needs the state of status flags AND registers unchanged. Not sure I am following completely here. So take this bit: F407: ;66 LDA #$FF ;2 68 .byte $2C ;4 72 What's the different in this and: F407: ;66 LDA #$FF ;2 68 NOP NOP (as many NOPs to get the same spacing in ROM) Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 5, 2019 Share Posted July 5, 2019 The BIT opcode is being used as a JMP...skipping over the following 2 bytes to the WSYNC. The advantage is that JMP burns 3 bytes of Rom, the BIT opcode only uses 1. The disadvantage is that BIT alters status flags and takes an extra cycle (neither is important for this case). Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 5, 2019 Share Posted July 5, 2019 (edited) On 7/2/2019 at 6:22 PM, rallyrabbit said: This leads into the last question, do you know where the game scales the speed of the enemies based on the current playing wave? LDA #$0F ;2 max. speed LDX attack_wave_hex ;3 load current wave # CPX #$0F ;2 BCS LD767 ;2 branch if higher than 15 (use max. speed) TXA ;2 set speed = wave # LD767: STA rF2 ;3 save to temp Ram (used at LD7F9) You could slow progression down by adding a couple bytes of code... LDA attack_wave_hex ;3 load current wave # LSR ;2 TAX ;2 LDA #$0F ;2 max. speed CPX #$0F ;2 BCS LD767 ;2 branch if wave # higher than 31 (use max. speed) TXA ;2 set speed = wave # / 2 LD767: STA rF2 ;3 save to temp Ram If you want to alter the maximum speed, just change the value #$0F to something lower in the LDA and CPX lines. Edited July 5, 2019 by Nukey Shay Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 6, 2019 Share Posted July 6, 2019 City Kernel humanoid glitch fixed: LF43Ewaste: ;61 dec $2E ;5 66 lda #$00 ;2 68 STA GRP0 ;3 71 clc ;2 73 bcc LF43EE ;3 0 CityKernel: ;37 ldx pptr ;3 40 lda #$00 ;2 42 sta CTRLPF ;3 45 lda #$8A ;2 47 sta COLUPF ;3 50 dey ;2 52 ContCity: ;52 sta HMCLR ;3 55 CPY rA1 ;3 58 BCS LF43Ewaste ;2 60 LDA (object_gfx_vector),Y ;5 65 STA GRP0 ;3 68 BNE DrawEnemy ;2 70 STA rA1 ;3 73 BEQ LF43EE ;3 0 DrawEnemy: ;71 LDA (object_color_vector),Y ;5 0 LF43EE: STA HMOVE ;3 3 STA COLUP0 ;3 6 lda PF0Tbl,x ;4 10 sta PF0 ;3 13 lda PF1Tbl,x ;4 17 sta PF1 ;3 20 LDA (ship_vector),Y ;5 25 STA GRP1 ;3 28 lda PF2Tbl,x ;4 32 sta PF2 ;3 35 sta $2E ;3 38 tya ;2 40 and #$03 ;2 42 beq IncCity ;2 44 .byte $C5 ;3 47 IncCity: inx ;2 47 dey ;2 49 bne ContCity ;2 51 JMP LF53B ;3 Getting close to being able to double the size of the city tables (to draw Defender's actual city gfx) Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted July 7, 2019 Author Share Posted July 7, 2019 On 7/5/2019 at 4:35 PM, Nukey Shay said: LDA #$0F ;2 max. speed LDX attack_wave_hex ;3 load current wave # CPX #$0F ;2 BCS LD767 ;2 branch if higher than 15 (use max. speed) TXA ;2 set speed = wave # LD767: STA rF2 ;3 save to temp Ram (used at LD7F9) You could slow progression down by adding a couple bytes of code... LDA attack_wave_hex ;3 load current wave # LSR ;2 TAX ;2 LDA #$0F ;2 max. speed CPX #$0F ;2 BCS LD767 ;2 branch if wave # higher than 31 (use max. speed) TXA ;2 set speed = wave # / 2 LD767: STA rF2 ;3 save to temp Ram If you want to alter the maximum speed, just change the value #$0F to something lower in the LDA and CPX lines. Not sure if that is giving me what I wanted. Playing around with it a bit.... Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted July 7, 2019 Author Share Posted July 7, 2019 18 hours ago, Nukey Shay said: City Kernel humanoid glitch fixed: LF43Ewaste: ;61 dec $2E ;5 66 lda #$00 ;2 68 STA GRP0 ;3 71 clc ;2 73 bcc LF43EE ;3 0 CityKernel: ;37 ldx pptr ;3 40 lda #$00 ;2 42 sta CTRLPF ;3 45 lda #$8A ;2 47 sta COLUPF ;3 50 dey ;2 52 ContCity: ;52 sta HMCLR ;3 55 CPY rA1 ;3 58 BCS LF43Ewaste ;2 60 LDA (object_gfx_vector),Y ;5 65 STA GRP0 ;3 68 BNE DrawEnemy ;2 70 STA rA1 ;3 73 BEQ LF43EE ;3 0 DrawEnemy: ;71 LDA (object_color_vector),Y ;5 0 LF43EE: STA HMOVE ;3 3 STA COLUP0 ;3 6 lda PF0Tbl,x ;4 10 sta PF0 ;3 13 lda PF1Tbl,x ;4 17 sta PF1 ;3 20 LDA (ship_vector),Y ;5 25 STA GRP1 ;3 28 lda PF2Tbl,x ;4 32 sta PF2 ;3 35 sta $2E ;3 38 tya ;2 40 and #$03 ;2 42 beq IncCity ;2 44 .byte $C5 ;3 47 IncCity: inx ;2 47 dey ;2 49 bne ContCity ;2 51 JMP LF53B ;3 Getting close to being able to double the size of the city tables (to draw Defender's actual city gfx) Man! Been working on isolating that glitch for the past two hours... that's that I guess, thanks. I got a lot of the other final stuff in, scoring, enemy tables for the various waves, title screen, graphics as I want them, removing more dead code, changed how hyperspace and smart bombs work to get it back to one controlled game play etc. Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted July 9, 2019 Author Share Posted July 9, 2019 Do you happen to know where the Stargate code is for when the player hits a stargate. I have an idea. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 11, 2019 Share Posted July 11, 2019 Look at the code below LD20B...this is the routine that checks which type of object was hit when a collision occurs. If it is object #$10 (stargate), a branch is taken to LD282, which checks if you are still in a lower wave number (<11) and carrying 4 humanoids or more for a level skip. Otherwise, routine LD2B8 sets which area of space to warp (abducted humanoid sections take priority here). The original branch and the code between LD282 and LD2E0 can be erased for a version of the game which does not use a stargate (e.g. Defender). Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 11, 2019 Share Posted July 11, 2019 (edited) Correction: The code between LD282 and LD2F5 (+ the 2-byte data table LDE15 and the store at LD117). Edited July 11, 2019 by Nukey Shay Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 11, 2019 Share Posted July 11, 2019 Stargate disable added to assembly. Also, I used the cycles wasted in the city code to improve player ship visibility. Defendr2.asm Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted July 12, 2019 Author Share Posted July 12, 2019 On 7/11/2019 at 7:39 AM, Nukey Shay said: Look at the code below LD20B...this is the routine that checks which type of object was hit when a collision occurs. If it is object #$10 (stargate), a branch is taken to LD282, which checks if you are still in a lower wave number (<11) and carrying 4 humanoids or more for a level skip. Otherwise, routine LD2B8 sets which area of space to warp (abducted humanoid sections take priority here). The original branch and the code between LD282 and LD2E0 can be erased for a version of the game which does not use a stargate (e.g. Defender). IT's weird, I traced it down to that too, but that code is not doing what I thought it would be doing..... Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted July 13, 2019 Author Share Posted July 13, 2019 On 7/11/2019 at 7:54 AM, Nukey Shay said: Correction: The code between LD282 and LD2F5 (+ the 2-byte data table LDE15 and the store at LD117). You're right, the code is actually LD2B8 to LD2F5 that is the core of the gating, where LD282 to LD2B8 is actually just deciding special circumstances. Cool. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 13, 2019 Share Posted July 13, 2019 Removing that code provides enough free space to add Defender's full city gfx...just a couple of branch pagecross glitches to iron out. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.