Author Topic: Catastrophy: In Development  (Read 18530 times)

sirhcman

  • Guest
Re: Catastrophy! (Current working title)
« Reply #30 on: September 12, 2015, 11:40:44 AM »
so does this mean we will have parallax?

Lost Monkey

  • Hero Member
  • *****
  • Posts: 1342
Re: Catastrophy! (Current working title)
« Reply #31 on: September 12, 2015, 12:18:52 PM »
Cat Ass Trophy? Do you ship to Canada?

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Catastrophy! (Current working title)
« Reply #32 on: September 14, 2015, 05:12:47 AM »
I can help with some parallax code for HuC (I've written a few libraries for it). HuC does offer hsync, or scroll, support. That might be enough for what you need, though.

 If you find that things start slowing down, it's most likely array or pointer access. This is painfully slow on HuC (local variables are as well; use globals when possible). Bit shifting is also pretty slow. But surprisingly, it's not that difficult to overcome with some function/asm/code. I've done stuff like make C fastcall pragma functions, with asm on the target side, that can easily be used to access far data or pointer/array data. So instead of var=array[index], you'd do something like var=array_access(array,index). HuC treats all near data as far data when a pointer is used, so you get no speed increase when using local ram for arrays (which you would normally think you would).

 Anyway.. dynamic tiles, hsync scrolling, sprites - that's how you're going to get parallax out of the system.

DarkKobold

  • Hero Member
  • *****
  • Posts: 1200
Re: Catastrophy! (Current working title)
« Reply #33 on: September 14, 2015, 05:46:00 AM »
If you find that things start slowing down, it's most likely array or pointer access. This is painfully slow on HuC (local variables are as well; use globals when possible). Bit shifting is also pretty slow. But surprisingly, it's not that difficult to overcome with some function/asm/code. I've done stuff like make C fastcall pragma functions, with asm on the target side, that can easily be used to access far data or pointer/array data. So instead of var=array[index], you'd do something like var=array_access(array,index). HuC treats all near data as far data when a pointer is used, so you get no speed increase when using local ram for arrays (which you would normally think you would).

Interestingly, I've not run into any speed issues yet with the game. Most parts are just doing fun things with state machines, so no one piece of code currently being run is incredibly intensive. Also, I've found that most of my speed comes from sticking to char as much as possible. At least, that has been my dogmatic approach, since the HuC6280 is an 8bit processor.

My biggest concern is just running out of space, atm. I'm not sure how optimal the compile is, so if it ends up burning through chunks of ROM, we won't be able to make the game as cool as possible.
Hey, you.

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Catastrophy! (Current working title)
« Reply #34 on: September 14, 2015, 05:51:09 AM »
If you don't use one of the optimized option for HuC (I forget which switch), all char access is treated as int anyways (for operations).

DarkKobold

  • Hero Member
  • *****
  • Posts: 1200
Re: Catastrophy! (Current working title)
« Reply #35 on: September 14, 2015, 06:31:24 AM »
If you don't use one of the optimized option for HuC (I forget which switch), all char access is treated as int anyways (for operations).

So, afaik, it did help. In my early days, I was accessing some of my arrays using int. array[int]. I was getting major timing issues. When I switched to array[char], the code ran without issues. Perhaps getting your assembly routine might help even more. I don't use a ton of arrays atm, but that might change. Thus far, I've been pointer-free.
Hey, you.

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Catastrophy! (Current working title)
« Reply #36 on: September 14, 2015, 06:25:23 PM »
Ahh yeah, int array access will be slower than char. HuC doesn't optimize for split high/low array of 16bit wide elements (something very common with 65x line). Writing backend functions as fastcalls is a nice way to keep it C style, without the inline asm mess, but still get some of that asm speed. I'm not sure how the other HuC guys do it, though. Maybe they can chime in with their closely guarded secrets :)

Punch

  • Hero Member
  • *****
  • Posts: 3278
Re: Catastrophy! (Current working title)
« Reply #37 on: September 14, 2015, 06:30:51 PM »
Can't you do a "#define int char" to cheat on speed anyway? :v

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Catastrophy! (Current working title)
« Reply #38 on: September 15, 2015, 04:34:31 AM »
This might be some inspiration. The gameboy only has one BG layer.

DarkKobold

  • Hero Member
  • *****
  • Posts: 1200
Re: Catastrophy! (Current working title)
« Reply #39 on: September 15, 2015, 05:23:11 PM »
Stupid question time! I'm getting a green border on my TV. I thought this was color 0, but I must be mistaken, because I set it to 0, and it still is bright green.

Hey, you.

Punch

  • Hero Member
  • *****
  • Posts: 3278
Re: Catastrophy! (Current working title)
« Reply #40 on: September 15, 2015, 05:34:59 PM »
Mega Cat?

You're writing ZERO to the palette #0 slot #0, but are you updating the higher byte? Remember that they're all 16 bit registers, and a color slot index is like this:
MSB | LSB
---- ---G | GGRR RBBB
Probably the MSB is set to 00000001, giving value '4' for the green color.

edit:
Mega-Neko?

Another thing, if I recall correctly the sprite color #0 is used for the overscan area, but I'm not sure, maybe try inspecting that too?
« Last Edit: September 15, 2015, 05:41:16 PM by Punch »

Gredler

  • Guest
Re: Catastrophy! (Current working title)
« Reply #41 on: September 15, 2015, 07:14:17 PM »
Another thing, if I recall correctly the sprite color #0 is used for the overscan area, but I'm not sure, maybe try inspecting that too?

Yes that green color is what I've been using for index color 0. Should I make two black colors on thr index? Is this not only a emulation issue? I dont see it when testing on the everdrive, only when using an emulator

DarkKobold

  • Hero Member
  • *****
  • Posts: 1200
Re: Catastrophy! (Current working title)
« Reply #42 on: September 15, 2015, 07:24:51 PM »
Mega Cat?


Hell yes!

Mega-Neko?


Hell no!

Another thing, if I recall correctly the sprite color #0 is used for the overscan area, but I'm not sure, maybe try inspecting that too?


Cool, I can give that a try. Its easy to write setcolor(256,0) if that is all it takes.

Yes that green color is what I've been using for index color 0. Should I make two black colors on thr index? Is this not only a emulation issue? I dont see it when testing on the everdrive, only when using an emulator



If you are on a CRT, it isn't a problem. Cue galam coming in to abuse me in 5...4...3...2...1...

« Last Edit: September 15, 2015, 07:41:13 PM by DarkKobold »
Hey, you.

sirhcman

  • Guest
Re: Catastrophy! (Current working title)
« Reply #43 on: September 15, 2015, 10:50:08 PM »
Game looks great dk, you guys should be proud!

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Catastrophy! (Current working title)
« Reply #44 on: September 16, 2015, 04:57:02 AM »
Stupid question time! I'm getting a green border on my TV. I thought this was color 0, but I must be mistaken, because I set it to 0, and it still is bright green.




 Color 0 for BG is the BG color, obviously, but color 0 of the sprite index (@ $100) is the border color when no display is showing (BG or sprites).