The new fork of HuC

[nodtveidt]

I think he meant with straight-up HuC code though... there's no direct function for it.

[touko]

I think he meant with straight-up HuC code though... there's no direct function for it.

Ah ok, if it's only huc functions you'r right .

[Bonknuts]

Getting back to work on Catastrophy, I've had a few thoughts on what would be helpful to have, as asm code.

First, there is no way to clear vram directly. A quick bit of asm that writes all zeros to vram would be helpful. cls() and reset_satb() don't actually empty the vram. (The main reason I need this is because I'm using 48pix high images in 64pix high sprites. Thus, I need to clear out the extra 0x80 of unused sprite space)

 Yeah, if I remember (this weekend), I can write you a simple set of functions in HUC to do this for you. If someone hasn't already.

Second, an asm code for doing simple RLE decoding into vram would be awesome, assuming one could also add a separate program that compresses images into .bins, and tells you the % savings.

 That's pretty doable. I don't know about anyone else, but I've had to write different RLE compressors to re-inserting compressed graphic data back into rom (hacking). So it wouldn't be too difficult just to adapt such tools for regular use.

Finally, a program that helped you keep track of what is in vram would be awesome. Essentially, it'd just be a 32pixel wide listing from 0x0000 to 0x8000, so you could insert your images, and see how much you are using up. I know that sort of exists in emulators, but its hard to actually use.

 So you feed a "script" file some text, like what HUC uses, and use that to output a list as well as a visual pic of how vram is organized? Pretty doable, but it's only really valuable if your level or such is static in vram usage. Dynamic allocation is a bit harder to show resource usage for.

[DarkKobold]

So you feed a "script" file some text, like what HUC uses, and use that to output a list as well as a visual pic of how vram is organized? Pretty doable, but it's only really valuable if your level or such is static in vram usage. Dynamic allocation is a bit harder to show resource usage for.

Honestly, I was just thinking something like an excel style chart, where I could just load the PCX files in. Its probably really not necessary, as better planning and execution would help. As rover pointed out, a little bit of planning goes a long way. Usually I just load stuff into vram where I'm fairly certain there is free space.

[DarkKobold]

Getting back to work on Catastrophy, I've had a few thoughts on what would be helpful to have, as asm code.

First, there is no way to clear vram directly. A quick bit of asm that writes all zeros to vram would be helpful. cls() and reset_satb() don't actually empty the vram. (The main reason I need this is because I'm using 48pix high images in 64pix high sprites. Thus, I need to clear out the extra 0x80 of unused sprite space)

 Yeah, if I remember (this weekend), I can write you a simple set of functions in HUC to do this for you. If someone hasn't already.

Any luck with this?

[Bonknuts]

I'm not at a system that I can test this code on, but try this out:

Code: [Select]

void clearVram(int cellOffset, int numOfCells)
{

  /* vramAddress and VDCcells are global ints */
  vramAddress = cellOffset<<4;
  VDCcells = numOfCells;
 
#asm
   
    ;// In ASM, global variables are accessed with a preceding underscore.
   
    st0 #$00
    st1 #low(_vramAddress)
    st2 #high(_vramAddress)
    st0 #$02
       
    lda #low(_VDCcells)
    ldx #high(_VDCcells)
    st1 #$00

   
.loop   
    ;// Plane 0 & 1
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
   
    ;// Plane 2 & 3
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
   
   
    sec
    sbc #$01
    bcs .loop
    dex
    bne .loop

  #endasm

}

 It doesn't stall interrupts. It clears vram on a tile basis count, and a tile offset location. Normally vram is $0000 to $8000, but using tile offsets it's $000 to $800. Typically, HuC puts tiles at vram address $1000, which it tile offset $100. If you want to clear a single sprite cell, that would be a group of 4 tiles (a tile is 32 bytes, a sprite cell is 128 bytes). For example: to clear a single 16x16 sprite at vram address $5000, then do $5000 / $10 = $500 and a sprite cell is 4 tiles, so clearVram($500, 4). To clear all of vram; clearVram($000, $800). Etc.

 It's pretty rare that you'd want to "clear" a section of vram that's not tile based (the offset or segment system) - i.e. finer than 32byte segment/offset. It's also faster to do it this way too (32 bytes are clear in one loop iteration).

