Collision Detection

[Ninjabba]

So I closely follow Matthias Domin's demos on his website http://www.mdgames.de/lynx_eng.htm and I'm stuck at the 5th demo where he's doing collision detection.

 

The following line should activate collision detection

 

// Make sure, that collision detection is enabled in the Sprite-Engine:
  sprsys = _sprsys = _sprsys & 0xdf;

 

However, before this to work I need to replace the SetBuffers routine with a file he provides (setbuff.m65) which replaces the setbuff.obj in the lynx.olb library. So I try to compile his setbuff.m65 with ra65 as it is and I add the created object to lynx.olb, thus replacing the old routine in there.

 

When compiling the project now, I get an internal error "lib contains module type 55454"

 

edit: Hmm.. I think it has to do with the fact I'm not using an up-to-date version of cc65

Edited October 22, 2009 by Ninjabba

[GroovyBee]

However, before this to work I need to replace the SetBuffers routine with a file he provides (setbuff.m65) which replaces the setbuff.obj in the lynx.olb library. So I try to compile his setbuff.m65 with ra65 as it is on his website and receive 2 errors of bogus lines. When removing those 2 lines (I'm sorry, I really am bad at assembly so I have no idea what I'm doing here.. but it looked innocent), the file compiles and I add the created object to lynx.olb, thus replacing the old routine in there.

 

Can you try it again with the original files and capture the errors generated to a text file? Attach the error file to your post and I'll take a look.

[Ninjabba]

I'm currently developing in windows xp using Panther since this environment made me compile the first 4 demos easily. The only messages I receive after trying to compile setbuff.m65 with ra65 are the following two:

 

Error : line    10 (setbuff.m65):Bogus line
Error : line    14 (setbuff.m65):Bogus line
2 error(s) !

 

Then I tried compiling the file on the environment karri created for the U3 flashdrive with the same command and it just compiles. But for some reason I can't get the demos themselves compiled in karri's environment so I switched back to Panther with the created setbuff object and add it to the lynx.olb library. But compiling the whole project there gives me the internal error.

 

I edited my earlier post a bit, because I'm quite confused on the whole matter but try about anything that comes to mind. I hope I dont confuse you guys too much.

[GroovyBee]

Error : line    10 (setbuff.m65):Bogus line
Error : line    14 (setbuff.m65):Bogus line
2 error(s) !

 

I'm not a Lynx developer but I do use the CC65 development system. I can't find an online manual containing the assembler directives for RA65 (it seems to be very old) but looking at the setbuff.m65 source file, line 10 contains the assembler directive :-

 

   bsszp

 

at a guess that is the BSS section in Zero Page memory. That area is uncleared by the "C" runtime environment. The 2 lines after it reserve 4 bytes of zero page.

 

Line 14 contains the assembler directive :-

 

   text

 

That tells the assembler that the following lines of code should be placed in the final ROM image.

 

I don't think you can delete the directive "bsszp" without it affecting where those addresses will end up. If the linker puts them in the ROM space they aren't writable.

 

Maybe you are missing a command line parameter when you call ra65?

 

Has anybody updated these examples to use the lynx target in a recent release of CC65?

[Ninjabba]

I dont think its a parameter in ra65.. at least the version I use doesn't give me anything useful

[GroovyBee]

I dont think its a parameter in ra65.. at least the version I use doesn't give me anything useful

 

Can you generate a *.map file or a symbol table used in the final image. There should be a linker command line parameter to activate it. That will tell you if those locations have been fixed up in ROM space.

[Ninjabba]

Can you generate a *.map file or a symbol table used in the final image. There should be a linker command line parameter to activate it. That will tell you if those locations have been fixed up in ROM space.

 

I thank you for diving into my problem, but here is where I lack a huge amount of knowledge. I have no idea how to do this and how it will help me.

[TailChao]

Hi,

 

I've never used the CC65 development system for Lynx, but I must warn against using the Lynx's hardware collision feature. While it may make things easier at first glance, there is a huge speed penalty in enabling it. You're essentially forcing Suzy to perform every single drawing operation twice, and sacrificing an additional 8KB for the collision buffer. It is much easier in the long run, and much more efficient to use software collisions. Also, with hardware collisions, everything is on a per-pixel basis, so if only one pixel of a sprite touches another, it will be considered a hit. This can really kill gameplay since there's no leeway in when one object touches another.

 

Regardless, good luck on your Lynx experiments.

[GroovyBee]

I thank you for diving into my problem, but here is where I lack a huge amount of knowledge. I have no idea how to do this and how it will help me.

 

