It is currently Sat Nov 18, 2017 5:21 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 141 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10  Next
Author Message
 Post subject: Re: Lizard
PostPosted: Mon Mar 06, 2017 8:38 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19222
Location: NE Indiana, USA (NTSC)
That or downgrading the drums to Tim Follin fidelity so you can (ab)use DMC.


Top
 Profile  
 
 Post subject: Re: Lizard
PostPosted: Mon Mar 06, 2017 8:39 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
Nope.


Top
 Profile  
 
 Post subject: Re: Lizard
PostPosted: Wed Mar 08, 2017 5:03 pm 
Offline

Joined: Tue Dec 11, 2012 1:02 pm
Posts: 42
Since Brad is busy finalizing Lizard and definitely not getting distracted by trivial forum posts, I'll share my thoughts on how I would approach more parallax on a stage such the Lizard river zone, for the benefit of everyone except him, since he is too busy to be distracted by this...

- The scintilla dots/lines on the water could be sprites scrolling across the screen. May have to limit to 1 or 2 per line, but would work well regardless. Just set to low sprite priority. Flickering would be a benefit, as light shimmering on water often does so.

- The clouds could also be sprites. But if they are in the same VRAM pattern table ($0000 or $1000) as the background tiles, what you could do is have the first half/third of the screen set BOTH tables (PPUCTRL $2000) to draw from the same table, then after the cutoff point (via IRQ or sprite overlap or counting cycles) the PPUCTRL would be set to normal, where sprite and background tables have their own tables.

Hope this info is useful to anyone out there making a game with some kind of parallax.


Top
 Profile  
 
 Post subject: Re: Lizard
PostPosted: Wed Mar 08, 2017 6:29 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
psc wrote:
Since Brad is busy finalizing Lizard and definitely not getting distracted by trivial forum posts, I'll share my thoughts on how I would approach more parallax on a stage such the Lizard river zone, for the benefit of everyone except him, since he is too busy to be distracted by this...

I'll try very hard to take this statement in good faith, but if you want to talk about parallax without "distracting" me this thread is literally the opposite of where you should be posting.

psc wrote:
- dots/lines on the water could be sprites
- clouds could also be sprites.

Sprites are a nice idea, but I simply don't have the free palettes to use on either clouds, or dots on the water.

Before you follow up with a suggestion that I could change my other sprites and palette usage to make room, I will say that I have other design goals that are more important to me (and are consistent with the rest of the game) which necessitate those palettes.

Also, the clouds (spoiler?) aren't actually "background" in my game, they are platforms you can stand on as part of the foreground, which makes me want them not to parallax with the orange rocks, though maybe that's a stupid artistic choice that nobody else would agree with. (It's my game, though, so I'm gonna go with my gut there.)


Anyhow, since you all seem not to care that I didn't want to discuss this and keep egging me on, fine, I'll respond to the other suggestions:

