[Ongoing] Powerglove

[Lonewolf10]

I agree. This game is shaping up nicely

[ReadOnlyCat]

My, what a bunch of cute little monsters.
This looks really nice.

Is the blue background in this picture fully composed of sprites?
It really does not feel that repetitive.

Since you said that Fast RAM allowed you to handle more monsters I assume that by "engine" you also include gameplay code?

[Gzegzolka]

It looks very promising please do not abandon it. I would love to play this game one day.

[Lazycow]

@Gzegzolka: There are no plans to cancel the project. Not yet...

@ReadOnlyCat: The "spritefield" fills the whole background, repeating itself. It is build out of 6 sprites. (96x64 pixel) The 8th sprite is not available because of the scrolling and the 7th sprite makes problems on very early agnus chips. But 6 sprites are enough, obviously...

And yes, the speedtests have been done with the gameplay code. The code is designed to write the blitter registers between gameplay handling. (to enable the blitter to run concurrently)

[ovale]

Originally Posted by Lazycow

I made the Amiga low-level code compatible to my c64 low-level code, so I can just cross-compile my c64 games now.

Hello Lazycow, how this is possible? Do you write your games in C?
By the way, just checked your website, I like your style and it is awesome what you are able to do with a C64.

[Lazycow]

@ovale: Yes, the game mechanics themselves are written in C (and they're identical for C64 and Amiga). But there's also assembler code which handles scrolling and sprite multiplexing for the C64 (lowlevel6502.s).

On the Amiga, there's an additional layer (cameo64.c) which has the same API as the C64 lowlevel code. This was necessary, because my low level code on the Amiga handles "sprites" and scrolling differently than on the C64.

[Samurai_Crow]

Which C compiler do you use for the C64? Unless it's a good one (of which I'm aware of none) it might be a candidate for optimization.

[ovale]

Originally Posted by Lazycow

@ovale: Yes, the game mechanics themselves are written in C (and they're identical for C64 and Amiga). But there's also assembler code which handles scrolling and sprite multiplexing for the C64 (lowlevel6502.s).

On the Amiga, there's an additional layer (cameo64.c) which has the same API as the C64 lowlevel code. This was necessary, because my low level code on the Amiga handles "sprites" and scrolling differently than on the C64.

Well, this makes your games even more like little jewels to my eyes.

I always thought that C is the right choice for Amiga games but for C64 games, well ... thus is a surprise.

I would love to see this code if you will release it some day.

[Amiga1992]

Originally Posted by Samurai_Crow

Which C compiler do you use for the C64? Unless it's a good one (of which I'm aware of none) it might be a candidate for optimization.

Why do people keep the old conception of C being "slow"?
Not only Lazycow has explained that the core of the engine runs in assembler, most C compilers will turn the C into decent assembler anyway. He's also having the game mechanics there, which is perfect, because then the game becomes perfectly portable to whatever platform!

And most importantly, Lazycow is actually delivering a proper polished game to the Amiga, which is more than most people can say. It will run fine and that's all that matters. He knows what he is doing.

[Samurai_Crow]

I was thinking of the C64 version. The ANSI/ISO C standard assumes that an array index is type int and an int is no smaller than 16 bits. This requires expensive pointer arithmetic on a zero page register followed by an indexed indirect lookup. If C allowed 8 bit indexing, it would be another story.

[Lazycow]

It's kind of a balance act... Assembler can be faster than C, but it needs more development time. (a valueable resource) So it might be wise to use some C, but then the game has to be simpler... yada yada yada...

@Samurai_Crow: I used "cc65". The generated code can be ok, but ONLY if you follow some rules while programming. (not a trivial task) Hm... yes, cc65 can generate code to access tables with an 8bit index without a ZP pointer.

@ovale: I am thinking about releasing the low level code at some point. But it has to be finished, first... uh oh...

[Amiga1992]

Originally Posted by Lazycow

It's kind of a balance act... Assembler can be faster than C, but it needs more development time. (a valueable resource) So it might be wise to use some C, but then the game has to be simpler... yada yada yada...

Eeeeexactly.

[Samurai_Crow]

Originally Posted by Lazycow

@Samurai_Crow: I used "cc65". The generated code can be ok, but ONLY if you follow some rules while programming. (not a trivial task) Hm... yes, cc65 can generate code to access tables with an 8bit index without a ZP pointer.

Sweet! That means that it is possible to do the byteplane optimization for larger-than-byte-size datatypes!

struct thisStruct {
  int x;
  char *y;
  char z;
};

struct thisStruct w[256];

should become:

char x_hi[256];
char x_lo[256];
char y_hi[256];
char y_lo[256];
char z[256];
int xbuf;
char *ybuf; /* if possible, map ybuf to a zero page register */
register char wbuf; /* if possible, map wbuf to the y index register */

#define xget(index) wbuf=(index); xbuf.hibyte=x_hi[wbuf]; xbuf.lobyte=x_lo[wbuf];
#define yget(index) wbuf=(index); ybuf.hibyte=y_hi[wbuf]; ybuf.lobyte=y_lo[wbuf];
/*the z array can be accessed directly */

This way there is no array scaling required!

Originally Posted by Lazycow

@ovale: I am thinking about releasing the low level code at some point. But it has to be finished, first... uh oh...

I've been meaning to make this type of code available as a shared library on the Amiga. Let me know if you are interested in publishing the code as such.

[Lazycow]

@Samurai_Crow: Yes, nice shot! This would probably generate the fastest and shortest code with the cc65 compiler. You can also use pointers to structs if the pointer is a register variable, which generates only slightly larger code. But there are some pitfalls you have to be aware of.

The problem with a library of the Powerglove low level code is that it would need some extra work to make it more flexible. Currently it is pretty much designed around the game with hardcoded limitations.

Update: Early parallax scrolling test.

Currently, it's too slow on an unaccellerated A500, but I am working on it.

[Amiga1992]

Originally Posted by Lazycow

Update: Early parallax scrolling test.

Currently, it's too slow on an unaccellerated A500, but I am working on it.

Looks beautiful

[ovale]

Wonderful!
Do you have references to some document that explain how to obtain efficient code with cc65?

[Lazycow]

75% of the cc65 optimization tricks are explained in the ... ... (drumroll) ... cc65 manual.
(It is actually pretty good) With these hints alone you can easily double or tripple execution speed.

[ReadOnlyCat]

Originally Posted by Akira

Looks beautiful

Indeed.
Being both a good coder and artist is a really nice combination.

It probably comes with effort, as everything, but from what we are seeing here, the result is worth it.

[Amigajay]

Wow missed this one, looking great! Looks super smooth, can't wait until the finished game!

[Adrian Browne]

Looks good indeed. Will there be a physical release? Its all the rage right now, tanks, furry, tales of gorluth and maybe even maxwell mouse will all see physical releases.