Hacking TempGBA: NDSGBA revival

Do GBA games make your nono parts happy?


  • Total voters
    429
Once I'm done with most of the CATSFC changes, I will look at adding global button mappings and game-specific button mappings, akin to the global/game hotkeys, for A, B, L, R, Start and Select.

During my testing for the previous TempGBA, I noticed that the button mapping scheme for Legend of Zelda: A Link to the Past is completely bonkers, coming from the SNES version of the game. The button to grab/talk/act is R, not A, Select to open the item menu instead of Start, Start to open the save menu instead of Select, and that mixes me up, so I want to add complete button mapping.
Global button mapping should be relatively simple, as that is just swapping button calls.
 
Wow, after so much effort, it actually paid off in the end.

Good luck with the fixing up the code, I would help, but my areas of expertise do not include C(++) nor emulators. Hoping to learn some C++ this year though.
 
Very basic initialisation is failing in NDSGBA 1.21, including the console initialisation so that I can use console debugging with printf.

So instead of using the NDSGBA 1.21 source to build upon, what I'll do is restore the "TempGBA re-port" repository and use the NDSGBA 1.21 source code as a guide to hook in missing features and the right sound buffer size and so on.
 
  • Like
Reactions: Vinnymac
Very basic initialisation is failing in NDSGBA 1.21, including the console initialisation so that I can use console debugging with printf.

So instead of using the NDSGBA 1.21 source to build upon, what I'll do is restore the "TempGBA re-port" repository and use the NDSGBA 1.21 source code as a guide to hook in missing features and the right sound buffer size and so on.
it's that bad?:unsure:
 
it's that bad?:unsure:
Yes. The code essentially can't work at all, and I gave it the files it was supposed to be able to use. Fonts and bitmaps are both failing to be initialised, and that's already working in the older version we made from scratch.

I've restored the old repository and will hook features in slowly now. Interested people can start to get themselves a TODO list entry at the start of the thread if they want to copy CATSFC changes; I'll get to them sooner or later anyway, but if I get the changes already ready to import into my repository, it will be that much faster for me.
 
Yes. The code essentially can't work at all, and I gave it the files it was supposed to be able to use. Fonts and bitmaps are both failing to be initialised, and that's already working in the older version we made from scratch.

I've restored the old repository and will hook features in slowly now. Interested people can start to get themselves a TODO list entry at the start of the thread if they want to copy CATSFC changes; I'll get to them sooner or later anyway, but if I get the changes already ready to import into my repository, it will be that much faster for me.
Does that mean the source code was useless?
 
Today in the TempGBA repository:
* Auto frameskip, the most important one, was hooked. The other manual ones should also be hooked, but they don't work right. They behave like auto frameskip but with bubbly 'underwater' audio.
* A distinction was made between "runtime settings data" and "stuff the user said in the GUI", and only the latter part is now saved to the microSD card. Frameskip is 1 variable in the GUI for ease of use, but that 1 variable is split into the 2 that gpSP requires (auto vs manual as #1, the frameskip value as #2). This is on top of the CATSFC write-cycle improvements, too.
* Cheats support was copy-pasted as is, including GBK (SJIS?) encoding support. The UI text coordinates differ from the usual coordinates for these cheat interfaces. They will be realigned later.
* The key to open the menu had been X, but was made the Touch Screen. This is consistent with CATSFC and frees up X for using as a user-specified hotkey action later on, including opening the menu again if the user feels like it.
 
  • Like
Reactions: WiiUBricker
RTC? Is this RTC going to work based off of system time or is gonna be "only when the game is running" like thepatches for Pokemon?
Don't know yet, haven't found its code.

Alright guys, I want to get everyone's opinion on something.

Should I hook in rewinding, given that I also plan to have a quick save-state hotkey? Rewinding is essentially a special case of save state creation, and if the player can control when a saved state is made and loaded very quickly, rewinding may be less essential.

Edit: I'll also hook rapid fire along with all the other button remapping options later, because rapid fire is a special case of button remapping and I want to redo how it's presented in the user interface.
 
Don't know yet, haven't found its code.

Alright guys, I want to get everyone's opinion on something.

Should I hook in rewinding, given that I also plan to have a quick save-state hotkey? Rewinding is essentially a special case of save state creation, and if the player can control when a saved state is made and loaded very quickly, rewinding may be less essential.

Edit: I'll also hook rapid fire along with all the other button remapping options later, because rapid fire is a special case of button remapping and I want to redo how it's presented in the user interface.

Well, in the case of the NES emu I use, it has both but rewind was always a novelty for me since it had incredibly fast state load/saves. (via touch screen swiping patterns, which I might add is kinda awesome) But anyway, if you can fit both in you'll probably appeal to more people as long as it isn't cluttered/buggy.
 
I think that quick savestate is usefull only if you now something will happen and rewind is more for something unexpected. So my vote is for both :P. But I think that the first option must have priority over second one because is more versatile.

+1 for quick savestate
+1 for rewind
 

Site & Scene News

Popular threads in this forum