Horizontal Scrolling Game on A8

[José Pereira]

Hi, I am going to be direct:

 

"DON'T TURN THIS INTO ANOTHER A8vSC64 WAR!

IF SOO, ALBERT PLEASE LOCK THE THREAD, but do not erase it, as it might have here some interesting things..."

 

 

FIRST: Need to be in CharMode and Antic4 (No double high pixels like Zybex)

SECOND: No talk about PMs. by now, just SoftSprites, O.K.?

 

 

O.k. froom what I write on other Post I think i discouver a way to have more Chars free:

CharLine0: Charset0

CharLine1: Charset1

CharLine2: Charset2

CharLine3: Charset3

and the same Charsets like this on the other CharLines.

 

With this I would need only 4Chars for each Sprite (including Shifting) in each Charset.

How many SoftSprites maximum to get a speed near Armalyte on C64 (if possible...) and using this 4Charsets/Antic4?

 

My Chars free for the Backgr. would be=128-(1SoftSpritex4)

 

 

Thanks.

Just want to see once and for all what it is or what it isn't possible on A8!

José Pereira.

[José Pereira]

O.k. froom what I write on other Post I think i discouver a way to have more Chars free:

CharLine0: Charset0

CharLine1: Charset1

CharLine2: Charset2

CharLine3: Charset3

and the same Charsets like this on the other CharLines.

 

With this I would need only 4Chars for each Sprite (including Shifting) in each Charset.

How many SoftSprites maximum to get a speed near Armalyte on C64 (if possible...) and using this 4Charsets/Antic4?

 

My Chars free for the Backgr. would be=128-(number of SoftSprites x 4)

 

 

Or will my constant DLI changes of the Charsets in all the "8" BadLines kills any possibility of having a large number of SoftSprites moving on?

Thanks.

José Pereira.

[Heaven/TQA]

Jose... moving sprites by pixel or by char?

[José Pereira]

Jose... moving sprites by pixel or by char?

 

I think in using ANTIC4.

It is CharMode but they will have to movvve pixel (colour clock) or we will get into some

ZX R-Type if movving a Char at a time.

 

And also thinking this:

C64 moves 1 Hi-Resol. pixel a time but A8 moves in colour clock (one 2:1 pixel).

Like this would it be possible to move on A8:

-> some Soft(six/seven/eight SoftSprites?), stop

-> other Soft(more six/seven/eight SoftSprites?), stop

(this is saying like 25mhz will equal 1:1 C64 pixel, they will be in the same place same time as C64ones).

 

This way we were just doing like if there was not 12or14or16 on Screen but only half of them each time.

 

 

 

 

José Pereira.

[MaPa]

With soft sprites the issue is CPU speed and not free chars. If you do soft sprites with masking you need indirect LDA, AND, ORA, STA sequence for every byte of the sprite so it is 21 cycles for every byte. So if you have sprite 12x24 pixels so you have 4x4 chars, vertically you can start at the needed position so 4x24 bytes x21 cycles = 2016 cycles only for copy data of one sprite, add some overhead like increment the index register.. 2200++ cycles. So in theory in one antic 4 screen you have time for drawing around 10 these sprites. But just drawing.. you need to erase them too, in game scenario some music, sound, game logic etc. etc. so IMHO you end up with 4-5 sprites of this size max.? Adding my test of soft sprites in gr. 7, they are 12x16 pixels only and all it does is draw spritesm no sound no logic nothing. I don't say it is the fastest how it could be but IMHO not much faster if at all without unrolling code and hard coded data etc. The color bars shows how much time it needs to draw one sprite, the white below picture is start of erase.

8_sprites_12x16.xex

[José Pereira]

With soft sprites the issue is CPU speed and not free chars. If you do soft sprites with masking you need indirect LDA, AND, ORA, STA sequence for every byte of the sprite so it is 21 cycles for every byte. So if you have sprite 12x24 pixels so you have 4x4 chars, vertically you can start at the needed position so 4x24 bytes x21 cycles = 2016 cycles only for copy data of one sprite, add some overhead like increment the index register.. 2200++ cycles. So in theory in one antic 4 screen you have time for drawing around 10 these sprites. But just drawing.. you need to erase them too, in game scenario some music, sound, game logic etc. etc. so IMHO you end up with 4-5 sprites of this size max.? Adding my test of soft sprites in gr. 7, they are 12x16 pixels only and all it does is draw spritesm no sound no logic nothing. I don't say it is the fastest how it could be but IMHO not much faster if at all without unrolling code and hard coded data etc. The color bars shows how much time it needs to draw one sprite, the white below picture is start of erase.

 

 

