Triangle rasterization substitute.

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Triangle rasterization substitute.

Post by FrankenGraphics »

Also considering turning it into single direction scrolling with a very long map instead. I don't want to make *exactly* the same game.
I don't want to weigh in too much on your design choices, but it looked like you had a wind mechanic that complements the player avatar changing directions? But if you want to change that up, it's for example a pretty common setup to make levels two screens wide or tall, and "threadmill" the other direction wich is only 1 screen long. There's also the possibility to wrap let the "camera" wrap around the two-screen-wide field.

Oh, and since you probably have more than enough of prg-rom and chr-rom even with the simple CNROM and even more so with any mapper more generous than that, there's plenty of room to do something different and/or potentially larger than your first game, if you ever want to.
but there is a store a few blocks from my house that sells homebrew games.
Huh... i've never seen those titles before. and they're cheap. Wait, did you remove the picture? I didn't catch their names
Is the sprite 0 trick hard? You get an interrupt where you change the scroll position
Not hard, but a bit more limited and a bit more to think about than a proper irq. Sprite0 needs to have a solid pixel touching a solid pixel on the background. That makes it much easier to place the HUD/bar on the top because it will always remain still so you know where to score a sprite hit. Placing it at the bottom is trickier because you're not automatically guaranteed to get a sprite hit as the map moves around. Oh, and you must keep your status bar "out of sight" from the map scroll, naturally, but that goes for an irq split too. The last point is another thing that's in the favor of GTROM, since it can flick between 2 sets of 4 nametables, you can keep your status bar and other stuff in one set and the map/ in the other.
This is *way* more help than I was expecting to get.
It's a very friendly forum, but i think your illustrative example helped a lot.
User avatar
slembcke
Posts: 172
Joined: Fri Nov 24, 2017 2:40 pm
Location: Minnesota

Re: Triangle rasterization substitute.

Post by slembcke »

FrankenGraphics wrote:but it looked like you had a wind mechanic that complements the player avatar changing directions
Nah, it was hard coded in the original. It was a game jam game, so I never got far enough to make the wind into a mechanic.
FrankenGraphics wrote:Huh... i've never seen those titles before. and they're cheap. Wait, did you remove the picture? I didn't catch their names
Yeah... Posting that picture made me curious again and I started Googling the names. I think they might be pirate Japanese carts or something... I got weirded out and pulled the photo. I guess it's not my fault though... I made a another thread about that. viewtopic.php?f=5&t=16755
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Triangle rasterization substitute.

Post by FrankenGraphics »

slembcke wrote: Nah, it was hard coded in the original. It was a game jam game, so I never got far enough to make the wind into a mechanic.
Right, it's in the same direction all the time, but that's just aswell. What i mean is that (now that i played through it, i can say it with some confidence) that you've managed to put a lot of variation in terms of challenge and experience into one smallish map simply by the way the sail maneuvering + wind + direction works together, which comes easier when the boat can roam freely in all directions. I just wanted to comment on how good that felt. I found this combo of features better/more interesting than beforementioned "Solar Jetman" for the nes, which is a personal favourite.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Triangle rasterization substitute.

Post by Bregalad »

2) Use scanline interrputs [...] (Sounds hard)
3) Use CHR RAM and render into that. (Maybe hard? [...])
Is the sprite 0 trick hard?
Man, you're the first one here wondering if things are going to be hard. Most nesdev people are only interested to do things IF they are "hard".
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Triangle rasterization substitute.

Post by rainwarrior »

Bregalad wrote:I would definitely pre-render the ship at different angles. That's how Solar Jetman does it (it's a spaceship but the concept is the exact same), and it's a great NES game. Also with flipping you can reuse many angles, so you only have to pre-render angles between 0° and 90° and the rest is obtained by flipping existing frames. So with something like 5 or 6 angles you're done, there's really no need to do anything more complex.
I also think this is very sensible.

A 24x24 boat and a 16x16 sail maybe? That's only 13 tiles per angle. You could fit all this in ~1k of CHR, there's really no need for CHR-RAM or banking?
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Triangle rasterization substitute.

Post by FrankenGraphics »

Yeah it's easier with a smaller boat. I was under the impression it would be rather big because of the pico 8 proportions (like 4 tiles wide when facing east/west, so more or less a grid of 4x4 tiles, 3x3 for sails) but a smaller boat would additionally help towards the sprite limit per scanline if the foam trail is to be ported and be sprite based to some extent.

Larger objects do not only require more tiles per rotation cel, they also require more cels to look smooth rotating at the points farthest away from the centre. On the upside, they can be much more minute and precise in their rotation steps, which could perhaps be to the benefit of a game like this.

There's the sail meter to add in, too. but that can maybe be solved more efficiently as far as the game is concerned in the HUD.

There's also the possibility to prerender all sail positions and boat rotations onto the same sprite, rather than having independenly moving layers - this would require a lot more space, but it's pretty straightforward to do in photoshop with a minimalist boat design like in the original. The benefit is freeing up a lot of the scanline bandwidth + the marginal benefit of fewer sprites for the cpu to juggle around every frame.

CHR ram could just maybe help with constructing the foam trail on the bg layer with some primitive drawing in software. It would probably be a pain to get it to look right, but it could be a complement or an alternative to sprites.

Then again water foam wouldn't be the worst thing to let flicker if it's all sprite based and there's not enough room on the scanline.
User avatar
slembcke
Posts: 172
Joined: Fri Nov 24, 2017 2:40 pm
Location: Minnesota

Re: Triangle rasterization substitute.

Post by slembcke »

Started prototyping my boat sprites. Pre-computed sprites with flipping and palette swapping is going to be overly satisfactory I think:
Image
(The red/green channels are going to be mapped to the two bitplanes.)

64 rotations in only 32 character table slots. :D Leaves plenty for the sail animation and other effect sprites.

I started modifying the original Pico8 game to generate them, but was unsatisfied with the precision artifacts in my rasterizer. So instead I quick rewrote it as a shadertoy. Lol. Feels a little absurd, but whatever.
https://www.shadertoy.com/view/MllfW4
Post Reply