DMC IRQ: my game doesn't us DMC, and leaves $4011 at 0, so that's free. It does, however, use IRQ as an error handler (which technically shouldn't fire in the finished game, but it has a very useful development function so I lean heavily toward keeping it). That's the primary reason I wouldn't want to use it, but I also have to deal with making it work on both NTSC and PAL and test it, and there are a bunch of other details about it which I think are a hassle. It's the most doable of these unsolicited suggestions, though.

Timed NMI for the first split: I could cycle-time the first split and use sprite-0 for a second split, except now I'd be wasting 1/4 of a frame on the first split, and fitting the wait loop for sprite-0 into an approriate timing for a second split would be difficult. I'd have to design enemies around an update patterns that I could guarantee would fit into those timing windows. That's a big pile of constraints that I don't think would make the game play better. (I'm making a game here, not a graphical demo.)

Sprite overflow: In case you didn't know, sprite overflow evaluation is buggy. It's usable as a split point for a static screen, but I've got to deal with more or less arbitrary sprite combinations here. Then everything I said about timing the second split with sprite-0 in the last response applies again.

So... anyhow, if you really wanted to know, that's the jist of it. None of these suggestions are things I haven't considered, and all of them conflict with the design of things as-is. I haven't even mentioned how much code the river area shares with the rest of the game, and how all of the constraints from that impinge on its design as well. (Code space is getting pretty dear at this point in development, too.)

I would kind of like it if I could make the trees at the bottom have another split, but they're also already moving fast and hard to see, and if you pause the game, there's a pause bar at the bottom that completely covers it, so you can't really even stop to look at them. Maybe that would give you some idea why I don't think it's a visual effect I would prioritize over other goals.

It's a whole interactive system that has to work together, I can't just change one thing without having to redo a lot of other work. I have no use for unsolicited suggestions like this. Sure they sound simple to you, because you're only looking at one minor detail. To me, I have to fit it in with the hundred other parts of the finished river zone. You're just looking at the tip of the iceberg.


psc wrote:
Hope this info is useful to anyone out there making a game with some kind of parallax.

It would probably be a lot more "useful" to post ideas like that in a thread called "techniques for implementing parallax", instead of burying it in a thread about my game.

Similarly, I didn't really want to have to respond to this stuff because I don't think it's helpful to anyone (least of all me). Everything about the decision is specific to my game and how it works.


I don't mind being asked "why'd you do that?". That's usually a good question. Or even "I don't like this", or "did you consider this" are usually fine, but there's a gradual escalation to "here's how I would have designed your game", and an implication that you think I should justify the decisions I've made to you. I don't really like that.

Myask made a pretty innocent comment, and I made a short reply about it. Pubby was curious about that reply, and I got a bit pre-emptively defensive (sorry) because I knew a good answer is complicated and didn't want that to be demanded of me, but then collectively you persisted despite my protest, so... this is what I get I suppose.


Top
 Profile  
 
 Post subject: Re: Lizard
PostPosted: Wed Mar 08, 2017 8:17 pm 
Offline

Joined: Tue Dec 11, 2012 1:02 pm
Posts: 42
Quote:
Sprites are a nice idea, but I simply don't have the free palettes to use on either clouds, or dots on the water.

Lizard eye is white, cloud/water is white. Don't need exact color match for dots on water. Could even use a bright yellow or grey.

Quote:
Also, the clouds (spoiler?) aren't actually "background" in my game, they are platforms you can stand on as part of the foreground,

Doesn't mean that a certain area could have special clouds.

Quote:
It would probably be a lot more "useful" to post ideas like that in a thread called "techniques for implementing parallax", instead of burying it in a thread about my game.

That's what the search bar is for.

People care about your project, so it's kind of funny you would get annoyed when they ask questions. Do you really expect them to understand your design choices/tech limitations without knowing what goes into it?

Let me tell you quick story. There's this game called Pacman on the 2600. People said, "Why'd the dood make the colors all wrong? Why does the maze not look like the arcade?" Well the answer is that management demanded the background not have black as it was an internal policy to avoid screen burn in. And the maze was limited by the Rom space which the programmer had no say in. Now when you know the story behind why it has a seemingly arbitrary color palette that deviates from the source Arcade material, it makes more sense, and you appreciate the project more.

If the programmer said, "Trust me, I made the best possible game, I know what I'm doing, you just don't know what you're talking about," do you think people would go, "hmm, yeah, that's a satisfying answer, what a cool guy" ? Every engine and project has limitations. You seem to be taking things a bit too personally. Maybe people are just genuinely curious. NES development is a fascinating process.

Quote:
but there's a gradual escalation to "here's how I would have designed your game"

Uh, no. Who ever said that? It sounds like you're stressed and you're taking your feelings out on the fans.


Top
 Profile  
 
 Post subject: Re: Lizard
PostPosted: Wed Mar 08, 2017 8:45 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
rainwarrior wrote:
sprite overflow evaluation is buggy

Yes, but it's perfectly reliable if you use 9 high-priority sprites (say, 1 through 9 since you're saving sprite 0 for later) with no others above them. I don't know if that qualifies for your game, but those conditions are easily met in most status bars at the top of the screen.

The bad part for me is dedicating up to 10 sprites just to raster effects, leaving "only" 54 for actual game objects. On the other hand, Felix the Cat used more sprites than that to hide scrolling glitches at the right side of the screen, which not only sacrificed sprites but also effectively reduced the sprites per scanline limit to 7, but somehow still delivered large, interesting sprites, so maybe this sacrifice isn't such a big deal after all.

I've had a lot of trouble with the DPCM technique, so I personally wouldn't rank it so high in a list of possible techniques to use for raster effects. IRQs don't fire a consistent amount of time after the CPU requests the sample to be played, so you actually have to measure the error in order to compensate for it later. Another problem is that sometimes there are "phantom IRQs" firing immediately after you start the sample, which I could never understand or find the proper way to avoid/ignore. After a lot of trial and error, I got things to appear to work fine for several seconds, but every once in a while something would happen and completely mess up the effect for a frame.


Top
 Profile  
 
 Post subject: Re: Lizard
PostPosted: Wed Mar 08, 2017 10:08 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
psc wrote:
That's what the search bar is for.

My reply to pubby's question was a bit rude and hasty, and I regret it a little, but my goal was to not have an off topic discussion about pedantic stuff in this thread. That goal has thoroughly failed, I guess. I can resign myself to that but I'm not going to like it.

I really did mean it, though. You could start a thread about parallax techniques, and it would be a very nice place to talk about such stuff. Much better than right here. You still could do this right now. Anybody could. (Please.)

psc wrote:
rainwarrior wrote:
but there's a gradual escalation to "here's how I would have designed your game"

Uh, no. Who ever said that? It sounds like you're stressed and you're taking your feelings out on the fans.

Was that not a fair paraphrase of: "I'll share my thoughts on how I would approach more parallax on a stage such the Lizard river zone"?

You provoked hostility by mocking me for being "distracted". If you'd just made your unsolicited suggestion politely by itself, you would not have gotten the same response.

psc wrote:
People care about your project, so it's kind of funny you would get annoyed when they ask questions. Do you really expect them to understand your design choices/tech limitations without knowing what goes into it?

You didn't ask a question. Neither did tepples.

I don't expect anyone to understand my design decisions. Why would anyone understand that? If there are questions, I'm generally willing to answer, but just because there is a question doesn't mean it's entitled to an answer. It takes a lot of effort to respond correctly, and I resent it when this is not respected.

Sometimes I'd really rather not go into it. Can I not at some point say "there are a lot of details and I don't want to discuss them here/now". That's what I tried to do in response to pubby, but maybe not very tactfully.

psc wrote:
"Trust me, I made the best possible game, I know what I'm doing, you just don't know what you're talking about,"

Is what I've done here really equivalent to this statement? Is this really what you're comparing me to?


I think I've tried to answer every question that someone has ever put to me about this game, and this has been hard to do, so I do feel quite a bit insulted by this.

There are certain questions like "when will it be done", or B00daW's "what's going on?" from a few days ago, that are very difficult to answer, but I still try to make an effort to respond, even if I can't answer the question as asked.

If you want to mock me, or if I don't want to use your suggestion about sprites you wanna argue about every little detail about my response to it (use white sprites, or make special clouds even though I just said specifically I didn't want them to be)... what do you want me to say? I'm not going to have an argument about what I want in my game.

