Jump to content
IGNORED

7800Basic Trouble...


ZippyRedPlumber

Recommended Posts

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

Link to comment
Share on other sites

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.

 

 

 

  • Like 3
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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 by Ecernosoft
Link to comment
Share on other sites

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

 

 

 

Link to comment
Share on other sites

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

  • Like 4
Link to comment
Share on other sites

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

  • Confused 1
Link to comment
Share on other sites

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

 

 

  • Like 4
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 5
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...