As far as I remember, arrays in Pascal have the size in element 0 and are thus not zero-based, but 1-based for indexing.
The code works for me, I cannot reproduce the error.
I've sent you an email, maybe you can send me you files.
Sorry to interrupt thread flow ... but ...
since AdlibTrackerII is coded on Free Pascal FPC Pascal, can some of good will do a port for MSX + OPL4?
No , it contains lots of x86 machine code, 16 bit direct memory access, and would be way to big.
Hi...
The laamasari libs define 0 as the first index in the array:
sprite.inc file:
{This code contains sprite handling routines and variables etc.}
{Kari Lammassaari 1997
- Type Sprite8Type = Array[0..7] Of Byte;
anyways i'll keep on working ... Thanks for answer...
OK, you're right, you can choose how to index them in Pascal. I had forgotten about that
I think I found the problem: somehow the compiler cannot handle the hexadecimal values you are assigning. However, the error.txt it creates, mixes up the line number and the error number, therefore it seems a nonsense error. Somehow a compiler bug it seems, as far as I know it is perfectly legitimate code. There are 2 solutions you can try:
1) convert the hex to decimal in the code
2) some better programming. It is much quicker and robust to put all the unique sprite strings in constants like so:
CONST FighterType1: Sprite8Type=($FF,$FF,$7e,$7e,$7e,$7e,$FF,$FF);
and initialize with:
setspritepattern(0, FighterType1);
Or assign to an array member:
EnemySprite[15]:=FighterType1;
...
Two good ideas but they didn't work. Pascal or the libs does not care about decimal or hex o const o var... They just care of pissing me off ... I'm down right now.
Believe me or not I've tried for too long. Too may hours. I'll give it a chance for a couple of weeks and If i have no results, I'll quit. I tired fighting against invisible and unexplainable things. It has no sense... Perhaps I'm not good enought. It's not a problem there are other ways of enjoy a MSX.
What a pitty...
PS: I know there are Basic, assembler an C ... (may Turbobasic...) but a don't like any of them ... too much cons... May be I give C a chance someday... in a far future
I feel your pain. That's why I started out with working on existing code that I could actually compile. And the reliability of many libraries is questionable. The samples/demo's that are included: none of them could compile. Only snowfighter. Kind of depressing, as there's lot of things possible.
The last possibility with your code: try it with turbo pascal 3.3 compiler in MSX-DOS itself. Than we know it's a bug in 3.3f (which is a hacked version after all)
I must say I never had any problems with 3.3f... and I used Kari's libraries.