Unifished game from 1993

[Kaz atarionline.pl]

Jerzy "Mono" Kut and Marcin "MAG" Grochowina prepared a nice game engine in 1993, but project has been abandoned because LK Avalon wasn't interested in that. The program is able to read graphics data from disc drive during the game, game have 2 bitmaps (first: 16 shadows, second: 4 colors and PMG) and other innovative solutions. NOT OPTIMALISED YET! You can see movie or read article about (using Google or AltaVista Polish-English translator). Download here (press A on disc menu screen).

 

PS. Game title "Samobojcy" means "Suiciders".

[Rybags]

Interesting concept - interleave lines with only background on even, moving objects on the other.

 

Makes for quick action since the sprite draw/restore can be made a lot simpler, ie just XOR or plain draw/erase.

[Allas]

Impressive stuff, it's good to see new-working-ways on the infinite Antic still.

[JIMPACK]

Great project!

 

 

I was very impressed with technique applied, because I could not believe as mixed different graphics. Truly is a very great job! : D

 

I think we could then apply color to make it much more motivating.

Because as it stands, is an excellent graphics "demo". Congratulations! : D

[Rybags]

Colour would mean either GR. 10, which isn't PMG-friendly, or APAC which is CPU intensive.

 

Although such a game in APAC might be doable with the kernal interleaved such that the game loop code is executed in the spare cycles rather than just wasting them with WSyncs.

[Tezz]

That was an interesting idea and good to see some thought being made in developing an engine like that, i'd like to see more development using this method and maybe continuing it further, i think it would have potential for some interesting productions.

[analmux]

Although such a game in APAC might be doable with the kernal interleaved such that the game loop code is executed in the spare cycles rather than just wasting them with WSyncs.

 

I think the program already does something like this, as it is mixed GTIA and Normal mode. The gprior reg. must be changed every scanline.

 

APAC would not give the same possibilities for this screen setup, as it is already 2 scanlines for one 'super scanline of 256 colours'.

 

 

Interesting though, that I first thought it is 2 independent screens, mixed together. Having a closer look, the 16lum. background screen also contains a part of the software sprites. The 'sprites' must of course totally clip the background, so the 'background' pixels are erased inbetween the antic E lines.

Edited August 8, 2008 by Analogue Multiplexer

[mono]

Hi.

@Analogue Multiplexer: That is really two independent screens.

First is displayed on even scan lines, and has gprior=%00xx0100. It has logically 40 bytes width and I show there only 4 color flying objects. The method of show/hide is EOR. Because I have 40 bytes width I can draw objects without testing border range code - procedure is simpler because it only draw object for its full width. There are 8 invisible bytes on screen what is enough for hiding borders of objects.

Second screen is displayed on odd scanlines and has gprior=%01xx0001. It has background moving down and it has 32 bytes width. I draw static objects on background and animated guns with only STA and without any masking. But on background I show explossions too - these objects are masking and saving content of background.

@Rybags: Yes - I don't like wsyncing and it is observable there. On right border one pixel is flickering.

I use another one trick too for fuzzying content of screen. Displaylist has even empty lines on even vblk, and odd empty lines on odd vblk. Whole content is falling and arising about 1 scanline anternately.

I use pmg with black color for hiding background under flying objects. So pmg is placed "between" bitplanes and separate them. When I don't it the objects on 4-color screen are transparent. It can be observable on scoring counter.

Both screens have separate ram areas - they aren't interleaved.

Sorry for my english.

 

Edit: Main loop is realizing in spare cycles indeed.

Edited August 8, 2008 by mono

[analmux]

...I use pmg with black color for hiding background under flying objects...

 

Ah, thanks for explaining. I was already wondering why you used Players/Missiles at all. Seems like a very clever trick

[peteym5]

WIth a custom NMI routine and having a DLI bit set on every Antic 15 ($8F), you can toggle the 2 GTIA modes per scanline and just a single WSYNC before exiting. That still leaves lots of CPU time open for a simple VBI routine. I admit you probably cannot do something really complicated like moving big software sprites around on every frame. The other choice is Antic 2 mode APAC, but that requires 8 WSYNCS for each DLI and probably hold up the CPU more.

[mono]

I have a very simple NMI interrupt procedure:

dliint equ *
 pha
 lda nmist
 bmi dliroutine
vblk equ *
 lda dlist;pick up / fall down by one scanning line
 eor #$10;by switching emp7/emp8 empty lines
 sta dlist
 lda modeswitch;switch beq/bne
 eor #$20
 sta modeswitch
 ...
 pla
 rti

dliroutine equ *
 lda vcount;discovering scanline with single scanline resolution
 cmp lastvcount
 sta lastvcount
modeswitch equ *
 beq secondscanln
 lda #%00000100;pmg under playfield, 4-color mode
 bne *+4
secondscanln equ *
 lda #%01000001;pmg over playfield, 16-luminance mode
 bit 0;zeropage
 bit 0;zeropage
 sta gtictl
 pla
 rti

lastvcount dta b(0)

dlist equ *
 dta b(emp8),b(emp8),b(emp8+int);first dta is emp7 or emp8 switched on vblk
 dta b(gfx15+lms+int),a(backgroundscreen)
 dta b(gfx14+lms+int),a(objectscreen)
 ...

Both "bit" instructions are for delay purpose. NMI is discovered on my own, because our game picks up both roms (basic and os).

Falling down/rising up by one scanline is connected with switching beq/bne to avoid mistaking with gtia mode switching with one scanline resolution.

As you see this dlint takes about 50 cycles and about half line is free for cpu.

Edited August 8, 2008 by mono

[mono]

WIth a custom NMI routine and having a DLI bit set on every Antic 15 ($8F), you can toggle the 2 GTIA modes per scanline and just a single WSYNC before exiting. That still leaves lots of CPU time open for a simple VBI routine.

Yes, but we still have background i/o for loading background graphics. I think so blocking of irqs for one scanline will be too long for irq.

I admit you probably cannot do something really complicated like moving big software sprites around on every frame.

Unfortunatelly big software sprities can't be moving on one frame. This is the reason for using EOR for painting and erasing software sprities and for using 40 bytes line width.

The other choice is Antic 2 mode APAC, but that requires 8 WSYNCS for each DLI and probably hold up the CPU more.

This is the problem. Blocking irq for 8 scanlines is too long. On the other side: if we'll unlock irq during antic 2 mode drawing we lost of synchronisation required for switching gtia when irq occurs

And we lost advance of bitplans memory separation.