7800Basic Trouble...

[ZippyRedPlumber]

I've done of bit of code for the 7800 adaptation of my Lyra game;

Atari Dev Studio is giving my lip by stating the following;

Quote

libpng warning: Incorrect bKGD chunk length

libpng warning: Incorrect bKGD chunk length

libpng warning: Incorrect bKGD chunk length

*** (10): WARNING, image contains more unique colors than 160A allows

*** (18): WARNING, image contains more unique colors than 160B allows

*** (19): WARNING, image contains more unique colors than 160B allows

*** (20): WARNING, image contains more unique colors than 160B allows

*** (21): WARNING, image contains more unique colors than 160B allows

 

*** (): INFO, GFX Block #0 starts @ $E000

        tileset_ramchars walk_left_1 walk_left_2 walk_right_1

        walk_right_2

*** (): INFO, GFX block #0 has 3712 bytes left (232 x 16 bytes)

 

7800basic compilation complete.

 

User-defined 7800.asm found in current directory

 

--- Unresolved Symbol List

tileset_ramchars_color1  0000 ????         (R )

tileset_ramchars_color2  0000 ????         (R )

walk_right_1_color1      0000 ????         (R )

tileset_ramchars_color3  0000 ????         (R )

walk_right_1_color2      0000 ????         (R )

walk_right_1_color3      0000 ????         (R )

 

   stack allowance: 30 nested subroutines.

   the canary is situated at: $1c1

   39467 bytes of ROM space left in the main area.

     $1880 to $1fff used as zone memory, allowing 31 display objects per zone.

     2500 bytes left in the 7800basic reserved area.

 

Fatal assembly error: Source is not resolvable.

 

Cartridge size not a multiple of 4K bytes!

 

7800header 0.15 Jul 29 2022 10:37:28

*** WARNING: The file size of c:\7800basic-0.19-win-x64\7800basic\samples\ramcharmap\rumchurjamp.bas.bin isn't correct.

 

  opened parameter file a78info.cfg

 

  The ROM 'c:\7800basic-0.19-win-x64\7800basic\samples\ramcharmap\rumchurjamp.bas.bin' is compatible with CC2.

 

7800makecc2 v0.1

 

Exit code: 1

 

Cleaning up files generated during compilation...

What am I doing wrong? Please help me!

rumchurjamp.bas graphics.zip

[+Muddyfunster]

From the errors, it looks like you have too many colours in your images.

 

I opened up your graphics files and while they are .png, they are not indexed.

 

7800basic needs graphics files to be correctly indexed. For 160A you need to set your index to a max of 4 (3 colours + transparent). I would suggest using something like GiMP as it makes setting the index for the png file quite easy. (Image>Mode>Index)

 

You also need to define your 160A graphics correctly. Right now you are defining them as 160B.

 

 

incgraphic gfx/walk_left_1.png 160B
incgraphic gfx/walk_left_2.png 160B
incgraphic gfx/walk_right_1.png 160B
incgraphic gfx/walk_right_2.png 160B

 

change to :

incgraphic gfx/walk_left_1.png 160A 0 1 2 3
incgraphic gfx/walk_left_2.png 160A 0 1 2 3
incgraphic gfx/walk_right_1.png 160A 0 1 2 3
incgraphic gfx/walk_right_2.png 160A 0 1 2 3

 

The "0 1 2 3" are the index entries. Adding this, allows you to adjust the colours on the graphics without having to mess about with your palettes.

 

Get something displaying then we can address that if needed

 

Hope that helps.

 

 

 

[Ecernosoft]

9 hours ago, ZippyRedPlumber said:

I've done of bit of code for the 7800 adaptation of my Lyra game;

Atari Dev Studio is giving my lip by stating the following;

What am I doing wrong? Please help me!

rumchurjamp.bas 4.98 kB · 2 downloads graphics.zip 3.79 kB · 2 downloads

Too many colors in 160A

[+Muddyfunster]

18 minutes ago, Ecernosoft said:

Too many colors in 160A

Incorrect.

 

Per my explanation above, the graphics files only have 3 colours + transparency, which is fine for 160A. The issue is the files are not indexed correctly so the compiler reads them as having more colours.

 

Indexing the files correctly and referencing them correctly as 160A should fix the issue.

[ZippyRedPlumber]

It worked! Now to get the colors & collision right. Right now, Lyra's a janky white outline that's not even touching the playfield.

It feels like an ancient puzzle arranging the colors...