The output of the assembler and "C" compiler are interim object files. The linker joins all the files together into the final binary image and fixes up the accesses to the ROM/RAM etc. When its completed its job it can output a symbol table which is basically a list of all visible label names e.g. global function entry points, global variables etc. Try and run the linker on its own and get it to output a list of available parameters. From that it should be easy to identify the correct command line parameter.

 

From the sprite demo you mentioned I can see from the make file its called "link65.exe". Try using "link65 -h", "link65 -help" etc. to get its list of available commands. In a recent version of the CC65 package the linker is called ld65 and if you specify "-m rom.map" it will create the map file. Try that too and see what happens.

[+karri]

There is a few toolsets out there.

 

The BLL kit = an old assembler toolkit but very good and simple to use

 

The newcc65 compiler suite = obsolete in my opinion

 

The current cc65.org compiler suite. Released last week at www.cc65.org

 

My favorite compiler is this latest one. Here you are supposed to code using C mainly. This kit produces very optimized code and it has some tricky stuff bundled in automatically. The bad thing is that you don't see the Lynx chips directly. Your code will be much more generic.

 

I should really write a small suite in basic things and how to use it.

 

The graphics is done using the tgi library (see the docs section at cc65.org).

 

The ComLynx is done using the ser library.

 

The joystick + fire buttons uses the joy library.

 

The keyboard (Opt1, pause, Opt2) uses the conio library.

 

You should be able to enable collision buffers together with the tgi library. But so far I have no tutorial about it.

 

--

Karri

[Ninjabba]

The current cc65.org compiler suite. Released last week at www.cc65.org

 

I tried using this compiler, but I get all these errors when trying to compile the demos of Matthias.

 

C:\cc65\demo>cc65 -t lynx sprdemo1.c
C:\cc65\include/lynxlib.h(88): Warning: Implicit 'int' is an obsolete feature
C:\cc65\include/lynxlib.h(88): Error: ';' expected
...

 

I must admit, software collision sounds very nice after all the things I tried, and indeed will be better for any final product. But at this moment its not about the collision anymore... its about getting those files compiled..

Edited October 22, 2009 by Ninjabba

[GroovyBee]

C:\cc65\demo>cc65 -t lynx sprdemo1.c
C:\cc65\include/lynxlib.h(88): Warning: Implicit 'int' is an obsolete feature
C:\cc65\include/lynxlib.h(88): Error: ';' expected
...

 

What is on line 88 in the file lynxlib.h? Its much easier if you include the lines that have errors when we don't have access to your files and development environment. Don't attach the whole file for copyright reasons.

 

However, having looked at a lynxlib.h that I found online the function prototypes are malformed. The latest CC65 compiler likes void to be specified implicitly, so instead of "extern Function();", you need to specify "extern void Function(void);". Its good practice to do that anyway.

 

@karri: Has this lynx library been updated to build with a modern version of CC65?

[Ninjabba]

making all functions and variables explicit seems to compile the file good

 

C:\cc65\demo>cc65 -t lynx sprdemo1.c
sprdemo1.c(46): Error: Preprocessor directive expected
sprdemo1.c(47): Warning: Implicit `int' is an obsolete feature
sprdemo1.c(47): Error: `;' expected

 

now im left with this error, which poinst at directive of the control sprite block

 

#asm         
_SCB1     dc.b $c0,$10,$20
         dc.w 0,0
         dc.w 0,0,$100,$100
         dc.b $01,$23,$45,$67,$89,$Ab,$cd,$ef
#endasm

 

I tried writing it different

#define SCB1()
asm(     
    "dc.b $c0,$10,$20"\
    "dc.w 0,0"\
    "dc.w 0,0,$100,$100"\
    "dc.b $01,$23,$45,$67,$89,$Ab,$cd,$ef"
)

 

but then the compiler gives me the error

"sprdemo1.c(54): Error: ASM code error: dc.b is not a valid mnemonic" on this block

Edited October 22, 2009 by Ninjabba

[GroovyBee]

Personally I don't like having assembler and C mixed in the same file. However, you could try replacing the directive "dc.b" with ".byte" and the directive "dc.w" with ".word" and see if that makes a difference.

 

Alternatively you could change the line to a "C" language byte array and prefix it with "static const" to make sure its in ROM. Remember that the 6502 is little endian so the dc.w numbers will need to appear LSB first in the array. You might also need to remove the "_" from the start of the variable name depending on the scope of "_SCB1".

[+karri]

making all functions and variables explicit seems to compile the file good

 