Thanks, but if go into 48wide the problem increases, right?

Armalyte for example, that would only be needed 2SoftSprites as all the Enemys will move in free space. But I would need to have this free space Black as PF0.

Will this helps (our two ships only) and others free space?

 

José Pereira.

 

José Pereira

[emkay]

 

Thanks, but if go into 48wide the problem increases, right?

Armalyte for example, that would only be needed 2SoftSprites as all the Enemys will move in free space. But I would need to have this free space Black as PF0.

 

If you scroll via hardware, a 40 Bytes wide screen need 48 bytes to read. It's alike whether you see 40 or 48 bytes.

It seems, guys like Archer McLean are very unique on the A8. Doing fluent scrolling and "char-cluster"- based software sprites.

 

I also have no problem with "charmode" movement, if the gameplay/gamemechanic works well, as in Tomcat.

One of the greatest classics on the A8 "Boulder Dash" moves in charmode resolution...

[emkay]

The best "workaround" for many moving objects on the A8 still was to use ONE Softwaresprite for the "Protagonist" and do multiplexing of the PM for enemies and coloured parts on the screen. Possibly, for games like Armalyte, we had to drop full hardware scrolling and use charset rotations instead.

 

 

[Heaven/TQA]

Jose... have you had looked at Menace A8 prototype?

[Heaven/TQA]

and the C= Plus 4 shooter? can not remember the name...

[Heaven/TQA]

http://www.xeo3.com/

http://www.youtube.com/watch?v=Y27tpOod364

 

the c64 version

http://www.youtube.com/watch?v=Lb1qFjR-Q-0&feature=related

 

the cpc

http://www.youtube.com/watch?v=uVSjRVXRGx8&feature=related

Edited November 10, 2010 by Heaven/TQA

[Heaven/TQA]

http://www.jetbootjack.com/JBJ_oldgamesdownloads.html

[emkay]

http://www.jetbootja...sdownloads.html

 

It's one of those "Projects" that makes me wondering sometimes, why it ends in "do a dot, move a dot" , while one other "worse" machines , the games seem to be more fluent.

 

XeO3 really seems possible on the A8, if it is possible on the +4 . Well, but as it seems, someone needs to write a +4 emulator to run it fluent on the A8

[ANTIQ]

Has anyone ever tried preshifting the sprites and moving them by changing PMBASE?

[Rybags]

Why would you do that? PMs don't need shifting, they have colour-clock positioning built in.

 

Xeo3 would be a walk in the park except for the 128 vs 256 character limit. The fix might be simple but more likely would be fairly involved, plus you'd probably eat up anything from 4-8K more RAM in doing so.

[ANTIQ]

Crude example:

 

Say you want 100(!) 8x8 enemies, 4 per line, to come in from the right. You'd usually

 

- fill each player with 25 copies of the enemy image with a blank line before each and

- write an interrupt routine to change the horizontal position or colour or whatever of each enemy in the blank line.

 

Say you want to move them all vertically in formation. Could you

 

- fill 8 more sets of players with the enemy images, each set offset by a line and

- write a vertical movement routine which increments / decrements PMBASE and moves the interrupts up / down a line?

[Rybags]

You could, but then it's costing you 8K or more just to have all them moving over an 8 pixel vertical range at once.

You could save RAM by using double-line resolution and VDELAY.

 

Only worth doing if you're using the Playfield for background graphics.

[ANTIQ]

Consider what happens if the vertical movement routine jumps back to PMBASE 1 after PMBASE 9 but continues moving the interrupts down a line.

 

