Hacking TempGBA: NDSGBA revival

Do GBA games make your nono parts happy?


  • Total voters
    429
Golden sun 2 became worse, it was better in beta 11...

The sound now has more crackles in it, it laggs more and the visual effects are less smooth.
Its like the beta 10 test build you gave me.

Cpu at 5, frameskip [-] keep up with the game
If I reverse the change that made Golden Sun 2 (apparently) slower, I reverse all of beta 12. For me, the slowdown is much more bearable, only crackling once every 55-90 seconds when the music is complex near the end and it's about to loop. The scene where ...
the island of Suhalla is torn apart from the continent after the first beacon is lit
..., in particular, is much less crackly and has more FPS in beta 12. I may need to tune some things still, but the E1A00800 Guru Meditation that caused a crash in battles (see the previous page, or the one before that) shouldn't happen anymore. Perhaps the code clearing routine needs to be hand-optimised in MIPS asm to work better, and I'll need some more stats to find that out. You can see the stats I currently collect in /Tools/Debugging.

Another possibility is that all of the statistics collection itself is causing the slowdown, so I will remove that once the betas are over. It will definitely help me before then, though.
 
I tested beta 12 and found a bug in the GUI. Maybe it's a known bug, I didn't check all this thread yet.
Edit: it's not on the bug tracker.

When browsing a folder with the Stylus it's selecting the second entry above the selected one.
When using buttons to navigate it's working fine.


Edit:
Another GUI Bug:

When using the 3DS, launch the NDS FlashCard with Select Button pressed to play in original NDS display size.
The screen is shrinked, but the stylus input still use the full screen coordinates.
 
I tested beta 12 and found a bug in the GUI. Maybe it's a known bug, I didn't check all this thread yet.
Edit: it's not on the bug tracker.

When browsing a folder with the Stylus it's selecting the second entry above the selected one.
When using buttons to navigate it's working fine.
This one is now fixed for beta 13. I was still using hardcoded height values for this one, despite using GUI_ROW1_Y and GUI_ROW_SY for the rest.

Edit:
Another GUI Bug:

When using the 3DS, launch the NDS FlashCard with Select Button pressed to play in original NDS display size.
The screen is shrinked, but the stylus input still use the full screen coordinates.
This is not something I can fix, it'd be due to the DS-to-DSTwo link not detecting it's on a 3DS and not full-screen.
 
Thanks for fixing it quickly.
If you can't do anything for the 3DS then it's not a big problem. GBA games in original DS size are displayed too small anyway, I'm sure users would prefer playing with bigger screen (I do).
 
Thanks for fixing it quickly.
If you can't do anything for the 3DS then it's not a big problem. GBA games in original DS size are displayed too small anyway, I'm sure users would prefer playing with bigger screen (I do).
Well, look at it this way:
* A DSi XL user has larger pixels on no scaling;
* A 3DS user has scaling (which makes it look a bit shitty, no?) on pixel sizes similar to the DS Lite;
* A 3DS XL user gets either scaling on larger pixels (which would definitely make it look shitty) or no scaling on larger pixels (which would look better but small).

It is really unfortunate for 3DS XL users that I can't do anything in the touch coordinate handling.
 
Just tried it, and all works fine (played blackthorne).:gba:
For my curiosity, what was the problem in Blackthorne, and how did beta 12 fix it?

If it was massive slowdown and audio crackling, I'd like to see the values you have in /Tools/Debugging/Nebuleon's code cache flush counts for IWRAM and EWRAM in beta 12, please.
 
Awesome work, this emulator has really come a long way. Mario Advance 3 runs great at frameskip 0 in most areas. Hopefully it can reach full speed eventually!
 
Menu option, toggle with L/R or something? The DSTWO may not detect the screen size, but the user definitely will.
Or let him/her keep holding Select until TempGBA perhaps?

If someone could give me two photos of a 3DS or 3DS XL on the TempGBA main menu screen, I could try a very hacky workaround to convert coordinates. The first photo would show a 3DS on the TempGBA main menu screen unscaled/small, and the second photo would show the same 3DS on the TempGBA main menu screen scaled/big. That's so I can view how much space is lost to the 3DS bezel, and how much space is lost to the 3DS using native DS pixels.
 
If that's hackish, how about a calibration option (when you start up, with the option to "don't show this again"?)? That might be more accurate.

I can try taking some photos on my 3DS, but my phone's camera is pretty terrible. Don't you just need to know the 3DS screen resolution? I thought the touch screen coordinates were expressed in pixels.
 
  • Like
Reactions: Boriar
The touch screen, if what Cyan says is true, is expressed in units of 256ths-of-the-screen-width and 192ths-of-the-screen-height. So (0, 0) would correspond to the upper-left corner of the application in 3DS scaled mode, and beyond the application's boundaries in 3DS unscaled mode. The hack would be to take get_gui_input, and after it gets touch screen coordinates, bring them back into DS unscaled coordinates so that (0, 0) is inside the application's boundaries again.

But the division would make some touch inputs unattainable, like 1 pixel every 4 or 2 pixels every 9 or something like that.
 
The DS has resolution 256x192, the 3DS has resolution 320x240. So the 3DS has a 25% bigger resolution than the 3DS. Wouldn't it just be an 0.8 division? I mean, the size of the pixels doesn't change.

Anyway, here are pics I took of my regular 3DS. I've tried to keep the distance between the camera and the 3DS the same, but I still had to rotate them a little, so they may not be very accurate... in fact, now that I look at it,

Note that when you use native DS resolution, the touch screen is moved to the top of the screen and the top screen is moved to the bottom of the screen, so they are only separated by the hinge of the 3DS. That means that after division, you'll only have to add to the X-coordinate (as the screens are still centered).

http://i.imgur.com/pGUUbqc.jpg
http://i.imgur.com/pnHaJqW.jpg

EDIT: By the way, if the DSTWO only sends the frame and sound buffers, I assume rumble support would be out of the question?

Also, would it be possible to add an option to show the game on the bottom screen?
 
The DS has resolution 256x192, the 3DS has resolution 320x240. So the 3DS has a 25% bigger resolution than the 3DS. Wouldn't it just be an 0.8 division? I mean, the size of the pixels doesn't change.

Anyway, here are pics I took of my regular 3DS. I've tried to keep the distance between the camera and the 3DS the same, but I still had to rotate them a little, so they may not be very accurate... in fact, now that I look at it,

Note that when you use native DS resolution, the touch screen is moved to the top of the screen and the top screen is moved to the bottom of the screen, so they are only separated by the hinge of the 3DS. That means that after division, you'll only have to add to the X-coordinate (as the screens are still centered).

http://i.imgur.com/pGUUbqc.jpg
http://i.imgur.com/pnHaJqW.jpg

EDIT: By the way, if the DSTWO only sends the frame and sound buffers, I assume rumble support would be out of the question?

Also, would it be possible to add an option to show the game on the bottom screen?
Without those pictures, I would have simply assumed that the images were centered about both axes. So the image is in fact like this?:
3ds-unscaled-ds.png
 
So now I'm curious and confused. Does the save states from the old NDSGBA carry over to TEMPGBA? I have a crapload of good Pokemon pinball data RS that I don't want to lose. :( Hahah!
 
Big big thank you for that! Very fast response! :) Your emulator is a huge improvement, congratulations on your achievements thus far! :)
 

Site & Scene News

Popular threads in this forum