ultima Posted July 29, 2016 Share Posted July 29, 2016 I seem to remember RevEng posting a similar topic to this but would like to ask it once more if anyone would like to share some tips on saving cycles. Quote Link to comment Share on other sites More sharing options...
SIO2 Posted July 29, 2016 Share Posted July 29, 2016 (edited) Don't put the entire program in the main loop. In other words first make sure what you are updating needs updating. Edited July 29, 2016 by SIO2 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted July 29, 2016 Share Posted July 29, 2016 I seem to remember RevEng posting a similar topic to this but would like to ask it once more if anyone would like to share some tips on saving cycles. The best optimisations come from algorithmic changes. Posting your "slow" code and asking for optimisation tips or better algorithms than the ones you are currently using, would be a better approach in my opinion. 1 Quote Link to comment Share on other sites More sharing options...
SIO2 Posted July 29, 2016 Share Posted July 29, 2016 (edited) The best optimisations come from algorithmic changes. Posting your "slow" code and asking for optimisation tips or better algorithms than the ones you are currently using, would be a better approach in my opinion. I agree with you and want to add that, I think the best optimisation comes from first not doing what doesn't need done THEN by doing what does need done in a more efficient way. Edited July 29, 2016 by SIO2 1 Quote Link to comment Share on other sites More sharing options...
ultima Posted July 29, 2016 Author Share Posted July 29, 2016 (edited) The best optimisations come from algorithmic changes. Posting your "slow" code and asking for optimisation tips or better algorithms than the ones you are currently using, would be a better approach in my opinion. I managed to cut around 6 cycles removing some of the if..then statements with on..goto. It seems to blast out as high as 10 cycles over during certain enemy movement phases. BTW the enemy program under the headers _MaelstromAI & _MaelstromAI_II were modified from Random Terrain's collision prevention code to keep enemies off the playfield (as long as I establish pre-configured starting locations which at this time are only partially implemented). Edited August 14, 2016 by ultima Quote Link to comment Share on other sites More sharing options...
SIO2 Posted July 30, 2016 Share Posted July 30, 2016 (edited) One thing that jumped out at me is the if then can be grouped. if _Enemy = 12 then goto skipthispart if _Enemy = 10 then goto skipthispart if _Enemy = 11 then goto skipthispart if _Enemy = 13 then goto skipthispart if _Enemy = 14 then goto skipthispart if _Enemy = 15 then goto skipthispart if _Enemy = 16 then goto skipthispart if _Enemy = 17 then goto skipthispart Replaced by If _Enemy>9 && _Enemy<18 then goto skipthispart Edited July 30, 2016 by SIO2 1 Quote Link to comment Share on other sites More sharing options...
SIO2 Posted July 30, 2016 Share Posted July 30, 2016 (edited) Notice how many times you check collision(player0,player1). if collision(player0,player1) && _Enemy = 14 then Bit1_player_has_key_1 = Bit1_player_has_key_1 + %00000010 : _Enemy = 0 : _Sound3 = 4 if collision(player0,player1) && _Enemy = 10 then Bit0_player_has_key_0 = Bit0_player_has_key_0 + %00000001 : _Enemy = 0 : _Sound3 = 4 if collision(player0,player1) && _Enemy = 16 then Bit2_player_has_key_2 = Bit2_player_has_key_2 + %00000100 : _Enemy = 0 : _Sound3 = 4 rem player tries the door (door 5, door 13,door 17) and has the correct key if collision(player0,player1) && _Enemy = 5 && Bit0_player_has_key_0{0} then _Enemy = 0 : _Sound3 = 4 if collision(player0,player1) && _Enemy = 13 && Bit1_player_has_key_1{1} then _Enemy = 0 : _Sound3 = 4 if collision(player0,player1) && _Enemy = 17 && Bit2_player_has_key_2{2} then _Enemy = 0 : _Sound3 = 4 rem player tries the door (door 5, door 13,door17) and does not have the correct key if collision(player0,player1) && _Enemy = 17 && !Bit2_player_has_key_2{2} then gosub __Knock_Player_Back if collision(player0,player1) && _Enemy = 13 && !Bit1_player_has_key_1{1} then gosub __Knock_Player_Back if collision(player0,player1) && _Enemy = 5 && !Bit0_player_has_key_0{0} then gosub __Knock_Player_Back Try something like: if !collision(player0,player1) then goto __Skip_Coll_P0_P1 (put the tests we do if there is a collision here) __Skip_Coll_P0_P1 Edited July 30, 2016 by SIO2 1 Quote Link to comment Share on other sites More sharing options...
ultima Posted July 30, 2016 Author Share Posted July 30, 2016 Thanks SI02 & GroovyBee for the help. The version I posted seems to be useless for real hardware so I will return to an earlier build with the cycle savings (at least it has a more stable picture.) Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 31, 2016 Share Posted July 31, 2016 Use GOSUB as little as possible. Instead I've been using GOTO in a sort of structured manner. I use "after"_labelname "begin"_labelname and such to loop back/forward to code. begin_checkinputs: if demo = 1 then goto after_checkinputs checkinputs: if players = 1 then goto after_checkp2input checkp2input: REM /** Bleh **/ after_checkp2input: REM /** Bloopersnap **/ after_checkinputs: 2 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted August 1, 2016 Share Posted August 1, 2016 If you don't absolutely need the playfield resolution see if you can live with reducing the amount of playfield pixels that need to be drawn. As a bonus it frees up some variables for use! const pfres=6 1 Quote Link to comment Share on other sites More sharing options...
SIO2 Posted August 2, 2016 Share Posted August 2, 2016 (edited) ;*************************************************************** ; ; Missile collision check. ; ;``````````````````````````````````````````````````````````````` ; Skips this subsection if no player0/missile collision. ; if !collision(missile1,player0) then goto __Skip_Coll_Miss_P0 ;``````````````````````````````````````````````````````````````` ; Enemy thrown back on missile hit. if _Enemy = 11 then goto __Skip_Coll_Miss_P0 if _Enemy = 14 then goto __Skip_Coll_Miss_P0 if _Enemy = 16 then goto __Skip_Coll_Miss_P0 if _Enemy = 17 then goto __Skip_Coll_Miss_P0 if _Enemy = 13 then goto __Skip_Coll_Miss_P0 if _Enemy = 12 then goto __Skip_Coll_Miss_P0 if _Enemy = 5 then goto __Skip_Coll_Miss_P0 if _Enemy >= 6 then _HitPoints = _HitPoints - 1 : COLUP0 = $46 __Skip_Coll_Miss_P0 ;*************************************************************** I think the above could be replaced by the below ;*************************************************************** ; ; Missile collision check. ; ;``````````````````````````````````````````````````````````````` ; Skips this subsection if no player0/missile collision. ; if !collision(missile1,player0) then goto __Skip_Coll_Miss_P0 ;``````````````````````````````````````````````````````````````` ; Enemy thrown back on missile hit. if _Enemy <> 15 then if _Enemy > 10 && _Enemy < 18 goto __Skip_Coll_Miss_P0 if _Enemy >= 6 then _HitPoints = _HitPoints - 1 : COLUP0 = $46 __Skip_Coll_Miss_P0 ;*************************************************************** Edited August 2, 2016 by SIO2 Quote Link to comment Share on other sites More sharing options...
SIO2 Posted August 2, 2016 Share Posted August 2, 2016 Cool game. I look forward to seeing your final product. Quote Link to comment Share on other sites More sharing options...
SIO2 Posted August 2, 2016 Share Posted August 2, 2016 I worked on the Maelstrom routines. The attached .bas compiled for me and ran on my 7800 with only occasional jitters. Note that I patched past the title screen include so it will boot to a black screen. Just press fire to continue. ifropt1.bas 1 Quote Link to comment Share on other sites More sharing options...
ultima Posted August 3, 2016 Author Share Posted August 3, 2016 (edited) Nice work I added the title screen in and fixed a couple errors the mod to the breakable walls was missing some placement arguments. I also fixed the starting screen issue of firing at the dead tree to enter the dungeon and also fixed the boss.Ill post the .bas later when i grab my pc. Edited August 14, 2016 by ultima 1 Quote Link to comment Share on other sites More sharing options...
Papa Posted August 3, 2016 Share Posted August 3, 2016 Sometimes you eat the beam and, well, sometimes the beam, it eats you! (personally, I say if it looks good on real hardware then that's what's important. That's me, though. Some people don't ever even use real stuff anymore.) Quote Link to comment Share on other sites More sharing options...
ultima Posted August 4, 2016 Author Share Posted August 4, 2016 Sometimes you eat the beam and, well, sometimes the beam, it eats you! (personally, I say if it looks good on real hardware then that's what's important. That's me, though. Some people don't ever even use real stuff anymore.) Lol, true dude very true. I do want to play it on real hardware in the future. I did free up some processes this afternoon still trying to organize all the code to figure out if there are other areas that have become to complex or useless. Then the game still has lots of fine tuning. It seems like a never ending task to build a game engine just right. I still would like to see about adding more music and sound effects too. Quote Link to comment Share on other sites More sharing options...
ultima Posted August 5, 2016 Author Share Posted August 5, 2016 (edited) Heres version 13 Found some more cycles in drawing the players Started a multi music switcher (still under construction sometimes it works other times it makes some screaming atari noises but eventually fixes itself) - press reset to fix immediately(if music crashes) Edited August 14, 2016 by ultima Quote Link to comment Share on other sites More sharing options...
SIO2 Posted August 6, 2016 Share Posted August 6, 2016 Here are a couple more suggestions with a little extra code on each side so you can locate where they fit. skipthispart if _Bit7_Flip_P1{7} then REFP1 = 8 if !joy0up && !joy0down && !joy0left && !joy0right && _Bit5_Missile_Flag{5} then _Animation_Timer = 0 : goto __Skip_Joy0_Right rem move player normal way if no collision else use RT's routines to avoid sticky wall syndrome. if collision(player1,playfield) then goto __RT_Special if joy0up then _BitOp_Missile = %00000011 : _Bit7_Flip_P1{7} = 0 : _P1_UD = _P1_UD - 0.75 if joy0down then _BitOp_Missile = %00000101 : _Bit7_Flip_P1{7} = 0 : _P1_UD = _P1_UD + 0.75 if joy0left then _BitOp_Missile = %00001001 : _Bit7_Flip_P1{7} = 1 : _P1_LR = _P1_LR - 0.75 if joy0right then _BitOp_Missile = %00010001 : _Bit7_Flip_P1{7} = 0 : _P1_LR = _P1_LR + 0.75 goto __Skip_Joy0_Right __RT_Special rem random terrain's advanced collision prevention code+++++++++++++++++++++++++++++++++++++++++++++++++++++ start here if !joy0up then goto __Skip_Joy0_Up ;*************************************************************** ; ; Draw player and enemy. __Draw_Player_I COLUP1 = $C0 if _Animation_Timer < 14 then goto __Skip_AT1 if _Bit3_Missile_L{3} then goto __Fritz_Left_I if _Bit4_Missile_R{4} then goto __Fritz_Right_Frame_I if _Bit1_Missile_U{1} then goto __Fritz_Up_Frame_I if _Bit2_Missile_D{2} then goto __Fritz_Down_Frame_I __Skip_AT1 if _Animation_Timer > 15 then goto __Skip_AT2 if _Bit3_Missile_L{3} then goto __Fritz_Left_II if _Bit4_Missile_R{4} then goto __Fritz_Right_Frame_II if _Bit1_Missile_U{1} then goto __Fritz_Up_Frame_II if _Bit2_Missile_D{2} then goto __Fritz_Down_Frame_II __Skip_AT2 __Fritz_Left_I 1 Quote Link to comment Share on other sites More sharing options...
SIO2 Posted August 7, 2016 Share Posted August 7, 2016 (edited) The rems I added here to ds0 and ds1 seem to solve the music glitch. At least I have not heard it mess up since. Edited August 7, 2016 by SIO2 1 Quote Link to comment Share on other sites More sharing options...
ultima Posted August 8, 2016 Author Share Posted August 8, 2016 (edited) I added the bits you posted in two versions. A has some stiffness in the controls. I think I can fix this with some eight directional arguments, and in its current form will better go in the maelstrom routines ( its already 4 directional).B version is without the movement bypass. Edited August 14, 2016 by ultima Quote Link to comment Share on other sites More sharing options...
SIO2 Posted August 8, 2016 Share Posted August 8, 2016 (edited) I would just go with the control scheme you have in version B. A much bigger gain could be had if you could figure out how to structure the game so that it doesn't have to constantly swap banks. Edited August 8, 2016 by SIO2 1 Quote Link to comment Share on other sites More sharing options...
ultima Posted August 10, 2016 Author Share Posted August 10, 2016 (edited) - solved order of sound effects and added a new one - added a pause on the b/w switch (not sure why the playfield and players don't update color? Seems to only work on BK) - removed enemy speed control from difficulty switch - added SI02's music glitch fix - added collision check to enemy movement under maelstrom section - dropped weird backward music on overworld and replaced with a lovely G major chord shape - fixed a problem with secret walls opening before new screen is visible - cleaned up a lot of code and general readability in the source The cycles are a little jittery but seem to be out of the red. I'm not sure if there are any other issues/bugs or ideas to improve the gameplay anymore. If not I will try one more type of door (a trick door) and maybe a few items like torches to light dark rooms and some powerups to defense and attack bonuses ,what to do with the one difficulty switch now, plus the gamemodes which if all works out should be -story mode/-random mode/-2-player battle. Edited August 14, 2016 by ultima Quote Link to comment Share on other sites More sharing options...
iesposta Posted August 12, 2016 Share Posted August 12, 2016 I'm not sure if it saves cycles, but in a simple if/then goto label, if the label is close, technically within 128 bytes when compiled, you can drop the "goto". At the beginning use "set smartbranching on". This will add an assembler "goto" if the label is too far away to get to it free. It saves bytes -- sometimes hundreds of bytes in a 32K program. I really is best to start this on a copy, then drop a goto and compile. If the free space increases move on to the next one. If the free space stays the same, you can put it back or leave it out. The compiler is adding it back. If the program will not compile, it needs to have the goto because the label it is going to is too far away. Remember it only works in a simple if/then goto, not ones containing and (&&) or (||). Example it will not work: : if a>0 && a<50 then goto label Another one that may run faster is to use the not (exclamation point). Instead of: if a=0 then b=b+1 Use: if !a then b=b+1 Think of "!variable" as false (false is 0), and: if a then... without an exclamation means true (true is everything but 0). If you are checking if a variable is not zero, use: if a then b=b+1 Those (should) speed things along, as the Atari is checking a register's flag for a 1 or 0 instead of comparing the variable with a number. (Expert coders please correct me if either of these tips don't result in a speed up.) In the first tip, it is alway nice to see free space increase while the program runs the same, you haven't removed any programmed features, and you can use the reclaimed rom space for something new. 3 Quote Link to comment Share on other sites More sharing options...
ultima Posted August 13, 2016 Author Share Posted August 13, 2016 That's interesting I got the bit about removing the excess goto's but it didn't save any bytes. But I did manage to improve the AI by adding an extra counter to open a smaller time the enemy can move in. Will work more this weekend and post the results. Quote Link to comment Share on other sites More sharing options...
SIO2 Posted August 13, 2016 Share Posted August 13, 2016 ifropt2.bas ifropt2.bin Changes in _Skip_Sound01, the pause switch routine right after main loop, RT's player movement routines, _Player_Drawn_Start_Enemy_Draw, breakable walls routine, moved pfscorecolor = 0 from inside main loop to outside, replaced any <= or >= with equivalent < or > only, shortened up collision with enemy, changes in knock enemy back and Skip_Col,P0_P1. I also reorganized the enemy sprite selection so that they are selected by an on goto and the size and color data are wth the sprite data. Not sure if it that bit is really faster but wth all the changes it is a little quicker overall. 1 Quote Link to comment Share on other sites More sharing options...
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.