(Assume the first interrupt sets the first row of players' horizontal positions to 0.)

[Rybags]

Cheap Space Invaders.

[ANTIQ]

Ha! Bingo!

 

A much more sophisticated routine could move the interrupts arbitrarily and each interrupt could set PMBASE to any of the vertical offsets.

[Creature XL]

What about the background? When the background is empty (COLBK) then the soft sprite "copy" routine is easier. You can ommit the mentioned AND/OR and have in 11 cycles.

Further, hwo many different shapes? If it is only one (or not many) shapes per wave, you can copy the data into the zeropage and ommit the indirect "LDA (ZP),y" and use "LDA ZP" save 2 cycles further.

 

However, the fastest way of doing it (no matter if background == COLBK or not) is using what they call "compiled sprites" I think. You build a small copy program for every sprite. Jose, this doesn't work in "our thing" because we have too much sprite data. But if you haven't too many different sprites or a willing to use 128Kb then the "compiled sprites" are the best option. I would say, without testing, you can get 10 8x16 easily.

 

For better numbers and maybe small tests, you need to supply more information

[MaPa]

In this thread http://www.atariage.com/forums/topic/172227-horizontal-scrolling-game-on-a8/ I posted my test of some scroll technique and there is also software sprite included. In the test program you can see how much time it takes to draw that one sprite which is 10x26 pixels I think so 4x4 chars max. occupied. It check if there is any background to do proper masking or just copying so the time varies. Try to stand in front of some graphics to see how much time it can take to draw this one sprite which is not large at all. It's done with indexed instructions, no "compiled sprites" or something like that.

Edited November 11, 2010 by MaPa

[José Pereira]

http://www.xeo3.com/

http://www.youtube.com/watch?v=Y27tpOod364

 

the c64 version

http://www.youtube.com/watch?v=Lb1qFjR-Q-0&feature=related

 

the cpc

http://www.youtube.com/watch?v=uVSjRVXRGx8&feature=related

 

 

C16 is a little bit slow, of course, but why not possible in A8?

Lets see:

Think that instead of 256 (C16) all the Gfxs. were done into 128Chars.

Like you're doing a new and specific Game on A8!

 

On C16 only Soft Sprites there are maximun 10moving Ships (including our own but not the rotating Gfxs.)

On C64 I count maximum our Ship+12Enemys, what isn't anything great compared to Armalyte or others, I think.

 

 

Just get some pixels on Screen.

And rotate move some ships on the sky isn't it possible?

If we do things in a clever way we could get ANTIC4 and PF3, that is always very usefull.

Will it be so difficult, if Enemys with some clever thoughts only moving in the Sky and have not many shapes and probably something like this with 10Enemys:

->5Enemys same shape are the same Chars (9Chars).

->More 5Enemys other shape but all this 5 with the same shape are another 9Chars.

 

The 10Enemys are only 18Chars (without shifting), simple, you get more Chars for Gfxs. and Bullets.

Now if they only move in the Sky. Sky is Black, if Enemys are shapes with Black outside, you simply change Bacgr. Black cell for Enemys cells. Just this, I am not talking, by now, for games that will need AND/OR Soft Sprite...

 

I just want to see something like ARMALYTE in A8, is there asking for too much?

José Pereira.

 

 

 

Sorry I am not pressing you, I will never go into coding that I will ever do something like these ones... but why never anyone really tried!...

Or tried and stop, or tried and thought it weren't good, or try and didn't want to ask for help, or...

oR, oR,... Soo many "OR" but no "AND"!

AND/OR and we will have some SoftSprites

Hope you don't get upset with me...

José Pereira.

[Rybags]

C16/Plus4 isn't exactly "slow".

 

It's virtually the same speed as the A8 - I benched both with the same piece of looping code, the Atari is like 1-2% faster.

[José Pereira]

C16/Plus4 isn't exactly "slow".

 

It's virtually the same speed as the A8 - I benched both with the same piece of looping code, the Atari is like 1-2% faster.

 

 

C16 almost the same speed...

It seems that if someone is interested then he could see the code.

Is this C16 using Bitmap or CharMode?

 

Or someone could also see how many Chars C64 version uses...

I would be interested in helping, if someone wants...

Get here some PMs. on Ships I think I know how to colour them, I tried and show how it will be possible in Armalyte on the past...

But first we have to get the Software Sprites, right?

 

Hope someone have some free time and are interested, it would be great!...

José Pereira.