Anybody knows about GB/GBC games to notoriously have slowdowns in emulators ( for the DS ).
I'm testing Gameyob on a Sudokuhaxed DSi and I wanted to see how they fare compared to the DS.
We already know that Shantae runs steady 60 fps on the DSi.
Anybody else ?
I'm testing Gameyob on a Sudokuhaxed DSi and I wanted to see how they fare compared to the DS.
We already know that Shantae runs steady 60 fps on the DSi.
Anybody else ?
Well, the experimental Goomba for DS seems to run everything I throw at it fullspeed. There's some pretty serious issues in the Harry Potter games on Lameboy, both graphically and speed-wise (especially in battle). There are issues in Gameyob also, but I wonder if some extra speed would alleviate it. In particular there's quite a bit of flickering on character portraits. I've been working on this the last few days so I'd suggest using the latest build as of this post.
Edit: Okay wow. After fixing a slowdown issue in Castlevania Legends by realizing I didn't need to update timers as much as I was, the flickering is practically gone in Harry Potter, the battles run at full speed, and Alone in the Dark is running at ~47 FPS (up from FIFTEEN!). And with mid-frame palette changes, it also looks perfect aside from flickering of its own. This only improves particular games, but still! Best optimization ever!
Alone in the Dark's graphics are no longer messed up and Mortal Kombat 4 has cleared up some and is kinda playable now (no longer a solid color but still a bit obscured)
Edit: Was talking about the previous version had not updated this page before posting as I was on my DS
Edit: Was talking about the previous version had not updated this page before posting as I was on my DS
Just a minor report, I tested out Tetris DX on the latest build downloaded around 6pm March 24th 2013, and the background now changes colour like it is meant to. 
I have a suggestion that may aid in user testing/feedback, you could add build info to the executable, such as how you can view ROM info on the emulator menu.
Something like a compile date or a current SVN (if applicable) will aid in determining when issues are resolved, or regressions are possibly introduced.
I have a suggestion that may aid in user testing/feedback, you could add build info to the executable, such as how you can view ROM info on the emulator menu.
Something like a compile date or a current SVN (if applicable) will aid in determining when issues are resolved, or regressions are possibly introduced.
Perfect Dark runs at now from 15FPS to 60FPS
I can also confirm Alone is running at about 47FPS!
I can also confirm Alone is running at about 47FPS!
There is build info in the executable, it's in "Subtitle 1" which should be viewable before starting it - for instance on AKAIO, I can to press select to see the more detailed information instead of just the filename. If it's not visible from some launchers I could make a debug option also.Just a minor report, I tested out Tetris DX on the latest build downloaded around 6pm March 24th 2013, and the background now changes colour like it is meant to.
I have a suggestion that may aid in user testing/feedback, you could add build info to the executable, such as how you can view ROM info on the emulator menu.
Something like a compile date or a current SVN (if applicable) will aid in determining when issues are resolved, or regressions are possibly introduced.
I was about to provide some feedback about the palette modification every scanline, saying you didn't need to copy the palettes into a line's render state if the palettes weren't modified during it, but it appears you handled this by returning if the palettes weren't modified in arm9/source/gbgfx.cpp:drawScanline.
But there's some stuff I don't understand.
As of commit fad99a8, there's this code in gbgfx.cpp at line 572:
Why do you force some scanlines to be modified? At scanline 0 I understand, because that's the top of the screen; maybe at 1; definitely when the Window Y changes; but the other condition seems foreign to me. Why would you force a scanline to be modified if the previous one was modified but the second previous one wasn't?
Yes, I'm still looking randomly through your code and seeing what could be improved
But there's some stuff I don't understand.
As of commit fad99a8, there's this code in gbgfx.cpp at line 572:
Code:
if (scanline == 0 ||
(scanline == 1 ||
(renderingState[scanline-1].modified && !renderingState[scanline-2].modified)) ||
scanline == ioRam[0x4a])
lineModified = true;Why do you force some scanlines to be modified? At scanline 0 I understand, because that's the top of the screen; maybe at 1; definitely when the Window Y changes; but the other condition seems foreign to me. Why would you force a scanline to be modified if the previous one was modified but the second previous one wasn't?
Yes, I'm still looking randomly through your code and seeing what could be improved
The reason for that is that some hblanks are missed entirely. I'm not exactly sure why, but it seems to have something to do with other interrupts interfering, possibly within libnds. When I set REG_IE to 7 this phenomenon seems to disappear, but that cuts off all communication with arm7, which needless to say isn't good.I was about to provide some feedback about the palette modification every scanline, saying you didn't need to copy the palettes into a line's render state if the palettes weren't modified during it, but it appears you handled this by returning if the palettes weren't modified in arm9/source/gbgfx.cpp:drawScanline.
But there's some stuff I don't understand.
As of commit fad99a8, there's this code in gbgfx.cpp at line 572:
Code:if (scanline == 0 || (scanline == 1 || (renderingState[scanline-1].modified && !renderingState[scanline-2].modified)) || scanline == ioRam[0x4a]) lineModified = true;
Why do you force some scanlines to be modified? At scanline 0 I understand, because that's the top of the screen; maybe at 1; definitely when the Window Y changes; but the other condition seems foreign to me. Why would you force a scanline to be modified if the previous one was modified but the second previous one wasn't?
Yes, I'm still looking randomly through your code and seeing what could be improved
If you play the Oracle games you'll probably see the last line of the bar up top flickering... it's subtle but it's there. That flickering would contaminate the entire screen below it if I didn't have a bit of redundancy so that one missed hblank can be compensated for.
Edit: Actually you might have a point about palettes being copied over when not necessary, I was wondering why the wavy screens in the Harry Potter games were slower than they used to be. I'll take another look at it.
Actual physical proof that someone's using my emulator! Somehow I couldn't feel sure people were using it even after 18 pages of comments.
Also I'll have Pikachu's cry sounding decent in the next stable release (as it did in v0.2).
Hey! I'm using it. Though I'm a bit busy with other DSTwo development, so I didn't have much inclination to try your new changes. I'm also a bit wary of using it more for playing and saving games.
I just made a little subfeature for your GUI, which is deleting key configs. You'll find it on GitHub.
Though I'm a bit busy with other DSTwo development, so I didn't have much inclination to try your new changes. I'm also a bit wary of using it more for playing and saving games.I just made a little subfeature for your GUI, which is deleting key configs. You'll find it on GitHub.
>Implying it isn't the best GBC emulator around already
You sir, are quite modest.
Mario Land 2 in Color: Only on GameYob! (My girlfriend borrowed my ML2 cartridge so only the manual is there)
Donkey Kong Land with Y & B button setup is pure gold. A and B on DS is too unplayable for me since my fingers aren't small enough.
Also, Conker's Pocket Tales is running fullspeed 60fps while it was running around 45 - 50 in the overworld before, and it also runs like that on Lameboy. It just has a sprite glitch on Conker though, flickering and stuff but I'm sure it'll be fixed.
Now excuse me while I go play fullspeed Shantae.
Oh boy... 207-238 FPS on the overworld in Pokémon Yellow, 127 in battles while displaying text, 193 while executing moves, 252 in the Pokémon list. I think I'll go ahead and try making fast-forward mode for your emulator, Drenn, and hook it into the GUI and hotkeys.
In Nebuleon/GameYob/master commit 53e058c: fast forward mode (GUI Menu / Settings) and a fast forward remappable key.
I've requested a pull for that too.
I've requested a pull for that too.
It's more complicated than fast-forward, and might not be doable depending on how much RAM is tied up by the rewind data.
E: But I'll let Drenn decide.
Faceball 2000 plays better at 110 FPS. Thanks again!
When I find the time I'll take a look at how nesDS does it. If I can do it without compromising speed I will.
Looks like it's using a special memory bank controller used only in hudson's games, which I haven't emulated yet. When I find some documentation for it I'll add it in.
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
@
BigOnYa:
We all knew once Panda joined chat, after the response OMG, she/they be back everyday, much love!+1
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
