Jump to content
IGNORED

The hamburger experiment


Recommended Posts

  • 8 months later...
15 hours ago, atari2600land said:

I would like to finish this up. But would anyone care if I continue to work on it? Pick up where I left off?

 

 

If you are asking if someone has interest in you finishing the game, yes, by all means, I invite you to complete it.  I would be interested in seeing it completed, as I have always enjoyed your other quirky games.

 

If you are asking if someone has any interest in completing the game for you, then I would expect you may not find many takers, if any at all.

 

I suppose that anyone who has an interest in making a game, is busy with their own projects to take on someone else’s.

 

If you are bored with this one and are looking to start a new, fun project, I’m sure that many here will completely sympathize with that sentiment, and nobody would reproach you for pursuing other projects.

 

    dZ.

Edited by DZ-Jay
Link to comment
Share on other sites

OK, I'll keep working on this game. I need a suggestion for level 9. Level 10 will be the Calorie Castle. Here's what I have so far in terms of levels.

1. meadow

2. mountains

3. sea

4. desert

5. moon

6. caves

7. suburbs

...and I just worked on putting in level 8: Fattening Forest. I still need to compose a short background song for it, but I worked a whole bunch on it last night.

633223999_fatteningforest.gif.45c5bf86bb426ba1ba7da26bcd8ee9da.gif

I think I'll change the level number to lives number (the 8 indicating it's level 8.)

  • Like 1
Link to comment
Share on other sites

I thought even though level 3 was the sea, I'd make level 9 be the beach. This I think will end up with the same levels as the NES verion, but with the levels scrambled around (and of course looking different.)

shot0038.gif.1d396029b95552b195ac84af440f9fff.gif

The waves of the ocean actually move down. I changed the lettuce head so it looks more sinister. And I changed the level number in game to lives instead, which I think is more important than what level # you're on.

 

Question: I tried making a cloud in level 1 but I had to move it down a lot because if I put it up more it would flicker a bunch and I'm wondering why. Probably something I'm doing wrong.

Link to comment
Share on other sites

On 2/3/2023 at 8:45 PM, atari2600land said:

I thought even though level 3 was the sea, I'd make level 9 be the beach. This I think will end up with the same levels as the NES verion, but with the levels scrambled around (and of course looking different.)

shot0038.gif.1d396029b95552b195ac84af440f9fff.gif

The waves of the ocean actually move down. I changed the lettuce head so it looks more sinister. And I changed the level number in game to lives instead, which I think is more important than what level # you're on.

 

To me, the lives count is only important when you lose one.  It offers no practical information while playing the level.

 

I would imaging the level number would be the same — it is not something I would look for while actively playing, although it does provide a measure of progress, which in itself can be a motivator to continue playing.

 

Personally, I would include both, but if not possible, find a way to remind the player of the one which is not shown all the time.

 

On 2/3/2023 at 8:45 PM, atari2600land said:

Question: I tried making a cloud in level 1 but I had to move it down a lot because if I put it up more it would flicker a bunch and I'm wondering why. Probably something I'm doing wrong.


It is definitely something you are doing wrong, otherwise it would happen on every game. ;)

 

Could you post a video of the flicker, or provide a more detailed description?

 

If it only happens at the top rows, it is probably something to do with the timing of the BACKTAB drawing or Sprite updates.

 

The short of it is that, the BACKTAB is drawn one row at a time, from top to bottom, and this process starts shortly after the VBLANK interrupt.  So, if you wait too long after the WAIT statement to draw a BACKTAB card, you may miss the rendering of the row for the current frame.

 

Obviously, this affects the top rows more because they are processed sooner than the lower ones.

 

    dZ.

Edited by DZ-Jay
Link to comment
Share on other sites

On 2/3/2023 at 5:48 PM, atari2600land said:

OK, I'll keep working on this game. I need a suggestion for level 9. Level 10 will be the Calorie Castle. Here's what I have so far in terms of levels.

1. meadow

2. mountains

3. sea

4. desert

5. moon

6. caves

7. suburbs

...and I just worked on putting in level 8: Fattening Forest. I still need to compose a short background song for it, but I worked a whole bunch on it last night.

633223999_fatteningforest.gif.45c5bf86bb426ba1ba7da26bcd8ee9da.gif

I think I'll change the level number to lives number (the 8 indicating it's level 8.)


All that aside, the bigger question on everyone’s mind is, are the Hamburgers still on their way to Switzerland? ;)

 

    dZ.

Link to comment
Share on other sites

Here's what happens when I put it the cloud's position at 59. In order to stop it from doing this, I have to put it at 139.

wrongcloud.gif.0d94da2a19b2e3c45dd018993416f912.gif

I guess I'll get rid of the lives number so I can use it for something else. Perhaps I'll add some sesame seeds on top of the burger. The castle will be at the end, after they go through there, the game will end.

Link to comment
Share on other sites

On 2/6/2023 at 7:45 PM, atari2600land said:

