cycle saving tips?

[ultima]

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.

[SIO2]

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

[GroovyBee]

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.

[SIO2]

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

[ultima]

 

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

[SIO2]

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

[SIO2]

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

[ultima]

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.)

[+Gemintronic]

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:

[+Gemintronic]

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

[SIO2]

;***************************************************************

;

; 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

[SIO2]

Cool game. I look forward to seeing your final product.

[SIO2]

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

[ultima]

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

[Papa]

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.)

[ultima]

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.

[ultima]

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

[SIO2]

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

[SIO2]

 

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

[ultima]

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

[SIO2]

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

[ultima]

- 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

[iesposta]

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.

[ultima]

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.

[SIO2]

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.