rumchurjamp.bas.a78

[Ecernosoft]

On 9/30/2022 at 7:09 AM, Muddyfunster said:

Incorrect.

 

Per my explanation above, the graphics files only have 3 colours + transparency, which is fine for 160A. The issue is the files are not indexed correctly so the compiler reads them as having more colours.

 

Indexing the files correctly and referencing them correctly as 160A should fix the issue.

Oh, ok.

 

And I was only making an educated guess, as I've never programmed in 7800basic before. The problem stated here is one of the reasons.

[saxmeister]

@ZippyRedPlumber are you using the boxcollision routines built into 7800basic or doing your own detection?

 

If your character isn't exactly a square/box then you may need to write your own detection routine based on the pixels in your artwork.

[Ecernosoft]

On 10/1/2022 at 4:59 PM, saxmeister said:

@ZippyRedPlumber are you using the boxcollision routines built into 7800basic or doing your own detection?

 

If your character isn't exactly a square/box then you may need to write your own detection routine based on the pixels in your artwork.

Or you can just treat your character as a box!

[Ecernosoft]

On 10/1/2022 at 1:23 AM, ZippyRedPlumber said:

It worked! Now to get the colors & collision right. Right now, Lyra's a janky white outline that's not even touching the playfield.

It feels like an ancient puzzle arranging the colors...

rumchurjamp.bas.a78 48.13 kB · 5 downloads

@ZippyRedPlumber Are you making a platformer of some sort?

[ZippyRedPlumber]

5 hours ago, Ecernosoft said:

@ZippyRedPlumber Are you making a platformer of some sort?

Yep :3

[Ecernosoft]

5 hours ago, ZippyRedPlumber said:

Yep :3

*goes insane since he loves platformers*

[ZippyRedPlumber]

Well got the palette fixed & some part of collision fixed as well, but a lot of the platforms are still janky anyone know how to fix this?

rumchurjump.bas.a78 rumchurjump.bas.bin rumchurjump.bas

[Ecernosoft]

21 minutes ago, ZippyRedPlumber said:

Well got the palette fixed & some part of collision fixed as well, but a lot of the platforms are still janky anyone know how to fix this?

rumchurjump.bas.a78 48.13 kB · 0 downloads rumchurjump.bas.bin 48 kB · 0 downloads rumchurjump.bas 4.04 kB · 0 downloads

@ZippyRedPlumberI can!

But I require two things:

1. That you can code in ASM (Or know how to insert ASM into your program)

2. Where in memory your tilemap is located

 

 

Edit: I can just make you a subroutine that checks for collision and you can use that.

Edited October 4, 2022 by Ecernosoft

[Ecernosoft]

Also, I see what is wrong. In tiles, add 6 to the XPOS to get where you are standing on. (You need to acomidate for scrolling!)

Edited October 4, 2022 by Ecernosoft

[+Muddyfunster]

1 hour ago, ZippyRedPlumber said:

Well got the palette fixed & some part of collision fixed as well, but a lot of the platforms are still janky anyone know how to fix this?

rumchurjump.bas.a78 48.13 kB · 3 downloads rumchurjump.bas.bin 48 kB · 0 downloads rumchurjump.bas 4.04 kB · 1 download

You need to include your entire project folder or I can't test any changes to the code to help you (I'm missing your latest gfx for example).

 

 

 

[ZippyRedPlumber]

2 hours ago, Muddyfunster said:

You need to include your entire project folder or I can't test any changes to the code to help you (I'm missing your latest gfx for example).

 

 

 

Here's the new gfx folder, help me fix this please.

graphics.zip

[+Muddyfunster]

12 hours ago, Ecernosoft said:

Also, I see what is wrong. In tiles, add 6 to the XPOS to get where you are standing on. (You need to acomidate for scrolling!)

There isn't any scrolling in this code so I'm not sure why he needs to increase the XPOS by 6. That would be incorrect.

 

The fact that the OP has a question in 7800Basic should probably tell you that offering help in ASM isn't going to actually help much.  

 

9 hours ago, ZippyRedPlumber said:

Here's the new gfx folder, help me fix this please.

graphics.zip 9.02 kB · 0 downloads

 

In your program, there is some code that looks underneath your character sprite to read a value from RAM based on where your sprite is. It's basically taking a look and saying "is the block underneath me a platform, a spike or is it sky".

 

It does this using the peekchar command :

 

