Jump to content
IGNORED

Fluid simulation for new 2600 game concept


8bitPoet
 Share

Recommended Posts

26 minutes ago, ZackAttack said:

You don't have to line up the color change if you draw the bed posts with COLUBK and change COLUPF inside the bedpost. That means carpet and bed are PF and bedposts are background. Then you have a few cycles where the color change can happen without visual artifacts.

In coding my mockup screen, and trying to make it perfect, I've already tried this.  That's why I commented on it.  And because of the 4 vs. 3 timing issue, on one side or the other the color change will not match up.  It will occur mid-PF-pixel.  It's not a deal-breaker, and it doesn't make the game impossible to create, it just looks a bit glitchy.  Using the missiles as masks is one possible way to cover the mis-colored area.

 

I just strive for perfection, LOL.  And sometimes hardware limitations get in the way... 

  • Like 1
Link to comment
Share on other sites

Here's specifically what I was trying to do.  Change the COLUBK from DkBrown to LtGreen and back to DkBrown mid-scanline.  Shown at the white arrows.  And it's not possible to get the change to line up perfectly with the PF pixels, sigh...  I'm only trying to help here, you know.

 

 

Untitled.gif

 

To be clear, this is a mockup of my mockup in Stella, LOL.  What is shown in the screen is not actually possible, I altered it in "Paint." 

Edited by glurk
  • Like 2
Link to comment
Share on other sites

1 hour ago, glurk said:

Here's specifically what I was trying to do.  Change the COLUBK from DkBrown to LtGreen and back to DkBrown mid-scanline.  Shown at the white arrows.  And it's not possible to get the change to line up perfectly with the PF pixels, sigh...  I'm only trying to help here, you know.

 

Thinking outside the box a bit:

 

At the left, if you can always guarantee that the first green pixel shown after the bedpost is the opposite (one is BK and other is PF),

   then you don't have to worry about being perfect with your color change,

   as long as it happens before the second green pixel is drawn

   AND that your switching the color that was used as the bed post. 

 

It takes careful planning of the graphics data and kernel code, but I think it's doable.

 

  • Like 1
Link to comment
Share on other sites

6 hours ago, glurk said:

Here's specifically what I was trying to do.  Change the COLUBK from DkBrown to LtGreen and back to DkBrown mid-scanline.  Shown at the white arrows.  And it's not possible to get the change to line up perfectly with the PF pixels, sigh...  I'm only trying to help here, you know.

Ah, you're right. I totally forgot that there are two colors per line in the mattress region. Sorry about that.

 

To keep things simple, let's draw carpet, bedpost, and sheet with COLUBK and mattress with PF. We can make the bedposts 12 pixels wide and align them with the PF. I tested this out in Gopher2600 with the hmove triggered every line to mask the left 8 pixels. Level 1 is a little asymmetric, but I think it's an acceptable compromise in order to keep things moving along. It should also be much less noticeable in the final render.

 

Here's a screenshot. Difficulty levels are represented by each respective third of the screen. Bedposts are in brown, carpet in pink, sheets change color twice per third and triangles are the mattress. Diagonal line made of PF is just for reference.

 

image.thumb.png.9e6b8d5637ae17f3eb995272069afb04.png

  • Like 2
Link to comment
Share on other sites

11 hours ago, ZackAttack said:

This is what the score could look like if we put it all on one line. The lives remaining can either be as it is or replace it with 1-3 sprites when the total lives are 3 or less.

image.thumb.png.9df2cf0cfb7489453aec3e9738a70fb6.png

@ZackAttack This is incredible! I think having the Lives represented as icons helps the player not confuse the additional number as part of the score. So we would probably only have a max of 3 lives for each player.

Link to comment
Share on other sites

Thought I'd drop a quick update for anyone interested.

 

@ZackAttack and I have been juggling between this project and Octopusher, making incremental progress on each.

 

In an effort to manage and communicate the details of this game, I've started a Game Design Document in Notion. I couldn't find a template for this specific genre, so I'm making it up as I go. You can view the document here: https://www.notion.so/8bitpoet/Waterbed-Bouncers-52947ad9f90146d195ffe7ffb8854a86 and let me know what you think. I'd love to get some feedback from a developer's perspective. What else could I include and/or elaborate on, to make this more useful?

 

