+- Forum (https://www.boriel.com/forum)
+-- Forum: Compilers and Computer Languages (https://www.boriel.com/forum/forumdisplay.php?fid=12)
+--- Forum: ZX Basic Compiler (https://www.boriel.com/forum/forumdisplay.php?fid=11)
+---- Forum: Gallery (https://www.boriel.com/forum/forumdisplay.php?fid=18)
+---- Thread: New game: Earthraid (/showthread.php?tid=462)
Re: New game: Earthraid - LCD - 05-31-2012
EarthraidSourceFiles.zip (Size: 8.3 KB / Downloads: 727)
Here are the source Files of "Earthraid". After compilation you must load BeepFXDemo at 60000 for the beeper effects or else the game will crash. But you can also REM out all lines with "call 60000". I used Assembler Call to not destroy the seed of randoms, and to save some bytes.
Re: New game: Earthraid - britlion - 05-31-2012
I'm surprised you didn't incbin or #include the assembly - that's what I did for my sound tests....
Re: New game: Earthraid - JBGV - 05-31-2012
Thanks !
Re: New game: Earthraid - LCD - 05-31-2012
britlion Wrote:I'm surprised you didn't incbin or #include the assembly - that's what I did for my sound tests....That was because it uses fixed addresses. Using ORG was a pain in my previous games. Nice Tool but I failed until now to make a SUB of it.
After the game was completed, I just added the sound effects using BeepFX preview function. I know, thats a bit primitive, but... It works.
JBGV Wrote:Thanks !You are welcome.
Re: New game: Earthraid - britlion - 06-01-2012
Oh - it's pretty easy. You have to output assembly, and perhaps do a search and replace on "PAT" for a unique name.
For example, right now my never-to-be-completed footy game has multiple tunes in it:
Code:
SUB FASTCALL playTune(tune AS UBYTE)
REM gets a 0,1,2 in A and sets HL to point to relevant tune before dropping into player.
ASM
AND A
LD HL,TUNE1
JR Z,TUNESTART
DEC A
LD HL,TUNE2
JR Z,TUNESTART
LD HL,TUNE3
#include "Player.asm"
TUNE1:
#INCLUDE "Grandstand.asm"
; 400 bytes
TUNE2:
#INCLUDE "MOTD.asm"
; 489 bytes.
TUNE3:
#INCLUDE "WorldOfSport.asm"
; 102 bytes
END ASM
END SUBAnd each assembly output from beepola has been tweaked to be unique:
Code:
DEFB 0 ; GrandStandPATtern loop begin * 2
DEFB 50 ; Song length * 2
DEFW 12 ; Offset to start of song (length of instrument table)
DEFB 1 ; Multiple
DEFW 0 ; Detune
DEFB 0 ; Phase
DEFB 0 ; Multiple
DEFW 6 ; Detune
DEFB 0 ; Phase
DEFB 1 ; Multiple
DEFW 12 ; Detune
DEFB 0 ; Phase
GrandStandPATTERNDATA: DEFW GrandStandPAT0
DEFW GrandStandPAT0
DEFW GrandStandPAT1
DEFW GrandStandPAT3
DEFW GrandStandPAT2
DEFW GrandStandPAT6
DEFW GrandStandPAT3
DEFW GrandStandPAT5
DEFW GrandStandPAT6
DEFW GrandStandPAT3
DEFW GrandStandPAT4
DEFW GrandStandPAT7
DEFW GrandStandPAT4
DEFW GrandStandPAT8
DEFW GrandStandPAT9
DEFW GrandStandPAT10
DEFW GrandStandPAT1
DEFW GrandStandPAT3
DEFW GrandStandPAT2
DEFW GrandStandPAT6
DEFW GrandStandPAT3
DEFW GrandStandPAT5
DEFW GrandStandPAT6
DEFW GrandStandPAT3
DEFW GrandStandPAT11
; *** GrandStandPATtern data - $00 marks the end of a GrandStandPATtern ***
GrandStandPAT0:
DEFB $BD,0
DEFB 190
DEFB 119
DEFB 190
DEFB 118
DEFB 6
DEFB $00
GrandStandPAT1:
DEFB 178
DEFB 154
DEFB 119Just by search and replace of "PAT" with "GrandStandPAT" to make all labels unique to this bit of code.
Player code is included separately from data, therefore.
Re: New game: Earthraid - LCD - 06-02-2012
I will try when I'm back.
Re: New game: Earthraid - britlion - 06-04-2012
Very nice little game, LCD. Very difficult, too - even on easy levels! There's never enough time to hit back. I was using poison a lot, and then realised that just shortens lifespan, and really doesn't stop the darned things. Mines seem to be the most winning.
I noticed it seems to crash occasionally - a couple of times when generating a landscape and once right after starting. There's some corruption occurring sometimes, somewhere...
LCD Wrote:By the way, I noticed that BeepFX crashes in ZXBC if is called inside a SUB:
Code:Sub BeepFX(effect as ubyte)
poke 60001,effect
asm
call 60000
end asm
end sub
I think that's because it corrupts the IX register. I've posted a HOWTO for a cleaner method of using it, I think - which pushes IX as part of the beepfx code, and pops it when back to ZXB. Also allows you to just #include assembly, rather than link binaries.
(I know you've seen that, LCD - but thought I'd mention it for anyone else reading this thread later!)
Re: New game: Earthraid - boriel - 06-04-2012
britlion Wrote:Very nice little game, LCD. Very difficult, too - even on easy levels! There's never enough time to hit back. I was using poison a lot, and then realised that just shortens lifespan, and really doesn't stop the darned things. Mines seem to be the most winning.It probably uses the BEEP ROM routine which effectively changes IX (I also had this problem with BEEP). Your sub above could be optimized as:
I noticed it seems to crash occasionally - a couple of times when generating a landscape and once right after starting. There's some corruption occurring sometimes, somewhere...
LCD Wrote:By the way, I noticed that BeepFX crashes in ZXBC if is called inside a SUB:
Code:Sub BeepFX(effect as ubyte)
poke 60001,effect
asm
call 60000
end asm
end sub
I think that's because it corrupts the IX register. I've posted a HOWTO for a cleaner method of using it, I think - which pushes IX as part of the beepfx code, and pops it when back to ZXB. Also allows you to just #include assembly, rather than link binaries.
(I know you've seen that, LCD - but thought I'd mention it for anyone else reading this thread later!)
Code:
Sub FASTCALL BeepFX(effect as ubyte)
asm
push ix
ld (60001), a ; 8 bit fascalled params comes into A register
call 60000
pop ix
end asm
end subRe: New game: Earthraid - britlion - 06-04-2012
No - it uses IX as a pointer into its sound data. Since ZXB uses IX for its own purposes, this is definitely a conflict.
The version for 'include I posted up added a push IX near the start of the code, and the suggested SUB contains a catching POP IX at the end; similar to Boriel's suggestion.
Re: New game: Earthraid - LCD - 06-06-2012
britlion Wrote:Very nice little game, LCD. Very difficult, too - even on easy levels! There's never enough time to hit back. I was using poison a lot, and then realised that just shortens lifespan, and really doesn't stop the darned things. Mines seem to be the most winning.
I noticed it seems to crash occasionally - a couple of times when generating a landscape and once right after starting. There's some corruption occurring sometimes, somewhere...
LCD Wrote:By the way, I noticed that BeepFX crashes in ZXBC if is called inside a SUB:
Code:Sub BeepFX(effect as ubyte)
poke 60001,effect
asm
call 60000
end asm
end sub
I think that's because it corrupts the IX register. I've posted a HOWTO for a cleaner method of using it, I think - which pushes IX as part of the beepfx code, and pops it when back to ZXB. Also allows you to just #include assembly, rather than link binaries.
(I know you've seen that, LCD - but thought I'd mention it for anyone else reading this thread later!)
I will make later a v 1.1 with your suggestions, but never noticed any crash in generating the landscape, and I have played the game 1000 times. Strange... Do you have a special emulator setup? I usualy load the game with tape loader (so it runs in 128K mode).
Re: New game: Earthraid - britlion - 06-06-2012
I was running it in 48K mode. Perhaps that's it.
Re: New game: Earthraid - LCD - 06-06-2012
britlion Wrote:I was running it in 48K mode. Perhaps that's it.Just tested something: I used a heap of 100 bytes. After reducing it to 80 bytes, it crashed after generating map (I do not use any strings, just texts). So rising heap to 256 bytes will maybe fix this problem. Currently I make some optimisations for release 1.1, so there will be a new version soon.
Re: New game: Earthraid - boriel - 06-06-2012
LCD Wrote:Compilig with --debug-memory the program will complain about out of memory immediately. Sometimes, the fact the program "runs" does not actually mean it's all ok. A malloc can silently fail, and the program seems to be ok.britlion Wrote:I was running it in 48K mode. Perhaps that's it.Just tested something: I used a heap of 100 bytes. After reducing it to 80 bytes, it crashed after generating map (I do not use any strings, just texts). So rising heap to 256 bytes will maybe fix this problem. Currently I make some optimisations for release 1.1, so there will be a new version soon.
Also memavail() and maxavail() functions are already available in the library/ directory. So you can maybe use all of this to check for minimum heapsize. 256 is really small already! (Heap also needs about 20 bytes for itself!).
Re: New game: Earthraid - LCD - 06-06-2012
boriel Wrote:LCD Wrote:Compilig with --debug-memory the program will complain about out of memory immediately. Sometimes, the fact the program "runs" does not actually mean it's all ok. A malloc can silently fail, and the program seems to be ok.britlion Wrote:I was running it in 48K mode. Perhaps that's it.Just tested something: I used a heap of 100 bytes. After reducing it to 80 bytes, it crashed after generating map (I do not use any strings, just texts). So rising heap to 256 bytes will maybe fix this problem. Currently I make some optimisations for release 1.1, so there will be a new version soon.
Also memavail() and maxavail() functions are already available in the library/ directory. So you can maybe use all of this to check for minimum heapsize. 256 is really small already! (Heap also needs about 20 bytes for itself!).
Tried it with --debug-memory
If heapsize was 80, I got "Out of memory", with heapsize 85 all was Okay. It was working in 48K mode too. I'm puzzled a bit.
Re: New game: Earthraid - slenkar - 06-06-2012
boriel Wrote:LCD Wrote:Compilig with --debug-memory the program will complain about out of memory immediately. Sometimes, the fact the program "runs" does not actually mean it's all ok. A malloc can silently fail, and the program seems to be ok.britlion Wrote:I was running it in 48K mode. Perhaps that's it.Just tested something: I used a heap of 100 bytes. After reducing it to 80 bytes, it crashed after generating map (I do not use any strings, just texts). So rising heap to 256 bytes will maybe fix this problem. Currently I make some optimisations for release 1.1, so there will be a new version soon.
Also memavail() and maxavail() functions are already available in the library/ directory. So you can maybe use all of this to check for minimum heapsize. 256 is really small already! (Heap also needs about 20 bytes for itself!).
I dont see memavail or maxavail in the library directory in program files/boriel tm/zx basic compiler/library or in the wiki