If there are things you're actually curious about, and you want to ask, please just ask them, as questions.


Top
 Profile  
 
 Post subject: Re: Lizard
PostPosted: Wed Mar 08, 2017 10:20 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
tokumaru wrote:
rainwarrior wrote:
sprite overflow evaluation is buggy

Yes, but it's perfectly reliable if you use 9 high-priority sprites (say, 1 through 9 since you're saving sprite 0 for later) with no others above them.

Ah, I had forgotten that detail of it. Thanks. (I do have some sprites that would go above the split point, though I suppose I could move the overflow way up and delay the split significantly to compensate.) Still, my real problem is having to have an extra wait loop mid-screen. One wait-split it not bad, two waits breaks up the execution too much.

tokumaru wrote:
Felix the Cat used more sprites than that to hide scrolling glitches at the right side of the screen

This technique kinda forces 8x16 sprites too. (Doesn't hurt to have CHR banking in this situation either.)

tokumaru wrote:
I've had a lot of trouble with the DPCM technique, so I personally wouldn't rank it so high in a list of possible techniques to use for raster effects. IRQs don't fire a consistent amount of time after the CPU requests the sample to be played, so you actually have to measure the error in order to compensate for it later. Another problem is that sometimes there are "phantom IRQs" firing immediately after you start the sample, which I could never understand or find the proper way to avoid/ignore. After a lot of trial and error, I got things to appear to work fine for several seconds, but every once in a while something would happen and completely mess up the effect for a frame.

Yes, this is some of what I meant by it being a "hassle".


Last edited by rainwarrior on Wed Mar 08, 2017 11:13 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Lizard
PostPosted: Wed Mar 08, 2017 10:38 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 946
rainwarrior wrote:
I really did mean it, though. You could start a thread about parallax techniques, and it would be a very nice place to talk about such stuff. Much better than right here. You still could do this right now. Anybody could. (Please.)


This Lizard is not the Lizard of Parallax Technique Discussion. (link to topic for discussing that)


Top
 Profile  
 
 Post subject: Re: Lizard
PostPosted: Fri Oct 20, 2017 2:52 am 
Offline

Joined: Tue Dec 15, 2015 3:50 am
Posts: 10
consider adding this one

Image


Top
 Profile  
 
 Post subject: Re: Lizard
PostPosted: Fri Oct 20, 2017 4:40 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
Heh. It me.


Top
 Profile  
 
 Post subject: Re: Lizard
PostPosted: Mon Oct 30, 2017 2:08 am 
Offline

Joined: Tue Jun 28, 2011 2:39 pm
Posts: 152
Really fun thing. One issue though, please change this enemy's look. It's easy to mistake it for a checkpoint. Or change checkpoint, doesn't really matter.

Image


Top
 Profile  
 
 Post subject: Re: Lizard
PostPosted: Mon Oct 30, 2017 3:07 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 581
There's a Win 3.11 version of Lizard?


Top
 Profile  
 
 Post subject: Re: Lizard
PostPosted: Mon Oct 30, 2017 10:24 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
The Windows version is built for XP... maybe that's just a 3.1 skin? Or maybe a 3.1 emulator running the NES ROM?


Top
 Profile  
 
 Post subject: Re: Lizard
PostPosted: Mon Oct 30, 2017 12:39 pm 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 581
Win 3.11 coding wouldn't be that different from NES actually, banked memory and all, just 16-bits. Everyone is doing things for old consoles, but old Windows is all forgotten :'(


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 141 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group