I thank the developer of the emulator.
I wonder if any part of the next update will be possible to emulate Super Mario RPG.
Saludos
no, the o3ds is already close to its limits with normal snes games.
Homebrew SNES9x for Old 3DS
- Thread starter bubble2k16
- Start date
- Views 791,983
- Replies 2,478
- Likes 146
no, the o3ds is already close to its limits with normal snes games.
- Joined
- Feb 10, 2009
- Messages
- 5,484
- Trophies
- 2
- Location
- Sacramento, California
- Website
- lazerlight.x10.mx
- XP
- 5,498
- Country
@Wargla - SA-1 chip support will not be likely.
True, but you have to understand that there's more going on with emulating an SNES than just emulating its CPU, and tacking on another CPU that runs at 3x the frequency doesn't amount to requiring 3x the resources for overall emulation. Shifting work over to the GPU already reduces the CPU requirements by a lot, but there is still room for improvement and more can be shifted to the GPU. From what I understand, if this emu works much like blargSNES, then what's being done is each tile cel being used and/or requires a change because of the color palette is converted from indexed bitplane to direct color bitmap and dropped into a texture cache, and a polygon list is being built up from scratch each frame, so that not only requires having to examine each visible tile, but the reading/writing of memory to build the lists and convert tiles to a usable format takes a bit of time. From my research and poking around with the 3DS, the system felt more or less designed around having static polygon lists that use other parts of the system (like shaders) to get everything in motion. So the current methods for GPU rendering, imo, kind of go against the design and don't exactly work to the system's advantages, even if it's faster to get a good output than software rendering.
edit: lol, didn't even realize that I was replying to TC in this post, so now I feel kinda embarrassed.
Last edited by DiscostewSM,
@DiscostewSM - No problem. Nice to hear some views from a fellow dev. I've had a look at some of the PICA200 documentation and found that they have some color look-up-tables as part of the procedural texture pipeline. Perhaps that's the bump mapping you were referring to? If that's what you were referring to I had been wondering if that can be put to good use too.
I've been doing a lot of timings of the code execution when testing the 3DS port of Snes9x. Rough breakdown of the timing that we have of a standard game of 60 frames during a typical in-game emulation. For the non-technical folks, 60 frames should run within 1000 milliseconds (or 1 frame must run within 1000/60 milliseconds)
In a typical 60 frames in-game:
- CPU Emulation: 400-500ms (50% of the time)
Some games like F-Zero almost run at 900-1000ms per 60 frames.
Even with speed hacks there's very little that can be done to reduce the amount of time spent in the CPU emulation in F-Zero.
That's also why frame skipping in F-Zero doesn't work that well.
- SPC Emulation: 50-60ms
- Graphics (Drawing to the screen): 200 ms
Generally about 50ms per background layer, and another 50 ms for sprites, depending on the number of sprites.
If we have to draw the sub-screen and there are very heavy HDMA effects (like the BOF2's battle transition),
this figure easily bursts 500ms and more.
Emulating the SA-1 (a CPU 3x faster than the main CPU), will add 1500ms to the emulation time and push the total emulation time to beyond 2000ms (that means 30FPS or less). And there are other considerations. Emulating a parallel SA-1 is more complicated that emulating the SPC700. I'm pretty sure you already know, but for the non-technical folks: the main CPU and SPC-700 has limited visibility of each other. Because of that, we don't have to truly keep the SPC700 running in sync with the main CPU cycle by cycle. We only have to sync the SPC700 at much longer intervals apart, and only when the main CPU starts communicating with the SPC700. This provides a significant speed increase (almost 80% speed increase!) This is probably one of the things I did that provided the largest speed increase. The rest of the optimisations only provided modest performance boosts.
But for the SA-1 we will have to emulate both main CPU and SA-1 in lock-step (I think). This puts a much heavier load on the 3DS, switching back and forth emulating both processors just to keep them tightly in sync will definitely add more than just 1500ms to the overall emulation time.
So even in an extreme case, I do not draw anything to the screen at all (in layman's term I skip all frames), I will never achieve a full 30FPS . And that is why I've never considered investing time into emulating SA-1.
The New 3DS will probably do a better job of emulating SA-1 instead.
No problem. Nice to hear some views from a fellow dev. I've had a look at some of the PICA200 documentation and found that they have some color look-up-tables as part of the procedural texture pipeline. Perhaps that's the bump mapping you were referring to? If that's what you were referring to I had been wondering if that can be put to good use too.I've been doing a lot of timings of the code execution when testing the 3DS port of Snes9x. Rough breakdown of the timing that we have of a standard game of 60 frames during a typical in-game emulation. For the non-technical folks, 60 frames should run within 1000 milliseconds (or 1 frame must run within 1000/60 milliseconds)
In a typical 60 frames in-game:
- CPU Emulation: 400-500ms (50% of the time)
Some games like F-Zero almost run at 900-1000ms per 60 frames.
Even with speed hacks there's very little that can be done to reduce the amount of time spent in the CPU emulation in F-Zero.
That's also why frame skipping in F-Zero doesn't work that well.
- SPC Emulation: 50-60ms
- Graphics (Drawing to the screen): 200 ms
Generally about 50ms per background layer, and another 50 ms for sprites, depending on the number of sprites.
If we have to draw the sub-screen and there are very heavy HDMA effects (like the BOF2's battle transition),
this figure easily bursts 500ms and more.
Emulating the SA-1 (a CPU 3x faster than the main CPU), will add 1500ms to the emulation time and push the total emulation time to beyond 2000ms (that means 30FPS or less). And there are other considerations. Emulating a parallel SA-1 is more complicated that emulating the SPC700. I'm pretty sure you already know, but for the non-technical folks: the main CPU and SPC-700 has limited visibility of each other. Because of that, we don't have to truly keep the SPC700 running in sync with the main CPU cycle by cycle. We only have to sync the SPC700 at much longer intervals apart, and only when the main CPU starts communicating with the SPC700. This provides a significant speed increase (almost 80% speed increase!) This is probably one of the things I did that provided the largest speed increase. The rest of the optimisations only provided modest performance boosts.
But for the SA-1 we will have to emulate both main CPU and SA-1 in lock-step (I think). This puts a much heavier load on the 3DS, switching back and forth emulating both processors just to keep them tightly in sync will definitely add more than just 1500ms to the overall emulation time.
So even in an extreme case, I do not draw anything to the screen at all (in layman's term I skip all frames), I will never achieve a full 30FPS . And that is why I've never considered investing time into emulating SA-1.
The New 3DS will probably do a better job of emulating SA-1 instead.
Last edited by bubble2k16,
My o3ds runs all the games I care about at 59+ fps! I love this project!
@DespyCL - Yes dynarec could help. But it's a tough job and requires a lot of time of just a handful of 30+ games. And how much improvement that will give... I am not optimistic.
But one things for sure: I don't want to go down that path... Rather just get a new 3DS... But if there's any dev who's willing to try, I am sure no one will mind.
And how much improvement that will give... I am not optimistic. But one things for sure: I don't want to go down that path... Rather just get a new 3DS... But if there's any dev who's willing to try, I am sure no one will mind.
Last edited by bubble2k16,
Haha, no problems man. I really appreciate your job since my fav games already runs at almost full speed@DespyCL - It could help. But it's a tough job and requires a lot of time of just a handful of 30+ games.
- Joined
- Feb 10, 2009
- Messages
- 5,484
- Trophies
- 2
- Location
- Sacramento, California
- Website
- lazerlight.x10.mx
- XP
- 5,498
- Country
@bubble2k16 Not the procedural stuff. It won't work there because that doesn't use any texture data, which is necessary in this case. What we used was a combination of Luminosity/Alpha textures (8-bit vs 16-bit Direct color, and pointing at the same data), texture combiners (mainly for the alpha channel), and light environment stuff like its LUTs. The result provides a mimic of a 256 color palette, with entry 0x80 used as entry 0 for transparency because that entry always results in black (it's a normal vector equaling zero-length thing).
Regarding your timings per second, is the graphic drawing happening while the system is doing other things? And with the CPU side, is that just for emulating the CPU, or does that include other things like the creation of polygon lists for the GPU?
Regarding your timings per second, is the graphic drawing happening while the system is doing other things? And with the CPU side, is that just for emulating the CPU, or does that include other things like the creation of polygon lists for the GPU?
@DiscostewSM - I haven't been a 3D hardware person until my recent project this 3DS port, so my knowledge about 3D hardware in general is quite limited. Do you have any source codes available for reference?
The CPU's 500ms is really just the emulating of the main CPU, and the DMA and the HDMA and stuff. Unlike BlargSNES, Snes9x saves a lot of the main CPU registers into memory rather than into the ARM registers, since Snes9x is mainly written in C++.
The creation of the polygon lists falls under the Graphics part, which takes about 200ms for the typical in-game screens of about 3 BGs.
Once the entire frame's emulation ends, the full set of GPU commands (which includes drawing of all the polygons) are flushed to the GPU. And then while the GPU draws this frame in parallel, we continue to emulate the next frame, populating the next frame's GPU commands in a separate command buffer. Then after the current frame's emulation ends, we will wait to ensure the GPU is finished with the drawing previous frame. Then we swap the frame and we flush the current frame's GPU commands.
In a sense the 3D GPU hardware is always drawing 1 frame earlier than the actual emulation is happening. In practical sense, no one can tell anyway.
This is slightly different from what BlargSNES did. If I understood right, BlargSNES flushes the GPU command buffer regularly within the same frame.
The CPU's 500ms is really just the emulating of the main CPU, and the DMA and the HDMA and stuff. Unlike BlargSNES, Snes9x saves a lot of the main CPU registers into memory rather than into the ARM registers, since Snes9x is mainly written in C++.
The creation of the polygon lists falls under the Graphics part, which takes about 200ms for the typical in-game screens of about 3 BGs.
Once the entire frame's emulation ends, the full set of GPU commands (which includes drawing of all the polygons) are flushed to the GPU. And then while the GPU draws this frame in parallel, we continue to emulate the next frame, populating the next frame's GPU commands in a separate command buffer. Then after the current frame's emulation ends, we will wait to ensure the GPU is finished with the drawing previous frame. Then we swap the frame and we flush the current frame's GPU commands.
In a sense the 3D GPU hardware is always drawing 1 frame earlier than the actual emulation is happening. In practical sense, no one can tell anyway.
This is slightly different from what BlargSNES did. If I understood right, BlargSNES flushes the GPU command buffer regularly within the same frame.
Hi, bubble!
Having tested quite a few games (and adding them to the compatibility list), I've stumbled upon some games that suffer from a "dark tint" on certain layers.
Games likes Star Ocean, Super Bomberman 2 and 3, DoReMi Fantasy, and others. Are you aware of the root of this issue, and do you think there will be a solution in the near future?
Thank you very much for your hard work, you have no idea how happy and satisfied you've already made me (and many others) with this emulator!
It's a real blessing!
Having tested quite a few games (and adding them to the compatibility list), I've stumbled upon some games that suffer from a "dark tint" on certain layers.
Games likes Star Ocean, Super Bomberman 2 and 3, DoReMi Fantasy, and others. Are you aware of the root of this issue, and do you think there will be a solution in the near future?
Thank you very much for your hard work, you have no idea how happy and satisfied you've already made me (and many others) with this emulator!
It's a real blessing!
Last edited by yoshinatsu,
Hello! First of all thanks for that awesome emulator. I´m using it and i want to comment a bug i find. I play Super MArio World from the All Stars + SMW USA rom, using cia of v0.35
At bosses #2 Norton amd #4 Ludwig the enemy turns black and allmost imposible to see it.
At bosses #2 Norton amd #4 Ludwig the enemy turns black and allmost imposible to see it.
Did you guys try to save state and then loading the same state? That usually fixes some of the graphical issues in this awesome emulator..
D
Deleted User
Guest
Since people mentioned graphical issues, I also see some layer problem on DKC2 in the second lava level (but the first one is fine though, attached screenshot and savestate), might be related.
There is also some slight layer rendering problem in chrono trigger, so it might all stem from the same issue, just expressed in different way (note how it was there in CT for 0.33 due to screenshot bordering, so probably not a regression if it's the same problem)
There is also some slight layer rendering problem in chrono trigger, so it might all stem from the same issue, just expressed in different way (note how it was there in CT for 0.33 due to screenshot bordering, so probably not a regression if it's the same problem)
Similar threads
-
-
@
Psionic Roshambo:
I like that games can be fixed after the fact, hate that it's being abused via beta tests... And DLC... I was a 7800 owner back in the day and loved Impossible Mission, turns out I couldn't beat it because it was actually impossible lol -
@
Psionic Roshambo:
I never knew about it at the time but a fixed version was available but you had to mail in your broken copy lol
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
Psionic Roshambo:
https://youtu.be/Gy3BOmvLf2w?list=OLAK5uy_k27izUIERfT-RIE1qN1CHIOIkW4h5A9BY Play this song if Hippies are bothering you! lol
-
-
-
-
-