Here's what happens when I put it the cloud's position at 59. In order to stop it from doing this, I have to put it at 139.

wrongcloud.gif.0d94da2a19b2e3c45dd018993416f912.gif

I guess I'll get rid of the lives number so I can use it for something else. Perhaps I'll add some sesame seeds on top of the burger. The castle will be at the end, after they go through there, the game will end.


Well, there is something really weird with the coordinates of that cloud sprite.

 

How are you updating its position?  It seems that compensating for scrolling is not done consistently on every frame.

 

I suppose that the problem is reverse:  the position is updated wrongly, but it just so happens that if you move it a lower row, it is not manifested due to a timing issue.

 

I suggest you take a look at the code that is adjusting the horizontal position, and track down anything that may be changing it in order to counter the scrolling.

 

    dZ.

 

P.S.  I seem to recall you mentioning a similar issue in an earlier level.

Edited by DZ-Jay
Link to comment
Share on other sites

2 minutes ago, atari2600land said:

It's not a sprite, but a tile.

 

Aha!  I thought as much, but wasn't sure.  Then it is precisely what I suggested first:  On certain frames, the update probably comes too late after the WAIT, and misses the STIC building its buffer for that row.

 

This is why it actually works correctly when you move it down:  you get more time before the STIC processes that row.

 

You should make sure that updating the BACKTAB cards occurs right after updating sprites, as close to the WAIT statement as possible.

 

     -dZ.

Link to comment
Share on other sites

7 minutes ago, atari2600land said:

I put the SPRITE commands close together. I put the scrolling function (where the tiles are printed) close to that. It still won't work. What am I doing wrong?

 

herts41.bas 45.89 kB · 0 downloads

 

I'll take a look.  The SPRITE and SCROLL functions are expensive, so that could be affecting it.  I also will check the post-scroll adjustment.

 

    -dZ.

Link to comment
Share on other sites

I'm looking at the code now, but I wanted to point out two errors:

Error: GOTO FINISH_OUT_LEVEL from procedure EXPLOSION flows inside main code (stack disruption)
Error: GOTO FINISH_OUT_LEVEL from procedure LEVEL_BOSS flows inside main code (stack disruption)

 

Procedures "explosion" and "level_boss" include a GOTO out of the procedure into label "finish_out_level."  This is a problem, because if the GOTO is reached, the "return" of the procedure is never executed.  This will slowly build up the stack and lead to a potential stack overflow.

 

You should never use GOTO to exit a PROCEDURE, only RETURN (or END, which implies the RETURN).

 

Anyway, that is not your cloud problem, but it is a potential problem with your program.

 

By the way, can you point me in the direction of the variables that handle the state of that cloud?

 

      -dZ.

  • Like 2
Link to comment
Share on other sites

OK. The whole cloud movement begins at the scrolling procedure at the end of the program. The variables are bgitemx (which is used to put the cloud on the screen), and bgitem (a timer used to count down when to remove the cloud from the screen and put it on the right side again.)

 

Thanks for warning me about the stack problem, I'll try to fix it once the cloud program is fixed.

Link to comment
Share on other sites

3 minutes ago, carlsson said:

If "finish out level" itself is a procedure that exits as expected, it might be less of a problem, though I suppose "inside main code" is a hint that is not the case.

 

It is not.  There are a ton of free-floating labels and very few procedures.  I suppose, "finish_out_level" could be turned into a procedure, since it seems to contain some common code used throughout.  I tried to followed some of the spaghetti to see if it ended up on a PROCEDURE at some point, but at least for one of them, it did not.

 

Is there a way to prevent the compiler from failing on this error?  I seem to recall that there was an "OPTION" argument for it, but I can't remember what it was.

 

 

1 minute ago, atari2600land said:

OK. The whole cloud movement begins at the scrolling procedure at the end of the program. The variables are bgitemx (which is used to put the cloud on the screen), and bgitem (a timer used to count down when to remove the cloud from the screen and put it on the right side again.)

 

Thanks for warning me about the stack problem, I'll try to fix it once the cloud program is fixed.

 

Thanks, I was on the right track, but the rest of the context you provided helps.  I'll look into it.

 

    -dZ.

Link to comment
Share on other sites

On 2/9/2023 at 3:02 PM, atari2600land said:

OK. The whole cloud movement begins at the scrolling procedure at the end of the program. The variables are bgitemx (which is used to put the cloud on the screen), and bgitem (a timer used to count down when to remove the cloud from the screen and put it on the right side again.)

 

Thanks for warning me about the stack problem, I'll try to fix it once the cloud program is fixed.

 

Well, the strange thing is that my version of the compiler will not let me compile with those GOTOs.  This was introduced in 1.4.0 (January 2019), so you are probably using an earlier version.

 

If I comment the two GOTOs, I can build the project, but when I run it ... it's flicker city!  I am not sure if this is what you see, but everything flickers -- not just the cloud, but the score, the sprites, everything.

 

    dZ.

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