C:\cc65\demo>cc65 -t lynx sprdemo1.c
sprdemo1.c(46): Error: Preprocessor directive expected
sprdemo1.c(47): Warning: Implicit `int' is an obsolete feature
sprdemo1.c(47): Error: `;' expected

 

now im left with this error, which poinst at directive of the control sprite block

 

#asm         
_SCB1     dc.b $c0,$10,$20
         dc.w 0,0
         dc.w 0,0,$100,$100
         dc.b $01,$23,$45,$67,$89,$Ab,$cd,$ef
#endasm

 

I tried writing it different

#define SCB1()
asm(     
    "dc.b $c0,$10,$20"\
    "dc.w 0,0"\
    "dc.w 0,0,$100,$100"\
    "dc.b $01,$23,$45,$67,$89,$Ab,$cd,$ef"
)

 

but then the compiler gives me the error

"sprdemo1.c(54): Error: ASM code error: dc.b is not a valid mnemonic" on this block

 

Could you email this sprdemo1.c so I can have a look at it.

 

lynxlib.h does not exist anymore. Don't include it. Include lynx.h instead.

 

You could create a new type for sprites like this:

 

typedef struct {
   char a,b,c;
   void *next;
   char *bitmap;
   int x, y;
   int sx, sy;
   char pal[8];
} sprite_t;

 

Now you can define your SCB1 like this:

 

sprite_t SCB = {
    0xc0,0x10,0x20,
    0,0,
    0,0,0x100,0x100,
    {0x01,0x23,0x45,0x67,0x89,0xAb,0xcd,0xef}
};

 

If you want to change something in your code you write

 

SCB.x = 1234;
SCB.y = 2345;

 

If you need to pass the structure pointer to your routine

 

void changePos( sprite_t *spr, int x, int y ) {
   spr->x = x;
   spr->y = y;
}

 

You should be able to call this routine from your code like this:

 

changePos(&SCB, 1234, 2345);

 

There is not much point in mixing in asm pieces in C-code. Either code in C or in asm.

 

Oh, and go to the library and borrow a book to learn C-programming. The cc65 is a full C-compiler that knows all the tricks found in the book. I have an old book by Kerningham and Ritchie. It is only around 5mm thick and contains everything I need to know about C.

 

For info about the special functions available by the cc65 system read this http://www.cc65.org/doc/funcref.html

 

There is also a very fundamental change in the interrupt-code. The interrupt handler is set up at start time. The tgi-driver uses interrupts automatically so does the serial driver.

 

If you want to add an own interrupt handler for some reason in is "easy" to do. (This must be done in assembler.)

 

.interruptor    _gametime
.export         _playtime
_playtime:
       .byte   $00
       .byte   $00
       .byte   $00

.proc   _gametime: near
.segment        "CODE"
       inc     _playtime
       bne     @goon
       inc     _playtime+1
       bne     @goon
       inc     _playtime+2
@goon:  clc
       rts
.endproc

 

This interruptor will be called during every interrupt. If you only use the tgi-driver then it will be called at every VBL interrupt (75 times per second).

 

If you have many interrupts active then you need more code to find out who is interrupting.

 

The interruptor takes care of saving/restoring the registers and returning using rti. If you return with carry set then the interrupt was handled and the interruptor will exit. In this case I return with carry clear as our display handler will also need to take care of the VBL interrupt. The interrupt logic will call all interruptors if nobody sets the carry flag.

--

Karri

Coding in asm is a bit like eating with chopsticks. If you are good at it it works, But for me I just waste time and everything is messy.

Edited October 23, 2009 by karri

[+karri]

I checked the sprdemo5 code and it is not at all compatible with cc65 anymore. In order to run it it should look like this.

sprdemo5.txt

--

Karri

[Ninjabba]

I thought I was missing out something big. Seems I'm using a totally different version of the lynx.h header which includes 3 other assembly files... I tried to write this out with the new asm function, but its impossible. Thanks for looking at that file! I'm gonna try it right away!

[+karri]

I thought I was missing out something big. Seems I'm using a totally different version of the lynx.h header which includes 3 other assembly files... I tried to write this out with the new asm function, but its impossible. Thanks for looking at that file! I'm gonna try it right away!

 

You also need to run co65 on the tgi driver and the joy driver. I will try to make a small packet that compiles out of the box when I get home today.

 

But the basic thing is to link the loadable drivers, graphics and the demo source to produce an executable file.

--

Karri

[Ninjabba]

