3 replies to this topic

[supercat]

Is it practical to use bB for part of the code in an assembly-language game while minimizing bB's own memory usage (preferably overlaying bB's temp variables with some kernel-temp variables from the assembly-language part)? Although I am definitely a fan of writing custom kernels suited to game requirements, there are some types of game code that could be done more conveniently in a higher-level language.

For example, it would be more convenient to say something like

  if (joystick right and xvel < 2)
	xvel = xvel + 0.25
  else if (joystick left and xvel > -2) or (xvel > 0.25)
	xvel = xvel - 0.25
  else if (xvel < -0.25)
	xvel = xvel + 0.25
  else
	xvel = 0

than to try to code all that in machine code. To be sure, the machine code version would be faster and more compact, but the bB version could still be much easier to work with.

Normally, bB reserves a lot of memory for variables, kernel temp stuff, the playfield, etc. I would want to get rid of all that. The goal would be to create subroutines in bB which don't use any memory except variables I've explicitly assigned, other than some temp variables which I've overlaid on my own kernel temps. Does that seem practical?

[batari]

supercat, on Sat Mar 1, 2008 3:44 PM, said:

Is it practical to use bB for part of the code in an assembly-language game while minimizing bB's own memory usage (preferably overlaying bB's temp variables with some kernel-temp variables from the assembly-language part)? Although I am definitely a fan of writing custom kernels suited to game requirements, there are some types of game code that could be done more conveniently in a higher-level language.

For example, it would be more convenient to say something like

  if (joystick right and xvel < 2)
	xvel = xvel + 0.25
  else if (joystick left and xvel > -2) or (xvel > 0.25)
	xvel = xvel - 0.25
  else if (xvel < -0.25)
	xvel = xvel + 0.25
  else
	xvel = 0

than to try to code all that in machine code. To be sure, the machine code version would be faster and more compact, but the bB version could still be much easier to work with.

Normally, bB reserves a lot of memory for variables, kernel temp stuff, the playfield, etc. I would want to get rid of all that. The goal would be to create subroutines in bB which don't use any memory except variables I've explicitly assigned, other than some temp variables which I've overlaid on my own kernel temps. Does that seem practical?

Yes, that's possible and bB was written so such a thing would be fairly simple to do.

You could do it one of two ways. One, you could make a custom includes file containing all of your asm files and none of the ones included with bB except bB.asm and the libraries it needs (e.g. fixed_point_math.asm, but even that isn't needed most of the time.) Your asm files should reference 2600basic_variable_redefs.h and the asm or header files contain any equates that bB expects to use. I think the fixed-point math routines use a few of the temp variables (temp1, temp2, etc.)

Another way is to simply have bB compile the code, creating bB.asm, which you can then "include" it from another asm file as long as you have defined the equates that it uses somewhere and also include any other asm libraries it needs, if any.

Lastly, if you are using fixed point variables, you need to "dim" them that way so the compiler knows how to deal with them. In the example below, I've picked a couple of names for the integer and fractional portions.

Here is your code rewritten for bB, partly due to syntax, and partly to work within the limitations. The number of booleans in a conditional statement is limited, and bB doesn't seem to like the unary minus (I thought I'd fixed that, but apparently I didn't) and in conditions, fixed point variables only compare their integer portions. (I may have made a mistake, so don't trust my code )

  dim xvel=xint.xfrac
  if joy0right && xvel < 2 then add25
  if joy0left && xvel >= 254 then xvel=xvel-0.25:goto donemoving
  if xvel=255 && xfrac>192 then add25
  xvel = 0:goto donemoving
add25
  xvel = xvel + 0.25
donemoving

[supercat]

batari, on Sat Mar 1, 2008 4:25 PM, said:

Another way is to simply have bB compile the code, creating bB.asm, which you can then "include" it from another asm file as long as you have defined the equates that it uses somewhere and also include any other asm libraries it needs, if any.

Would there be any naming conventions I'd have to watch out for to ensure that bB doesn't generate any symbols that would conflict with mine? An approach that would avoid that risk would be to have the bB program generate a separate binary and then use some other program to link them (this could work out nicely if the bB stuff would occupy its own bank).

Quote

Here is your code rewritten for bB, partly due to syntax, and partly to work within the limitations. The number of booleans in a conditional statement is limited, and bB doesn't seem to like the unary minus (I thought I'd fixed that, but apparently I didn't) and in conditions, fixed point variables only compare their integer portions. (I may have made a mistake, so don't trust my code )

  dim xvel=xint.xfrac
  if joy0right && xvel < 2 then add25
  if joy0left && xvel >= 254 then xvel=xvel-0.25:goto donemoving
  if xvel=255 && xfrac>192 then add25
  xvel = 0:goto donemoving
add25
  xvel = xvel + 0.25
donemoving

I think you forgot about decrementing xvel if the controller is stationary and it's above 0.25. Also, the code seems to assume that velocity is an 8.8 number. One of the big features of bB is its ability to work with 4.4 quantities. Would those pose any weirdness here?

[batari]

supercat, on Sat Mar 1, 2008 5:41 PM, said:

batari, on Sat Mar 1, 2008 4:25 PM, said:

Another way is to simply have bB compile the code, creating bB.asm, which you can then "include" it from another asm file as long as you have defined the equates that it uses somewhere and also include any other asm libraries it needs, if any.

Would there be any naming conventions I'd have to watch out for to ensure that bB doesn't generate any symbols that would conflict with mine? An approach that would avoid that risk would be to have the bB program generate a separate binary and then use some other program to link them (this could work out nicely if the bB stuff would occupy its own bank).

It generates its own labels, but all generated symbols begin with a "." so one could use the "subroutine" directive in DASM to avoid label clashes, or just avoid prepending your own symbols with a "."

Quote

Quote

Here is your code rewritten for bB, partly due to syntax, and partly to work within the limitations. The number of booleans in a conditional statement is limited, and bB doesn't seem to like the unary minus (I thought I'd fixed that, but apparently I didn't) and in conditions, fixed point variables only compare their integer portions. (I may have made a mistake, so don't trust my code )

  dim xvel=xint.xfrac
  if joy0right && xvel < 2 then add25
  if joy0left && xvel >= 254 then xvel=xvel-0.25:goto donemoving
  if xvel=255 && xfrac>192 then add25
  xvel = 0:goto donemoving
add25
  xvel = xvel + 0.25
donemoving

I think you forgot about decrementing xvel if the controller is stationary and it's above 0.25. Also, the code seems to assume that velocity is an 8.8 number. One of the big features of bB is its ability to work with 4.4 quantities. Would those pose any weirdness here?

Yes, I did assume that xvel was 8.8. If it's 4.4, declare it as dim xvel=var.var. No special considerations are needed for calculations, and you can mix types (types are detected automatically) but conditional statements only compare 8.0 integers, so if you compare constants, the decimal in 4.4 values is shifted 4 places right. So xvel<2 would become xvel<32, xvel>=254 becomes xvel>=224, and xvel=255 && xfrac>192 becomes xvel>252 ( I think.)