herochar=peekchar(screendata,mytemp1,mytemp2,20,12)

 

herochar is the value of the tile that is being returned. (in your dim section there is a variable "screendata" at location $2200 = that's where it's looking).

 

So why is it not working? well the short version is when your sprite hits the platform, it's not reading it as a platform, it's reading it as a spike.

 

if herochar=6 then heroy=heroy-55

 

If the tile under your sprite returns a value of "6" when you land on the platform, your character then jumps up 55 pixels. (the action for touching a spike in the original example). If you comment it out, it works.

 

If you add spikes or other hazards in later and choose to check them this way, you will need to alter your code appropriately to accommodate them. If you change the graphics in the example, you may also need to update the references. Each tile has a number, the example has 6 as the spike, yours might be something else.

 

There are a bunch of "if herochar" in the program, that's the code that's checking for those conditions and then doing stuff.

 

Also, I think a couple of comments are back to front in the original example and your temp1 value to get the the x coordinate was looking in the wrong place so the wrong tiles got painted.

 

mytemp1=(herox+8)/16 : rem 16 is our zoneheight
mytemp2=heroy/16 : rem 8 is 160A character width, but x2 for doublewide


should read : 

mytemp1=(herox+4)/8 : rem 8 is 160A character width, but x2 for doublewide
mytemp2=heroy/16 : rem 16 is our zoneheight 

 

 

As you are in zoneheight 16, you need to adjust any checks based on the number of vertical zones. for zoneheight 16 you will usually have 12 zones instead of 24.

 

Based on that, this bit of code needs to be changed :

 

 if mytemp1>19 || mytemp2>23 then goto falling

 

