Hacking NDSSFC/CATSFC revival

[Hanafuda]

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.

I agree. For those games where a full screen view really matters, setting 4 (smoothed) really is quite acceptable.

 

[Killermech]

I'm not arguing that the current ratios are bad. In particular games, some prioritize top or bottom screen a little bit more. In which can't be adjusted since you only have bottom / top / middle. You're simply just
relocating the display area. As for using full screen mode, performance is reduced by about 30% which is a lot for just wanting to be able to see an extra pixel down or up.

So being able to move the display area, is something that won't affect hardware / performance or anything. As you're just relocating the display area as far as I know.
The only thing I'm requesting is an option to be able to adjust it up or down manually.

Naturally in the end, I'm more than happy that he has revived this project and for all the amazing stuff he has already done. Right now, it's already at a point where performance wise, is at a place we never thought we would ever have. So if he doesn't want to do it, then I won't hold it against him or anything. But it would be a nifty feature which I think would be appreciated by many.

 

[Firebug2009]

taping into the DS's wireless to play 2 player games (WWF games, Mortal Kombat, Secret of Mana,Zombies ate my Neighbors..etc) would be a bitchin' addon lol

 

[Charli]

I actually just got a translation to German on IRC. If you'd like, you could review it. I would message you a GitHub commit once it's in the language file.

I finally found some time to have a look at the translation. I've made some suggestions in the commit on GitHub

 

[Deleted member 319809]

[...]

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

I would like to gently point you towards 1.30 and its lack of empty space in the V&A menu

That aside, thanks for the pictures. Here's a bit of info you were missing (I deal with that information daily, but you don't, so it's normal you were missing it):

* DS resolution = 256x192
* SNES lo-res = 256x224 (NTSC), 256x239 (PAL)
* SNES hi-res = 512x448 (NTSC), 512x478 (PAL)

With that out of the way, I also haven't heard of PAL folks saying their games were cut off, so really there are only 32 viewports to deal with, from scanlines 0 .. 191 to scanlines 32 .. 223.

Perhaps, then, I could add the 32 viewport values at the end of the existing values?
[0] Entire screen
[1] Top, square pixels
[2] Bottom, square pixels
[3] Middle, square pixels
[4] Entire screen, smoothed
Lines 0-191 (top)
Lines 1-192
Lines 2-193
. . .
Lines 15-206
Lines 16-207 (middle)
Lines 17-208
. . .
Lines 29-220
Lines 30-221
Lines 31-222
Lines 32-223 (bottom)

Essentially you were proposing an option with 32 values, and I don't know how tedious that would be to select with the Left and Right keys when only one press is recognised per 1/5 second. What would be more intuitive and quicker perhaps, would be a slider. But the GUI code is a mess, and I don't really want to touch it. Or a menu during emulation, but that would probably kill batteries and distract from the game.

 

[Normmatt]

Nebuleon you could always do the interface stuff on the nds side and just use the mips side for emulation. This way would require you to make a custom arm7/arm9 code but it could bring some speedups.

 

[Killermech]

@Nebuleon
Thanks for the reply and the useful information! Didn't know about the spot in 1.3 as I was still using 1.29.

As I said before, I just wanted a simple request to enhance the gaming experience slightly more in certain games. So I really don't want it to become a problematic feature that would consume more time than other features that would have a higher priority.

So I have another idea for implementation if it's possible, to avoid messing with the Gui too much.
How about having the new aspect ratio (the one you can adjust) in the Gui, but having the setting / values to adjust it in an external file? Like for example in the .ini file. That way you can simply change the value in the file and it would apply to the new aspect ratio option when you start up the emulator.

Naturally I have no idea if this would be too hard to do or anything. But it would be more effective than having the setting in the Gui directly since it seems that would involve some problematic programming.

 

[Deleted member 319809]

@Nebuleon
Thanks for the reply and the useful information! Didn't know about the spot in 1.3 as I was still using 1.29.

As I said before, I just wanted a simple request to enhance the gaming experience slightly more in certain games. So I really don't want it to become a problematic feature that would consume more time than other features that would have a higher priority.

So I have another idea for implementation if it's possible, to avoid messing with the Gui too much.
How about having the new aspect ratio (the one you can adjust) in the Gui, but having the setting / values to adjust it in an external file? Like for example in the .ini file. That way you can simply change the value in the file and it would apply to the new aspect ratio option when you start up the emulator.

Naturally I have no idea if this would be too hard to do or anything. But it would be more effective than having the setting in the Gui directly since it seems that would involve some problematic programming.

It would be easy enough to add it to the GUI, and harder to put it in another .ini file. The issue I have is that it would be tedious for the user to flip through the options, is all.

 

[Killermech]

It would be easy enough to add it to the GUI, and harder to put it in another .ini file. The issue I have is that it would be tedious for the user to flip through the options, is all.

Here I thought it would end up being easier to have the value in an external file. I guess that pretty much sums what kind of a programming wizard I am
As for the values, it doesn't have to be pixel by pixel either. The setting could be adjusted 5 pixels up / down per change, instead of 1 pixel at a time. So if it starts with 100 Default, and can go down to 80 and up to 120. Then it would only be 8 extra values and the Gui lag shouldn't matter too much compared to if it adjusted 1 pixel at a time which would make it 40 values instead.

 

