Castlevania IIIe issues
Moderator: Moderators
I see Rad Racer 2 having about a 20 pixel distortion on the right side of the scanline where the horizon meets the road... but as far as I can tell that's a programming issue in the game, not an emulation issue. The glitching is not at all similar to the screens you posted... nothing like that is going on in RR2.
The glitching in Rad Racer 1 that Drilian mentioned when you go to the left side of the road is a similar problem.
Unfortunately, I don't own either of these carts, so I can't see how things look on the real thing.
edit: took a snapshot of what I mean
http://hypher.net/disch/rr2.png
The glitching in Rad Racer 1 that Drilian mentioned when you go to the left side of the road is a similar problem.
Unfortunately, I don't own either of these carts, so I can't see how things look on the real thing.
edit: took a snapshot of what I mean
http://hypher.net/disch/rr2.png
I just use tilecaching, instead of a tedious 2-byte fetching. This isn't real hardware for such nostalgic things.
Zepper
RockNES author
RockNES author
Can't you handle offset = x_scroll + (ppupixel >> 2) ?Disch wrote:- Increase X scroll every 4th cycle (4, 12, 20, 28, etc)
Zepper
RockNES author
RockNES author
I load and render tiles ahead of time to a temporary buffer... which I later render to the screen. I keep something like:
u8 nBGRender[256 + 16];
u8 nSprRender[256 + 8];
every 0th cycle on the scanline (0, 8, 16, 24, etc) I load and draw a tile and attributes to nBGRender. Later on the 4th cycle (4, 12, etc) I increment the counter. I do a similar thing with sprites... but I also store a special flag (0x80) if the sprite has low priority... and another (0x40) if it's sprite 0 (for sprite 0 hit detection)
When actually rendering pixels to the screen... I do something like:
This makes BG and Sprite clipping/disabling a breeze -- nBGClip/nSprClip are always either 0 (no clipping), 8 (clipping), or 256 (BG or Sprite disabled). Also handles the pipeline where there's a delay between when tiles are loaded and when they're drawn... plus it makes sprite 0 detection very simple.
u8 nBGRender[256 + 16];
u8 nSprRender[256 + 8];
every 0th cycle on the scanline (0, 8, 16, 24, etc) I load and draw a tile and attributes to nBGRender. Later on the 4th cycle (4, 12, etc) I increment the counter. I do a similar thing with sprites... but I also store a special flag (0x80) if the sprite has low priority... and another (0x40) if it's sprite 0 (for sprite 0 hit detection)
When actually rendering pixels to the screen... I do something like:
Code: Select all
a = nBGRender[ nHScroll + nScanlineCycle ];
b = nSprRender[ nScanlineCycle ];
if(nScanlineCycle < nBGClip) a = 0;
if(nScanlineCycle < nSprClip) b = 0;
if(b & 0x80) // render BG pixel if 'a' is nonzero... else render sprite pixel
else // render Sprite pixel if 'b' is nonzero... else render BG pixel
if(a && (b & 0x40)) // raise Sprite 0 hit flag
Why bother? I'd rather update and use the PPU address (LoopyV) in realtime... since it theoretically could be altered by the game midscanline through $2006 or something.Can't you handle offset = x_scroll + (ppupixel >> 2)
I can guarantee that Castlevania 3 - Dracula's Curse (E) does glich while scrooling vertically in Nintendulator as well than on the real hardware (many emus doesn't show the glitch exacly how it is on the real hardwar), however I don't know if the US version has gliches or not.
Useless, lumbering half-wits don't scare us.
Nesticle isn't a reference in accuracy department, you know. However, when I run MegaMan 6 on my PAL NES, it doen't look like when you switch to PAL mode trough Nintendulator, but I got an illegal copy from my brother-in-law, so maybe the code is different to be compatible with PAL (because the NTSC one would glitch).
Useless, lumbering half-wits don't scare us.
-
- Posts: 2158
- Joined: Sun Jun 05, 2005 2:04 pm
- Location: Minneapolis, Minnesota, United States
- Contact:
I hate running things on PAL, it sucks. But yeah I wish Nesticle was an accurate emulator, because I LOVE the setup in Nesticle, and I really like the "make your own window size" thing they have. I only use Nesticle to play Final Fantasy 3, because it works just fine in Nesticle. Well, I don't know why i'm talking about that, so I'm going to stop.
I think the worst thing about Nesticle is that, due to its extreme popularity, people would hack ROMs to run correctly in it, and thus ruin them when more accurate emulators eventually started coming out. I can't remember any game specifically, but I know there were changes made to ROMs for the express purpose of making them run in Nesticle, which wasn't accurate enough to handle them as-is.
Thus, there are now hacked ROMs floating around that don't run right in the newer crop of emulators, making them seem broken, when it's really the ROM that's broken.
and Final Fantasy 3 works in many emulators that are miles-and-above better than Nesticle.
Thus, there are now hacked ROMs floating around that don't run right in the newer crop of emulators, making them seem broken, when it's really the ROM that's broken.
and Final Fantasy 3 works in many emulators that are miles-and-above better than Nesticle.
-
- Posts: 2158
- Joined: Sun Jun 05, 2005 2:04 pm
- Location: Minneapolis, Minnesota, United States
- Contact:
I know, but for some reason, I have way more fun playing it in Nesticle than in emus like Nintendulator. The thing I hate about Nintendulator is that you can't have a full window with black borders and a square screen. Ya know what I'm saying? And I HATE that you can't change the D-Pad controls on Jnes, otherwise I think I'd use that more often. I use it all the time for testing my ROMs, but I only use it for testing. Have you noticed that it's really not a good idea to write code where you incbin a .nam file? the top half usually appears on the bottom of the screen, wilst the bottom appears on the top. The only emu I know that keeps it centered is Jnes.