TWiLight Menu++ has all of the widescreen codes in "sd:/_nds/TWiLightMenu/extras/widescreen.pck", and they're automatically enabled once you launch a game with the 16:10 aspect ratio setting.
If there's any of those screen swaps that have been missed, the game will presumably stay on the "wrong" screen until the next reset. In short: the game needs testing to confirm that we've caught all the screen swaps.
There are indeed a few unregistered screen swaps who mess up the screens until a reboot.
This is pretty annoying; so I completed the code with the remaining screen swaps I found, namely the Krak Pot (alchemy) and Battle Records menu screens.
This is for the EUR version of DQ9, but i guess you can easily adapt it for other regions.
Ookamiden has issues on the sections where it gives the player a 2d image to trace a silhouette.
Expected Behavior: The top screen displays a 2D image, it slides down and fills the bottom screen fully, letting the player trace the image and the game recognizes it.
Actual Behavior: The top screen Displays a 2D image, it slides down and the image gets compressed on the bottom screen, and when tracing this version the game does not recognize it.
You can actually swap the top and bottom screens using the in-game TM++ menu (L+Down+Select). Since that game uses pre-rendered backgrounds, any codes making it true 16:10 will change the alignment of collision and mess up the game, but you can force the top screen to stretch and fit the full screen by holding Y while the game is booting if you're cool with the slightly stretched image. That's actually how I've been playing it and it's IMO the best way to experience the og RE
Hello all, I'm trying to figure out how to get widescreen working in TWiLight Menu++ for a romhack.
The romhack in question is the Super Mario 64 DS widescreen patch by @gamemasterplc, which is linked next to the widescreen cheats for SM64DS and adjusts the 2D UI elements so they're scaled correctly. After a bit of struggle I learned in this open issue: Force widescreen patch for ROM hacks that the widescreen setting in TWL Menu++ will only work for games with widescreen cheats in the widescreen.pck file, but romhacks change the CRC so they don't match.
I can still run the romhack in widescreen if I'm willing to install the widescreen patch into the TwlBg.cxi that's in luma/sysmodules (and stretch out all the incompatible games, too). I tried opening widescreen.pck with Notepad++ and with a cheat code editor but I'm not really sure how to edit this file on my own. Any advice?
Hello all, I'm trying to figure out how to get widescreen working in TWiLight Menu++ for a romhack.
The romhack in question is the Super Mario 64 DS widescreen patch by @gamemasterplc, which is linked next to the widescreen cheats for SM64DS and adjusts the 2D UI elements so they're scaled correctly. After a bit of struggle I learned in this open issue: Force widescreen patch for ROM hacks that the widescreen setting in TWL Menu++ will only work for games with widescreen cheats in the widescreen.pck file, but romhacks change the CRC so they don't match.
I can still run the romhack in widescreen if I'm willing to install the widescreen patch into the TwlBg.cxi that's in luma/sysmodules (and stretch out all the incompatible games, too). I tried opening widescreen.pck with Notepad++ and with a cheat code editor but I'm not really sure how to edit this file on my own. Any advice?
It should already be compatible. Just turn on widescreen for that ROM hack (if it's not turned on globally in TWLMenu++ Settings).
If it doesn't activate widescreen when launching it, please post a link to the patch you used.
It should already be compatible. Just turn on widescreen for that ROM hack (if it's not turned on globally in TWLMenu++ Settings).
If it doesn't activate widescreen when launching it, please post a link to the patch you used.
You're right, since I had to manually add the cheats in for circle pad compatibility, I assumed I'd need to manually add the widescreen cheats. It was as simple as disabling the redundant widescreen cheat! Thanks Robz.
EDIT: I've hit the character limit in the OP, so I'm commandeering this post.
Nice!
I've just edited this post to move a few of these down to the bottom as I hadn't considered that a lot of games use the touch screen as the primary display, so things like the Zelda games won't gain anything from being displayed in widescreen on 3DS. The games in the top half of the list use the top screen either primarily or at least a decent amount (Dragon Quest IX and Mario & Sonic at the Olympic Winter Games both swap screens depending on gameplay mode), but for now I'd say it's probably not worth adding any of the cheats from the second screen list to usrcheat.dat.
~~~
Working
P
This code handles dual-screen 3D (i.e. top screen widescreen, bottom screen 4:3). It's only a dual-screen 3D game insofar as there's a 3D Pac-Man on the touch screen, which is really just HUD stuff, but this looks slightly nicer than the previous code which crunched him.
Chalk another one up for the generic alternating widescreen fix (modified slightly as I hooked the actual AR reading here).
This code pokes a different address (0x0203422C) to fintogive's original code; I just went and remade it from scratch. I don't know why fintogive's code doesn't match mine, but on my end fintogive's code does nothing while mine works without issues. It's possible this game uses different addresses, either by level or across reboots or something, since a different code apparently worked for fintogive. The address fintogive is poking does contain 0x1555 normally, like an aspect ratio address should, but the rendering is completely unchanged for me when this address is poked.
Same pointer-in-a-pointer approach as How to Train Your Dragon.
NB: This is not the same game as Penguins of Madagascar on 3DS, which is based on the film and is a terrible game. This game and the sequel below are based on the TV series, The Penguins of Madagascar, and are really fun little multiple-character puzzle-platformers in the vein of The Lost Vikings.
This game isn't anything special, I just thought it would be interesting to try something a bit different. In this game, you play on the touch screen and the default controls are mostly stylus-based, but you can switch to d-pad controls in the options. I tied the widescreen hack into that setting, so if you play with stylus controls, you'll get normal touch screen 4:3, but if you switch to the d-pad controls, gameplay is swapped to the top screen and the widescreen hack is applied.
Stylus controls <---> D-Pad controls
As usual for very 3DS-specific codes, there's also a normal 16:9 code here for emulator users.
Why are you even playing this, Rayman 3D is the same game.
Mildly interesting: along with Need for Speed, this is one of the few games that actually regularly polls the aspect ratio value, so you can change it and see the result immediately, not just the next time an area loads. Fun to goof around with in real-time.
The four addresses this code is hitting are: the first [intro/training], second [VS Mode], third [Slalom races] and fourth [all other races]. Noting this here because I had some difficulty finding what affected what while porting to Europe.
This game is a jerk, the aspect ratio is only kept in an accessible area of memory very briefly, then it moves into ARM9 memory, which Action Replay codes can't see. This code hits the value before it gets loaded into ARM9.
The menus in this game are simultaneously dual-screen 3D and alternating 2D/3D, so this code handles toggling widescreen on and off in those. Alternating 2D/3D is the one case where even emulator users will want the touch screen's 3D to be in 4:3, so there's no separate emulator code here. Technically, the gameplay is actually in dual-screen 3D too, but the touch screen map seems to handle its aspect ratio separately and I couldn't immediately find how to resolve it. Since that already leaves it in the state we want it on 3DS, I'm done with this code.
This game is originally played on the touch screen. This code swaps gameplay up to the top where it can be widescreened, and also handles the dual-screen 3D cutscenes, running the top screen in widescreen while the bottom screen remains in 4:3.
Code summary: 1) widescreen the title screen, 2) prevent gameplay from switching to touch screen, 3) hook into where gameplay AR gets loaded into a register, 4) hook into where (dual-screen) cutscene AR gets loaded into a register 5) custom ASM to fill the registers with appropriate widescreen values.
Since this code is very 3DS-specific with the screen swapping and the top-screen-only widescreen, I've also included a normal 16:9 code for emulator users.
This code swaps the overworld, battle and tutorial gameplay up to the top screen. In my testing, all of the touch features can be used with buttons instead, so swapping the screens should be fine.
The 16:9 code is for emulator users, and hits, in order: 1) tutorial areas and the incubator room 2) the space map when you hop between planets, 3) overworld gameplay and battles, 4) the load game screen.
This game normally runs on the touch screen, but this code switches gameplay to the top screen. The game has optional touch controls, but if you use the button controls you should be able to play no issues with screens swapped.
In addition to the standard cheat code, if you're playing USA Rev 1, there's also an much better patch by @gamemasterplc. This patch adds 16:10 widescreen support to 2D elements like menus, text boxes, etc. as well.
Some of the Party Games are played on the touch screen, this code handles disabling widescreen when those games are in play. Since that makes this code very 3DS-specific, I've included a normal 16:9 code for emulator users as well.
I tested on a clean Japanese version ROM. There is an English fan translation for this game which I didn't test, but in all likelihood this would work fine with that too.
This game alternates between the top screen (most gameplay) and the bottom screen (track editor). The game is also pretty obnoxious about how it handles reads of the aspect ratio, so this code hooks input in order to write another hook into the ITCM area (outside of the range of the Action Replay engine) to run a custom routine to adjust the aspect ratio based on which screen is currently handling 3D. It's complicated, but it works.
There's also a code for emulator users which widescreens both screens.
This game alternates display across the top and bottom screens depending on gameplay mode as well as cutscenes, so this code corrects for that and only adjusts the top screen.
For emulator users, there's also a code which widescreens bottom-screen stuff as well.
This game is a goddamn mess of offsets, I swear every camera angle must use an independent aspect ratio offset. On the upside, this did mean I was able to leave things like bottom-screen cutscenes in 4:3. I also left dual-screen cutscenes in 4:3 (top screen stretched) because most of the action seems to occur on the bottom screen anyway, at least in early-game cutscenes.
In order, the addresses affect: offset 1 - general overworld gameplay, some cutscenes, 2 - enemy encounter zoom effect, 3 - battles, 4 - Oz's shop, 5 - dialogue scenes, 6 - intro cutscene.
Do note that this is a very 3DS-centric code since it consciously makes the top screen widescreen while leaving the touch screen alone. so there's also a dual-screen widescreen code that emulator users can take advantage of if they're playing the USA version.
3D in this game alternates between the top screen (most of everything) and the bottom screen (e.g. the "matchup" screen), but this code currently just widescreens everything, so touch screen stuff looks crunched. I don't consider that significant enough to put this under Issues, but I do intend to come back to it and see if I can fix the touch screen stuff. For emulator users, this code is already perfect.
These next codes are tested but have significant issues. They "work" but have major flaws affecting how enjoyable they are.
This code forces gameplay to be on the top screen, but your enjoyment may be hampered by the broken transition effect between screens and the fact that the sky is now on the bottom screen.
Like most of Griptonite's games, this one seems to adjust its camera based on how much you can see horizontally, so this runs "vert-". In addition, the player's gun is not affected, so it looks wider than intended. Neither make the game unplayable on their own, but it's more problems than you really want to see.
This game is less than ideal in widescreen because gameplay varies between top and bottom screens (e.g. overworld on bottom screen, normal races on top screen, those awful balloon popping games on bottom screen). The code in its current state has an incomplete handling of correcting for this, so while the (touch screen) overworld is in 4:3 and normal races are in 16:10, some areas like the (touch screen) balloon popping challenges are also displayed in crunched 16:10 on the touch screen.
Also included is fintogive's original 16:9 code, for emulator users.
This game is the worst in the series for widescreen. Each game in the series put successively more emphasis on the top screen, and we can't widescreen 2D segments. In the first game it was just a menu, not too bad. Second game, it's used for menus but also an expanded view so you can see the sky. In the third game, the whole orientation has flipped and gameplay is on the top screen.
So this code swaps the overworld down to the touch screen, so you can play Star Force 3 like in the first two Star Force games, with widescreen battles. It's playable, but you'll encounter issues using the interface since you're expected to interact with a lot of things using the touch screen. All of the touch features still work, but the buttons are on the top screen and you need to touch the equivalent place on the touch screen.
Hacked by request; this game is played entirely on the touch screen and touch control mechanics are layered throughout, so while this code flips the screens, realistically the game just isn't playable. It's all touch this button, drag these coins to the piggy bank guy (I don't know the pig's name), tap these enemies to shoot at them. Don't bother using this.
Europe-only because the USA release is infested with DGamer and this hack is so useless I figured it was only worth doing once.
This group of codes are currently untested and/or in-progress.
This one's pretty weird, it does use 0x1555 for some things, but not in the same way as other games. I followed where it was writing it out to and found some other display parameters right next to where 1555 ends up which adjusted the aspect ratio.
What a monster, but this time, a pretty neat and tidy monster unlike the previous code I made for this game. I can't be bothered going through what every part of this code is doing, so here's a summary: 1) widescreening gameplay, 2) widescreening character creation, 3) hooking writes to the top/bottom screen register, 4) having the game write the results of any screen-swaps into 0x2000000 instead of the real register 5) having the game read from 0x2000000 instead of the real register to determine unique screened behaviors like disabling input while the menu is up.
This code has been tested somewhat, but I really want to give it some more before adding it to the working section since it's so much more complex than any other games' hacks that I've worked on.
OK, this code is a bit of a mess, so I'm actually going to go through what each part is doing separately. You can tell where a code ends by the D2000000 00000000 which ends each section.
The first code (starts with 5216A49C) is affecting the aspect ratio in normal gameplay and cutscenes, etc. The stock game adds together 0xFB5 and 0x5A0 to make 0x1555, so that part is instead adding 0xFBA and 0x9E0.
The second (921FEC70) and third (92242E80) codes are affecting widescreen display of the character creation screen. I'm patching it in two places because it seems to be a race condition between the cheat engine and the game, with the engine not getting to the first address fast enough to stop it being propagated to the second. In an emulator like DeSmuME where cheats are "instant", the second part isn't necessary, but it is needed on hardware.
The fourth code (521BF1F8) is preventing the screen from swapping during gameplay and cutscenes, because this game is originally a bottom-screen-only affair. However, this causes some problems addressed below.
The fifth code (92101CE0) is first checking some timer address in order to wait a couple of seconds before writing out the payload, preventing a crash--I suspect anti-piracy or something, but the issue doesn't occur in emulators so I have no way to debug it--then replacing the code that handles whether the player character is interactive or not (originally, input was disabled when the player is on the top screen, because in the stock game, that means the inventory is in use) with a branch to a custom ASM hack. Instead of checking which screen is running 3D, that ten-line custom routine checks an address in memory which determines whether the inventory or other menus are currently being displayed and disables input only if that is the case.
The sixth code (21CAD18) re-enables opening the Camp menu with X button, which is otherwise disabled when 3D is on the top screen.
So I was definitely wrong about being able to write a generic routine to handle these types of games--not that I think it's impossible, just beyond my capability. Even so, here's Dragon Quest IX forced to run in top screen widescreen instead of on the touch screen. The only reason this ran on the touch screen seems to be that you can control the player using a sort of virtual analog stick, but Super Mario 64 DS did the same thing and runs on the top screen. I find the touch controls awful, but I think this setup actually improves them since there's no stylus blocking your view of what the hell you're doing.
This code is in a bit of a transitional state. The current code has been reworked to be much simpler, and basically just writes to the screen-swap register once then redirects all further screen swaps and reads to junk memory. It's basically the same approach but done better, doing a better job of letting the game handle a fake version of the screen register with unmodified behavior. On the other hand, we're only writing out the correct screenedness once, at the very beginning of the game, instead of whenever the game tries to set the "wrong" one. If there's any of those screen swaps that have been missed, the game will presumably stay on the "wrong" screen until the next reset. In short: the game needs testing to confirm that we've caught all the screen swaps.
Note: currently, only USA and Europe have screen-swap hacks, the Japanese version will just run on the touch screen.
The old version worked like this: 1) widescreen, 2) hooking changes to screen swap register, 3) mediocre custom ASM that writes the screen changes out to 0x02000000, 4) having the game read from 0x02000000 to determine screenedness behavior.
This game does have touch controls but they seem to be entirely optional and only replicate things you can do with the physical buttons, so swapping screens shouldn't be an issue.
If you're playing in an emulator, most of this code is unnecessary as it relates to swapping the screens so the game is played on the top screen. The first three lines are the actual widescreen hack.
Code summary: 1) widescreen, 2) six different hooks where the game changes screens--what are you doing, game, you are bad, 3) the custom ASM to replace each of those six hooked screen-swaps, 4) patching nine different checks of which screen is currently running 3D--WHAT ARE YOU DOING, GAME, YOU ARE BAD.
Works on both the clean Japanese ROM and the English 1.0 patch.
Bottom-screen games
These games display primarily on the touch screen, so ... you're not really getting anything by running them with widescreen cheats. However, it is possible to hack games to swap the screens, and in future there may also be a way to swap the screens using a TwlBg patch, so these codes may become somewhat useful depending on how much they rely on touch input. For right now, these are a bit useless.
Code:
16:10 Widescreen for 3DS
9202A284 00001555
1202A284 0000199A
D2000000 00000000
I made this before I realized the game plays on the bottom screen because it's entirely touch-controlled, making it useless on 3DS. It's very untested.
This game is played entirely on the touch screen with touch input throughout, so it can't really be switched to the top screen effectively.
I'm not even going to bother making an actual 3DS version of this because the only part that even runs on the top screen is the difficulty select. This is 1000% useless on 3DS, only use it on emulators.
Side effects:
- Chickens (and possibly other entities) can walk through walls a bit near the top of the screen, possibly game breaking I dont know.
- Some NPC's eyes are glitched out and are 100% round and black, they look like zombies.
NB: These side effects are associated with the original 32-bit, unconditional version of this code. The improved version given above may or may not resolve these issues.
Gameplay in these games spans both screens simultaneously. Whether or not these games can be fixed for widescreen is a bit hit and miss, as it can only be done if the game determines its aspect ratio every single frame rather than at some other interval.
Gameplay is sort of mostly on the top screen, but boss fights span both top and bottom, as do cutscenes, so large chunks of the game look wrong with this code.
Dual-screen life sim ala Animal Crossing. The first code hits most of gameplay, the second one hits one specific scene during character creation, and the third hits the cloud overlays in certain outdoor areas. The clouds are scaled in the opposite direction to 3D elements, hence us going lower here rather than higher.
These games alternate their 3D screen between top and bottom, e.g. Diddy Kong Racing with its normal (top screen) vs. touch (bottom screen) races. Most of these can probably be fixed, but they will need additional work to handle widescreening only the top screen. It may be worth researching the POWCNT1 register of the NDS, which sets which screen is currently rendering 3D. It would probably be possible to work up a conditional that restores normal, non-widescreen behavior when POWCNT1 is showing that the bottom screen is currently handling 3D.EDIT: Except that POWCNT1 is an ARM9 register and Action Replay codes run on ARM7, so ... nope.
EDIT2: Actually, I came back to this subject now that I've learned a bit of ASM and I've written this generic code that you can plug a few variables into to adjust the aspect ratio depending on which screen is handling 3D right now. It's important to note that this will only be effective for games which poll the aspect ratio regularly, e.g. every frame, or at area transitions. Games like Ducati Moto which only bother to check the aspect ratio once won't be helped by this code. You'll also need to know how to find a good place to hook and I can't be bothered explaining that.
This first one is intended to hook into something that runs every frame like input, and write out 0x1555/0x199A as needed.
[TABLE=full]
[TR]
[td]
AAAAAAA is an address you're hooking
and BBBBBBBB is the instruction it's replacing.
AAAAA+4 is the address of the next line after AAAAAAA.
BBBBBBBB and CCCCCCCC are the two instructions the hook replaced.
DDDDDDD is the aspect ratio address for the game.
AAAAA+8 is the address two lines after where you put your hook.
[/td]
[/TR]
[/TABLE]
This version is newer and cleaner, it's intended for hooking directly into reads of the aspect ratio value:
[TABLE=full]
[TR]
[td]
AAAAAAA is an address you're hooking
and BBBBBBBB is the instruction it's replacing.
AAAAA+4 is the address of the next line after AAAAAAA.
BBBBBBBB is the instruction your hook replaced.
X in these two instructions is the
register you're plugging 1555/199A into.
AAAAA+8 is the address two lines after where you put your hook.
[/td]
[/TR]
[/TABLE]
3D in this game alternates between the top screen (card battles/puzzles) and bottom screen (overworld, world map).
Games in this list either alternate between or simultaneously display using 2D and 3D, so they will only be widescreen in 3D portions, but stretched in 2D portions. It looks pretty ugly.
Gameplay screen varies in this game, between top, bottom and both screens depending on the minigame. This code handles widescreening only the 3D stuff which appears on the top screen, but any 2D minigames which appear on the top screen will be stretched. This code is about as good as it's going to get, barring possible support for "Big Blowout" and "Boogie Beam", two top screen 3D minigames I haven't been able to get widescreened.
Also included is a dual-screen 16:9 widescreen code, but you'll have the same problem there except now 2D games on either screen will be stretched.
This game uses 2D sprites over a 3D backdrop, so changing the aspect ratio only affects the background. If you did adjust the 2D elements to a wider aspect ratio as well, you'd kind of break the game since it's a vertical shmup and the edges of the screen mark the boundaries of where your ship can travel. You really just can't change the aspect ratio on a game like this without significantly reworking how it operates.
Technically I quit working on this code before actually implementing true 16:10, so the aspect ratio is actually a couple pixels off, but since it's not really usable anyway I'm not too worried.
This code only seems to affect certain 3D elements like the course flyover before an event, losing all widescreen once you get in-game. Also, the main screen varies depending on which minigame you're playing, including dual-screen segments, so even if it supported widescreening gameplay it would needs significant work be able to disable widescreen when the touch screen is displaying 3D.
In case you haven't seen it, @Sono has been researching the hardware scaler used to filter games when they're running in DS mode in the TWPatcher - DS(i) mode screen filters and patches thread. This allows setting new and different filters and scaling DS games to different sizes than the official 256*192 or 320*240. For the purposes of this thread, what's important is that it also supports scaling to different aspect ratios than the original 4:3, specifically 384*240 (a 16:10 aspect ratio). Since scaling to a different aspect ratio would make everything look stretched, this thread compiles cheats which make games render to a native 16:10 aspect ratio.
Sono has released a preliminary version of his patcher for 64-bit Windows in this post, which can be used to patch TwlBg.cxi with widescreen scaling. You will need to do this to take advantage of these codes on your 3DS. If you're using TWiLight Menu++, there are instructions in the thread for how to get it working there; these cheat codes are also bundled with TWLMenu++, so those instructions should be all you need. If you're using a flash card, you'll need to add these cheats to your card's usrcheat.dat with a tool like R4CCE.
A lot of these codes have 3DS-specific behaviors like disabling widescreen on the bottom screen and swapping the top and bottom screens for some games. If you're here because you're interested in widescreen support for DS games in general (i.e. not on the 3DS specifically), you should check out this thread by @PRAGMA, How to play NDS Games in HD Widescreen (16:9, 21:9, 32:9)! That thread explains how to use widescreen cheats in DeSmuME, as well as how to adjust the cheats to suit your screen's aspect ratio.
Any codes that weren't created for this thread were sourced from PRAGMA's GBATemp thread and this DeSmuME thread.
This game uses 0x155C for its aspect ratio value. Tracking it backward, it calculates that from 0x1000 * 0xFF / 0xBF, or 4096 * 255 / 191. This is a bit of a weirdly inaccurate way to calculate aspect ratios, since 255/191 is like, 4.00523559:3, as in, a few thousands off true 4:3. But whatever, I followed the game's own rules here, so instead of using the normal 16:10 value of 0x199A, I'm using 0x19A2, which is precisely the same proportion off from true 16:10 as 0x155C is from 4:3.
Only the Korean release of this game is publicly dumped.
This game and one of Griptonite's other DS titles, Spider-Man - Web of Shadows actually seem to be running on the same engine, this code works identically to the WoS code.
fintogive had originally written this 16:9 code as a one-liner:
Code:
022D211C 00001C72
However, the game dynamically allocates memory, so that address is highly unreliable. I recreated this as a pointer code from scratch and it should now work all the time.
This weird game uses 0x155C for in-game stuff, but that value gets dropped way out in RAM, so instead of tracking and modifying that, here we're modifying the fraction used to calculate that value, which begins with loading 0xFF/0xBF into the ARM9 division register. Here we replace that with the 16:10 equivalent and let the game run with it.
This game is way off from everything else, using 0x159A for its aspect ratio value. The 3DS code adjusts the aspect ratio depending on which screen is currently handling 3D, so for emulator users there's a separate 16:9 code which just makes both screens wide.
This game was OK but I felt like it could have used a longer title. Jeez. Another Griptonite joint here, looks like it also runs on the general 2.5D game engine they used for Assassin's Creed II and Web of Shadows.
The first three lines of this code are a screen swap since this game plays on the bottom screen normally. There are zero touch controls in this game, so flipping it up should have just as many consequences. The rest is hooking some code to write out our preferred aspect ratio in the ITCM, which is outside of the range of the Action Replay.
If you need to change the aspect ratio of this code, e.g. for emulator use, the E3A00902 and E3A01A05 near the bottom are where the magic happens. They translate to the ASM instructions mov r0, 0x8000 and mov r1, 0x5000, i.e. 8:5, aka 16:10. So 16:9 should be E3A00A16 (mov r0, 0x16000) and E3A01A09 (mov r1, 0x9000).
This sucked to hack, NO$GBA doesn't display the menus, so I had to simultaneously run the game on real hardware in order to get around.
The code for this dual-screen 3D game handles adjusting only top-screen 3D. For emulator users, just the first three lines should give you a dual-screen widescreen hack.
Woof, big one. This is the first public code to take advantage of the generic alternating widescreen fix, which you can find down in the Issues section.
Forgive my enthusiasm, I'm just excited that any of this worked at all given that until a few days ago I'd never written anything in assembly before, so here's some screenshots:
I'll go over what each portion of this hack is doing:
The first code (52099474) is checking and replacing an instruction which swaps the screens; this is because normal 2D gameplay takes place on the top screen. I've moved it down to the bottom screen so we can benefit from the native 4:3 bottom screen on the 3DS. Battles remain up on the top screen, and the customization and battle menus are also unchanged, swapping between screens at will.
The second code (920245E0) makes robot battles widescreen. It's so quaint and normal.
The third code (520FFDB0) is hooking aspect ratio reads and jumping to 0x02000000 to run some custom ASM.
The fourth code (52000000) is where that custom routine is being written out. Long story short, it checks which screen is running 3D currently and loads the appropriate widescreen/4:3 value for that screen instead of the one the game asked for, then jumps back to the game.
A previous version of this code was unreliable, this updated one is tested and working all the way through chapter 1 and partway into chapter 2.
For documentation's sake, the first address (which was the only address hit in the initial bugged version of this code) affects normal gameplay, the second one triggers in certain rooms (I have no idea what dictates which rooms; the first consistent example I found was the room with the elevator door in chapter 1), the third one is the zoomed-out running camera, fourth is whenever the game does a fade effect and you switch between the light and dark worlds (no spoilers, I'm guessing, I don't actually know anything about this game), and the fifth one is what the game switches to briefly after a fade is over.
The opening cutscene/title screen is in dual-screen 3D, so the bottom half looks a bit goofy, but gameplay and normal cutscenes are all on the top screen.
This is primarily a dual-screen game, but it's super friendly about it, reading in the aspect ratio once then copying it to separate memory for the top and bottom screens, so we only have to patch the top screen aspect ratio, not pass the game a different value each time it asks. Thanks, game. The other things this code does are to swap battles up to the top screen (like Dragon Quest IX) for some extra widescreen goodness. The game has no touch input for battles, so there's nothing to be lost by moving them up top.
As usual, since this is a 3DS-specific code, there's also a normal 16:9 code for emulator users, who also have wide touch screens.
This is a turn-based strategy RPG which is largely in 2D and on the touch screen, but battles are full 3D on the top screen. It works out OK in widescreen since the top screen is otherwise just static menus and things.
From what I can tell, this game only checks the aspect ratio offset on initial boot, and continues running at that aspect ratio throughout. This is a problem for Ducati Moto because the (3D) character, motorcycle and track select are on the touch screen, so if we enable widescreen, those elements are squished, and we can't correct for this by changing the aspect ratio dynamically because the game won't change ARs until the next reboot. gamemasterplc resolved this in alternative code by swapping the menus up onto the top screen where they can be widescreened effectively.
This game's title screen has some 3D on the touch screen, so this code handles disabling widescreen for displaying that. If you're using an emulator, there's another code that simply widescreens everything.
As discovered by @ChampionLeake, this game stores the aspect ratio value outside of the range the Action Replay can access, so here we hook some code and have the game write out 1555/199A (depending on the current screen) for us.
Overworld gameplay in this game is on the touch screen, so having the top screen in widescreen doesn't get you a whole lot. This cheat makes battles (which run on the top screen) widescreen, as well as some other minor things like the character naming screens and the inventory/ability menus.
Also included is an alternative version of this code which also swaps the screens so that cutscenes and overworld gameplay also play out on the top screen, so you get a bit more bang for your buck. Since TWiLight Menu++ bundles the "normal" widescreen codes for these games, you can find TWLMenu++ widescreen hacks for the alternative versions attached to this post. View attachment 178940
Both of the below codes are specifically aimed at 3DS users, where only top-screen things are displayed in widescreen. If you're an emulator person, I'd recommend you use the second code and remove the first three code blocks (nine lines), and remember to change the aspect ratio values to whatever suits your monitor.
Same as the sequel, most of this game is played on the touch screen, so you're only getting widescreen for the battles. Since this code is 3DS-specific and only widescreens the top screen, I've included a separate 16:9 widescreen code for emulator users.
Overworld gameplay in this game is on the touch screen, while battles take place on the top screen, so this code is mostly only adding widescreen to battles, adjusting back to normal 4:3 during overworld gameplay. I did also try swapping the overworld up to the top screen, but the (entirely touch-based) fossil digging minigame uses the same check, so it also got flipped up as well. I might take another look at it for an alternative screen-swapping widescreen code, but this one works just fine if you're happy with only battles (and whatever else happens on the top screen) displaying in widescreen.
Also including a dual-screen 16:9 code for emulator users.
The touch screen is the primary screen in this game because it has a number of completely optional touch mechanics. This means the game is entirely playable using buttons, so we can swap the screens without breaking the game.
I keep forgetting to make a note of it when I find one like this. GoldenEye won't even boot up if you just use that middle line there as a one-liner. Really shows the importance of conditionals.
Handles displaying 3D touch screen menus in 4:3 and top screen gameplay in 16:10. Also included is a standard dual-screen 16:9 code for emulator users.
Decent rhythm game. I actually recommend the European version, because the USA one includes DGamer, the long-defunct Disney social network. It will pop up notices to tell you about new DGamer stuff you've unlocked that you can never do anything with because DGamer is even deader than Miiverse.
This game, ugh. It's similar to other Griptonite games like Assassin's Creed II, but this time the pointers are nested, so I had to find a pointer to another pointer to the render values. Booooooooooooooooooo.
Maybe it's obvious, but make sure you choose "Normal" controls, not the stylus controls. In normal mode, gameplay is on the top screen, while in stylus mode it's touch-based like the Zelda DS games.
I know you might think I'm kinda scraping the bottom of the barrel here, but weirdly, Griptonite actually developed this as a sequel to the (well-regarded) Crash of the Titans. It's probably not good, but it's an interesting curio at least.
This game had a sequel, The Infinity Gauntlet, on DS and 3DS. I didn't bother hacking the sequel since anyone on 3DS is probably playing the 3DS version. I'll probably do it if somebody actually asks, this first game was easy to find the hack for.
This game also got some kind of Walmart exclusive edition, but I wasn't able to find a copy in order to check if it needs a different code.
Note that these games are primarily in 2D and played on the touch screen, with the top screen usually being reserved for menus. As far as I know, only the battles in this game are 3D, so those are the only thing being widescreened here.
Just like Star Force 1, these are primarily 2D games, so you get limited benefits from running in widescreen. Probably just the battle mode. An additional problem this time is that the 2D gameplay spans both screens now instead of the top screen just being a menu, so the stretching may make the game less enjoyable. I took a couple of screenshots of this one since it seemed worth demonstrating:
The last code fixes the culling which was most visible in morph ball training, with thanks to @gamemasterplc for finding a similar thing in the final game.
If you're looking to use this code for 16:9, e.g. in an emulator, you should be able to adjust those 9Fs at the end of the lines to 90 and the 199A to 1C72.
Dumb stuff: This game has separate aspect ratio values for the tires, the roads and the car bodies in the opening, then another one for gameplay. Amused me for a couple minutes making nonsense cars with tires that aren't connected to the body.
This code accounts for certain scenes like track intros taking place on the touch screen by switching back to 4:3 for those. Separate dual-screen code for emulator users.
2D games are a lot more complicated (or more often, just impossible) to add widescreen to and involve substantial code rewrites. Fortunately, @gamemasterplc has done just that for New Super Mario Bros. (USA).
In the description of this video is an xdelta patch you can download and apply to your NSMB ROM to make it run in 16:10 widescreen.
EDIT: I've hit the character limit in the OP, so I'm commandeering this post.
Nice!
I've just edited this post to move a few of these down to the bottom as I hadn't considered that a lot of games use the touch screen as the primary display, so things like the Zelda games won't gain anything from being displayed in widescreen on 3DS. The games in the top half of the list use the top screen either primarily or at least a decent amount (Dragon Quest IX and Mario & Sonic at the Olympic Winter Games both swap screens depending on gameplay mode), but for now I'd say it's probably not worth adding any of the cheats from the second screen list to usrcheat.dat.
~~~
Working
P
This code handles dual-screen 3D (i.e. top screen widescreen, bottom screen 4:3). It's only a dual-screen 3D game insofar as there's a 3D Pac-Man on the touch screen, which is really just HUD stuff, but this looks slightly nicer than the previous code which crunched him.
Chalk another one up for the generic alternating widescreen fix (modified slightly as I hooked the actual AR reading here).
This code pokes a different address (0x0203422C) to fintogive's original code; I just went and remade it from scratch. I don't know why fintogive's code doesn't match mine, but on my end fintogive's code does nothing while mine works without issues. It's possible this game uses different addresses, either by level or across reboots or something, since a different code apparently worked for fintogive. The address fintogive is poking does contain 0x1555 normally, like an aspect ratio address should, but the rendering is completely unchanged for me when this address is poked.
Same pointer-in-a-pointer approach as How to Train Your Dragon.
NB: This is not the same game as Penguins of Madagascar on 3DS, which is based on the film and is a terrible game. This game and the sequel below are based on the TV series, The Penguins of Madagascar, and are really fun little multiple-character puzzle-platformers in the vein of The Lost Vikings.
This game isn't anything special, I just thought it would be interesting to try something a bit different. In this game, you play on the touch screen and the default controls are mostly stylus-based, but you can switch to d-pad controls in the options. I tied the widescreen hack into that setting, so if you play with stylus controls, you'll get normal touch screen 4:3, but if you switch to the d-pad controls, gameplay is swapped to the top screen and the widescreen hack is applied.
Stylus controls <---> D-Pad controls
As usual for very 3DS-specific codes, there's also a normal 16:9 code here for emulator users.
Why are you even playing this, Rayman 3D is the same game.
Mildly interesting: along with Need for Speed, this is one of the few games that actually regularly polls the aspect ratio value, so you can change it and see the result immediately, not just the next time an area loads. Fun to goof around with in real-time.
The four addresses this code is hitting are: the first [intro/training], second [VS Mode], third [Slalom races] and fourth [all other races]. Noting this here because I had some difficulty finding what affected what while porting to Europe.
This game is a jerk, the aspect ratio is only kept in an accessible area of memory very briefly, then it moves into ARM9 memory, which Action Replay codes can't see. This code hits the value before it gets loaded into ARM9.
The menus in this game are simultaneously dual-screen 3D and alternating 2D/3D, so this code handles toggling widescreen on and off in those. Alternating 2D/3D is the one case where even emulator users will want the touch screen's 3D to be in 4:3, so there's no separate emulator code here. Technically, the gameplay is actually in dual-screen 3D too, but the touch screen map seems to handle its aspect ratio separately and I couldn't immediately find how to resolve it. Since that already leaves it in the state we want it on 3DS, I'm done with this code.
This game is originally played on the touch screen. This code swaps gameplay up to the top where it can be widescreened, and also handles the dual-screen 3D cutscenes, running the top screen in widescreen while the bottom screen remains in 4:3.
Code summary: 1) widescreen the title screen, 2) prevent gameplay from switching to touch screen, 3) hook into where gameplay AR gets loaded into a register, 4) hook into where (dual-screen) cutscene AR gets loaded into a register 5) custom ASM to fill the registers with appropriate widescreen values.
Since this code is very 3DS-specific with the screen swapping and the top-screen-only widescreen, I've also included a normal 16:9 code for emulator users.
This code swaps the overworld, battle and tutorial gameplay up to the top screen. In my testing, all of the touch features can be used with buttons instead, so swapping the screens should be fine.
The 16:9 code is for emulator users, and hits, in order: 1) tutorial areas and the incubator room 2) the space map when you hop between planets, 3) overworld gameplay and battles, 4) the load game screen.
This game normally runs on the touch screen, but this code switches gameplay to the top screen. The game has optional touch controls, but if you use the button controls you should be able to play no issues with screens swapped.
In addition to the standard cheat code, if you're playing USA Rev 1, there's also an much better patch by @gamemasterplc. This patch adds 16:10 widescreen support to 2D elements like menus, text boxes, etc. as well.
Some of the Party Games are played on the touch screen, this code handles disabling widescreen when those games are in play. Since that makes this code very 3DS-specific, I've included a normal 16:9 code for emulator users as well.
I tested on a clean Japanese version ROM. There is an English fan translation for this game which I didn't test, but in all likelihood this would work fine with that too.
This game alternates between the top screen (most gameplay) and the bottom screen (track editor). The game is also pretty obnoxious about how it handles reads of the aspect ratio, so this code hooks input in order to write another hook into the ITCM area (outside of the range of the Action Replay engine) to run a custom routine to adjust the aspect ratio based on which screen is currently handling 3D. It's complicated, but it works.
There's also a code for emulator users which widescreens both screens.
This game alternates display across the top and bottom screens depending on gameplay mode as well as cutscenes, so this code corrects for that and only adjusts the top screen.
For emulator users, there's also a code which widescreens bottom-screen stuff as well.
This game is a goddamn mess of offsets, I swear every camera angle must use an independent aspect ratio offset. On the upside, this did mean I was able to leave things like bottom-screen cutscenes in 4:3. I also left dual-screen cutscenes in 4:3 (top screen stretched) because most of the action seems to occur on the bottom screen anyway, at least in early-game cutscenes.
In order, the addresses affect: offset 1 - general overworld gameplay, some cutscenes, 2 - enemy encounter zoom effect, 3 - battles, 4 - Oz's shop, 5 - dialogue scenes, 6 - intro cutscene.
Do note that this is a very 3DS-centric code since it consciously makes the top screen widescreen while leaving the touch screen alone. so there's also a dual-screen widescreen code that emulator users can take advantage of if they're playing the USA version.
3D in this game alternates between the top screen (most of everything) and the bottom screen (e.g. the "matchup" screen), but this code currently just widescreens everything, so touch screen stuff looks crunched. I don't consider that significant enough to put this under Issues, but I do intend to come back to it and see if I can fix the touch screen stuff. For emulator users, this code is already perfect.
These next codes are tested but have significant issues. They "work" but have major flaws affecting how enjoyable they are.
This code forces gameplay to be on the top screen, but your enjoyment may be hampered by the broken transition effect between screens and the fact that the sky is now on the bottom screen.
Like most of Griptonite's games, this one seems to adjust its camera based on how much you can see horizontally, so this runs "vert-". In addition, the player's gun is not affected, so it looks wider than intended. Neither make the game unplayable on their own, but it's more problems than you really want to see.
This game is less than ideal in widescreen because gameplay varies between top and bottom screens (e.g. overworld on bottom screen, normal races on top screen, those awful balloon popping games on bottom screen). The code in its current state has an incomplete handling of correcting for this, so while the (touch screen) overworld is in 4:3 and normal races are in 16:10, some areas like the (touch screen) balloon popping challenges are also displayed in crunched 16:10 on the touch screen.
Also included is fintogive's original 16:9 code, for emulator users.
This game is the worst in the series for widescreen. Each game in the series put successively more emphasis on the top screen, and we can't widescreen 2D segments. In the first game it was just a menu, not too bad. Second game, it's used for menus but also an expanded view so you can see the sky. In the third game, the whole orientation has flipped and gameplay is on the top screen.
So this code swaps the overworld down to the touch screen, so you can play Star Force 3 like in the first two Star Force games, with widescreen battles. It's playable, but you'll encounter issues using the interface since you're expected to interact with a lot of things using the touch screen. All of the touch features still work, but the buttons are on the top screen and you need to touch the equivalent place on the touch screen.
Hacked by request; this game is played entirely on the touch screen and touch control mechanics are layered throughout, so while this code flips the screens, realistically the game just isn't playable. It's all touch this button, drag these coins to the piggy bank guy (I don't know the pig's name), tap these enemies to shoot at them. Don't bother using this.
Europe-only because the USA release is infested with DGamer and this hack is so useless I figured it was only worth doing once.
This group of codes are currently untested and/or in-progress.
This one's pretty weird, it does use 0x1555 for some things, but not in the same way as other games. I followed where it was writing it out to and found some other display parameters right next to where 1555 ends up which adjusted the aspect ratio.
What a monster, but this time, a pretty neat and tidy monster unlike the previous code I made for this game. I can't be bothered going through what every part of this code is doing, so here's a summary: 1) widescreening gameplay, 2) widescreening character creation, 3) hooking writes to the top/bottom screen register, 4) having the game write the results of any screen-swaps into 0x2000000 instead of the real register 5) having the game read from 0x2000000 instead of the real register to determine unique screened behaviors like disabling input while the menu is up.
This code has been tested somewhat, but I really want to give it some more before adding it to the working section since it's so much more complex than any other games' hacks that I've worked on.
OK, this code is a bit of a mess, so I'm actually going to go through what each part is doing separately. You can tell where a code ends by the D2000000 00000000 which ends each section.
The first code (starts with 5216A49C) is affecting the aspect ratio in normal gameplay and cutscenes, etc. The stock game adds together 0xFB5 and 0x5A0 to make 0x1555, so that part is instead adding 0xFBA and 0x9E0.
The second (921FEC70) and third (92242E80) codes are affecting widescreen display of the character creation screen. I'm patching it in two places because it seems to be a race condition between the cheat engine and the game, with the engine not getting to the first address fast enough to stop it being propagated to the second. In an emulator like DeSmuME where cheats are "instant", the second part isn't necessary, but it is needed on hardware.
The fourth code (521BF1F8) is preventing the screen from swapping during gameplay and cutscenes, because this game is originally a bottom-screen-only affair. However, this causes some problems addressed below.
The fifth code (92101CE0) is first checking some timer address in order to wait a couple of seconds before writing out the payload, preventing a crash--I suspect anti-piracy or something, but the issue doesn't occur in emulators so I have no way to debug it--then replacing the code that handles whether the player character is interactive or not (originally, input was disabled when the player is on the top screen, because in the stock game, that means the inventory is in use) with a branch to a custom ASM hack. Instead of checking which screen is running 3D, that ten-line custom routine checks an address in memory which determines whether the inventory or other menus are currently being displayed and disables input only if that is the case.
The sixth code (21CAD18) re-enables opening the Camp menu with X button, which is otherwise disabled when 3D is on the top screen.
So I was definitely wrong about being able to write a generic routine to handle these types of games--not that I think it's impossible, just beyond my capability. Even so, here's Dragon Quest IX forced to run in top screen widescreen instead of on the touch screen. The only reason this ran on the touch screen seems to be that you can control the player using a sort of virtual analog stick, but Super Mario 64 DS did the same thing and runs on the top screen. I find the touch controls awful, but I think this setup actually improves them since there's no stylus blocking your view of what the hell you're doing.
This code is in a bit of a transitional state. The current code has been reworked to be much simpler, and basically just writes to the screen-swap register once then redirects all further screen swaps and reads to junk memory. It's basically the same approach but done better, doing a better job of letting the game handle a fake version of the screen register with unmodified behavior. On the other hand, we're only writing out the correct screenedness once, at the very beginning of the game, instead of whenever the game tries to set the "wrong" one. If there's any of those screen swaps that have been missed, the game will presumably stay on the "wrong" screen until the next reset. In short: the game needs testing to confirm that we've caught all the screen swaps.
Note: currently, only USA and Europe have screen-swap hacks, the Japanese version will just run on the touch screen.
The old version worked like this: 1) widescreen, 2) hooking changes to screen swap register, 3) mediocre custom ASM that writes the screen changes out to 0x02000000, 4) having the game read from 0x02000000 to determine screenedness behavior.
This game does have touch controls but they seem to be entirely optional and only replicate things you can do with the physical buttons, so swapping screens shouldn't be an issue.
If you're playing in an emulator, most of this code is unnecessary as it relates to swapping the screens so the game is played on the top screen. The first three lines are the actual widescreen hack.
Code summary: 1) widescreen, 2) six different hooks where the game changes screens--what are you doing, game, you are bad, 3) the custom ASM to replace each of those six hooked screen-swaps, 4) patching nine different checks of which screen is currently running 3D--WHAT ARE YOU DOING, GAME, YOU ARE BAD.
Works on both the clean Japanese ROM and the English 1.0 patch.
Bottom-screen games
These games display primarily on the touch screen, so ... you're not really getting anything by running them with widescreen cheats. However, it is possible to hack games to swap the screens, and in future there may also be a way to swap the screens using a TwlBg patch, so these codes may become somewhat useful depending on how much they rely on touch input. For right now, these are a bit useless.
Code:
16:10 Widescreen for 3DS
9202A284 00001555
1202A284 0000199A
D2000000 00000000
I made this before I realized the game plays on the bottom screen because it's entirely touch-controlled, making it useless on 3DS. It's very untested.
This game is played entirely on the touch screen with touch input throughout, so it can't really be switched to the top screen effectively.
I'm not even going to bother making an actual 3DS version of this because the only part that even runs on the top screen is the difficulty select. This is 1000% useless on 3DS, only use it on emulators.
Side effects:
- Chickens (and possibly other entities) can walk through walls a bit near the top of the screen, possibly game breaking I dont know.
- Some NPC's eyes are glitched out and are 100% round and black, they look like zombies.
NB: These side effects are associated with the original 32-bit, unconditional version of this code. The improved version given above may or may not resolve these issues.
Gameplay in these games spans both screens simultaneously. Whether or not these games can be fixed for widescreen is a bit hit and miss, as it can only be done if the game determines its aspect ratio every single frame rather than at some other interval.
Gameplay is sort of mostly on the top screen, but boss fights span both top and bottom, as do cutscenes, so large chunks of the game look wrong with this code.
Dual-screen life sim ala Animal Crossing. The first code hits most of gameplay, the second one hits one specific scene during character creation, and the third hits the cloud overlays in certain outdoor areas. The clouds are scaled in the opposite direction to 3D elements, hence us going lower here rather than higher.
These games alternate their 3D screen between top and bottom, e.g. Diddy Kong Racing with its normal (top screen) vs. touch (bottom screen) races. Most of these can probably be fixed, but they will need additional work to handle widescreening only the top screen. It may be worth researching the POWCNT1 register of the NDS, which sets which screen is currently rendering 3D. It would probably be possible to work up a conditional that restores normal, non-widescreen behavior when POWCNT1 is showing that the bottom screen is currently handling 3D.EDIT: Except that POWCNT1 is an ARM9 register and Action Replay codes run on ARM7, so ... nope.
EDIT2: Actually, I came back to this subject now that I've learned a bit of ASM and I've written this generic code that you can plug a few variables into to adjust the aspect ratio depending on which screen is handling 3D right now. It's important to note that this will only be effective for games which poll the aspect ratio regularly, e.g. every frame, or at area transitions. Games like Ducati Moto which only bother to check the aspect ratio once won't be helped by this code. You'll also need to know how to find a good place to hook and I can't be bothered explaining that.
This first one is intended to hook into something that runs every frame like input, and write out 0x1555/0x199A as needed.
[TABLE=full]
[TR]
[td]
AAAAAAA is an address you're hooking
and BBBBBBBB is the instruction it's replacing.
AAAAA+4 is the address of the next line after AAAAAAA.
BBBBBBBB and CCCCCCCC are the two instructions the hook replaced.
DDDDDDD is the aspect ratio address for the game.
AAAAA+8 is the address two lines after where you put your hook.
[/td]
[/TR]
[/TABLE]
This version is newer and cleaner, it's intended for hooking directly into reads of the aspect ratio value:
[TABLE=full]
[TR]
[td]
AAAAAAA is an address you're hooking
and BBBBBBBB is the instruction it's replacing.
AAAAA+4 is the address of the next line after AAAAAAA.
BBBBBBBB is the instruction your hook replaced.
X in these two instructions is the
register you're plugging 1555/199A into.
AAAAA+8 is the address two lines after where you put your hook.
[/td]
[/TR]
[/TABLE]
3D in this game alternates between the top screen (card battles/puzzles) and bottom screen (overworld, world map).
Games in this list either alternate between or simultaneously display using 2D and 3D, so they will only be widescreen in 3D portions, but stretched in 2D portions. It looks pretty ugly.
Gameplay screen varies in this game, between top, bottom and both screens depending on the minigame. This code handles widescreening only the 3D stuff which appears on the top screen, but any 2D minigames which appear on the top screen will be stretched. This code is about as good as it's going to get, barring possible support for "Big Blowout" and "Boogie Beam", two top screen 3D minigames I haven't been able to get widescreened.
Also included is a dual-screen 16:9 widescreen code, but you'll have the same problem there except now 2D games on either screen will be stretched.
This game uses 2D sprites over a 3D backdrop, so changing the aspect ratio only affects the background. If you did adjust the 2D elements to a wider aspect ratio as well, you'd kind of break the game since it's a vertical shmup and the edges of the screen mark the boundaries of where your ship can travel. You really just can't change the aspect ratio on a game like this without significantly reworking how it operates.
Technically I quit working on this code before actually implementing true 16:10, so the aspect ratio is actually a couple pixels off, but since it's not really usable anyway I'm not too worried.
This code only seems to affect certain 3D elements like the course flyover before an event, losing all widescreen once you get in-game. Also, the main screen varies depending on which minigame you're playing, including dual-screen segments, so even if it supported widescreening gameplay it would needs significant work be able to disable widescreen when the touch screen is displaying 3D.
GUIs stretch to wider screen normally, but many 2d backgrounds are missing on the sides, revealing out of bounds elements.
Any way to tweak the code to only display original render area in 4:3 while keeping screen swap during double screen cutscenes??? I dont even need extended render area. I just want main screen on top without breaking said cutscenes like in AC wild world (which is under "Issues" category!) .
I tried to remove widescreen segments from the code but game redscreened...
… 2d backgrounds are missing on the sides, revealing out of bounds elements. …I dont even need extended render area. I just want main screen on top without breaking said cutscenes…
Are you using TWLMenu++? If so, there is a toggle for which screen goes where in the L+down+select menu. You wouldn't even need the widescreen code turned on.
Are you using TWLMenu++? If so, there is a toggle for which screen goes where in the L+down+select menu. You wouldn't even need the widescreen code turned on.
Although it somehow still displays cutscenes correct automatically?
And thats good but both screens start flashing rapidly like there trying to swap places?
Can I just manually lock it in to be main screen: bottom to display cutscenes correct / top screen for normal gameplay but whack cutscenes??? I couldn't break cutscenes on purpose even if I wanted to
Although it somehow still displays cutscenes correct automatically?
And thats good but both screens start flashing rapidly like there trying to swap places?
Can I just manually lock it in to be main screen: bottom to display cutscenes correct / top screen for normal gameplay but whack cutscenes??? I couldn't break cutscenes on purpose even if I wanted to
Sometimes games are very insistent about which screen to display things on - presumably setting this flag again on every frame rather than just at the beginning of an event and assuming it will stay the way it's set. E.g. the treasure-fishing minigame in Phantom Hourglass.
You seem to have discovered the limitation of the setting I have described - it won't automatically change the screens over for cutscenes vs. gameplay. You would need to change the setting manually when you know a particular event is coming up. Cheat codes can be used to edit the game to do this automatically, as the current widescreen patch seems to do?
It wasn't too long ago we saw our first glimpse of Courage Reborn, another Twilight Princess PC port in the works based on last year's decompilation efforts. With...
After much speculation, Nintendo has finally followed their competitors in announcing price increases for their hardware.
You can find a breakdown of what's changing...
Seemingly out of nowhere a PC port for Pokemon Platinum has surfaced online, bundled alongside the source code for those interested in building and developing it for...
Airing last night with very little in the way of warning, a brand new Nintendo Direct was aired. Running for 15 minutes in total, it took a moment to celebrate the...
Known more widely for their unusual stock price in modern times, GameStop has seen a steady decline as the go-to retail space for US gamers. In what feels like an...
With very little in the way of announcement, Valve has today increased the price of the Steam Deck but some fairly considerable margins. Both of the available models...
As a part of their Financial Results Briefing for the previous year, Nintendo president Shuntaro Furukawa took to the floor to answer key questions around the Switch...
Earlier this year, Sony announced major price increases for the PS5, PS5 Pro, and PlayStation Portal. Now the company is raising prices again, this time for...
We are once again here to tell you about a game leaking before its release, but for once, it's not one published by Nintendo. The game files for Microsoft's upcoming...
Continuing with the great news of Pokémon Platinum getting a native unofficial PC port just a few days ago, today, yet another classic title from the franchise has...
It wasn't too long ago we saw our first glimpse of Courage Reborn, another Twilight Princess PC port in the works based on last year's decompilation efforts. With...
With very little in the way of announcement, Valve has today increased the price of the Steam Deck but some fairly considerable margins. Both of the available models...
After much speculation, Nintendo has finally followed their competitors in announcing price increases for their hardware.
You can find a breakdown of what's changing...
Airing last night with very little in the way of warning, a brand new Nintendo Direct was aired. Running for 15 minutes in total, it took a moment to celebrate the...
Known more widely for their unusual stock price in modern times, GameStop has seen a steady decline as the go-to retail space for US gamers. In what feels like an...
Seemingly out of nowhere a PC port for Pokemon Platinum has surfaced online, bundled alongside the source code for those interested in building and developing it for...
Earlier this year, Sony announced major price increases for the PS5, PS5 Pro, and PlayStation Portal. Now the company is raising prices again, this time for...
As a part of their Financial Results Briefing for the previous year, Nintendo president Shuntaro Furukawa took to the floor to answer key questions around the Switch...
The latest in a growing number of native PC ports, Paper Mario ReCut got its first pre-release build earlier this week. Based on the N64 recompilation toolchain, the...
A whole hour of PlayStation content is on the way, thanks to the latest State of Play showcase. Headlining the stream will be Marvel's Wolverine, alongside a...