hmm, the new version of cc65 doesn't seem to recognize the objects I create with sprpck as legit objects. I used to link them creating a library of .obj sprites created with sprpck. In your solitaire game I see that you use the assembler on the file in .spr format created by sprpck? Can you enlighten me how that works?

 

Found something in an older thread:

 

http://www.atariage.com/forums/topic/97065-sprpck-problems/

 

.global mysprite

.segment "RODATA"

mysprite: .incbin "mysprite.spr"

 

works for me

Edited October 23, 2009 by Ninjabba

[+karri]

hmm, the new version of cc65 doesn't seem to recognize the objects I create with sprpck as legit objects. I used to link them creating a library of .obj sprites created with sprpck. In your solitaire game I see that you use the assembler on the file in .spr format created by sprpck? Can you enlighten me how that works?

 

Found something in an older thread:

 

http://www.atariage.com/forums/topic/97065-sprpck-problems/

 

.global mysprite

.segment "RODATA"

mysprite: .incbin "mysprite.spr"

 

works for me

 

True. The object format has changed completely. I should really create a resource compiler that eats bitmaps directly...

 

But currently you need to have a small *.s file that maps the sprite bitmap to a label. The code you wrote above does it.

 

A summary of all steps needed to build this is here:

 

Create a file called bg.s with this content:

 

. global _bg000000

. global _bg000001

. global _bg000002

. global _bg000003

.segment "RODATA"

_bg000000: .incbin "bg000000.spr"

_bg000001: .incbin "bg000001.spr"

_bg000002: .incbin "bg000002.spr"

_bg000003: .incbin "bg000003.spr"

 

sprpck -t6 -S016016 -r004001 -a008008 -p2 bg.bmp

 

cp $CC65_HOME/tgi/lynx-160-102-16.tgi .

co65 --code-label _lynxtgi lynx-160-102-16.tgi

 

cp $CC65_HOME/joy/lynx-stdjoy.joy .

co65 --code-label _lynxjoy lynx-stdjoy.joy

 

After this we should have:

bg000000.spr

bg000001.spr

bg000002.spr

bg000003.spr

bg.s

lynx-160-102-16.s

lynx-stdjoy.s

 

You should now be able to compile and link everything together with

cc65 -t lynx -o demo.o bg.s lynx-160-102-16.s lynx-stdjoy.s sprdemo5.c

 

--

Karri

 

PS. I have not tried this myself yet. Perhaps later today...

Edited October 23, 2009 by karri

[Ninjabba]

I feel I'm close to having this solved.. but its still not working here. I'm trying to get only one sprite on the screen here.

The files created so far (I feel like polluting the board now, but here it goes):

dg02.s

lynx-160-102-16.s

lynx-stdjoy.s

dg02.spr

and the source file sprdemo.c

also included the original bmp

 

sprdemo.zip

 

if I try to compile all the files together like you posted earlier, I get this:

 

C:\cc65\demo>
cc65 -t lynx -o demo.o dg02.s lynx-160-102-16.s lynx-stdjoy.s sprdemo1.c

additional file specs ignored
additional file specs ignored
additional file specs ignored
dg02.s(1): Error: Identifier expected
dg02.s(1): Warning: Implicit 'int' is an obsolete feature
dg02.s(1): Error: ';' expected
...

Edited October 23, 2009 by Ninjabba

[+karri]

Here is a compiled version together with sources and makefiles.

collision.zip

This requires the latest release of the compiler tools from www.cc65.org to successfully compile.

 

--

Regards,

 

Karri

[+karri]

After seeing this code it is obvious that in order to get rid of the asm-stuff I need to add more tgi_ioctl calls to the driver. Something like:

 

tgi_setcollision(on/off);

tgi_selcollisionoffset(offset);

 

If the collision is active then tgi_clear would also clear the collision buffer.

 

Perhaps this could be a seperate tgi driver.

 

A third driver could also be nice. A 512 by 512 screen with a movable window around it.

 

Or perhaps I include all these features to the next standard tgi driver. Hmm.

--

Karri

[Ninjabba]

thanks heaps! I havent got it compiled yet, since running a makefile under windows is just garbage, so I'm trying to get cc65 installed on ubuntu. But I need to socialize with friends for now, since I locked myself up with this problem for a few days now. Again a big thanks!

[GroovyBee]

thanks heaps! I havent got it compiled yet, since running a makefile under windows is just garbage, so I'm trying to get cc65 installed on ubuntu.

 

You can download nmake v1.5 from this windows KB article :-

 

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q132084

 

However, I've never tried that version myself to build CC65 projects.