Development - I ask all

[matashen]

Hello at all

 

Please do only choose max 4 of the 8 questions.

 

Fell free to discuss with me about an IK/IK+ Clone.

 

I try to answer all questions you have.

 

 

Regards

 

Matthias

[roland p]

3rd fighter, bombs, balls, all moves.

 

Would it be possible to include the original amiga music?

[Lynxman]

I think you should make all 8 options.

 

[matashen]

I think you should make all 8 options.

 

 

Not enough RAM.

Integrate a cool MOD-music is possible, but eats lot of RAM. That means that "BOMB STAGE" + "BALL STAGE" is not possible if i would integrate MOD music

[Fadest]

The 3rd fighter is the only mandatory thing for an IK+ game

 

And Comlynx a must-have in my opinion.

 

When we spoke about this years ago with Templeton, we wanted to use Lynx hardware to have some zoom effects like Neogeo fighters. This was a feature asked but Templeton, but it is quite easy to code and use only some bytes of code...

 

Edit : [privte joke for french readers]Oh, and music is not mandatory, the Lynx is mp3-devices compliant [/private]

Edited April 11, 2010 by Fadest

[SwedenLynxer]

The Alpine Games Bonus Card have a karate game demo , I wish that demo would turn in to a game. Why not ask Duranik if they can share the backgrounds and animation? It looks amazing!

[roland p]

Integrate a cool MOD-music is possible, but eats lot of RAM. That means that "BOMB STAGE" + "BALL STAGE" is not possible if i would integrate MOD music

But the FIGHT, BOMB and BALL STAGE don't have to be in the RAM at the same time?

[Tom-Lynx]

ComLynx support is the most important in my humble opinion.

[matashen]

Integrate a cool MOD-music is possible, but eats lot of RAM. That means that "BOMB STAGE" + "BALL STAGE" is not possible if i would integrate MOD music

But the FIGHT, BOMB and BALL STAGE don't have to be in the RAM at the same time?

Its difficult to reload different parts. Duranik does it in alpine games, but i only code in C, and i dont have the knowledge to do this in C.

[matashen]

The 3rd fighter is the only mandatory thing for an IK+ game

 

And Comlynx a must-have in my opinion.

 

When we spoke about this years ago with Templeton, we wanted to use Lynx hardware to have some zoom effects like Neogeo fighters. This was a feature asked but Templeton, but it is quite easy to code and use only some bytes of code...

 

Comlynx should be no problem to integrate.

[matashen]

The Alpine Games Bonus Card have a karate game demo , I wish that demo would turn in to a game. Why not ask Duranik if they can share the backgrounds and animation? It looks amazing!

 

DURANIK codes in Assembler

I write in C - so NOGO

 

and its not so cool write in codesegments, others had writen. Everyone has an own style of codeing and thats not so funny rewriteing otherones code.

[sage]

Integrate a cool MOD-music is possible, but eats lot of RAM. That means that "BOMB STAGE" + "BALL STAGE" is not possible if i would integrate MOD music

But the FIGHT, BOMB and BALL STAGE don't have to be in the RAM at the same time?

Its difficult to reload different parts. Duranik does it in alpine games, but i only code in C, and i dont have the knowledge to do this in C.

 

Its not so hard to archive, but you really have to write independent codes. Same for assembler.

 

Or you use KArris new C compiler which magically can do that.

[matashen]

Integrate a cool MOD-music is possible, but eats lot of RAM. That means that "BOMB STAGE" + "BALL STAGE" is not possible if i would integrate MOD music

But the FIGHT, BOMB and BALL STAGE don't have to be in the RAM at the same time?

Its difficult to reload different parts. Duranik does it in alpine games, but i only code in C, and i dont have the knowledge to do this in C.

 

Its not so hard to archive, but you really have to write independent codes. Same for assembler.

 

Or you use KArris new C compiler which magically can do that.

 

OK, i got a lot of knowledge about since Lynxopoly. Today i got you loader running. Maybe its now possible to create different stages and reload it.

 

