SFXs are disassembled in src/audio/sfx/

I could not find /usr/local/bin in the repository so I assume that these have to be created. In this case, where do I place /usr/local/bin, or does it not matter?

Additionally, I how do you build rgbfgx? The page itself does not mention any instructions and there are no executables (unlike rgbds, which is essentially a set of executables). I've tried some tutorials I googled, but using cmd with the make all command just resulted in a bunch of error messages.

Thanks in advance, I'm really new to this. ):

Hi. I had an old version from 2019, but I decided to update it (completely fresh), and I've noticed that whenever I try to edit, let's say, a card's picture, and compile to see if it works, all the tiles composing that picture get scrambled, even if I change a single pixel. This did not happen on that old build, and I do not know what to do.

I updated rgbds and tried several versions, but they either can't compile because they're too old, or just produce this result.

Is there something I'm missing, or is this an actual issue?

Even though "arena" makes more sense as a card location (like bench, hand, deck, or discard pile), "active" might be a more recognizable term to use overall.
Note that the location constant using this term also applies to attached energy cards, not just the Pokemon card on the field.

Currently, the style guide touches on how to name shorter texts like UI (try to use the words in the text, or shave off a few and use the key words), and Names (use the full name).

I think that it'd be a good idea to come up with a consensus on how longer Dialogue texts should be renamed. They can span many lines, and can't be condensed as easily as UI texts can be.

My idea is that we find some way to describe what's being talked about, but add the speaker to the beginning. Something like Imakuni_IntroductionText or ImakuniAskToDuelText for texts 0467 and 0468 respectively. I personally prefer with the underscore.

Please share any thoughts on how naming texts could work, thank you!

It might be worth setting up continuous integration and Symbols branch for this repo similar to pokecrystal.

https://discord.gg/d5dubZ3

BeedrillKind to PoisonBeeName, etc.

Also change ; kind, *_KIND and *Kind references to "Category".

Well I know there are two glitches in TCG called the Duel Escape Glitch and the Zapdos LV68 Glitch. It would be nice if there was a docs section in poketcg just like pokecrystal that describes the glitches in detail however I managed to find information on the Duel Escape Glitch but not much information on the Zapdos LV68 Glitch.

Duel Escape Glitch Pastebin: https://pastebin.com/QnYGzNey

Zapdos LV68 Glitch (not much info though): https://glitchcity.wiki/Zapdos_LV68_glitch

Currently, there's a mix of "Attack" and "Move" being used in the repository to denote the exact same concept. I'm more used to the term "Move" from the main games, but "Attack" may be more appropriate in TCG? Regardless, these two should be consolidated into either of them.

rgbds v0.6.0 includes a rewrite of rgbgfx which breaks many of the pngs in this repo, for example https://github.com/pret/poketcg/blob/master/src/gfx/hand_cards.png

My first hunch is that the new rgbgfx now ignores all the embedded rgbgfx flags in the png files which we used to use, although I attempted to remove them in 652ce4e and 786574f but it's possible that I missed some.
It could also just be a matter of different default options.

For now, poketcg needs to be built with rgbds v0.5.x.

Possibly use *_DECK constants when not requiring -2 (DeckPointers, LoadDeck) and equivalent *_DECK_ID constants when requring -2 (wOpponentDeckID, and data tables that load a deck ID to this address, such as NPCDataTable entries). These would therefore start with SAMS_PRACTICE_DECK_ID.

This might be confusing, but I think the current arbitrary use of -2 to refer deck related constants is even more confusing. I also think that having separate constants would be clearer than using some macro with a similar purpose.

If there's no opposition, I'll do this myself at some point.

Also, UNNAMED_DECK_2 -> UNNAMED_2_DECK.

This is a cool project. I've always wondered how the algorithms in this game work, and now I've finally been able to start answering my questions. :-)

There are a few interesting bugs/glitches documented in the disassembly, but I believe I know of another that isn't currently mentioned. I have encountered occasions in duels against a computer opponent using Venomoth's Shift whereby, if a Mysterious Fossil or Clefairy are in play somewhere, the computer will illegally change Venomoth's type to, say, Fire, even if no Fire Pokémon exists in play. Meanwhile, the UI will still prohibit the player from performing the same antic.

In the UI code for validating the Shift color selected by the player, there's a call to GetPlayAreaCardColor. This call appears to explicitly check if the card in play is a trainer card and correctly assume a type of colorless if so. On the other hand, when the AI is choosing a color, it calls a separate routine to check if its proposed color is legal, and this code appears lacks the check for a trainer card.

Since trainer cards don't have the “color” byte in the data structure, I suspect that this missing check blindly reads some arbitrary byte, resulting in the AI using Shift to switch types to something that may not actually be in play as required by the card's rules.

I'm not an ASM guru, though, so maybe someone more knowledgeable of the code might want to double-check this. But if I am correct, then maybe it would be worth adding a comment in the code to document this programming error. I could make a PR for this.

The compressed map and SGB data are being included directly into the ROM. Creating a compressor tool would allow this data to remain in its uncompressed form in the project folders, so that they can be compressed when running make. This makes it easier to digest and edit this data.

Hey there.
The European versions fixed some bugs like the option to instantly win a battle. I would really like to know if they changed even more like that Card Pop bug.

Sorry to bother, but whenever I make a change to the cards, and I try to compile running just "make" I get this error:

"baserom.gbc tcg.gbc are different: byte 335, line 1"

But apparently running "make tcg.gbc" actually outputs the modified rom, seemingly fine.

What's that error for, exactly?

Script commands are currently written like:

	run_command ScriptCommand_MovePlayer
	db NORTH
	db $02

This could be written friendlier like:

	move_player NORTH, 2

with a macro definition like:

move_player: MACRO
	run_command ScriptCommand_MovePlayer
	db \1
	db \2
ENDM

This file, unlike the rest of the files in this folder contains the palette information.

New types/additional types possible, etc?
Been wondering, if any of you figured out how to do it.

Also, I am not sure, but I assume there are changes that you allow that regular handhelds couldn't handle.

If not, wondering if you have made any flags available for turning stuff that emulators not the original devices can handle.

It would be awesome to be able to run a game like this, with steel and dark types and all cards up until the end of gen 2 in the game or more if possible.

Just some thoughts that occured to me. Also, multiple regions would be interesting as well.

Imagine having this have the potential to make something as big as RBY or more so GSC!

Anywho, just some things I felt like sharing, some might be outlandish right now, but please do tell me your thoughts.

Currently the _textfw macro in macros/text.asm has to do OPT Wno-unmapped-char, and test for the existence of a character by doing CHARLEN(...) == 1. It could instead test for ISCHARMAP(...) without the silenced warning.