memcpy question

[fultonbot]

Okay, so this is quick question but I want to ask it FIRST before I waste my time working a scheme that is not possible.

If I define data like this:

data level1

   $01, ; gZoneID

   $01, ; gZoneGraphic

   $FF, ; gzoneSize1

   $04, ; gzoneSize1

   $01, ; gzoneNumberMin

   $03, ; gzoneNumberMax

   $01, ; gZoneEnemy1 = 

   $00,  ; gZoneEnemy2 = 0

   $00,  ; gZoneEnemy3 = 0

   $0D,  ; gZoneEnemyFreq1 = 0

   $00,  ; gZoneEnemyFreq2 = 0

   $00,  ; gZoneEnemyFreq3 = 0

   $1A,  ; gZonefuelFreq = 0

   $34,  ; gZoneShieldFreg = 0

   $68,  ; gZonemissileFreq = 0

   $00,  ; gZoneHasJet = 0

   $00  ; gZoneBombFreq

 

 

 

And define a set of variables like this:
 

dim gZoneGraphic = var53

 dim gZoneSize1 = var54

 dim gZoneSize2 = var55

 dim gZoneEnemy1 = var56

 dim gZoneEnemy2 = var57

 dim gZoneEnemy3 = var58

 dim gZoneEnemyFreq1 =var59

 dim gZoneEnemyFreq2 = var60

 dim gZoneEnemyFreq3 = var61

 dim gZonefuelFreq = var62

 dim gZonemissileFreq = var63

 dim gZoneShieldFreg = var64

 dim gZoneHasJet = var65

 dim gzoneNumberMin = var66

 dim gzoneNumberMax = var67

Can I then do something like this:

 

 if level = 1 then memcpy gZoneID level1 17

 

And have my level data magically set-up for me in the proper variables?

 

Is there a better way to do this?
All of this level data is in its own bank (6) with a single subroutine to fill-up the vars based on level

 

-Steve

 

 

 

Edited October 11, 2020 by fultonbot

[+SmittyB]

Yes that will work fine because the data you're copying and the locations you're copying to are in the same order and contiguous.

 

The approach of having a list of IF statements can optimised with a bit of assembly, but no need to bother about that unless you really want / need to.

[fultonbot]

13 minutes ago, SmittyB said:

Yes that will work fine because the data you're copying and the locations you're copying to are in the same order and contiguous.

 

The approach of having a list of IF statements can optimised with a bit of assembly, but no need to bother about that unless you really want / need to.

Good.  I'll start here and refactor when the IFs become annoying.

[fultonbot]

4 hours ago, SmittyB said:

Yes that will work fine because the data you're copying and the locations you're copying to are in the same order and contiguous.

 

The approach of having a list of IF statements can optimised with a bit of assembly, but no need to bother about that unless you really want / need to.

 

[fultonbot]

It looks like each piece of data in that table is taking 2 bytes.   Is that how it works?

 

[edit]

 

So it definitely looks like, even though I seem to have define the data as one byte each, when I use memcpy it uses up 2 bytes for each.

 

For example, this data:

 

data gZone1

   $01, ; gZoneGraphic

   $01, ; gZoneGraphicSplit

   $FF, ; gZoneSize1

   $04, ; gZoneSize2

 

Need to be addressed like this:

 dim gZoneStart = $23EC

  dim gZoneGraphic = $23EC

  dim gZoneGraphicSplit = $23EE ; this means the sides have different GFX

  dim gZoneSize1 = $23F0

  dim gZoneSize2 = $23F2

 

With a byte between each variable.

 

Is this the way it's supposed to work?

Is there a way to define data as a single byte?

 

-Steve

Edited October 12, 2020 by fultonbot

[fultonbot]

Okay, I think I figured it out.
I have to define the data like this:

data gZone1 

   $01,$01,$FF,$04,$01,$00,$00,$0D,$00,$00,$1A,$34,$68,$00,$00,$01,$03

end

With no CRLF and then it doesn't add the extra byte.

 

 

[+Andrew Davie]

Not familar with this environment at all, but could it be the trailing comma on the first version (on each line) is interpreted as having a 0-byte added?

 

[fultonbot]

31 minutes ago, Andrew Davie said:

Not familar with this environment at all, but could it be the trailing comma on the first version (on each line) is interpreted as having a 0-byte added?

 

 

It was not the comma...it was the hard CRLF.  I used a soft CR+[Shift] at the end of each line, and it works.  
I think I'm going to go with packed on a single line, else I will forget and then spend hours debugging it before I realize the issue is the the data itself.

[+Andrew Davie]

24 minutes ago, fultonbot said:

 

It was not the comma...it was the hard CRLF.  I used a soft CR+[Shift] at the end of each line, and it works.  
I think I'm going to go with packed on a single line, else I will forget and then spend hours debugging it before I realize the issue is the the data itself.

