Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
New game: Earthraid
#16

.zip   EarthraidSourceFiles.zip (Size: 8.3 KB / Downloads: 642)
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.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#17
I'm surprised you didn't incbin or #include the assembly - that's what I did for my sound tests....
Reply
#18
Thanks !
Reply
#19
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.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#20
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 SUB


And 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 119

Just 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.
Reply
#21
I will try when I'm back.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#22
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!)
Reply
#23
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!)
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:
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 sub
Reply
#24
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.
Reply
#25
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).
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#26
I was running it in 48K mode. Perhaps that's it.
Reply
#27
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.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#28
LCD Wrote:
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.
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.

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!).
Reply
#29
boriel Wrote:
LCD Wrote:
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.
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.

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.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#30
boriel Wrote:
LCD Wrote:
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.
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.

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
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)