Messages

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Gah, you are right!

I only recompiled the exes and completely forgot to copy the include directory. Game compiles and works fine with the latest HuC when I copied that direcrory, except for sound obviously (I was using Ulis IRQ).

I don't mind sharing the project source if you need more regression tests. I should fix some stuff first though, like sound.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Hello, I'm trying to get my game up and running in this new version of HuC (previously used a fork of Uli's) but I'm having problems. I'm trying one commit at the time.

The following commit introduces this compile error:

Code Select Expand

commit: Fix arg_to_fptr() usage of magic numbers for argument types. 11/14/2016 08:16 John Brandwood

1>  ;error: pce/pce.c(479)
1>  ; case 0: map_data = pce_ep1_map00; pce_map_banks = bank( pce_ep1_map00); set_map_data( pce_ep1_map00 + 4, 32, 32); break;
1>  ;                                                                                                                ^
1>  ;******  can't get farptr  ******

Which is later fixed by this commit:

Code Select Expand

commit: Hack to fix Uli's fake-symbol kludge that was breaking arg_to_fptr(). That whole fake-symbol klud... 11/15/2016 09:43 John Brandwood
The game however is just completely broken when running in Mednafen. I guess I will have to try all commits in-between (which doesn't compile due to the farptr error above) to find which commit is actually breaking my game.

And finally this commit introduces an assemble error that is still present in the HEAD commit:

Code Select Expand

commit: Change System Card variables in "equ.inc" to use a "__" prefix. 11/16/2016 08:15 John Brandwood
1>  #[1]   game.s
1>   2073  16:A8FF            stx __ax
1>         Undefined symbol in operand field!
1>   2073  16:A902            sta __ax+1
1>         Undefined symbol in operand field!
1>   2075  16:A909              stx __cl
1>         Undefined symbol in operand field!
1>   2082  16:A91A              stx __dl
1>         Undefined symbol in operand field!
1>   2084  16:A921            stx __di
1>         Undefined symbol in operand field!
1>   2084  16:A924            sta __di+1
1>         Undefined symbol in operand field!
1>   2096  16:A934              stx __al
1>         Undefined symbol in operand field!
1>   2097  16:A939            sty __bl
1>         Undefined symbol in operand field!
1>   2097  16:A93E            sty __si
1>         Undefined symbol in operand field!
1>   2097  16:A943            sty __si+1
1>         Undefined symbol in operand field!
1>   2099  16:A94A              stx __cl
1>         Undefined symbol in operand field!
1>   2103  16:A954              stx __al

Not sure what the last one is about. Any pointers?

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

The original MOD spec doesn't allow you to change the 'BPM' setting. That's a later thing, in other trackers. And it has nothing to do with rhythmical feel. Because artists have told me what they were trying to do. I don't know about you, but I can't distinguish between a tick difference every other frame in relation to note lengths; I can only perceive it as change in tempo.

I was mainly talking about more advanced module formats though, like S3M, XM and IT. But for MOD this is probably true, but the same can be seen in XM songs which always had tempo control. The original MOD format is near useless as a intermediate music format.

To me it's very apparent in drum sequences. But usually it's at least a 2+ tick alternation and probably in a different BPM as well.

I recently fixed a "bug" in my replayer for PC that was causing each tick to be +-2.9 ms off (rounded to nearest audio frame of 128 samples). When I fixed this to be sample accurate there was a night and day difference, especially when you used the retrig command.

No, 50hz is 125BPM. 60hz is 150BPM in trackers. Hz * 60 / 4 / 6.

Yeah of course. I mixed up PAL and NTSC, I'm too used with PAL.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

So if the BPM is based on down count of 3 (1/60 ticks), when that expires refill the downcount to 3-1, then on expire back to 3 - and repeat. You'd think this would get you 'warbly' sounds, but it doesn't. It gets you a BPM that's in between a 3 tick and a 2 tick. In MOD or XM files, you can set the tick on every pattern line, and a pattern line is read once the tick down count reaches 0. So it's not uncommon to see something like tick defines as 3,2,3,2,3,2,3,2 going all the way down the pattern - etc. Of course, you could do this on the player side too.

Well, when modules do alternating speed changes it is not to simulate an in-between tempo, it is to create a rhythmical feel where every other note is longer/shorter. If they wanted to change tempo they would just change the BPM.

Of course you could do this to simulate a different tempo but to me that would change the musical impression of the song.

60 Hz is always going to be 125 BPM in a tracker, so I would avoid creating modules in other tempos.

Anyway, back to topic perhaps.

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

Well, isn't the purpose of programming to do things yourself? Plus I already have an accurate XM/S3M replayer so outputting this data was easy.

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

I have no experience with MML, in my understanding it's just a container format for music just like MID. I don't care about that as I hate working DAW tools.

For my game I run my XM player on PC and convert every tick (or every other tick if you don't want full resolution) to an absolute PCE period and volume value and save that to a file. Then on the PC Engine I would just read a byte that tells me what's in the current tick, and if'ts not empty I read and apply the PSG states (period, volume).

This way I support all effects and envelopes without any runtime overhead. The downside is that it might use a bit more ROM than other solutions.

Currently I can generate the file but not yet play it. I haven't worked on my game for a few months for reasons but I hope to continue on it next year.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Yep, I installed the wrong gcc package (just named "gcc"). Apparently that is based on Cygwin... 

EDIT: Works now and the game runs. I also had to increase "#define NUMTAG 10" to 64.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

I successfully compiled HuC with the msys2 you linked, but I cannot launch the executables outside the msys shell. Missing msys-gcc_s-1.dll and more.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

I use the timer interrupt for DDA sound streaming. The way I setup my IRQ handler is super hacky and it would much better if there was a cleaner way of doing this.

This is my initialization code

Code Select Expand

#asm
sei
setvec #2, pce_timer_interrupt
vec_on #2
cli
#endasm

irq_enable(IRQ_TIMER);
timer_set(1);
timer_start();

pce_timer_interrupt defined as follows

Code Select Expand

#asm
...

pce_timer_interrupt:
dda_update 0, _pce_dda0, _pce_dda0+1, _pce_dda0+2, _pce_dda0+4
dda_update 1, _pce_dda1, _pce_dda1+1, _pce_dda1+2, _pce_dda1+4

;// Remap old banks if changed
bbr7 <snd_flags, .return
rmb7 <snd_flags ;// Clear mapped bit
lda _pce_snd_oldbanks ;// a = old lower bank
tam #DATA_BANK
lda _pce_snd_oldbanks+1 ;// a = old upper bank
tam #DATA_BANK+1

.return:
rts
#endasm

I also modified startup.asm in HuC to get my handler up and running

Code Select Expand

timer_user:
  jmp   [timer_jmp]
 timer:
- bbs2 <irq_m,timer_user
  pha
  phx
  phy
+ bbr2 <irq_m,.ack
+ jsr timer_user
+.ack:
  sta   irq_status ; acknowledge interrupt
-.exit: ply
+ ply
  plx
  pla
  rti


As I said, this was just hacked together to get around the unfinished IRQ/timer implementation in HuC.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

How do you compile for Windows if you are not using Cygwin?

I can test your latest build but it is currently incompatible with my game due to the struct member limit. Here are a couple of changes I did to in my fork of Ulis HuC that I never pushed. Btw, I'm markusburetorp on Github, I also did some changes to pcxtool which you already integrated.

bump total number of struct members from 30 to 128
src/huc/defs.h

Code Select Expand

-#define NUMMEMB         30
+#define NUMMEMB         128

irq_enable and irq_disable behavior was inverted
include/pce/library.asm

Code Select Expand

_irq_enable:
  txa
+ eor #$ff
  sei
- ora irq_disable
+ and irq_disable
  sta irq_disable
  cli
  rts
 _irq_disable:
  txa
- eor #$ff
  sei
- and irq_disable
+ ora irq_disable
  sta irq_disable
  cli
  rts


[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

In my game I don't use any explicit multiplications at all, so personally I don't want the 2k table in my ROM. But there are probably a bunch of implicit ones from array accesses though.

I use "16bitvalue >> 4" a lot though, I haven't looked into optimizing the generated code for that. Is that worth doing?

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Using local variables isn't as bad in this version if you compile with -fno-recursive -msmall.

[Localizations, Games, Apps, Docs / Re: Stupid @#$@!# HuC hit another imaginary limit.]

I hit the max number of structs (32) pretty quickly in Ulis HuC. I bumped the constant and recompiled, works! Might be that simple for the function limit as well, although I have a lot of functions and no problem yet.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

Clang + LLVM backend for Hu6280 would be optimal. HuC works fine for me but a better compiler would mean more advanced homebrew.

In my homebrew game the game code is cross platform and the PCE backend is a mix of HuC + asm. I plan to port it to Amiga and SNES in the future (if I ever finish it). Without C this would not be possible.

[Localizations, Games, Apps, Docs / Re: The new fork of HuC]

I've used it for about a year now. I use Cygwin for compiling and you can use the compiled exe without Cygwin later, just need to have a cygwin dll copied alongside the exe files.

I would not have started doing PCE homebrew without this fork.

[Localizations, Games, Apps, Docs / Re: SGX HuC lib question]

Nice in that they fixed that glaring issue of treating fixed ram arrays as far data. Local variables used an internal stack (with indexing), which made them slow. How did this solve this? Especially for nesting functions? ZP+indexing address mode?

You simply can't have nested function calls (this is a compiler switch). This is not a problem for me.

What made you choose HuC over CC65? The existing library support?

I wasn't aware of the CC65 until just recently. I probably not bother with it at this stage.KMN

[Localizations, Games, Apps, Docs / Re: SGX HuC lib question]

I use uli's updated version of HuC (https://github.com/uli/huc) which comes with some SuperGrafx support as well. Arrays are no longer far ptr accesses, you can use local variables etc. I'm working on my first PC Engine homebrew game at the moment and it's a breeze to develop using HuC. The only code that required assembly was the sound code (dda streaming). Having the game code in C is a must for me since I plan on porting the game to Amiga and DOS later.

Obviously there are some quirks that required me to recompile the compiler and modify the HuC library, but those are simple changes. Another quirk is that it is easy to write illegal C code that still compiles an runs but with undefined behavior, I solved that by cross-compiling the game code on PC with static analysis.

[Localizations, Games, Apps, Docs / Re: Some audio stuffs]

Hello, my first post here.

What is the difference between HuC6280 and HuC6280A exactly? I've head different things like click reduction and panning fixes?