Its hard to say if its definitely unstable. Different cards may yield different results, so more tests are necessary. If more clock speeds are added, it won't be in the main release branch.
Hacking NDSSFC/CATSFC revival
- Thread starter Deleted member 319809
- Start date
- Views 173,844
- Replies 707
- Likes 15
Its hard to say if its definitely unstable. Different cards may yield different results, so more tests are necessary. If more clock speeds are added, it won't be in the main release branch.
Fixed in commit 16a41b4, pending the next CATSFC release. States made before that commit (i.e. right now, in 1.29), despite having improper sound when loaded, will reload with proper sound after that commit (i.e. if you compile your own plugin or in 1.30); they are not corrupted permanently.
Edit: It's still true that code from later Snes9x versions would help audio-related matters
Oh. Another example of something that could work tons better on non-shaky code... ... which I had totally forgotten about until I started merging branches.
The SNESAdvance-style speed hacks branch. A test build of speed-hacks over 1.29 code using default settings (highest CPU, etc.) runs Super Mario Bros 3 (in SMAS+World), at the map screen, on fast-forward at over 200 frames per second. Speed hacks could also help with the battery usage by allowing the use of lower CPUs than 5 for compatible games.
The SNESAdvance-style speed hacks branch. A test build of speed-hacks over 1.29 code using default settings (highest CPU, etc.) runs Super Mario Bros 3 (in SMAS+World), at the map screen, on fast-forward at over 200 frames per second. Speed hacks could also help with the battery usage by allowing the use of lower CPUs than 5 for compatible games.
With that comment about the immensely improved speed of that particular game, I assume some games that previously required a frameskip of 1 or 2 may no longer need it. So are we looking at some games playing at full speed with no frameskipping? I remember from the SNESAdvance days and after that, speedhacks made the performance of numerous games skyrocket. At least using SNES emulators for GBA and DS. Heard it had similar improvements on PSP as well.
If you add speedhack support btw, would it be possible for you to support them using an external separate .dat file or something like that? The only reason I suggest doing it that way instead of implementing the hacks internally is in case someone wants to build their own custom speedhack file to add new games or hacks. It would probably be easier to simply swap a "snesadvance.dat" file or whatever you might call it here than having to recompile the entire thing every time you want to alter the speedhacks. Or is this simply not possible?
- Joined
- Nov 24, 2008
- Messages
- 428
- Trophies
- 0
- Location
- Somewhere in cali
- Website
- www.youtube.com
- XP
- 370
- Country
Fixed in commit 16a41b4, pending the next CATSFC release. States made before that commit (i.e. right now, in 1.29), despite having improper sound when loaded, will reload with proper sound after that commit (i.e. if you compile your own plugin or in 1.30); they are not corrupted permanently.
Edit: It's still true that code from later Snes9x versions would help audio-related matters
Awesome pancakes! Looking forward to it and the other new improvements
Also, I have a little request. Naturally if it's too complicated to implement, then just don't bother. But I was wondering if there could be an option to manually move the game screen up or down.
In aspect ratio, there's these options, full screen non aliased, bottom screen, top screen, middle screen and full screen aliased. While the full screen covers it, it adds additional lag to the game. The bottom screen option
removes a good portion of the top screen, while the top screen does the same to the bottom screen.
The middle screen is however almost perfect. But in some games, the top or bottom is a little bit more prioritized, so if you could manually set the screen for example a few pixels up or down, that would make certain games perfect. Like an extra option where you could set the values manually.
Like for example:
Terranigma - Middle screen aspect ratio is almost perfect, but it cuts the text a little bit of the bottom text box. While the top text box has a few extra pixels to spare and it would still be readable.
If you could manually move the screen a few pixels up, then it would make the game screen perfect and both text boxes would be perfectly readable.
Another one is:
Super Castlevania IV - In one of the earlier stages, you couldn't see if there was a platform on the bottom with the middle screen aspect ratio. But if you would be able to manually move the screen one pixel down, then you suddenly would be able to see the outline of the platform without the need to switch to bottom or full screen aspect ratio.
For the text being cut off by vertical resolution limits, it might be a nice feature to have the ability to scale only certain individual layers of the background instead of either scaling all of them or moving the entire image up and down. That could serve as a solution for text being cut off in some games while the rest of the graphics in the other layers would still look clean and unstretched.
If I recall correctly, SnemulDS had an option like this. You could choose in the options to scale only layer 3 of the background i believe while keeping the other layers unaltered (from playing around with games in SNES9x, layer 3 seems to be commonly used for text in RPG's, and platformers often use it for HUD related graphics). On top of this, SnemulDS supports scaling in a different manner from how other emulators would do it. Instead of just scaling random lines throughout the image (so that the entire screen appears squished), you can choose a different method that cuts out the pixels from just the middle of the screen instead. This means about 31 horizontal lines of pixels are sliced out in the middle of that layer instead of being spread out over the screen. By doing this, text and graphics at the top and bottom of the screen don't appear squished. This is a nice feature for RPG's, platformers, or any game that usually keep their text or HUD items almost exclusively at either the top or bottom of the screen, but don't make much use of the middle part of that layer.
Of course if you come across a game that DOES use the middle of that layer for important graphics, you'll be missing some detail. But those are just some thoughts on the matter and possibilities. Dunno how difficult it would be to implement features like that.
If I recall correctly, SnemulDS had an option like this. You could choose in the options to scale only layer 3 of the background i believe while keeping the other layers unaltered (from playing around with games in SNES9x, layer 3 seems to be commonly used for text in RPG's, and platformers often use it for HUD related graphics). On top of this, SnemulDS supports scaling in a different manner from how other emulators would do it. Instead of just scaling random lines throughout the image (so that the entire screen appears squished), you can choose a different method that cuts out the pixels from just the middle of the screen instead. This means about 31 horizontal lines of pixels are sliced out in the middle of that layer instead of being spread out over the screen. By doing this, text and graphics at the top and bottom of the screen don't appear squished. This is a nice feature for RPG's, platformers, or any game that usually keep their text or HUD items almost exclusively at either the top or bottom of the screen, but don't make much use of the middle part of that layer.
Of course if you come across a game that DOES use the middle of that layer for important graphics, you'll be missing some detail. But those are just some thoughts on the matter and possibilities. Dunno how difficult it would be to implement features like that.
Ohhh thanks for the points said
Altough im a programmer, i barely know something else different from Java, C#, Visual Basic, Delphi.
I will get the Snes9X code and see what can i do/learn to help in somehow.
This would be a nice feature, but it would still create the problem Killermech is having. He mentioned that using full screen, the text is fine, however it decreases performance, so the problem is the processing power it takes for scaling the image. Just scaling a text layer would have the same effect as scaling the whole image performance wise, so it is really of no benefit adding.
SnemulDS can do such things because it uses the DS's hardware for graphics. Each layer is already split up into its different memory banks and has its own registers and background modes that would allow the DS hardware to scale things efficiently. With CATSFC, everything is handled through software, so each additional step added between the image generating process and the image output process will decrease performance.
No. It will not reduce the need for an auto-equivalent frameskip of 2, because the DSTwo-DS link is then too congested to return button presses. Auto frameskip at 2 is of paramount importance, because the lack of waiting for ~60 milliseconds is what killed the button sync from NDSSFC 1.05 to CATSFC 1.28.
However, what it may mean is less jerky frame rates, needing less CPU emulation load during rendering-intensive frames. For certain games, you would also be able to switch the CPU frequency down to [1] 300 MHz or [0] 240 MHz for improved battery life.
Using a .dat file was the plan all along. Currently, only a few speedhacks are hardcoded, but that was for quickly testing the implementation of the SNESAdvance speed hack opcodes. I didn't feel like implementing a text file format again without proof that it actually mattered during emulation. The testing has not concluded. I believe it's not stable enough yet.
Yesterday I tested a very speed-hack-heavy game that was specified in snesadvance.dat, Super Mario All-Stars + World, and it corrupted the screen in its Mario World sub-game but played correctly, and emulation was correct for at least Mario 3.
Or maybe I just had the wrong game by CRC32...
That would create too many checks in the code; it would check for scaled rendering of a layer every 4 pixels drawn. It would slow down even when unscaled, but when scaled, it would slow down much more, needing to write 4 pixels in software to half-colours in an 8-pixel area. Currently the scanline is also not passed to the drawing routines either.
And making the Snes9x code itself aware of scaled rendering hinders porting efforts.
CATSFC maintenance release 1.30 is now out, and has mostly only a fix for this issue (and a few issues with the Spanish translation).
Thank's for the update 1.30. That diffidently fixed the save state sound issue on Mega Man X2 and 7. Also would like note that i find both those much more playable now. Example, In Mega Man 7 in the very first level with the steam roller guy, You can actually see all of him and there is very little slow down in the fight.
Cheers for the fast fix!
Anyways, as you didn't reply to my other post. Maybe you misunderstood my request to be related to the other. I don't want any complicated stuff as mentioned earlier. What I was wondering about is if there could be a simple option to move the 'display area' up or down manually in normal sized.
Like in aspect ratio bottom, top and middle. All display the game's natural size. But due to the NDS's aspect ratio limitations, it can only display a particular area (unless scaled).
My request was, if there could be an option to simply move the display area you can see on your NDS up or down manually.
If needed, I can add some pictures of what I mean tomorrow if there's further confusion.
Anyways, as you didn't reply to my other post. Maybe you misunderstood my request to be related to the other. I don't want any complicated stuff as mentioned earlier. What I was wondering about is if there could be a simple option to move the 'display area' up or down manually in normal sized.
Like in aspect ratio bottom, top and middle. All display the game's natural size. But due to the NDS's aspect ratio limitations, it can only display a particular area (unless scaled).
My request was, if there could be an option to simply move the display area you can see on your NDS up or down manually.
If needed, I can add some pictures of what I mean tomorrow if there's further confusion.
Yes please. I'd also like an idea of your preferred implementation. I don't see it as very practical to have 34 options in the aspect ratio dialog, for instance.
Hypothetical option in Video&audio:
Pixel offset: Show all, Show all (smoothed), 0 cut from top, 1 cut from top, 2 cut from top, 3 cut from top, ..., 30 cut from top, 31 cut from top, 32 cut from top
Hi Nebuleon and all,
And what about an option putting black bands on the left and on the right of the screen ? In that case, you will always have the full screen without any distortion.
Is it hard to be implemented ?
It needs about 8 times more processing than the full-screen smoothed vertically-crushed option. You might end up with 10 frames per second, garbled audio or stuck controls, or a combination of them.
Alright, since this comment I have found two things:
* 200 frames per second on the SMW3 map on fast-forward is the speed offered by regular CATSFC.
* Speed-hacked CATSFC is writing patched opcodes in the wrong places. Likely the Snes9x header removal and ROM memory map de-interleaving makes ROM offsets incompatible with SNESAdvance. So it's patching Mario World in SMAS+World with a byte that's meant for another game. If that is so, then all speed hacks in the .dat file will fail if used.
Alright here goes. I just took a random picture and they're all just examples. As I know the current display area is bigger than what I put in the example.
First to explain what the things are in the pictures. The red bar represents the "Display Area", this is what you currently see in your DS while playing (I darkened the area you won't see while playing to further empathize the effect).
1. This first picture is, Aspect Ratio - Middle Screen, Square pixels
It simply, focuses on the middle screen. But the problem in this one, is that it cuts the text a bit. So the only way to see it, would be to change to Bottom Screen, Square pixels (or scaled).
2. In the 2nd picture is, Aspect Ratio - Bottom Screen, Square pixels
Focusing on the bottom part of the screen, but missing out a big deal on the top area.
3. Lastly, this is, Aspect Ratio - Top Screen, Square pixels
Same as the previous one, but instead focuses on the top area.
These three pictures are merely to give an understanding of what I meant earlier by Display Area. Now that that's taken cared of, to the actual idea / request.
4. Now the request is simply. It's to be able to move the Display Area manually. For example, in the first picture lets say that the player doesn't really care what happens on the top part, but wants to be able to read the text without having to change aspect ratio. But he doesn't want to cut too much of the top area by selecting Bottom screen aspect ratio as sometimes things do happen up there.
He simply wants to be able to take down the display area a few pixels so he can read the text fully and at the same time just sacrifice the pixels on the top area the game doesn't need. So maybe it looks like this:
5. Now for the idea as to the actual implementation
I thought this could be added in either Video & Audio or in Options. I noticed that in the Video & Audio, there was an empty spot at the bottom that would fit it perfectly. Naturally, this can go in Options as well, below CPU frequency.
The Request
As for how it would roughly look (Naturally names can be changed and whatever. They're simply there to represent the feature).
As for what it means, it's quite simple. First you add a new Aspect ratio option, which can be changed at will (the display area). You change it through the new option added in the bottom Display Area.
100 simply represents the middle. Having it on 100 is the same as
Aspect Ratio - Middle Screen, Square pixels. But, by pressing the Left or Right pad. You can adjust the number to for example lets say it caps at 80 and 120. So if you change it to 101, the Display Area will move 1 pixel up. If you have it at 110, the Display Area will move 10 pixels up. If you have it at 90, the Display Area will move 10 Pixels down and so on.
For example in the 4th picture, the display area was moved a bit down so he could read the text. Let's say that for example in that screen, the Display Area setting is 90.
That's pretty much it. If there's anything you're wondering about or didn't fully understand. Then by all means just ask away
First to explain what the things are in the pictures. The red bar represents the "Display Area", this is what you currently see in your DS while playing (I darkened the area you won't see while playing to further empathize the effect).
1. This first picture is, Aspect Ratio - Middle Screen, Square pixels
It simply, focuses on the middle screen. But the problem in this one, is that it cuts the text a bit. So the only way to see it, would be to change to Bottom Screen, Square pixels (or scaled).
2. In the 2nd picture is, Aspect Ratio - Bottom Screen, Square pixels
Focusing on the bottom part of the screen, but missing out a big deal on the top area.
3. Lastly, this is, Aspect Ratio - Top Screen, Square pixels
Same as the previous one, but instead focuses on the top area.
These three pictures are merely to give an understanding of what I meant earlier by Display Area. Now that that's taken cared of, to the actual idea / request.
4. Now the request is simply. It's to be able to move the Display Area manually. For example, in the first picture lets say that the player doesn't really care what happens on the top part, but wants to be able to read the text without having to change aspect ratio. But he doesn't want to cut too much of the top area by selecting Bottom screen aspect ratio as sometimes things do happen up there.
He simply wants to be able to take down the display area a few pixels so he can read the text fully and at the same time just sacrifice the pixels on the top area the game doesn't need. So maybe it looks like this:
5. Now for the idea as to the actual implementation
I thought this could be added in either Video & Audio or in Options. I noticed that in the Video & Audio, there was an empty spot at the bottom that would fit it perfectly. Naturally, this can go in Options as well, below CPU frequency.
The Request
As for how it would roughly look (Naturally names can be changed and whatever. They're simply there to represent the feature).
As for what it means, it's quite simple. First you add a new Aspect ratio option, which can be changed at will (the display area). You change it through the new option added in the bottom Display Area.
100 simply represents the middle. Having it on 100 is the same as
Aspect Ratio - Middle Screen, Square pixels. But, by pressing the Left or Right pad. You can adjust the number to for example lets say it caps at 80 and 120. So if you change it to 101, the Display Area will move 1 pixel up. If you have it at 110, the Display Area will move 10 pixels up. If you have it at 90, the Display Area will move 10 Pixels down and so on.
For example in the 4th picture, the display area was moved a bit down so he could read the text. Let's say that for example in that screen, the Display Area setting is 90.
That's pretty much it. If there's anything you're wondering about or didn't fully understand. Then by all means just ask away
to killer mech, I think that the current ratios he put into play work excellent considering the hardware constraints. I would prefer him to work towards speed and compatibility.
Similar threads