Regards

 

Matthias

[dan h]

Hi Matthias

I would leave Bomb and Ball Stage as nice-to-have memory-wise.

Third fighter would be fantastic, all animations plus new ones and of course more backgrounds should also be there.

Later

[roland p]

OK, i got a lot of knowledge about since Lynxopoly. Today i got you loader running. Maybe its now possible to create different stages and reload it.

 

On second thought, maybe just start with a version that fits in memory, and save the dynamic loading thing for later? Anyway, I don't think the actual code will be more than 64KB? Isn't it the samples/graphics that will take up the most space? Maybe you can load the graphics on the fly and keep one codebase.

[matashen]

OK, i got a lot of knowledge about since Lynxopoly. Today i got you loader running. Maybe its now possible to create different stages and reload it.

 

On second thought, maybe just start with a version that fits in memory, and save the dynamic loading thing for later? Anyway, I don't think the actual code will be more than 64KB? Isn't it the samples/graphics that will take up the most space? Maybe you can load the graphics on the fly and keep one codebase.

The actual code is without some things:

- only graphics / background & fighters / 3 moves are not finish

- comlynx is integrated

- no collision detection

- no sound

- no computer-ai

- ..

 

actual i have 20KB free space

but i need a lot for the rest of the game

 

for a ball stage i need additional code for the detection and the balls, and there are more pics i need for the moves in normal mode. So i think its better to switch from one part to another by reloading code.

[+karri]

Please also check Wookies ideas. He has some good ideas for magically streaming data from the cart to RAM.

 

I would sooo like to spend days on improving the cc65 and adding good cart support. But no time for Lynx right now

 

--

Karri

[matashen]

Please also check Wookies ideas. He has some good ideas for magically streaming data from the cart to RAM.

 

I would sooo like to spend days on improving the cc65 and adding good cart support. But no time for Lynx right now

 

--

Karri

 

remember, i use the cc65 from bastian Schick, not the same as you.

[+karri]

Please also check Wookies ideas. He has some good ideas for magically streaming data from the cart to RAM.

 

I would sooo like to spend days on improving the cc65 and adding good cart support. But no time for Lynx right now

 

--

Karri

 

remember, i use the cc65 from bastian Schick, not the same as you.

 

Actually the cc65 42Bastian used is just an earlier version. I got 42Bastians permit to merge his code back to the mainline of cc65 so it is really the same compiler. The only thing is that the compiler has evolved a lot during the years. Now it produces much smaller and faster code.

 

But of course you are free to choose any tools you feel comfortable with.

--

Karri

[matashen]

Please also check Wookies ideas. He has some good ideas for magically streaming data from the cart to RAM.

 

I would sooo like to spend days on improving the cc65 and adding good cart support. But no time for Lynx right now

 

--

Karri

 

remember, i use the cc65 from bastian Schick, not the same as you.

 

Actually the cc65 42Bastian used is just an earlier version. I got 42Bastians permit to merge his code back to the mainline of cc65 so it is really the same compiler. The only thing is that the compiler has evolved a lot during the years. Now it produces much smaller and faster code.

 

But of course you are free to choose any tools you feel comfortable with.

--

Karri

 

If its the same compiler, why does the inline assembler is so different?

[Shawn Jefferson]

If its the same compiler, why does the inline assembler is so different?

 

It has evolved a lot during the years... and it is current being supported and developed, unlike the "newcc65" of BS unfortunately.

[matashen]

If its the same compiler, why does the inline assembler is so different?

 

It has evolved a lot during the years... and it is current being supported and developed, unlike the "newcc65" of BS unfortunately.

 

The Main thing is, with the old "newcc65" from BS i get German Suport from Bastian Schick, Björn Spruck and many more... if i use the cc65.org version from karri, i dont know where i get the same suport. Karri can help, but he has many workload and not many time - and its quite more difficult for me to explain something in english.

[+karri]

If its the same compiler, why does the inline assembler is so different?

 