mytemp2 is checking the vertical zone number  (your sprite's Y location / 16)

 

As we noted, in zoneheight 16 you only have 12 zones (0-11), so probably change ">23" to ">11".

 

Finally, the sprite plotting: In the example it plots a "top" sprite and a "bottom" sprite. I don't think your code needs that so the underlying code wont work properly. You also have 2 frames for each direction instead of 4 so again you are getting blank frames as the code is looking for a frame that doesn't exist.

 

For now I've tidied that up so you get 1 frame for each dir. You can change that later to suit your needs.

 

I've attached a revised file.

 

 

 

 

 

rumchurjump_edited.bas

[Ecernosoft]

7 hours ago, Muddyfunster said:

There isn't any scrolling in this code so I'm not sure why he needs to increase the XPOS by 6. That would be incorrect.

 

The fact that the OP has a question in 7800Basic should probably tell you that offering help in ASM isn't going to actually help much.  

 

 

In your program, there is some code that looks underneath your character sprite to read a value from RAM based on where your sprite is. It's basically taking a look and saying "is the block underneath me a platform, a spike or is it sky".

 

It does this using the peekchar command :

 

herochar=peekchar(screendata,mytemp1,mytemp2,20,12)

 

herochar is the value of the tile that is being returned. (in your dim section there is a variable "screendata" at location $2200 = that's where it's looking).

 

So why is it not working? well the short version is when your sprite hits the platform, it's not reading it as a platform, it's reading it as a spike.

 

if herochar=6 then heroy=heroy-55

 

If the tile under your sprite returns a value of "6" when you land on the platform, your character then jumps up 55 pixels. (the action for touching a spike in the original example). If you comment it out, it works.

 

If you add spikes or other hazards in later and choose to check them this way, you will need to alter your code appropriately to accommodate them. If you change the graphics in the example, you may also need to update the references. Each tile has a number, the example has 6 as the spike, yours might be something else.

 

There are a bunch of "if herochar" in the program, that's the code that's checking for those conditions and then doing stuff.

 

Also, I think a couple of comments are back to front in the original example and your temp1 value to get the the x coordinate was looking in the wrong place so the wrong tiles got painted.

 

mytemp1=(herox+8)/16 : rem 16 is our zoneheight
mytemp2=heroy/16 : rem 8 is 160A character width, but x2 for doublewide


should read : 

mytemp1=(herox+4)/8 : rem 8 is 160A character width, but x2 for doublewide
mytemp2=heroy/16 : rem 16 is our zoneheight 

 

 

As you are in zoneheight 16, you need to adjust any checks based on the number of vertical zones. for zoneheight 16 you will usually have 12 zones instead of 24.

 

Based on that, this bit of code needs to be changed :

 

 if mytemp1>19 || mytemp2>23 then goto falling

 

mytemp2 is checking the vertical zone number  (your sprite's Y location / 16)

 

As we noted, in zoneheight 16 you only have 12 zones (0-11), so probably change ">23" to ">11".

 

Finally, the sprite plotting: In the example it plots a "top" sprite and a "bottom" sprite. I don't think your code needs that so the underlying code wont work properly. You also have 2 frames for each direction instead of 4 so again you are getting blank frames as the code is looking for a frame that doesn't exist.

 

For now I've tidied that up so you get 1 frame for each dir. You can change that later to suit your needs.

 

I've attached a revised file.

 

 

 

 

 

rumchurjump_edited.bas 4.02 kB · 1 download

Is part of the reason you exist is to correct me? Lol

 

ok, yeah true. I’m saying when he checks for collision. But whatever, you’re idea works, I guess

[Traxx]

1 hour ago, Ecernosoft said:

Is part of the reason you exist is to correct me? Lol

He kinda has to for the Op's sake,you're suggesting things that are not even in his code.

[+Muddyfunster]

20 minutes ago, Ecernosoft said:

Is part of the reason you exist is to correct me? Lol

 

ok, yeah true. I’m saying when he checks for collision. But whatever, you’re idea works, I guess

Not at all and that's not how my comment is intended.

 

I'm really not trying to "police" you, but if you are giving someone wrong advice (based on their questions about 7800 Basic) then perhaps it's a good thing for someone to offer an alternative and say if it's wrong advice. This case the OP is working exclusively in 7800Basic, so ASM related answers aren't very helpful or relevent.

 

Someone else might come along in the future with a similar problem, searching for guidance and they would find those wrong answers are not much help.

 

If someone asked about ASM and I gave them a bad answer and you saw it, you would say something to correct it right? give a better answer that would be more useful? That's what the boards are for, to help each other. 👍

 

 

[Ecernosoft]

6 minutes ago, Traxx said:

He kinda has to for the Op's sake,you're suggesting things that are not even in his code.

Yeah….. true

[Ecernosoft]

1 minute ago, Muddyfunster said:

Not at all and that's not how my comment is intended.

 

I'm really not trying to "police" you, but if you are giving someone wrong advice (based on their questions about 7800 Basic) then perhaps it's a good thing for someone to offer an alternative and say if it's wrong advice. This case the OP is working exclusively in 7800Basic, so ASM related answers aren't very helpful or relevent.

 

Someone else might come along in the future with a similar problem searching for guidance and they would find those wrong answers are not much help.

 

If someone asked about ASM and I gave them a bad answer and you saw it, you would say something to correct it right? give a better answer that would be more useful? That's what the boards are for, to help. 👍

 

 

I was just joking….

yeah. Ok. Ok!

Im not too good w/ 7800basic and you know that @Muddyfunster.

also, I’m only making educated guesses here.

[+Karl G]

13 minutes ago, Ecernosoft said:

I was just joking….

yeah. Ok. Ok!

Im not too good w/ 7800basic and you know that @Muddyfunster.

also, I’m only making educated guesses here.

Not to pile on here, as I understand that your suggestions and advice come from a place of enthusiasm for the platform and a desire to help, but in general I would suggest not offering advice on the choices other devs have made for their projects (including e.g. language choice and video mode) unless explicitly requested. Devs are generally aware of their options and the trade-offs of their choices. I would save giving advice for when devs are specifically asking for help. In this case, if the question involves something you are not familiar with like 7800Basic, then it's probably better to wait for someone who knows the toolchain to answer the question instead of trying to make educated guesses.

[Ecernosoft]

Just now, Karl G said:

Not to pile on here, as I understand that your suggestions and advice come from a place of enthusiasm for the platform and a desire to help, but in general I would suggest not offering advice on the choices other devs have made for their projects (including e.g. language choice and video mode) unless explicitly requested. Devs are generally aware of their options and the trade-offs of their choices. I would save giving advice for when devs are specifically asking for help. In this case, if the question involves something you are not familiar with like 7800Basic, then it's probably better to wait for someone who knows the toolchain to answer the question instead of trying to make educated guesses.

Ok. Unless I 100% know for now on,I won’t suggest.

[ZippyRedPlumber]

It worked! Thanks @Muddyfunster

 

Now I want to make her jump here's my code sample;

Quote

jumping
  rem ** a simple no-physics jump routine
  heroy=heroy-1
  if heroy=heroy-55 then goto donejumping
donejumping

Is this right?