Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store
  • entries
    34
  • comments
    88
  • views
    26,186

bBasic - Animating 12 sprites simultaneously

Robert M

Entry posted by Robert M

756 views

 Share

Goals:

-> Animate all 10 virtual sprites simultaneously to create circulating arial swarm.

-> Animate player0 under joy1 control to run left and right.

-> P0 flickers at 30Hz, use the other copy of P0 to give the player a flaming sword.

 

Design:

-> Start from last entry.

-> Reimplement the joy1 reading code from 2 entries ago to use an on..goto statement rather than if-statements.

-> reintegrate the player animation code with the new joy1 code. Only left and right movement are implemented.

-> Add flaming sword sprites for player0.

-> The virtual sprites are stacked vertically at intervals of 10 lines. With flickering at 30Hz there are 2 stacks of 5 sprites.

-> One stack of sprites moves down 10 lines, and then resets to its starting position. The other stack rises 10 lines and then resets.

-> Each sprite has status info (color in this demo, it could include image). When the stacks reset the 10 statuses are rotated, and the illusion of circling objects is created.

 

Implementation:

main005.txt

main005.txt.bin

 

Lessons learned:

-> When your code compiles but doesn't run, double check for misspelled labels. (more below)

 

Recommendations for improving bBasic:

-> When I compile with errors, sometimes I get an error message and sometimes I don't. I don't understand why that is. Usually the problem is an undefined label, but whether I see the error seems to be random. When I can't see any message it looks like the code has compiled, but it will not run, and the binary image is incomplete. Is there a DASM switch I can set that will insure I get all possible error messages?

-> For example if I take line 253 of the attached source code and change it to this: 

	goto playerStand

When I compile, it appears to succeed, but really it has failed. Why is there no undefined symbol error message printed out by DASM?

 

Up Next:

-> Refining animation of the virtual sprites.

 Share

4 Comments

Recommended Comments

batari

I think this time it's not my fault ;) There is a bug (or at least an annoyance) in DASM, in that complex asm files tended to produce literally hundreds of bogus label mismatches, unresolved symbols and the like. I think it's because DASM wasn't designed to handle machine-generated asm like bB produces, but it seems to mostly handle it.

 

But the result was that the output was extremely unhelpful when trying to debug, so my solution for bB 1.0 was to try and filter the output of DASM to limit all of the crap it spit out. Unfortunately it didn't work well enough, as you are noticing.

 

Since then, I've been working with my own hacked version of DASM that will be released with bB 1.1, that detects the bogus messages before they ever get displayed. This was also necessary due to a branch bug in DASM (a real bug) that I found while attempting to compile HUGE bB sources.

 

So, long story short, I tried your source and it appears to be working over here:

batari Basic v1.01 (C)2005-2007
2600 Basic compilation complete.
DASM V2.20.07bB, Macro Assembler (C)1988-2007
--- Unresolved Symbol List
0.playerStand			0000 ????		 (R )

--> cycle74_HMCLR f086				  

Fatal assembly error: Source is not resolvable.
Build complete.

Oops, there is one bogus label mismatch there ;) I'll get on that.

Link to comment
Robert M
I think this time it's not my fault ;) There is a bug (or at least an annoyance) in DASM...

 

Thanks for the quick explanation. I was suspecting it was some sort of filtering done by bBasic. I have seen the excessive error messages from DASM myself when using complicated macros. I am really looking forward to the bB 1.1 release. ;)

 

Cheers!

Link to comment
EricBall

6502 assemblers can run into problems when they can't determine if an address is zero page or not. (So whether the instruction is 2 or 3 bytes.) This can then mess up branches if the offset is close to the maximum.

 

Also pay special attention to the branch offset calculation as it's signed and based on the PC of the next instruction(IIRC).

Link to comment
batari
6502 assemblers can run into problems when they can't determine if an address is zero page or not. (So whether the instruction is 2 or 3 bytes.) This can then mess up branches if the offset is close to the maximum.

 

Also pay special attention to the branch offset calculation as it's signed and based on the PC of the next instruction(IIRC).

Yeah, the DASM problems are indeed related to what you said above. But I still call it a bug, as DASM really does not need to tell us what label mismatches it thinks it finds during early passes, especially when they get resolved in later passes.

 

As for the branch thing, a branch is based on the PC of itself. E.g. $D0 00 is a BNE to itself.

 

The DASM branch bug is also related to the above. It happens when in the second pass, a negative branch target may differ from its location in the first such that seems to be <-128 bytes away. If DASM completed the pass, it would find that the branch location also moved such that it would resolve properly, but instead it triggers a fatal assembly error.

 

Fortunately, the problem is somewhat rare, but unfortunately, my "fix" for this fixes it but also sometimes allows real out-of-range branches to make it through. I'm looking into that.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×

  • Recently Browsing   0 members

    • No registered users viewing this page.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...