It has evolved a lot during the years... and it is current being supported and developed, unlike the "newcc65" of BS unfortunately.

 

The Main thing is, with the old "newcc65" from BS i get German Suport from Bastian Schick, Björn Spruck and many more... if i use the cc65.org version from karri, i dont know where i get the same suport. Karri can help, but he has many workload and not many time - and its quite more difficult for me to explain something in english.

 

42Bastian also wrote a BLL macro package to the new assembler. Most of the BLL macros work as they used to.

 

But of course this is still work-in-progress. It would be nice to implement the full BLL kit for the cc65. Because then you could mix compilations in C and asm freely.

 

I hope that if we just get enough people doing the final touches on the new cc65 compiler it would be really simple to use and you could mix asm and C freely.

 

The next BIG thing we need is good cart support. It has to use standard calls like open and read. But it does not need file names.

 

--

karri

[Shawn Jefferson]

But of course this is still work-in-progress. It would be nice to implement the full BLL kit for the cc65. Because then you could mix compilations in C and asm freely.

 

I hope that if we just get enough people doing the final touches on the new cc65 compiler it would be really simple to use and you could mix asm and C freely.

 

The next BIG thing we need is good cart support. It has to use standard calls like open and read. But it does not need file names.

 

Hi Karri,

 

What do you mean by mixing asm and C freely? From my point of view, you can already do that with cc65 easily, as you can use in-line assembler or .s modules, but I know you know that, so I guess you mean something else?

 

We probably have different views on the cart issue, as I don't think it's worth trying to fit the round peg of the Lynx cart access into the square hole of POSIX i/o. Why not just provide some routines to access the cart, callable from both C and asm, and don't worry about implementing open/read? I guess cross-platform-ability is the goal there? Really though, anything non-trivial is probably going to be written to the Lynx hardware, and doesn't want/need the overhead of file i/o, IMO. On that topic I'd like to see the defines for the lynx hardware (_suzy.h, etc..) included in the lynx cc65 package too, like the Atari 8-bit and C64 has (_antic.h for 8-bit, _vic.h for C64).

[+karri]

 

Hi Karri,

 

What do you mean by mixing asm and C freely? From my point of view, you can already do that with cc65 easily, as you can use in-line assembler or .s modules, but I know you know that, so I guess you mean something else?

 

We probably have different views on the cart issue, as I don't think it's worth trying to fit the round peg of the Lynx cart access into the square hole of POSIX i/o. Why not just provide some routines to access the cart, callable from both C and asm, and don't worry about implementing open/read? I guess cross-platform-ability is the goal there? Really though, anything non-trivial is probably going to be written to the Lynx hardware, and doesn't want/need the overhead of file i/o, IMO. On that topic I'd like to see the defines for the lynx hardware (_suzy.h, etc..) included in the lynx cc65 package too, like the Atari 8-bit and C64 has (_antic.h for 8-bit, _vic.h for C64).

 

I mean that lyxass cannot be compiled by cc65. To mix lyxass with cc65 I have to include it as a seperate binary blob. If I could compile the asm with the ca65 then I could link it with the linker.

 

The benefit is that C-code and asm could share cart access, sound support, screen update mechanism, ComLynx.

 

Today lyxass programs will copy the complete initialization and duplicate everything.

 

About the open/read it makes sense to use them. You can very easily get the same usability as the 42Bastian's code.

 

fno = open(filename, accessflags); // This also fetches the directory entry into RAM
status = read(fno, entry->loadAddress, entry->fileSize);

 

The Lynx has only one file open at a time (fno is always 1). So what the open really does is that it fetches the directory entry of file "filename" into RAM.

 

The file naming I planned to implement is "0", "1", "2",...

 

After the open call you have this entry-structure in RAM:

 

.byte blockNumber
.word byteOffsetInBlock
.byte hiBlockNumber
.word loadAddress
.word fileSize

 

Compared to the old way of doing this I believe it is easier to understand. And you can read more or less data from the cart depending on how your game works.

 

--

Karri