[2ndApex]

taping into the DS's wireless to play 2 player games (WWF games, Mortal Kombat, Secret of Mana,Zombies ate my Neighbors..etc) would be a bitchin' addon lol

NesDS style NiFi would be awesome but IDK if the Supercard SDK does that yet.

 

[gusmento01]

Great work, thanks, Donkey Kong country works great now.

 

[Deleted member 319809]

Great work, thanks, Donkey Kong country works great now.

You're welcome

*looks to the left*
Would you like to contribute a Portuguese localisation to the emulator, perhaps? It would help out some of your fellow Brazilians who don't understand English, as well as those in Portugal.

 

[Deleted member 319809]

Can anyone make enough sense of the GUI's cheat option, scrolling and drawing code to add some scrollers to the cheats interface?

The cheat GUI is in source/nds/gui.c, functions cheat_menu_init, reload_cheats_page, cheat_option_passive, etc.
The scrolling and drawing code is in source/nds/draw.c, functions draw_hscroll_init, draw_hscroll, draw_hscroll_over, and the various uses of the passive_function in source/nds/gui.c.

In the latest code on GitHub, multipart cheat codes now appear as one line in the cheat interface again, at the cost of making cheat options activated with [A] instead of the directions, ← and →. I thought it would be cool to add scrollers so the directions can be used for something useful, but it looks like I need to initialise and finalise some scrollers in the code, probably every time a cheat page changes OR the player presses a key to activate a new cheat OR when new cheats are loaded, EXCEPT when the menu first loads, EXCEPT if there are cheats already loaded when the menu first loads.

 

[gusmento01]

You're welcome

*looks to the left*
Would you like to contribute a Portuguese localisation to the emulator, perhaps? It would help out some of your fellow Brazilians who don't understand English, as well as those in Portugal.

I can help with the translation. I will start tonight.

 

[Diego Liberal]

I can help on the translation too, but i didn't quite figured out how to do it õ.O

Edit: Forget it, i managed, just dealing with localization now o-o
And thinking if it will accept words like : opção... does it acepts this kind off characters?
ç õ ã é í ...

 

[Deleted member 319809]

I can help on the translation too, but i didn't quite figured out how to do it õ.O

There are instructions in the readme on GitHub, as well as at the top of the file itself, CATSFC/system/language.msg. If you don't know how to hook the translation into the code, I can do that. You can also test your translation live in the emulator by editing the English block instead of adding a Portuguese block.

The file is UTF-8 encoded. That means you need to open it with the correct encoding in your text editor, but you can use characters with accents, like ç and ã.

You can send me the result in a variety of ways, including a PM on this forum.

 

[Diego Liberal]

There are instructions in the readme on GitHub, as well as at the top of the file itself, CATSFC/system/language.msg. If you don't know how to hook the translation into the code, I can do that. You can also test your translation live in the emulator by editing the English block instead of adding a Portuguese block.

The file is UTF-8 encoded. That means you need to open it with the correct encoding in your text editor, but you can use characters with accents, like ç and ã.

You can send me the result in a variety of ways, including a PM on this forum.

Ohh i see, thanks for helping me help you
I noticed the encoding, so i'm already doing in UTF-8

Portuguese tend to be longer than english, so i wonder if it will break any aesthetic, but i will see that after i do this first rough translation.
I need find better words for many things, like "saved state", but this is a localization issue, so pay no attention for this

 

[Adrock4]

This isn't exactly a big deal, but I think development of this has progressed to the point where it might be a good idea to have a new name, simply because what we have now is pretty substantially different from what was CATSFC.

 

[Rydian]

I re-submit my vote for NEBSFC if a change happens.

 

[Deleted member 319809]

I re-submit my vote for NEBSFC if a change happens.

The "naming subthread" starting at post #24 didn't really end, I guess... But I thought it had, so I shall explain myself more.

I had decided to keep the name as CATSFC for practical reasons, not going to NEBSFC. I considered TempSFC and reverting to NDSSFC, but those weren't practical enough. I had weighed multiple issues:
* Renaming the system directory to NEBSFC messed with auto theme installers. Auto theme installers recognised NDSSFC, of course, and some recognised ShadauxCat's CATSFC, but they would not recognise NEBSFC until they were updated. The DSTwo "scene" seemed barren before I barged in and made my boatload of updates for CATSFC, so it did not seem wise to rename stuff and break it.
* Renaming the system directory to NDSSFC would have caused massive confusion as to the origin of updates. I imagine users would have thought the Supercard Team was doing updates and asking on the Supercard Forum about it instead of GBATemp.
* Renaming the project releases messed with filetrip. Filetrip shows "You may want the latest version instead: ..." prominently at the top. Having it as NEBSFC would mean that, unless a user knew to check GBATemp for new forks, they would never have seen the newer version. Keeping it as CATSFC, those with bookmarks to CATSFC 1.1 on filetrip, or searching CATSFC to download it, became aware that someone picked up the torch. I actually saw a few people on the Supercard Forum start talking about my improvements in January; they must have searched for CATSFC on some search engine.
* It seemed like too much effort for nothing to update the repository.
* ShadauxCat's intent was to have one repository for the community to use. The repository is named CATSFC. This was stated in post #78.