~Red
Camper
Posts: 68
|
Post by ~Red on Jan 1, 2010 10:23:14 GMT -5
I have found next to no information about how the Sprite Decompression works in Red, nor how to add Decompressed sprites like Brown.
I also would like to know if anyone has tried changing the scripts in Red (such as movement, being given items, Yes No boxes, given Pokemon)
|
|
|
Post by Cartmic on Jan 1, 2010 11:57:48 GMT -5
What MeanMrMustard did in brown was if I remember correctly is write a new picture display routine and point to uncompressed graphics.
I came up with a theory years ago that the graphics were stored as instructions which when passed through the "decompression" routine are drawn to the screen on the fly. A while later Tauwasser did some separate research into it and produced some documentation.
The events stuff is written in Assembly Language.
|
|
~Red
Camper
Posts: 68
|
Post by ~Red on Jan 2, 2010 11:24:21 GMT -5
Could you (potentially) write a program that edits scripts in Red? I have attempted to learn ASM before but it went straight over my head.
|
|
|
Post by Mateo on Jan 2, 2010 11:42:19 GMT -5
Since the scripts are written in asm, you will still have to learn asm. A script editor for red would basically just be an asm compiler.
|
|
~Red
Camper
Posts: 68
|
Post by ~Red on Jan 2, 2010 11:51:44 GMT -5
The only thing I never really understood about ASM is what you write it in. People say a HEX Editor but others say a Decompiler? I don't get it.
|
|
|
Post by Mateo on Jan 2, 2010 12:00:45 GMT -5
You can do it either way. If you know what the opcodes are in hex, you can write it directly in hex. However, you can also use a compiler, and type it in english and then it will translate it into hex for you. It's just like I script for gold in a hex editor, but some people use PKSV.
Also, I have only a minimal understanding of ASM as it is. I'm just starting out with learning it, so I can't answer a lot of questions about it. iimarkus knows more about ASM though
|
|
|
Post by iimarckus on Jan 3, 2010 10:32:47 GMT -5
Pokémon RBY sprite decompression in CThere are no compressors that I know of. Cartmic is correct in saying that Meanmrmustard rerouted the display routine to not use compression. The only thing I never really understood about ASM is what you write it in. People say a HEX Editor but others say a Decompiler? I don't get it. It can be done in a hex editor but this is slow and error-prone. Typically the quickest solution for simple ROM hacking. Major hacks or outright homebrew are nominally written in any text editor (like Notepad), then run through an "assembler" which spits out a complete ROM file. The most widely-used Game Boy assembler is probably RGBDS. Using an assembler is much, much, much nicer than hex editing because you can use labels instead of manually calculating pointers, define your own constants and macros, and put comments in the source file; none of these can be done in a hex editor. Most, if not all, Game Boy games were written with an assembler. I have a disassembly of Red in progress (haven't worked on it in a few months, but it's still on my to-do list). I need to move it to source control -- think Wikipedia's history/compare feature -- but I'll get around to it later.
|
|
~Red
Camper
Posts: 68
|
Post by ~Red on Jan 3, 2010 14:28:10 GMT -5
Ok. I think I understand now. I will try and plough through ASM School.
|
|
~Red
Camper
Posts: 68
|
Post by ~Red on Jan 6, 2010 15:48:40 GMT -5
Sorry for double post but I have to ask something. The thing that keeps bugging me about ASM is registers. ASM School doesn't really cover what they are or do. Are they kind of like Variables that hold data? I'm really confused. Also, do I have to learn how each and every register operates?
|
|
|
Post by iimarckus on Jan 9, 2010 15:20:57 GMT -5
Sorry for double post but I have to ask something. The thing that keeps bugging me about ASM is registers. ASM School doesn't really cover what they are or do. Are they kind of like Variables that hold data? I'm really confused. Also, do I have to learn how each and every register operates? I remember understanding registers being a real epiphany for me. You know about memory. It's a collection of contiguous values. RAM location $0000 can hold a one-byte value (0 to 255; $00 to $FF if you prefer). Location $0001 can hold a different one-byte value, and so on all the way to $FFFF. A CPU register can also hold a one-byte value. Instead of referring to these with numbers (memory locations), we refer to them with letters. These are the CPU registers in the Game Boy: a b c d e f h l s p ASM opcodes usually manipulate values in these registers. E.g., ld a,$11 ; puts the value $11 into register a ld c,a ; puts the value of a ($11) into register c, so c now holds $11The registers in the Game Boy CPU are 8-bit (0 to 255). You can simulate 16-bit registers by combining two 8-bit registers. For instance, there is an ASM opcode ld hl,$2000 ; puts $20 into h and $00 into lAn easy way to remember which is which: h is the high byte and l is the low byte. Only some registers can be paired: af bc de hl sp sp is always paired. You will never refer to s or p separately. Most of the registers simply hold a value: a, b, c, d, e, h, and l each simply hold a value. Of these, a (often called the "accumulator") is the most versatile: there is a " ld a,$xx" instruction but no " ld c,$xx" instruction, so to put a value in c you have to do " ld a,$xx" and " ld c,a" in succession. f (the "flags" register) is special. You cannot write values to f. Instead four bits will change depending on what happened during the last instruction. The two major flags are z (zero) and c (carry). z is set (becomes 1) if the result of the last instruction is 0, and reset (becomes 0) otherwise. c is set if there is an overflow or reset otherwise. E.g., ld a,$FF inc a ; increments aAfter this a will hold $00 and the carry flag will be set, because it overflowed. The stack pointer (sp) is more complicated and I'm not sure I can give a sufficiently simple explanation. Just know that when you call the current execution location is pushed onto the stack and when you ret it is popped off.
|
|
Hyde~
Camper
NeverDie~
Posts: 51
|
Post by Hyde~ on Jan 9, 2010 18:52:45 GMT -5
I DIDNT UNDERSTAND
|
|
~Red
Camper
Posts: 68
|
Post by ~Red on Jan 10, 2010 17:07:18 GMT -5
And can I take data from an address in the ram and put it in a register? Can I even take something from the rom into the ram with asm?
|
|
|
Post by iimarckus on Jan 11, 2010 14:34:35 GMT -5
FYI: a hex/ASM equivalent tabledescription of each opcodeAnd can I take data from an address in the ram and put it in a register? Yes. E.g., ld a,[$XXYY] will copy the value from memory location $XXYY to a. Note the brackets. $XXYY refers to the 16-bit value $XXYY; [$XXYY] refers to the 8-bit value located at $XXYY. You will also sometimes see [hl] or similar, meaning the 8-bit value at the location pointed to by hl. As usual, the accumulator is more versatile: there is a ld a,[$XXYY] instruction but no ld b,[$XXYY] etc. insruction. Can I even take something from the rom into the ram with asm? It appears you don't know the RAM layout of the Game Boy. 0000-3FFF: ROM bank 0 4000-7FFF: switchable ROM bank 8000-9FFF: VRAM A000-BFFF: external RAM C000-CFFF: WRAM0 D000-DFFF: WRAM1 E000-FDFF: ECHO (typically not used) FE00-FE9F: OAM RAM FEA0-FEFF: unused FF00-FF7F: Game Boy hardware registers (not related to the CPU registers described earlier) FF80-FFFE: HRAM FFFF: Interrupt enable register Each of these areas of RAM has a specific purpose. VRAM, video RAM, is for tile data. External RAM is (I believe) save data. WRAM, work RAM, is general scratch area. This is why Gameshark codes are between 01XX00C0 and 01XXFFDF: the device only modifies WRAM because that's where games keep most data like lives and hit points. OAM RAM contains sprites. HRAM, high RAM, is the only RAM that can be accessed during a DMA transfer. As you can see, ROM bank 0 is always in RAM. The first $4000 bytes of ROM are always at their corresponding location in RAM. Look at any memory dump and you will see the ROM header starting at $104. Writing to this area will have no effect, because it is read-only. The area of RAM from $4000 to $7FFF can contain any ROM bank except bank 0. One bank at a time, of course; you must switch between them. This is done with a piece of hardware in the cartridge called a Memory Bank Controller. When you write to RAM location $2000, normally a meaningless procedure because that area is read-only, the MBC will intercept the instruction and page in a bank. E.g., after the following instructions: ld a,2 ld [$2000],aROM bank 2 (that is, the area of ROM from $8000 to $BFFF) will be paged into RAM locations $4000 to $7FFF. Banking is why pointers to ROM locations are typically between $4000 and $7FFF -- because they're really pointing to RAM, not directly to the ROM. It goes without saying that the area of RAM from $4000 to $7FFF is also read-only.
|
|
~Red
Camper
Posts: 68
|
Post by ~Red on Jan 12, 2010 8:39:20 GMT -5
So I could put decompressed sprites into the ROM. Switch to the bank that holds them then move it from that part of the RAM to the address that holds the currently loaded sprite?
(I think the address for opponents sprite and your backsprite is $9000 for about 200 bytes)
|
|
|
Post by iimarckus on Jan 12, 2010 15:04:28 GMT -5
Yes.
|
|