Stupid question but I will ask it : since GBA resolution is 240 × 160px and NDS is 256 × 192px, how is the GBA display rendered on the NDS screen ? 1:1 and aligned top/left ? or stretched to 256 × 192 ?
Seems that sometimes that are stuff drawn outside 240 × 160 - while some others time it's in this 240 × 160 area.
Im a bit confused...
*
Edit : Oh I understand now.
For some games, they is stuff drawn outside the 240 × 160 area, thus it becomes visible on the NDS screen (example of such game : Yoshi's Island) - while for some other, nothing is drawn (then we got "black bars" - example : Metroid).
Seems that sometimes that are stuff drawn outside 240 × 160 - while some others time it's in this 240 × 160 area.
Im a bit confused...
*
Edit : Oh I understand now.
For some games, they is stuff drawn outside the 240 × 160 area, thus it becomes visible on the NDS screen (example of such game : Yoshi's Island) - while for some other, nothing is drawn (then we got "black bars" - example : Metroid).
Last edited by ShaolinAssassin,
It's 1:1 top-left. Without adding a delay of one frame (and currently some other vram allocation related issues) it's not possible to do any post processing of the picture.
Ok, ty. I got confused by Yoshi's Island, as this game draw outside the 240 × 160 area.
For everyone reading this, it would be interesting to test a lot of games that are on the gbaemu4ds compatibility list as to see how well they work in gbarunner2 compared to that.
Edit: It's also important to note that glitches in what's outside the visible area on a real gba should not be regarded to as glitches (so that's the right 16 pixels and the bottom 32 pixels), because it's not meant to be seen.
Edit: It's also important to note that glitches in what's outside the visible area on a real gba should not be regarded to as glitches (so that's the right 16 pixels and the bottom 32 pixels), because it's not meant to be seen.
Last edited by Gericom,
I've committed an experimental arm9 sd read branch. It looks promising, speed wise, but it still contains bugs.
Edit: Bugs are fixed. Speed is much better on the arm9 card read branch. Give it a try I would say.
Edit: Bugs are fixed. Speed is much better on the arm9 card read branch. Give it a try I would say.
Last edited by Gericom,
Well, the rom does not enable the dsi additional speed, so you would need something like nds bootstrap to benefit from it. For code running in itcm (gba bios, abort handler) and from cache (rom) it could be faster.Wow, this is cool
I have some questions though. If this is a hypervisor... Uhh, does that mean it's not emulating the GBA? Like, running them natively similar to Nintendont? What would be the limitations of this?
But, awesome work :3
EDIT: oh, and also, if this is the proper place to ask, will performance increase if ran on 3DS with TWL speeds on, or will it not affect it at all due to not being a regular emulator? (Which ties in with one of my above questions) @Gericom
Doesn't seem to want to load anything at all on my side - crashes with a green top screen, and this error message:
Running on a DSi XL/Supercard DSTWO. One quirk of note- the SD card in question's formatted with 64k cluster size.
I'll see about testing it with a more normal SD card later.
Code:
UNDFO(Slot-1)
01007364
E3A00405
4000001F
0200A1D0Running on a DSi XL/Supercard DSTWO. One quirk of note- the SD card in question's formatted with 64k cluster size.
I'll see about testing it with a more normal SD card later.
Try using a cluster size of 4kb. Loading the bios from card currently fails when the cluster size is bigger than 16kb. Also some people are experiencing some problems with the new arm 9 read branch, which seem to be related to different devkitarm versions. I'm looking into the problem. I'm not using the latest version by the way.
Good news, I'm working on a new sound core to fix the crackles as much as possible. The sound improve branch works quite good with donkey kong country currently. The samplerate is still fixed, so only games that use 13378 Hz sound right. Use the X button to resync the sound if needed
Use an older devkitarm. I thought O2 would fix that error. You could also try -nostdlib first. (In the arm9 makefile. make clean and make after that)
EDIT: I can provide a working build tomorrow if you want
Last edited by Gericom,
Yeah, I tried the last three devkitarm versions and had the same results. I'll wait then, thank you
Did you try -nostdlib? If not try that first. If it doesn't work try r41 of devkitarm it's the one I'm usingYeah, I tried the last three devkitarm versions and had the same results. I'll wait then, thank you
turns out it really was the devkitarm release. I tried with r41 and it worked now!
In Pokémon, there are now less audio glitches and the game also doesn't freeze anymore when entering a battle. Nice!
Very nice!
We're trying to resolve the issue with the never devkitarm here: https://github.com/Gericom/GBARunner2/issues/2
It seems like the new gcc has a number of dirty tricks on it's sleeve that fucks up everything. It replaced loops that cleared a bit of memory with calls to memset, which is not available at that point (and which I even had commented out and replaced by those loops) and now it's emitting a STRB instruction instead of a call to a function that makes it possible to do a 8 bit write in vram (because STRB is ignored in that region)
In the latest commit on the sound improve branch you can enable vertical centering and masking by uncommenting
in the arm7 main.cpp. This is experimental and may cause issues with a couple of games. Don't use it when testing games.
Code:
#define CENTER_AND_MASK_ENABLED
Last edited by Gericom,
Similar threads
-
- Article
