search

pret / pokecrystal

Disassembly of Pokémon Crystal
https://pret.github.io/pokecrystal/
2.11k stars 805 forks source link

Debugging pokecrystal on Linux #619

Closed IoIxD closed 5 years ago

IoIxD commented 5 years ago

I apologize that this is more of a help post then an actual issue but I've been using Linux (Debian 9 "Stretch", specifically) to make a Pokemon ROM Hack. I'm currently experimenting with editing maps and, specifically, warps to maps. Upon booting a new game and getting past Oak's intro, the screen remained gray and eventually the emulator crashed. I'm pretty sure it's because I changed the warps and tileset for the Player's room. But I can't tell because other then giving me info on what the program is doing, VisualBoyAdvance for Linux doesn't have a debugger. I did some Google searching and found an emulator titled BGB, but it needs Wine to run on Linux, and I don't really want to install something like Wine on an already small laptop.

What is the best way to go around debugging pokecrystal, specifically on Linux, without wine?

Pokechu22 commented 5 years ago

A reminder that the original VBA has not been updated since 2005 and has security issues. You can try VBA-M, which is at least actively maintained. Alternatively, try bizhawk since that's more debugger oriented (though apparently on linux that also requires libwine though apparently not wine itself).

ISSOtm commented 5 years ago

VBA-M is still a bad idea for development due to its still poor accuracy (not as bad as VBA but still really low-tier). BGB is basically the ideal choice thanks to its near-perfect accuracy and debugging capabilities, which come in handy faster than you'll expect (trust me there... x) ) I know people with small laptops who do use BGB on Debian, too, and while they agree it's not ideal, using another emulator would also be less than ideal. If it's absolutely impossible to get Wine on Linux for whatever reason (lack of disk space), then you can use SameBoy, which has limited debugging capabilities on Linux (terminal only, no VRAM viewer or such facilities...) and is the single most accurate GB emulator in existence.

Pokechu22 commented 5 years ago

BGB is closed source as far as I can tell, which is why I don't want to recommend it (but I'm not very actively involved in any kind of gameboy development). In my experience it's generally better to have access to code, since you never know what you'll need to debug, but probably most people don't need to go that far.

Though VBA-M is definitely still poor. I just don't want to make any other strong recommendations.

ISSOtm commented 5 years ago

I don't see what's bothering with BGB not being open-source; to debug your GB code, what good is it to know what code your emulator is made of?

Pokechu22 commented 5 years ago

Being able to see why something behaves the way it does? It's come up for me, though I don't remember exactly the case. But it can really help with debugging to look at how the implementation is handling your own code, sometimes. Perhaps not initially, and if you're just debugging one thing it (hopefully) won't matter, but for me over time it has come up in enough places that I make it my policy to prefer open-source stuff.

ISSOtm commented 5 years ago

Seeing why something happens is easier to figure out using a debugger than looking at some emulator code. The actual way to know why something is happening is by looking at docs, and if they're incomplete, ask the community, because it means the docs are lacking and need to be completed. Funny story, I had to debug a STAT interrupt glitch in my code, which I couldn't explain even after tracing the faulty instruction (IF bit 1 got inexplicably set), and I found no mention of it anywhere, so I asked BGB's maker, beware, who explained what the STAT bug was. I added it to the GBDev Wiki since. I tried looking at Gambatte's code, but it's all unreadable. So no, open-source basically means nothing.

Pokechu22 commented 5 years ago

You do you, I guess. In my experience it's still been useful to work with the code on occasion and that's not something I'd be willing to drop (but I haven't had to diagnose anything timing-related); I like having all options available to me. (Of course there are also points about closed-source emulation and preservation, but this is not the time or place for that as this is about debugging).

I don't have enough stake in this to make a strong argument, and I'm not going to be convinced the other way. So I'll drop it for now.

mid-kid commented 5 years ago

BGB right now is probably the best debugger there is. Even on small laptops and under wine, I recommend trying it, since there's a big chance it'll run just fine. Other emulators with debugger include SameBoy and maybe mGBA, I'm not sure if mGBA has a GB debugger, though.