Gameboy Development Forum

Hi PinoBatch, yes I am getting the feeling that hblank is quickly consumed with the lengthy c instructions.

The end result I'm trying to achieve is the following:

I have an artist making some ascii art using this software:
http://www.gridsagegames.com/rexpaint/index.html

He composes his art choosing symbols from this array of 16x16 custom tiles:
http://www.gridsagegames.com/rexpaint/f … _12x12.png

That ascii software lets him choose 2 arbitrary colors for each tile, we are restricting the total palette to 16 colors max, but I won't be able to restrict his workflow to using 8 palettes 4 colors each.
He's coming up with pictures like the first one on this page:
http://www.gridsagegames.com/rexpaint/gallery.html#

So, first thing I tried was processing his artwork with the standard hicolor technique, and it all went fine, it always converts perfectly, no color bleeds.

Now my thought is: hicolor is overkill in my case, I don't want 8 palettes swapped every 1 or 2 scanlines, I just need to recolor each row of tiles.

Final aim of my experiment is:
1) Export from the ascii art software each screen he makes, extracting a standard array of tiles id is of course the easy part.
2) I will collect palettes and tile attributes in a tiles-row fashion, restricting to 8 palettes of 4 colors per row (making offline colors optimization at this stage).
3) Where I'm stuck, the GBC code that loads these palettes per row of tiles.

Problem is, I'm learning ASM just to solve this problem, and I'm still very confused on how I'd go about swapping the palettes in memory during hblank.

First problem that comes to my mind is where the asm code would fit in my C code, would something like this work?
  while(1){
    asmHBlankCode();
    gameCode();
    wait_vbl_done();
  }

Last edited by andreai (2018-06-08 02:06:55)

Thanks ISSOtm!

This is super useful, as well as super hard to understand just yet.

Before being able to start using that code I need a step back to really understand if I can have the palette/index asm routine enclosed in a C outer frame, and if yes, understand where this asm routine fits in the C code.

I know, you said it's not adviced for a game, but this game is really just a branching tree of static screens, like a game-book, so nothing else really goes on in the main loop aside from querying the joypad.

My guesses as to how to proceed:
Option A, the asm function is called from the main game while loop:
  while(1){
    asmCode(); // will this be in sync with the STAT register to understand when is the right time to swap palette?
    gameCode();
    wait_vbl_done(); // ?? do I need this here or is best moved inside the asm function?
  }

Option B, invoking the asm function from a GBDK interrupt handler instead.
But I guess GBDK is invoking a C function where I'm invoking the asmFunction, so I guess I'm wasting all the cycles I need to do the palette job, right?

Option C, can I somehow invoke an asm function before entering the main game loop and from that asm function setup the asm interrupts that will handle the palette swap?
main(){
asmCode();

  while(1){
    gameCode();
    wait_vbl_done();
  }
}

This would be the best of both worlds, as I'd keep my C loop while the interrupt jumps to the right asm instruction automatically.

Is one of these options viable or am I completely off?

Thank you ISSOtm! I am working on option A, I'll go trhough one step at the time.
Maybe by the end of this exercise I'll have enough understanding of the gbz80 that I will rewrite the whole thing in asm : )

For now I have a first success, I'm setting some test palettes for each row of tiles from asm code, also thanks to your snippets!

I do get flickers depending on what I do though, no idea why...I'll see what happens from here and post back the results (hopefully soon).

You might try different approach. Instead of abusing HBlank, try converting your pictures with bmp2cgb. For example, such picture gives me following output:

Bitmap size: 640 * 1056 px
Character/Attribute map: 80 * 132 = 10560 chars
Palettes usage: 8/8 slots
Tiles used: 57 (10503 duplicates removed: 10277 normal, 226 horizontal, 0 vertical, 0 horizontal & vertical, 0 transparent)

It's a bit overkill but serves as example that it could be displayed without any hassle. Of course your data might differ but you won't know unless you try.

Hm, just to clarify: above output is from w.i.p version, not available on GH yet. The old one couldn't handle whole image but with this excerpt I got:

Bitmap size: 256 * 256 px
Character/Attribute map: 32 * 32 chars
Palettes usage: 3/8 slots
Tiles used: 29 (995 duplicates removed: 967 normal, 28 horizontal, 0 vertical, 0 horizontal & vertical)

Last edited by tmk (2018-06-09 16:12:10)

Hi guys, yes, as I keep on studying the matter at hand, I'm also convinced the hblank trick is overkill.

The artwork from the textmode is 16 colors max, the app already gives me all the info I need in terms of tiles id and colors used (2 colors per tile), here's how to the converter should work I think:
# 1 collect unique tiles used
# 2 unify tiles that can be flipped and populate attribute array
# 3 collect the 2colors palette for each cell and associate each unique palette with each unique tile
# 4 compose 4x8 palettes merging the 2colors palettes and making sure coupled colors are kept together (not splitted across the 4colors palettes)
# (if colors can't form 4x8 palette warn artist he is a bad person)
# 5 for each unique tile collected in step 1, duplicate it for as many 2colors palettes associated in step 3 and swap pixel-colorId to match the proper 4 colors palette, keep populating the attribute array with palette-id per tile association
# (if total number of tiles used is more than 384, warn artist and detonate his computer)

Using both video memory banks I think I have all I need (and more) to handle that kind of artworks : )