OK, noted.

But just to confirm, you absolutely definitely tried it without the commas?

 

[fultonbot]

5 hours ago, Andrew Davie said:

OK, noted.

But just to confirm, you absolutely definitely tried it without the commas?

 

oh no I didn't...wait...
#*&!
Yes, you are right, it totally works without any commas at all. 
 

data gZone1 

   $01 ; 1-gZoneGraphic

   $01 ; 2-gZoneGraphicSplit

   $FF ; 3-gZoneSize1

   $04 ; 4-gZoneSize2

   $01 ; 5-gZoneEnemy1 

   $00 ; 6-gZoneEnemy2

   $00 ; 7-gZoneEnemy3 

[+Andrew Davie]

22 minutes ago, fultonbot said:

oh no I didn't...wait...
#*&!
Yes, you are right, it totally works without any commas at all. 
 

data gZone1 

   $01 ; 1-gZoneGraphic

   $01 ; 2-gZoneGraphicSplit

   $FF ; 3-gZoneSize1

   $04 ; 4-gZoneSize2

   $01 ; 5-gZoneEnemy1 

   $00 ; 6-gZoneEnemy2

   $00 ; 7-gZoneEnemy3 

 

I was persistent because I didn't want possibly incorrect information to mislead others on the forum with similar problems.

Thank you for going back and checking.

 

[fultonbot]

39 minutes ago, Andrew Davie said:

 

I was persistent because I didn't want possibly incorrect information to mislead others on the forum with similar problems.

Thank you for going back and checking.

 

Of course!
Great, yeah, thanks so much!

Edited October 12, 2020 by fultonbot

[RevEng]

Great catch, Andrew! ?

 

bB and 7800basic both have a remove_trailing_commas() function that gets called to work around the dasm trailing comma behaviour, but apparently the ";" comments in the source interfere with the work-around. I'll need to look into that.

[fultonbot]

6 minutes ago, RevEng said:

Great catch, Andrew! ?

 

bB and 7800basic both have a remove_trailing_commas() function that gets called to work around the dasm trailing comma behaviour, but apparently the ";" comments in the source interfere with the work-around. I'll need to look into that.

Okay.  I Kinda need those comments or I will never remember what each property represents!
If you look above, it worked with soft carriage return [shift]+[enter], but not a hard-carriage-return [enter]
Not sure if that helps or not.

 

[RevEng]

Well, it's more data for me as I figure out the work-around, so it can only help. ?

[SlidellMan]

I think I could learn something about programming levels from you, Fulton.

[fultonbot]

1 hour ago, SlidellMan said:

I think I could learn something about programming levels from you, Fulton.

It's all about "levers".   Back in the 2000's  I hired Rob Fulop (Demon Attack) to come to Mattel and hold a class on game design for our web-game team. (I also hired both Chris Crawford and Bill Kunkel for other classes) He was full of good advice, but the best piece was about "levers" for levels.  Basically creating enough variables that you can set for various possibilities.  Each "level" is simply a set of "lever" data that is loaded by engine and to operate on.   It might seem "obvious" now, but back then it was quite an eye opening idea for me.   I think this advice works well for the type of golden-age, single screen games I like to make,  but I think an expanded version could be used for anything.

-Steve

Edited October 12, 2020 by fultonbot

[SlidellMan]

Wow, you got to team up with legendary programmers? I have to say that you chose wisely to hire them.

[+Muddyfunster]

2 hours ago, fultonbot said:

It's all about "levers".   Back in the 2000's  I hired Rob Fulop (Demon Attack) to come to Mattel and hold a class on game design for our web-game team. (I also hired both Chris Crawford and Bill Kunkel for other classes) He was full of good advice, but the best piece was about "levers" for levels.  Basically creating enough variables that you can set for various possibilities.  Each "level" is simply a set of "lever" data that is loaded by engine and to operate on.   It might seem "obvious" now, but back then it was quite an eye opening idea for me.   I think this advice works well for the type of golden-age, single screen games I like to make,  but I think an expanded version could be used for anything.

-Steve

That's a great analogy and is pretty much where my own evolution led starting with Tyre Trax, Dare Devil and onwards to the 7800, where, with more resources, you can have more levers and complexity  

[fultonbot]

4 hours ago, Muddyfunster said:

That's a great analogy and is pretty much where my own evolution led starting with Tyre Trax, Dare Devil and onwards to the 7800, where, with more resources, you can have more levers and complexity  

Yeah, I'm really enjoying it.  Getting comfortable with bank-switching, data, 12-color sprites, helps a lot too.   I'm feel like I'm getting close to where the technology fades away and it becomes canvas I can use to my heart's content.  So many game ideas brewing, but I need to finish one first before I move on.