something strange when using templates ver 4.3

[BiNMaN]

in brief

if I use the bouncing enemy template in sprite type 2 the movement it causes sprite corruption

I use the same template in type 7 it worked but if I alter the code in the if collision 0 bit from kill to remove followed by subtract 1 from f (used for limiting sprites on the screen) the sprite doesn't move

if I add explode they move off the side of the screen instead of bouncing

using l/r patrolling enemy they seem to vibrate on the spot

u/d seems to be ok

I've barely even started to write anything and stuff is crashing left, right and centre

I have a counter in main loop 1 to spawn a sprite type and limit the number of enemies to 8

sprite initialisation randomly picks an x,y for sprite type 8

sprite type 8 animates and then turns into an enemy of another type

there is no scripting in for the player (as yet)

[BiNMaN]

hmmm, strange if I do it in small stages and test the game things seem to be ok

just worried that if I do a large amount of changes and don't save regulary the whole project could get fubared

[kas29]

...using l/r patrolling enemy they seem to vibrate on the spot...

In a template error. In the template you want to change values-
.....
let parama 0,
...
let parama 1,
...
let parama 1,
...
let parama 0
...

[BiNMaN]

ahhh

thank you, did not investigate further as I was frustrated at the time

[BiNMaN]

think some problems may be due to having enemies spawning at a random x,y

if it is an even number then everything is ok because pixel movement is 2x pixels

if it is odd then sprites may move outside of boundaries before the engine can react

could do with a

GETRANDOM 150 STEP 2
LET X = RND...

kind of thing

[lukebord1]

One thing for sure... complex coding and some changes, cause crashes which we expect to be fixed soon!
I'm restarting my project for the third (and last) time in v.4.3.

[Jonathan Cauldwell]

The left/right patrol template was written assuming the sprite would be walking on a platform or wall and is designed to turn around as soon as soon as it encounters any sort of gap. If this is not how you want the code to work you'll need to remove a few lines. It should look more like this:

IF PARAMA = 0
IF CANGOLEFT
SPRITELEFT
ELSE
LET PARAMA = 1
ENDIF
ELSE
IF CANGORIGHT
SPRITERIGHT
ELSE
LET PARAMA = 0
ENDIF
ENDIF

for spawning sprites at even coordinates use something like

GETRANDOM 75
LET X = RND
ADD X TO X

Lukebord1, Sorry you've had problems. I'll investigate the snapshot you sent and see what I can find.

[Jonathan Cauldwell]

Update:

Lukebord1, your crashes are probably down to where you are spawning the sprites, in a main loop event.

When spawning, AGD attempts to make a copy of the current sprite and then physically draws it upon the screen before you even get to set any coordinates, image or whatever. If no current sprite is defined the default coordinates can be garbage and may result in the sprite being drawn not on the screen but all over the streams, system variables, BASIC area etc which can result in horrible crashes. I can't fix it without making a change to the engine so previous versions of games wouldn't work with the new AGD. Thankfully, there is a work-around.

I thought I'd posted about this bug here but on looking again it looks like it was in the Tea and Sympathy thread on WoS so I'll put it here and start a new topic in the Hints and Tips section.

When spawning sprites from anywhere other than a sprite event, either make the first line of the event this:

ORIGINAL

or better still, use this (Spectrum versions 4.0 to 4.3):

ASM 221
ASM 33
ASM 180
ASM 4

[lukebord1]

Well first of all thanks Jon, can't wait for next AGD version...
Rewriting code events will take some time but it's not a tragedy... Rebuilding graphics (blocks/sprites/obj/map), could be very hard instead!... It could be fantastic if someway, we could "import" specific elements (such as graphics) from a previous version... But i don't want to put too much trouble, its just an idea ;-)

[Jonathan Cauldwell]

If you get a crash of this sort the data may still be intact. One thing you could try to do to salvage lost work might be to save the game data as a binary file.

In ZX Spin you select Save Binary File from the File menu and type 30000 into Start address and 35536 as Data Length. Leave the RAM Page set to Main Memory, then save your binary. Reload AGD, select File->Load Binary File and choose 30000 as the Start Address. Reload the binary and make sure you check the game thoroughly to make sure it isn't corrupt.

On the horizontally patrolling enemy template, I've added some documentation to V4.4 explaining that the template is designed for platformers and how it should instead be modified for a top-down view.

[BiNMaN]

Jan 2, 2014 20:46:27 GMT Jonathan Cauldwell said:

for spawning sprites at even coordinates use something like

GETRANDOM 75
LET X = RND
ADD X TO X

of course!!! that way you'll always get an even number, doh!!

[lukebord1]

Just for chronicle... In my experience, as Jon already knows, i had to save the work without AGD Basic loader.
When i add my custom loader, game loads and works properly.
Thanks guys for the support, now i can carry-on my game without problems.