[touko]

It's more faster to hide sprites and clear the BAT (addr $0000 -> $0800,it depend of your virtual screen size), than all the vram .

If you put zero in the BAT region to clear it, you'll see some artifact the next time on empty BAT parts if your screen is not entirelly filled with tiles,this is why it's better to clear the BAT with an empty tile .

[Bonknuts]

I'm assuming he wants to clear vram so that when he's viewing it in debugger window, vram contents match the area/section of the game code.

[DarkKobold]

I'm assuming he wants to clear vram so that when he's viewing it in debugger window, vram contents match the area/section of the game code.

Actually, its because we use quite a few 32x48px tall sprites, just loaded into a 32x64 sprite size. So, I load the VRAM with 0x180, and the extra 0x80 is filled with a previous VRAM load.

P.S., thanks for the code. I'll probably just use it to clear VRAM entirely at each level load, so timing shouldn't matter a ton.

[Bonknuts]

I'm assuming he wants to clear vram so that when he's viewing it in debugger window, vram contents match the area/section of the game code.

Actually, its because we use quite a few 32x48px tall sprites, just loaded into a 32x64 sprite size. So, I load the VRAM with 0x180, and the extra 0x80 is filled with a previous VRAM load.

P.S., thanks for the code. I'll probably just use it to clear VRAM entirely at each level load, so timing shouldn't matter a ton.

 Let me know if you have problems with it, or want to change it in anyway. I usually have some time on the weekends, so I can get to it within a week time frame. PM here and I'll give you my tomaitheous email address.

[touko]

Actually, its because we use quite a few 32x48px tall sprites, just loaded into a 32x64 sprite size. So, I load the VRAM with 0x180, and the extra 0x80 is filled with a previous VRAM load.

With meta sprites your problem would have gone .

You can also use this trick, you can transfert a blank 32x16 sprite in top/bottom of your 32x48 to clear the unused part,before transfer your sprite .
It's more faster than clearing all sprites/VRAM .

[Bonknuts]

Well, I'm assuming he wants to do this during the start of level or area loads. Not exactly in the middle while the game mechanics are functioning.

 Otherwise, if you're dynamically updating sprite data during the game and have this issue, I would use a special sprite load routine where it blanks out the remaining cells.. is best (and not the whole 32x64 block). That could work during in game updating. The routine I wrote could still work in conjunction with this as well.

[DarkKobold]

Actually, its because we use quite a few 32x48px tall sprites, just loaded into a 32x64 sprite size. So, I load the VRAM with 0x180, and the extra 0x80 is filled with a previous VRAM load.

With meta sprites your problem would have gone .

I haven't a clue what you mean by metasprite? A 32x32 and 32x16 put together?

[touko]

I haven't a clue what you mean by metasprite? A 32x32 and 32x16 put together?

Yes it's an exemple, it's a logical(software) sprite composed by many hardware sprites .
for a 32x48 pixels sprite you don't have to worry for the last 32x16 pixels,because it decomposed into 2 "little" sprites(32x32+32x16) and not a whole 32x64 like you did with 1 hardware sprites.
It's also a more efficient method to avoid/reduce flickering.

32x64 is very good for a full filled sprite, not for unsuported intermediate size like 32x48 or 16x48 etc ..

[nodtveidt]

If you have sprites to spare, 32x32+32x16 is better, but if your game is a sprite monster, 32x64 is sometimes your only option. It all depends on your sprite budget. From what I have seen of DK's game, it uses a lot of huge sprites, so maybe 32x64 is better. Also, if you have a general sense of where your sprites will be during gameplay, you can optimize the sprite pixels. For example... in HE's stage 00, we have 32x48 objects, but they have to use 32x64 sprites because the game engine literally uses every sprite the hardware has. However, we leave the bottom 16 pixels open. For some games, you might want to do the reverse... make the top pixels open and align the sprite pixels to the bottom of the sprite block... useful for, say, a 32x48 stalactite in a cavern... that way, you don't have 16 empty lines at the bottom of the stalactite, just waiting to cause an unintended overflow.