P.S. We're still hoping that another C programmer will join the team! We have cookies! :)

Edited by 8bitPoet
  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...
On 1/9/2023 at 10:08 PM, 8bitPoet said:

Wave-loop.thumb.gif.cf2523c0a739466641c7a9ce668ed6e2.gif

 

The most critical part of this game will be the wavy waterbed mattress.

 

6 frames is all that's needed to animate the wave motion of the mattress.

 

This is how I was thinking we could avoid all the complexity of trying to use math to generate the wave. Instead, we could loop the 6 frames back and forth.

I'm guessing that the source code would contain the data for each frame, but I'm out of my depth here.

 

The other hurdle is that the mattress playfield shifts horizontally to align the trough of the wave with the landing player sprite. See figures below.

shifting-playfield-fig1.thumb.jpg.e7a74d7c523404887f882b78d77475de.jpgshifting-playfield-fig2.thumb.jpg.ab82d67fc5f2e294bce1d210696d8c44.jpg

 

 

Cool concept design! 

The SuperCharger BASIC kit could be used to model it or create a version directly with blockier resolution:

Figure2_VirtualWorld.jpg.a7ea0bfb88f32ee307d0142ce27a3b46.jpg

 

You could fit all six slides into the virtual world and pan the playfield camera between the six frames or even between them to animate the waves at variable speeds up to 60x a second.

 

In this Silly Venture example FluidCity the playfield camera is panned pixel by pixel at 30 FPS and 60 FPS. 

 

You only get one color per row of playfield pixels and sprites pixels and you can draw the sprites and the frames on the virtual world using ASCII art.

 

  • Like 1
Link to comment
Share on other sites

On 2/4/2023 at 9:00 AM, Mr SQL said:

In this Silly Venture example FluidCity the playfield camera is panned pixel by pixel at 30 FPS and 60 FPS.

That's pretty cool!

 

Thanks for sharing that. I haven't worked out how the mattress motion would be implemented, yet. The ceiling fan blades and mattress are both part of the playfield. The extra tricky part is that the fan uses 7 frames of animation and the mattress uses 6. So the playfield has to be updated halfway down the screen. And the extra extra tricky part is that the horizontal position of the waves is determined by the position of the player landing on it.

Link to comment
Share on other sites

18 hours ago, 8bitPoet said:

That's pretty cool!

 

Thanks for sharing that. I haven't worked out how the mattress motion would be implemented, yet. The ceiling fan blades and mattress are both part of the playfield. The extra tricky part is that the fan uses 7 frames of animation and the mattress uses 6. So the playfield has to be updated halfway down the screen. And the extra extra tricky part is that the horizontal position of the waves is determined by the position of the player landing on it.

Thank you! 

 

You have different physics for different zones on the screen.

 

There is a Display List Demo here illustrating splitting the screen into multiple zones that may be helpful with your design.

 

Link to comment
Share on other sites

25 minutes ago, Mr SQL said:

There is a Display List Demo here illustrating splitting the screen into multiple zones that may be helpful with your design.

Very cool! Three zones, each animating in different directions! Is there a minimum increment limit to the horizontal animation or can it be finely controlled to shift a pixel at a time? Also, is it required to skip scanlines?

Link to comment
Share on other sites

2 hours ago, 8bitPoet said:

Very cool! Three zones, each animating in different directions! Is there a minimum increment limit to the horizontal animation or can it be finely controlled to shift a pixel at a time? Also, is it required to skip scanlines?

Thanks! Great questions.

 

There is no minimum increment limit to the horizontal animation, it can be finely controlled.

 

The Display list calls to create those zones can be placed in either vertical blank and each DL call creates a camera zone two or three pixels high sourced from anywhere in the large virtual world bitmap.

 

architecture.jpg.b8a2c5080c8c201adc4deb9dc28b720b.jpg

 

The zones may also be combined into larger zones.

 

In that demo the top zone is 5 pixels high so it needed two display list calls to construct it, one in the top and one in the bottom vertical blank so that the display is contiguous and the two zones will stay aligned as one large zone.

 

The middle zone is three pixels high and the bottom zone two pixels high so they use one display list call each.

 

The scanlines are skipped to obtain extra processing time during the blank scanlines.

 

 

  • Like 1
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...
 Share

  • Recently Browsing   0 members

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