Okay, my sprite shows up just fine on every emulator except for Nintendulator. When I move my sprite, you can see it move, but you can't see it when it's still. Any explanation for this? I do the load sprite method just fine:
Code:
lda #8
sta cy ; ypos
lda #5
sta ct ; tile number
lda #8
sta cx ; xpos, and we didn't do anything to attributes, because it's not neccisary
lda #high(cynthi) ;sprite dma
sta $4014
any explanation? I'd really like if I could figure this out, because it's annoying. thanks.
1. Write 0 to $2003 before performing a sprite DMA
2. Make sure you do your sprite DMA during VBLANK.
Are you making sure to use the same tile number when it's still and when it's moving? If not, then perhaps you are loading the walking cels but not loading the standing cels.
you mean like this?:
lda #$00
sta $2003
sta $2003
bit $2002
lda #high(cynthi)
sta $4014
because if so, that doesn't work. I can't really think of a way to do it in vblank besides in bit testing $2002. I wish I could just say:
see if bit 7 is on
and be done with that. Sorry, I hope I'm not looking stupid here...
Celius wrote:
lda #$00
sta $2003
sta $2003
Umm, why are you setting the SPR-RAM address
twice?
The SPR-RAM address is only 8 bits wide, so it is a
single-write register (contrary to GbaGuy's tutorial which erroneously treats it the same as $2005 and $2006).
As for doing it in VBLANK, you shouldn't be "detecting if you are in VBLANK", but should instead be simply performing the sprite DMA at the beginning of your NMI routine.
One other minor thing to note: ALWAYS read $2002 at least once before enabling NMIs via $2000, or you may find yourself receiving an immediate NMI if you happened to enable them during VBLANK without having read $2002 earlier...
Oh, man.. Something happened to my controls, and it's really bad. Well first of all, yes, my sprite does show up in Nintendulator, but when you press right, the sprite goes left really fast, when you press left, the sprite goes southwest really slow, when you press up, it goes up really fast, and when you press down, you go down a little slower, but not much. Oh, and if you press up twice, then press left, and it just goes left really slow. But if you press down twice, it goes southwest again. What happened? My controls code is fine, there's something else wrong.
Never mind, I fixed it. Okay, I was wondering something. What if you want things in your NMI to happen, but you want some things in your routine to happen at different times? Like, I want to increment vbl_count constantly, but I don't always want my sprite sitting there on the screen. How could I avoid this? Okay, this is bad, but I was thinking of something like this:
Code:
nmi:
inc vbl_count
lda rmlod ;variable for saying room is loaded
cmp #1 ; if variable is 1 (I add one to this variable when the room is loaded)
beq continue
rti
continue:
lda #0
sta $2003
jsr handlepad ; joypad
lda #high(cynthi)
sta $4014
rts
it's because I only want my sprite to appear when the level is loaded. I tried that, didn't work, because I'm bad at coding. Okay, any suggestions?
Disable sprites via $2001 when the level is not loaded, and/or clear the whole OAM with any value from $f0 to $ff, so all sprites won't be visible.
Not doing sprite DMA in a frame won't make sprites to disapear, they'll just stand where they were the last frame without moving.
Oh by the way, I forgot to say thank you, because your method worked. And also, is there any way to turn on clipping in Nintendulator? Because without clipping, FF3 is really bothering me, and I want it to be clipped. Any way to turn it on?
If, by "clipping", you mean restricting the rendered screen to 256x224, there is no such option. Any other forms of clipping are already implemented.
Quietust wrote:
If, by "clipping", you mean restricting the rendered screen to 256x224, there is no such option.
Then despite the excellent accuracy otherwise, if it can't be set to cut off the lines that a typical television cuts off, it is a poor emulation of an NES
connected to a consumer TV.
Nintendulator's goal is not to emulate an NES connected to a consumer TV - if it did, it would support fullscreen with VSYNC and have a bunch of graphic filters for 2xSAI, HQ2x, scanlines, and all that crap.
If you wanted to do that you would probably have to clip a few pixels on each side of the screen as well.
tepples wrote:
Quietust wrote:
If, by "clipping", you mean restricting the rendered screen to 256x224, there is no such option.
Then despite the excellent accuracy otherwise, if it can't be set to cut off the lines that a typical television cuts off, it is a poor emulation of an NES
connected to a consumer TV.
Good NES emulation should be measured by what it looks like when connected to the same TV as a real NES. I am sure that there is very little overscan if I hooked up my NES to my computer CRT. This is why I hate scanlines and such features in emulators. If you want the look of a crappy monitor, then hook up your computer to a crappy old TV via RCA composite.
Quote:
Good NES emulation should be measured by what it looks like when connected to the same TV as a real NES. I am sure that there is very little overscan if I hooked up my NES to my computer CRT.
Good point; what is really wanted here (by some) is an NTSC television emulator. A
real NES emulator would of course just output a raw NTSC composite video stream. :)
Even if we emulate an NES whose PPU generates component signals instead of emulating down to the level of NTSC composite or S-video signals, a lot of commercial and homebrew games such as Super C take advantage of the fact that the top and bottom are cut off so that they can hide the garbage when an attribute block is split across the top and bottom of the screen.
I think myself that the goal of an emulator is to look as close than what it would look on a real TV, regardless of techical details. I think FCEUltra does it very well, much more well than Nintendulator. But Nintendulator has the feature to log instruction, that is very usefull (but it sometimes takes 200% of my computer's CPU time and then it will bug).
Quote:
I think myself that the goal of an emulator is to look as close than what it would look on a real TV, regardless of techical details.
Over time I've realized (the obvious fact) that people write emulators for different reasons; it's not just about trying to make-believe one's PC is a big NES console on its side and one's monitor actually a TV set. The goal of the author for his emulator is whatever his goal is (the emulator itself has no goal, being non-sentient). Some write theirs in different languages, or try to implement unique features, or just enjoy the process itself.
Bregalad wrote:
I think myself that the goal of an emulator is to look as close than what it would look on a real TV, regardless of techical details. I think FCEUltra does it very well, much more well than Nintendulator. But Nintendulator has the feature to log instruction, that is very usefull (but it sometimes takes 200% of my computer's CPU time and then it will bug).
But there are games that Nintendulator has no problem emulating, yet make FCEUltra fall flat on its face. Nintendulator is all about low-level CPU, PPU, and APU accuracy. It could be, hands down, the end all be all of NES emulators if more work was done on usability improvements and polish for the end-gamer... that and ports to other platforms. Its slowness is becoming a thing of the past, with the progression of computer hardware. My point is that I wish more emulator authors started basing their emulators ontop of Nintendulator.
However, currently, my most used NES emulator is FCEUltra on the Xbox. I wish more emulators were ported to the Xbox... or at least a more recent port of FCEUltra
Because of the hardware acceleration, you can tweak FCEUltra/Xbox to get the overscan perfect. I did the side-by-side comparison with a real NES on a real TV. FCEUltra/Xbox's output was blurrier than the real NES, but otherwise was fairly close to the real thing. Of course, peripherial comparison was wildly different. NES games are meant to be played with a real D-pad, not the crap pawned off on people these days. Hell, even Nintendo has botched up their D-pad on the Gamecube, GBASP, and NDS. Oh well.
Anyway, for my FCEUltra/Xbox gets more gameplay-time because of the usability stuff that goes ontop of a solid emulator core. IMO, there is nothing stopping Nintendulator from having this, assuming somebody wanted to spend the time.
Nintendulator is really great for accuracy and has the log feature, but it screen render is really bad for my viewpoint. FCEU is nearly as accurate than Nintendulator, and has the debugger, and very nice rendered graphics, and is pretty slow, but nintenulator is even much more slower.
Virtua NES render also very good graphics, but has some problem while toggling $2006 midframe (not always emulated correctly) and while toggling $2001 midscanline, and emulates PAL very badly. It is not very accurate, but enough for most licenced NTSC games. I has a lot of other function, such as Name Table viewer (that Nintendulator also has, but it slows the thing down a lot). And VirtuaNES is pretty fast, and cause no problem running evin on my old slow PC, while Nintendulator runs even too slow on my new fast PC.
I think the XBost is one of the worst gaming machines out there, and should not be used at all, even to use it to play old games.