I just found this neat little site by accident. I'm not sure if anyone has posted it before but I couldn't find it in a search of the forums. I'm sure there are a ton of people with a million & 1 different opinions on what this guy has to say, but I just thought it was an interesting read and wanted to share.
http://www.racketboy.com/retro/nintendo ... sound.html
Pz!
Jonathon
He lost his credibility when he claimed that Slalom did split screen action.
"Lots of parallax scrolling without slowdown" for Metal Storm doesn't make much sense either, since it's done with CHR bankswitching, which costs near 0 CPU time. I think the writer doesn't have much knowledge of the architecture of the console, because sometimes he seems to consider trivial things special, maybe because they weren't done often. Still interesting though.
Well it is from the view of an average gamer not from the view of a programmer. You can do things that are really impressive for a programmer, but a player would just not notice anything special. On the other hand you can do a trick which is very simple but looks amazing. I can't come with exaples right now, but you see what I'm talking about.
PS:
It still makes me laught when they say "minimal slowdown and flicker" for Gradius games... which are without a doubt the most lagging and flickering games I've ever seen.
And "heavy doses of rotation effects" in CV3 whene there is just 2 places with rotating pendulums. Okay it is impressive but not what I call a heavy dose.
It also makes me simle when they say about each game that it is almost a 16-bit game... they sure don't know what they're talking about.
Bregalad wrote:
Well it is from the view of an average gamer not from the view of a programmer. You can do things that are really impressive for a programmer, but a player would just not notice anything special. On the other hand you can do a trick which is very simple but looks amazing.
That is absolutely true.
Bregalad wrote:
You can do things that are really impressive for a programmer, but a player would just not notice anything special. On the other hand you can do a trick which is very simple but looks amazing.
I agree that this is very well said.
A while ago I was working on a demo for the dreamcast. When I showed some friends they were more impressed with some cheesy smoke effect that took me like 2 seconds to do than anything else.
Bregalad wrote:
It also makes me simle when they say about each game that it is almost a 16-bit game... they sure don't know what they're talking about.
That largely depends on whether you consider the TG16 to be 16-bit. I will admit that late NES games approached TG16 graphical complexity, but the TG16 is no more 16-bit than the Jaguar is 64-bit. The CPU in the TG16 isn't too different from the one in the NES, just overclocked.
Overclocked and stuffed to the gills with a zillion handy instructions.
For CV3, there were also the gears in the clocktower, which is probably about as far as half the population ever got >.>
Bregalad wrote:
Well it is from the view of an average gamer not from the view of a programmer.
You are right. But since he's talking about technical features, it would be nice if he had a little more knowledge of the technical side of things.
Quote:
The CPU in the TG16 isn't too different from the one in the NES, just overclocked.
I dont even know what is that TG16 you're talkinb about, but a system is 8 bit or 16 bit, it can't be "almost 16 bit" (technically). That's what I was saying.
Quote:
For CV3, there were also the gears in the clocktower, which is probably about as far as half the population ever got >.>
Right I almost forgot since I usually skip that stage. So yeah that's a lot of rotation effects.
The turbografx actually does use a modified 6502. So yes it is 8 bit.
Bregalad wrote:
Quote:
The CPU in the TG16 isn't too different from the one in the NES, just overclocked.
I dont even know what is that TG16 you're talkinb about
This console was designed by Hudson Soft, made by NEC, and sold as "PC Engine" in some markets and "TurboGrafx-16" in others. You might not have heard about it because Nintendo's subsidiaries in Latin-alphabet markets were engaging in anticompetitive practices against multiplatform developers (and got convicted of such in a United States court). I took the "almost 16-bit" to mean that the visuals approached TG16 quality.
Quote:
but a system is 8 bit or 16 bit, it can't be "almost 16 bit" (technically).
The Intellivision CPU can be used as 8-bit, 10-bit, or 16-bit. The TG16 has an 8-bit CPU and a 16-bit video processor. The Sega Genesis and NeoGeo each have a 16-bit data bus, 32-bit registers, a 16-bit VDP, and a separate 8-bit data bus for the Z80 APU. The Super NES has 8-bit data bus, 16-bit registers, 16-bit PPU, and a separate 8-bit data bus for the SPC. The Jaguar has the Genesis CPU, two more 32-bit CPUs, and a flexible blitter with a 64-bit data bus.
Counting bits is confusing; different components in a system can have different word widths. Is there a definition of "bits" that calls the TG16 16-bit without also calling the Genesis 32-bit?
tepples wrote:
Counting bits is confusing;
Damn right. Computer/console makers only used this as a marketing scheme.
Anyway, by "almost 16-bit" I understand that the games could almost directly compete with the next generation games in terms of graphical quality. Indeed, Return of the Joker is visually amazing, and in my opinion actually looks better than the SNES and Genesis versions.
Dwedit wrote:
He lost his credibility when he claimed that Slalom did split screen action.
He lost his credibility when Shatterhand wasn't on the list. I mean... the sprites, backgrounds and such were amazing, very nice music, and there was a lot of multi-layered parallax in at least one of the levels (not as impressive as actual parallax as nothing scrolls in front of the background, but visually it looks very good).
Pushing the limits of the NES is a bit hard to define - do you mean it uses the maximum amount of system resources without choking on it, or that it makes things look and sound as good as possible, up to a 16-bit console level?
This particular list seems mostly like someone's personal favorite games. But if we were to try to get more specific, I wonder what we would come up with as pushing the limits.
I do agree that whether you push the CPU limits or not, some games just plain use their resources better than others. You can compare games with the same mapper and same data size, and some will just blow everything else out of the water, such as Shatterhand or Moon Crystal.
UncleSporky wrote:
Pushing the limits of the NES is a bit hard to define - do you mean it uses the maximum amount of system resources without choking on it, or that it makes things look and sound as good as possible, up to a 16-bit console level?
The latter. A game pushes a platform's limits if one could easily confuse it for the platform's successor's launch titles.
Well you'd have to be pretty dumb to confuse the sound coming out of the NES and the SNES.
http://en.wikipedia.org/wiki/Mode_7
Quote:
Mode 7 can only work on backgrounds, not sprites; therefore, any object that does not rotate/scale with the background must be a sprite, even items that would normally be thought of as part of the background, such as fixed platforms. The game developer must create a sprite with the same appearance as that object. For instance, in Super Castlevania IV, battles in which a boss rotates, such as with Koranot, have the mobile boss as the background, while the blocks on which the protagonist stands are sprites. With the obvious enhancements, this is similar to how some NES games featured battles against a giant movable boss without the slowdown and flicker inherent in a large sprite set—by making the boss the background, and then moving and animating it. Both systems' examples only must apply to objects in the horizontal plane of the moving object. For instance, a floor, ceiling or scoreboard can remain part of a background in both the NES and SNES examples as long as they are completely "above" or "below" the field of gameplay. They can also be turned into sprites if the whole screen is needed, but this can cause slowdown.
Moving a bunch of sprites in unity with each other causes slowdown? That must take a lot of cpu work moving one sprite individually and moving everything else from a displacement of that one sprite.
psycopathicteen wrote:
Moving a bunch of sprites in unity with each other causes slowdown?
The fact that having many sprites on screen causes slowdown is a common misconception. People often get that impression because usually sprites are used to represent game objects, and what actually causes the slowdown is the amount of game objects, not sprites.
Usually, each game object performs physics calculations, checks for collisions, and so on, so when there are lots of them this adds up to a lot of CPU time. But if a bunch of sprites are supposed to represent the same game object (without lots of individually moving parts), then it shouldn't slow the game down at all.
Indeed, here's a test ROM I found that can load more than 64 sprites worth of data at once (with heavy flickering) that shows very little slowdown:
http://www.geocities.jp/littlimi/arc/fc ... -02-21.zip
(Made by the same guy who did the Touhou Bad Apple
video/
ROM, which by the way is the most impressive thing I've seen on the NES.)
EDIT: Sorry about that,
here's the Bad Apple ROM page and
here's the sprite test one (bottom picture).
Those rom links don't work, and I'm quite sure it's because all of Geocities was taken down.
Edit: nvm, got it. I guess the japanese geocities was spared. I just got a currently unavailable message the first few times I tried it.
Kasumi wrote:
Edit: nvm, got it. I guess the japanese geocities was spared. I just got a currently unavailable message the first few times I tried it.
Ad-supported web hosting commonly blocks access from an external HTTP Referer. I needed to copy the URL and paste it into a new window.
Another stupid common misconception: The Genesis can "scroll backgrounds" faster than the Snes.
I'm so glad I found this website. I've been on smwcentral.com and it gave me a bad perception of the snes development scene.
psycopathicteen wrote:
Another stupid common misconception: The Genesis can "scroll backgrounds" faster than the Snes.
If an architecture can decompress maps and load nametables faster, it can scroll backgrounds faster. Tokumaru says his Sonic clone engine pushes the NES's limits at 16 pixels per frame in each direction. How fast can the Genesis and Super NES load nametables? And with both the Genesis and Super NES using CHR RAM, loading pattern tables once the player reaches a new area is also a concern.
Quote:
The fact that having many sprites on screen causes slowdown is a common misconception. People often get that impression because usually sprites are used to represent game objects, and what actually causes the slowdown is the amount of game objects, not sprites.
In fact this is not completely true. Because you normally clear the sprite buffer, and re-map all sprites in it every frame, each sprite will take a considerable amount of time to be mapped into shadow OAM. I figured my "maze sprites" routine was by far the one in the gameplay loop which took the most CPU time. Usually much more than the AI/collision routines.
The AI/collision routines takes much more time for the programmer to program them tough, and this gets fairly complex quickly, so he gets the impression it will take a lot of CPU time. But no, the simpler-to-write mazing sprite routine, which is ran a very high number of time each frame, takes the most CPU time, and this, having too much sprites on the screen can be a major cause of lagging.
@ tepples:
Snes can upload almost 3 screens of tile map during v-blank, if nothing else is being uploaded during that time.
@ bregald:
How does your "maze sprites" routine work?
For each object on the screen, it checks which animation frame it uses, and which direction it's facting, and fetch the corresponding meta-sprite. Then it calls the routine which mazes a meta-sprite to memory while translating it on the screen to the specified main position, and apply parameters to it (such as palette swap, horizontal flipping, or text-box area sprite clipping). It does this on each hardware sprite.
I don't know if this is the "standard" way to do this, but I think most games does something similar than mine. The only bad thing with mine is that "1 object = 1 meta-sprite" limitaton (although there is a way to make object invisible, there is no way to make them use multiple metasprites)
Bregalad wrote:
Because you normally clear the sprite buffer, and re-map all sprites in it every frame, each sprite will take a considerable amount of time to be mapped into shadow OAM.
Depends on how you do it. I for example don't clear the the whole sprite buffer every frame. I simply overwrite last frame's sprites with the current frame's ones and only clear (using a high Y coordinate, no need to waste time on the other bytes) the ones that weren't used. This means that if I use all 64 sprites, or something close to that, I'll spend nearly/absolutely no time clearing memory.
Quote:
I figured my "maze sprites" routine was by far the one in the gameplay loop which took the most CPU time. Usually much more than the AI/collision routines.
Again, depends on how you do it. If you are writing the sprites linearly first and "mazing" them later, I bet this is quite slow, because you spend time moving data around. I try to code my programs in a way that avoids moving already processed data around (I try to always read data from the source location, process it, and storing at the final location). My sprite cycling is done by processing (AI and drawing) the objects in random order every frame, which causes them to use "random" contiguous segments of OAM. It may not be as ideal as "mazing" the individual sprites, but it does the trick (all objects get a chance to be displayed) and isn't slow.
Quote:
The AI/collision routines takes much more time for the programmer to program them tough, and this gets fairly complex quickly, so he gets the impression it will take a lot of CPU time.
I'm pretty sure that in my engine the physics calculations take more time than drawing sprites... Reading metatiles from the map and processing collision information is no piece of cake for the CPU. But this is a platformer with lots of floor deformations I'm talking about... In a game with a top-down view you usually don't have to worry about floor deformation (metatiles are either solid or empty), gravity and things like that, so if your game is like that I guess I can understand your claims.
Quote:
But no, the simpler-to-write mazing sprite routine, which is ran a very high number of time each frame, takes the most CPU time, and this, having too much sprites on the screen can be a major cause of lagging.
I really think this is the fault of the approach you selected to handle the sprite cycling. I'm sure there are less CPU-intensive ways. I'm not saying your solution is bad though... As long as you can get the game to run without (much) slowdown, it's perfect.
I use a build_metasprite macro that puts the sprite attributes of each sprite of the metasprite onto a fake oam, then I have an oam processing routine that takes 16-bit x and y coordinates and turns them into 8-bit coordinates and interweves the 9th x-bit with the size bit.
I have a "DrawSprite" routine that objects call when they want to draw themselves. This routine subtracts the camera's coordinates from the object's coordinates to find the screen coordinate of the object, and then it positions each sprite of the metasprite using this coordinate as a reference. If one of these sprites is found to be off screen, it's skipped.
The "DrawSprite" routine receives as a parameter a value that is EOR'ed to every attribute byte, so that the sprite can be flipped (although there are extra calculations involving the coordinates for that), color changed or priority adjusted. The resulting data is sent directly to the OAM buffer.
That describes my build_metasprite macro perfectly, exept mine doesn't ignore offscreen sprites and it adds the attribute byte instead of EORing it.
psycopathicteen wrote:
That describes my build_metasprite macro perfectly, exept mine doesn't ignore offscreen sprites and it adds the attribute byte instead of EORing it.
I see... What happens to off screen sprites then? You can't let them simply appear at the opposite edge of the screen!
I chose to EOR because I might make metasprites that mix non-flipped and flipped sprites, and EOR lets me invert the flipping in both cases, a necessary step for flipping the metasprite as a whole correctly.
Quote:
Depends on how you do it. I for example don't clear the the whole sprite buffer every frame. I simply overwrite last frame's sprites with the current frame's ones and only clear (using a high Y coordinate, no need to waste time on the other bytes) the ones that weren't used. This means that if I use all 64 sprites, or something close to that, I'll spend nearly/absolutely no time clearing memory.
Well in fact I do that too, but if more sprites are used you still take slightly less time to clear the end of OAM buffer (set unused sprites' coordinates to $f0) and significantly more time to draw the visible sprite, resulting in more CPU being used.
Quote:
I really think this is the fault of the approach you selected to handle the sprite cycling. I'm sure there are less CPU-intensive ways. I'm not saying your solution is bad though... As long as you can get the game to run without (much) slowdown, it's perfect.
I didn't even mention sprite cycling. For my game priorities are important so I can't just draw them in any order, (I have to first sort the object before drawing them) which makes things slower, but that wasn't what I was talking about.
My routine which mases sprites is actually quite fast and I can handle a good deal of enemies without lagging (in fact I think I couldn't make it faster than what I did, but I might be wrong). What I was saying tough, is that more sprites on the screen DOES imply significantly more CPU time, while you were saying that there was no relation between both. Even if you made the routine fast, if it's called 40+ times in a frame it will still be significant, as for each sprite in a metasprite it will have to position it on the screen, check if it is off-screen, test if it is flipped, etc...
tokumaru wrote:
psycopathicteen wrote:
That describes my build_metasprite macro perfectly, exept mine doesn't ignore offscreen sprites and it adds the attribute byte instead of EORing it.
I see... What happens to off screen sprites then? You can't let them simply appear at the opposite edge of the screen!
I chose to EOR because I might make metasprites that mix non-flipped and flipped sprites, and EOR lets me invert the flipping in both cases, a necessary step for flipping the metasprite as a whole correctly.
After every sprite is written to the oam buffer, there is a routine that changes every pair of coordinates from 16-bit to 8-bit that also deals with offscreen sprites.
I chose ADDing just in case the same sprite patterns are located at a different spot of v-ram depending on the level.
psycopathicteen wrote:
After every sprite is written to the oam buffer, there is a routine that changes every pair of coordinates from 16-bit to 8-bit that also deals with offscreen sprites.
I see... That's the type of thing that could make the whole process slower though, since you have to run through the data one more time.
Quote:
I chose ADDing just in case the same sprite patterns are located at a different spot of v-ram depending on the level.
Ah OK. I only EOR the attribute byte (flipping, palette, priority), the pattern index can be added to something in my case too. The coordinates can't be overridden though (I don't see the point).
I did it because the Snes has that stupid 32 bytes where the 9th x-coordinate bit and the size bits are interweved. It was easier to take care of that first.
How does the NES scroll sprites off the left size of the screen?
psycopathicteen wrote:
How does the NES scroll sprites off the left size of the screen?
It doesn't, they just "pop"! =)
The same thing is true for the top of the screen.
At least the left side of the screen has an "8-pixel mask" feature available, the top does not. The only thing masking the top of the screen is your 1981 TV cropping the image.
Dwedit wrote:
At least the left side of the screen has an "8-pixel mask" feature available
I don't like to use that in my programs for some reason. I think I'm annoyed by the fact that the screen effectively becomes 31 (not a power of two, yuck!) tiles wide, meaning I can no longer perfectly align the camera to a 256-pixel wide block/screen. I'm pretty sure this is some kind of OCD. It doesn't bother me in other peoples' games though.
Quote:
the top does not.
In my current project I have manually masked out several scanlines at the top of the screen (like
Super Cars does), something that serves 3 purposes:
- provide extra time for VRAM updates;
- hide vertical scrolling glitches;
- allow sprites to scroll smoothly from the top of the screen;
The last purpose is actually just a bonus for me, I'm not that annoyed by sprites "popping", at least not the small sprites the NES uses (I'm sure I'd be annoyed if a large 32x32-pixel sprite couldn't scroll in/out smoothly).
tokumaru wrote:
I don't like to use [the $2001 window] in my programs for some reason. I think I'm annoyed by the fact that the screen effectively becomes 31 (not a power of two, yuck!) tiles wide, meaning I can no longer perfectly align the camera to a 256-pixel wide block/screen. I'm pretty sure this is some kind of OCD.
It appears you would hate the Super NES, which has a 224-pixel-tall screen and 240-pixel-tall maps. You'd hate the Game Boy Advance even more, with a 240x160 pixel screen and 256x256 pixel maps. I guess GBA games and those NES games that use the window treat each screen of the map as "overscannable".
tepples wrote:
It appears you would hate the Super NES, which has a 224-pixel-tall screen and 240-pixel-tall maps. You'd hate the Game Boy Advance even more, with a 240x160 pixel screen and 256x256 pixel maps.
I was 100% sure someone (most likely you) would bring this up, I was just waiting.
Even the NES has a 240-pixel tall screen and maps. At least all these dimensions are divisible by 16, not nearly as annoying as 248 IMO. The GBA scores some points for having 256x256-pixel maps, that makes them much easier to handle. I wish the NES could have stored it's tile attributes somewhere else (some internal memory like the OAM or palette RAM).
Quote:
The GBA scores some points for having 256x256-pixel maps, that makes them much easier to handle.
So does the GB, GBC and SNES (and possibly other Nintendo consoles I don't know how they work internally).
Quote:
I wish the NES could have stored it's tile attributes somewhere else (some internal memory like the OAM or palette RAM).
Use MMC5's Exended attributes then.
Otherwise, I really don't see the problem with having the screen not being a power of two. I guess you just made this one up.
I am in fact quite annoyed by sprite pop-up on NES games, but you eventually get used to this. And on the countrary of what you said, it looks "better" if an enemy or object entierely pop up at once than if individual tiles of it pop up every 8 pixels.
Bregalad wrote:
Otherwise, I really don't see the problem with having the screen not being a power of two. I guess you just made this one up.
I'm not making anything up... It's a fact that I don't like it. The fact that the height of the name tables is not a power of two causes the vertical hardware scroll to be desynchronized with the software scroll (camera), requires annoying boundary checks, makes attribute updates harder, and so on. I think I have enough reasons not to like that particular aspect of the NES. But since I like the NES as a whole, I can live with that. And once the code to deal with that is written, it's no longer an issue.
Quote:
And on the countrary of what you said, it looks "better" if an enemy or object entierely pop up at once than if individual tiles of it pop up every 8 pixels.
Please don't state your opinion as fact. I much prefer individual sprites popping up rather than whole objects.
Here's a video of a game where whole objects pop in. Do you really like that? I think (and this is my opinion, not a fact) it looks stupid.
Quote:
It's a fact that I don't like it. The fact that the height of the name tables is not a power of two causes the vertical hardware scroll to be desynchronized with the software scroll (camera), requires annoying boundary checks, makes attribute updates harder, and so on.
This is because the
tilemap is not a power of two. Above, you said you didn't like turning on the left clipping because the
size of the screen is not a power of two any longer. This is not related.
Quote:
Here's a video of a game where whole objects pop in. Do you really like that? I think (and this is my opinion, not a fact) it looks stupid.
No I don't really like it. But I don't like individual part of sprites popping up either.
Bregalad wrote:
This is because the tilemap is not a power of two. Above, you said you didn't like turning on the left clipping because the size of the screen is not a power of two any longer.
Yeah, I talked about both things. First I was talking about the screen, and when tepples mentioned the GBA I said that although its screen dimensions aren't perfect it gets points for its tilemap.
I don't like clipping the leftmost column on the NES because hiding a piece of the map that actually exists doesn't feel right to me, and if I were to show it, the scrolling logic would be kinda weird with the camera having to go beyond the level boundary (level decoding could get glitchy, there would be extra problems to deal with).
Quote:
No I don't really like it. But I don't like individual part of sprites popping up either.
But which do you dislike less? I think that a whole character popping up draws too much attention, much more than its small pieces would as it was progressively drawn.
Quote:
I don't like clipping the leftmost column on the NES because hiding a piece of the map that actually exists doesn't feel right to me,
Then you should always use 1-screen mirroring and never program for the SNES, GB, GBA, etc...
Now seriously hiding a piece of the map that actually exists is VITAL to not get any scrolling glitches, and the fact the NES doesn't do this by default sucks.
Quote:
But which do you dislike less? I think that a whole character popping up draws too much attention, much more than its small pieces would as it was progressively drawn.
Well I guess I dislike less the whole thing at once. At least there is never anything "distorded" on screen.
Bregalad wrote:
Then you should always use 1-screen mirroring and never program for the SNES, GB, GBA, etc...
I will not stop doing things just because I don't like a couple of things in the process... If that was the case I wouldn't do anything in life.
Quote:
Now seriously hiding a piece of the map that actually exists is VITAL to not get any scrolling glitches, and the fact the NES doesn't do this by default sucks.
A glitched part of the tile map is not a valid part of the level map, it's just a buffer of sorts. That is different from what I said. But enough of this.
Today I just made a new macro combining the animate macro and the build_metasprite macro into an oam_animation macro, and another macro combining the animate macro, the dma_sprite_graphics macro and the build_metasprite macro into a dma_animation macro.
It sucks that I can't freely use animation without relying on several different methods/tricks to get the best use of animation out of the Snes. Yes it is possible to pull off 60 fps animation, but you need to design levels in certain ways so that one enemy's animation doesn't interfere with another enemy.
Quote:
I don't like clipping the leftmost column on the NES because hiding a piece of the map that actually exists doesn't feel right to me
Now that's just silly
tomaitheous wrote:
Quote:
I don't like clipping the leftmost column on the NES because hiding a piece of the map that actually exists doesn't feel right to me
Now that's just silly
Eh, you could say the opposite is just as silly. If there's actually data there and the player can normally see it, but you block it just because a few sprites won't look absolutely perfect...just seems kind of petty. Even worse that the cover up uses a lot of resources.
I think everyone has different priorities when making games. Several of the old commercial games have different types of visual glitches, because the programmers had different priorities.
I absolutely hate scrolling glitches, so I'll do whatever I can to prevent them. Sprites popping at the left side of the screen don't bother me that much... it bothers me much less than hiding a perfectly good column of the level map, so I don't do that.
I think some of you are not respecting other peoples' opinions when you state as fact that a certain thing is stupid or silly, just because they differ from your own.
Hmmm, I wonder if it is possible to make an enhancement chip that could scroll sprites off the left side of the screen. Where you put a sprite at the side of the screen and the chip scrolls the individual pixels.
Well scroll smoothly sprites on the left is perfectly possible by using left-clipping.
Scrolling smoothly from the top is possible without an extra mapper too. You could do something battletoads-ish (use forced VBlank for the first 9 or 17 lines, but this complicates scrolling) or use a blank CHR-bank. MMC5's "fill mode" combined by a 8-sprite per line limitation abuse could do it with almost no sacrifices (just 8 sprites and an IRQ).
What could be possible (and cool) tough would be a mapper that could automatically disable it's CHR-ROM/RAM for the first 8/16 lines without the need of any IRQ, etc...
Quote:
Sprites popping at the left side of the screen don't bother me that much... it bothers me much less than hiding a perfectly good column of the level map, so I don't do that.
If this was renamed "31 column screen mode" would you still hate it ? It's not a perfectly good column because sprites popus up....
I mean there is several good arguments against this (heh I don't use left-clipping in my game) but I just feels like yours are biased.
psycopathicteen wrote:
Hmmm, I wonder if it is possible to make an enhancement chip that could scroll sprites off the left side of the screen. Where you put a sprite at the side of the screen and the chip scrolls the individual pixels.
I can only see this happening if a mapper provides a replacement for the usual OAM. This replacement would allow negative coordinates (this could work for the top of the screen as well, I guess) and would generate regular OAM data to feed to the NES, and would watch the rendering of the image very closely (kinda like the MMC5 does) and supply the PPU with modified patterns for the sprites that use negative coordinates.
Bregalad wrote:
You could do something battletoads-ish (use forced VBlank for the first 9 or 17 lines, but this complicates scrolling) or use a blank CHR-bank.
Why 9 or 17? 8 and 16 should work just fine. The fact that sprites can't start on scanline 0 doesn't matter, because if they could they would be completely masked off anyway. I'm blanking 16 scanlines at the top of the screen and it's working great (making the NMI constant-timed was a bit tough at first, but with that out of the way I'm 100% happy).
Quote:
MMC5's "fill mode" combined by a 8-sprite per line limitation abuse could do it with almost no sacrifices (just 8 sprites and an IRQ).
If you use 8 high priority transparent sprites to hide the others
then you will only be able to see sprites after 17 scanlines.
Quote:
What could be possible (and cool) tough would be a mapper that could automatically disable it's CHR-ROM/RAM for the first 8/16 lines without the need of any IRQ, etc...
True. That sounds like a simple enough feature to implement (the mapper would simply return $00 for all patterns for 8 or 16 scanlines).
Quote:
It's not a perfectly good column because sprites popus up....
It's a perfectly good column
of the level map, like I said before. I didn't say a perfectly good column of objects.
Quote:
I mean there is several good arguments against this (heh I don't use left-clipping in my game) but I just feels like yours are biased.
Of course they are biased, it's my game. I'm just expressing my thoughts, and everyone is free to disagree with them, but in a respectful manner rather than just stating that they are silly/stupid.
Quote:
but in a respectful manner rather than just stating that they are silly/stupid.
Yeah, maybe it's the language barrier or something. But I don't see how someone can take my comment seriously when I used the word "silly". Using the word "silly"... is just silly.
If you really wanted to minimize visual scrolling glitches, I'd recommend to go with vertical mirroring (like Milon's Secret Castle).
Maybe it's because my locale uses NTSC, but the topmost and bottommost scanlines are *always* off screen (as much as 8px on each edge, too!), whereas the leftmost and rightmost column of tiles is usually visible. Therefore, I could conclude that it'd be situationally easier to mask vertical glitches than horizontal.
Also, setting the scrolling mid-frame (i.e., after a forced vblank) isn't tricky at all, you just write $2006, $2005, $2005, $2006. You'll need to offset the Y scrolling to compensate, but that's a very trivial matter, and even though that last write to $2006 requires a little bit of bit shifting to calculate, that can all be calculated before the screen split.
Drag wrote:
If you really wanted to minimize visual scrolling glitches, I'd recommend to go with vertical mirroring (like Milon's Secret Castle).
I already solved all my scrolling issues. I use vertical mirroring and manually blank the top 16 scanlines of the image.