Multisprite experimentation

[accousticguitar]

Thanks accousticguitar!

 

Having a wee bit of memory issue here. I'm not that experienced with memory saving tricks so I'm asking, is there anything I can do with my code to save some memory?

Ram or rom? Although I'm not sure I could help either way.

[Rabbit 2600]

Rom I believe. It says "-992 bytes of ROM space left in bank 1"

 

I'm using a lot of multiples in each screen. Perhaps there is a way to only have the codes in level 1 and have the rest of the levels grab the codes and re-use them?

Edited June 13, 2013 by Rabbit 2600

[+Gemintronic]

Thanks accousticguitar!

 

Having a wee bit of memory issue here. I'm not that experienced with memory saving tricks so I'm asking, is there anything I can do with my code to save some memory?

 

 

SOURCE - default.bas

 

I have no idea how or why this kind of declaration is working/compiling.

dim _P1_L_R = player1x.a

 

I don't think bB can handle decimals like that.

if _P1_U_D < _P0_U_D then _P1_U_D = _P1_U_D + 0.04

 

I guess what I'm saying is, you might be running into compiler errors instead of actually running out of RAM.

[Rabbit 2600]

I don't know either why it works, I just know it does =)

 

Hm, perhaps. This is the whole message I get after adding the 4th screen:

"DASM V2.20.07, Macro Assembler ©1988-2003

bytes of ROM space left in bank 1

bytes of ROM space left in bank 2

-992 bytes of ROM space left in bank 1

segment: 1fd4 eqm vs current org: 23b4

default.bas.asm (4552): error: Origin Reverse-indexed.

Aborting assembly

Errors were encountered during assembly."

[+Random Terrain]

I have no idea how or why this kind of declaration is working/compiling.

dim _P1_L_R = player1x.a

 

I don't think bB can handle decimals like that.

if _P1_U_D < _P0_U_D then _P1_U_D = _P1_U_D + 0.04

 

 

Read all about it:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#fixedpoint

[Rabbit 2600]

Ahh, so it's called fixedpoints. Now I know =)

[Rabbit 2600]

Could perhaps a gosub or something be used to save me some memory?

[accousticguitar]

Could perhaps a gosub or something be used to save me some memory?

yes, anything that is repeated can be handled like that and it will save a lot of rom.

[Rabbit 2600]

Okay. Then that is what I should focus on. I'm totally inexperienced with gosubs.

 

Would this work?

 

Level_1
_sub1
							  dim _P1_L_R = player1x.a
							  dim _P1_U_D = player1y.b
							  dim _P2_L_R = player2x.c
							  dim _P2_U_D = player2y.d
							  dim _P3_L_R = player3x.e
							  dim _P3_U_D = player3y.f
							  dim _P4_L_R = player4x.i
							  dim _P4_U_D = player4y.j
							  dim _P0_L_R = player0x.k
							  dim _P0_U_D = player0y.l
return

Level_2
gosub _sub1

[accousticguitar]

For starters, I doubt you need to define the players more than once (but like I say, I'm really rusty).

 

player1:
    %00011110
    %00011011
    %00111101
    %00111100
    %01111110
    %01111110
    %01111110
    %11111111
    %11011011
    %11000011
    %10100101
    %10111101
    %10011001
    %10111101
    %10011001
    %10001101
end
player2:
    %00011110
    %00011011
    %00111101
    %00111100
    %01111110
    %01111110
    %01111110
    %11111111
    %11011011
    %11000011
    %10100101
    %10111101
    %10011001
    %10111101
    %10011001
    %10001101
end
player3:
    %00011110
    %00011011
    %00111101
    %00111100
    %01111110
    %01111110
    %01111110
    %11111111
    %11011011
    %11000011
    %10100101
    %10111101
    %10011001
    %10111101
    %10011001
    %10001101
end
player4:
    %00011110
    %00011011
    %00111101
    %00111100
    %01111110
    %01111110
    %01111110
    %11111111
    %11011011
    %11000011
    %10100101
    %10111101
    %10011001
    %10111101
    %10011001
    %10001101
end

[+Gemintronic]

Thanks R.T. I knew about it but completely ignored it in my own programming. Talk about tunnel vision!

 

A big help is defining boolean variables where possible. In my current game each screen has various properties. I use one 8-bit variable and end up with 8 separate switches for different aspects of the room:

 

dim roomstyle = c

 

def openeast=roomstyle{0}

def openwest=roomstyle{1}

def opennorth=roomstyle{2}

def opensouth=roomstyle{3}

def solid=roomstyle{4}

def loweropen=roomstyle{5}

def doorexit=roomstyle{6}

def toprowglow=roomstyle{7}

[accousticguitar]

I don't think you want the subroutine in level 1. It should be below the levels in my opinion. It could get caught in a loop the way you have it now.

 

I would try something like this. (Of course it gets more complicated with multiple banks. I don't quite remember how that works but I think you also have to specify which bank the subroutine is in).

 

Level_1
gosub SR1
(playfield, game logic, drawscreen, etc.)
goto Level_1
Level_2
gosub SR1
(playfield, game logic, drawscreen, etc.)
goto Level_2

SR1

															 dim _P1_L_R = player1x.a
															 dim _P1_U_D = player1y.b
															 dim _P2_L_R = player2x.c
															 dim _P2_U_D = player2y.d
															 dim _P3_L_R = player3x.e
															 dim _P3_U_D = player3y.f
															 dim _P4_L_R = player4x.i
															 dim _P4_U_D = player4y.j
															 dim _P0_L_R = player0x.k
															 dim _P0_U_D = player0y.l
return

[Rabbit 2600]

Okay, I took out the sprites and colors from all levels except the first one. That gave me some much needed space.

 

Gonna see if I can get the hang of gosub now.

[Rabbit 2600]

Hm, I just came up with an idea. Instead of having a bunch of separate screens, couldn't 1 screen be used instead, and each time you leave and re-enter the room pfpixels would be randomized and give the appearance of many different rooms?

[bogax]

Hm, I just came up with an idea. Instead of having a bunch of separate screens, couldn't 1 screen be used instead, and each time you leave and re-enter the room pfpixels would be randomized and give the appearance of many different rooms?

 

not with the multisprite kernel

the playfield is in rom and the playfield itself can't be changed

you can only change the whole playfield to a different one

 

is there any difference between the levels besides playfields?

if not you should have a single loop and change only

the playfield when you change levels

even if other stuff does change you should probably

have a single loop and just change the stuff that needs

when you change levels.

 

I told you before I'll tell you again take al that crap out of the loop

you only have to set the playfield once when you change it

you don't need to do it every time you go through the loop

same for the players.

 

there are things you have to set every time you do a drawscreen

but if you don't need to set something why waste time doing it?

[accousticguitar]

not with the multisprite kernel

the playfield is in rom and the playfield itself can't be changed

you can only change the whole playfield to a different one

 

is there any difference between the levels besides playfields?

if not you should have a single loop and change only

the playfield when you change levels

even if other stuff does change you should probably

have a single loop and just change the stuff that needs

when you change levels.

 

I told you before I'll tell you again take al that crap out of the loop

you only have to set the playfield once when you change it

you don't need to do it every time you go through the loop

same for the players.

 

there are things you have to set every time you do a drawscreen

but if you don't need to set something why waste time doing it?

Good points.

[Rabbit 2600]

Very good point bogax. It's a bad habbit I've adopted and I will do my best to break away with it. And the only difference is the playfields.

Edited June 14, 2013 by Rabbit 2600