Gameboy Development Forum

I gave it a shoot, and it really looks good, so great job. Did you work on every part of it on your own? I'd be mostly curious in the functions you used to arrange the various numbers' tiles since their graphics are really large. So, yes, I think I'd find the source code interesting.

looking for other gameboy programmers to make art/demos with

I'm more into ROM hacking, so I don't know if I would fit; what are your projects and plans, if I may ask?

I gave a quick look at the source, it's pretty neat (even if I found it too much articulated, in terms of number of splitted files). By the way, why did you store graphics as "byte declarations", wasn't it less tedious if you saved them as binary files?
Also, I noticed that you always used "jp" even if a "jr" was usable; you probably didn't have problems of optimizations considering the small size of required space. For bigger projects, since you said you're going to re-use some code, you might consider to optimize some parts of code.

As for me, I think I'm pretty comfortable with ASM. Actually, I'm working on a couple of projects:
- a disassembly (for eventual translation) of an unlocalized japanese game (bitbucket link here), which is on hold at the moment (havent worked on it since ages);
- a ROM hack of Pokemon Blue, called Wood (link to the thread), which is my main work, and will sure take a lot of time to be finished.

About compression, are you looking for documentation or actual code?
About text displaying: I don't think it should be a problem for you implementing it, considering the work you just showed. Anyway, if you will, I can disassemble the code that pokemon blue uses, or write down the main parts (will take some time, though).

Last edited by sawakita (2011-05-25 17:36:10)

When I said "too articulated" I was in a different mind, it was personal preference, since for my hack I keep all the code in one file (except for the Real Time Clock engine), and split data tables and constants on their own files (this is done because, since many routines aren't labeled, if I happen to disassemble a routine, I will then replace the raw address with the label given, so looking through a single file is faster than having more files). I realize that your project, being a development made from scratch, probably doesn't require this kind of "ploys".

Graphics' compression methods:
- Red/Blue/Yellow compression doc and my incomplete disassembly (a "c" program exists to decompress images from ROM, but no tools exist to compress data, as for now)
- Gold/Silver compression doc and compression tool
- some more compressions
It seems tha R/B/Y's compression is more efficient, but isn't usable unless you find a way to built a compressor (to simplify the method you could remove the meta-code part, if you aren't interested in mirroring on-the-fly, which seems to be one of the best advantages of this compression).
The G/S/C's compression is well documented and supported by more than one tool (I linked you the one I know, but I heard there are others)
If you're looking for something different you could implement a LZ compression (about which I know nearly nothing), which seems to be the most "trendy" (considering it's used very often in GBA and NDS games).

I should have said first that I haven't a good relationship with compressions (in fact I had to implement a "uncompressed-GFX branch" to the compression routine in Pokemon Blue/Wood [btw, I fixed the link in my previous post], to be able to add new monsters' pictures). So I'm probably the last person that should be giving advices about compression.

I'd definitely like to see the code from pokemon blue

What part of code are you referring at, exactly? Or you mean all of it? Because I use a partially disassembled ROM + "INCBINs". You can give a look at IIMarckus' WIP disassembly, on which I based mine (it's of Red, but Blue is almost the same).

About optimization:
another part you could have optimized was this (file is time_digit_functions.asm):

.nine:
    ld    bc,nine_map
    call    load_digit
    ret
.eight:
    ld    bc,eight_map
    call    load_digit
    ret

;(...)

.zero:
    ld    bc,zero_map
    call    load_digit
    ret

you could put:

.nine:
    ld    bc,nine_map
    jr .call_load_digit
.eight:
    ld    bc,eight_map
    jr .call_load_digit
.seven:
    ld    bc,seven_map
    jr .call_load_digit

;(...)

.zero:
    ld    bc,zero_map
.call_load_digit:
    jp    load_digit

when you have a "call" followed by a "ret" you should always use "jp" instead, because it uses less space in ROM and doesn't push anything in stack.
At devrs there's a document describing some optimization tips.

About Blue's text displaying routines, if you want them it will take me a while to reverse-engineering them.

Last edited by sawakita (2011-05-25 17:37:13)

hey, sorry for the late reply, I sort of forgot about this forum. Anyway, do you remember the link I gave you about Pokemon Red disassembly? The owner is actually working on reversing the text-engine so you can look at it (or at least, at part of it).

Thank you for the GFX offer, although I already have what I need, except perhaps some new tilesets for the maps.