Screens frComputer Games:

[José Pereira]

Attack Wave3: Entering Latge SpaceShip and Inside Enemys:

 

 

The Enemys at the Top and on the Bottom of the Space ships Walkway moving horizontally.

When the last one of the OpenSpace is off the Screen, change DLI. Backgr. colour on this Top and Bottom walways Lines to another Gray. and you'll get this:

 

The Middle Walkway are just PFs. with the Blue colours. Only two of that Enemy ships, soo I use P2&3 on them (the pixels are all messed, because I've made some mistakes and doesn't want to fix it, also to be painting our 2Ships in all the Screens redone).

 

The idea continues: All Soft Sprites and this time only 1Time each of the 4PMs.

 

 

 

I forgot to say on the other posts that I was using the Black as PF0 if I want to mask some PM2 and/or 3, and here it is.

The two Enemys at the Middle Walkway have PM2&3 in double width, but here no problem because are only, two just move that PMs. squares across the Screen (our Ships PM0&1 higher Priority covers all outside Enemy eventual pixels).

 

 

 

One more and I'm getting there...

 

 

Greetings.

José Pereira.

[José Pereira]

Hello all.

I take the Weekend to continue studding the Sprites movement and my Idea continue to seem right.

 

Yes, In my way of seeing things, all are of oftSprites on A8 and "1PM2&1PM3" or "2PM2&2PM3" or "3PM2&3PM3". Mostly of the times are only "2PM2&2PM3" and just possible with "1PM2&1PM3" in a Line, no real tricky things in this one.

 

I've get the Map (Level1, by now...) while scrolling the Game with the VICE Emulator.

Althought, because of the scrolling you not see the Enemy movements, but you can see all the Attacking Waves.

The number of Enemy ships on Screen are possible (6/8/10 maxim.) in Soft Sprites (just adding that number of PMs. i said)?

 

If you see carefully the their colours are the same of the Ships or in Lines without Large SpaceShip graphics and just DLIs. to PFs. on this Lines. The two/Four/Six on screen with the different colours are the ones where to use PM2&3.

When the Enemy Ships get into Large Space Ships Lines I will explain and prove later (just Pms as underlays in that Lines), but later on.

 

Soo, here it is the Level1 GameMap of Armalyte:

 

 

I will spend this week in redone all the Game Large SpaceShips and Ending Enemys into A8colour and than I will show place by place, Attack Wave by attack Wave, Lines by Lines that I?m probably in a good way.

Then the Softsprites remaking are not difficult, it's all in my mind...

Even if no one code this, we can have all the Scrolling Game done and all the Player/enemy Sphis done on A8.

Anyone interested in enter in this project with me?

 

 

Greetings.

José Pereira.

[PeteD]

Are you talking about doing the sprites/PMGs using PRIOR 0 ORing? If so then it's really not a good way to go about. There are numerous reasons from RAM to CPU time that make it a bad idea.

 

Pete

[José Pereira]

Are you talking about doing the sprites/PMGs using PRIOR 0 ORing? If so then it's really not a good way to go about. There are numerous reasons from RAM to CPU time that make it a bad idea.

 

Pete

 

 

Can you tel me that better.

I was thinking in that, but I can do just ored in PM0&1 on our Ships and get colours on enemy Ship only above Bakgr. (PM2&3)

What the problem (Speed?)

 

We have 12probably ships on Screen, but only 2PM0&1 Ored and 4 on Enemys(2+2 PM2&3, sometimes, not many 6times).

Please explain me and I would probably fix it...

 

 

Thanks.

José Pereira.

[PeteD]

The problem with using PRIOR 0 is you really need the PMs to be the same shape as the software sprites, that means a lot more RAM and more CPU to index, load, store the player data, especially if you're using a player AND a missile because missiles involve even more work to change. You're basically doing a software sprite routine with the chars and almost another one for the PMGs. The fastest way to add colour is with underlays using an expanded player, store 6 solid "pixels" which = 12 c64 pixels, x2 expand it gives you 24. You might end up with one overlapping another but I doubt it would be noticeable at the speed most of the sprites move.

 

 

Pete

[analmux]

The problem with using PRIOR 0 is you really need the PMs to be the same shape as the software sprites...

 

No problem if you only use PM2 and 3. They will only mix with PF2 and 3, and will be masked by PF0 and 1. Only problem: You'd need to use Antic 4 charmode, and PF2 and 3 cannot both be used in one character.

 

So, what I'm trying to tell here: In that case you won't need to make PM into the same shape AND you can expand them to quad width, as 'partial' underlays.

[PeteD]

That's a lot of "if" for something this complex.

 

To do that there would need to be a design where it's sure to work on everything. atm it seems there are situations where maybe it'll work and on other levels maybe it won't. Maybe José can confirm that one way or another when he's gone through all the levels.

 

If it is possible on everything in the game then I'd still go for full underlays as you'll get the colours you really want (possibly a wider range) as shown in earlier screenshots and it's no difference in CPU/RAM usage. There might be a problem with which colour to use as the faux BG with that though, I haven't really looked at Armalayte to be honest.

 

*edit*

And as you say, no same char square so no sprites overlapping but I'm not sure if that would look any worse than having one player overlap another with the full underlay. Depends what the colours are I suppose and what the hardware logic does with them all.

 

 

Pete

Edited March 16, 2010 by PeteD

[analmux]

OK, of course you're right, but I don't expect an exact 1-to-1 port anyway. And, why I proposed this type of underlay: Then you don't have to deal with the shapes, i.e. it's a win-win situation, as you need to move less PM data, and it can also be wider. When using an exact shape-underlay, you'd need to use single-width PMs instead. And, about the 5th-colour problem: It depends on how the programmer wants to move these swsprites around. If it is only horizontal, then you can always have free 5th-colour selection in the vertical direction. In the horizontal direction one needs to be more careful, i.e. don't do 5th-colour changes between two adjacent pixels, but at least keep 3 'other' pixels inbetween, to hide colour-cell clashes.

[paladina]

Search for good page,

 

ok, I found in this topics adress to the C64 screenshots with complete map of some games.

 

http://www.c64screenshots.com/

 

I know about ZX spectrum page too and Iam search for other page with games on C64, Amstrad and Atari ST, do you know about some ?

 

ftp://ftp.worldofspectrum.org/pub/sinclair/games-maps/

 

and in this way search games DEFENDER OF THE CROWN, SPACE CRUSADE, HERO QUEST and BARBARIAN by Melbourne House (2D arcade).

 

thx.

[José Pereira]

OK, of course you're right, but I don't expect an exact 1-to-1 port anyway. And, why I proposed this type of underlay: Then you don't have to deal with the shapes, i.e. it's a win-win situation, as you need to move less PM data, and it can also be wider. When using an exact shape-underlay, you'd need to use single-width PMs instead. And, about the 5th-colour problem: It depends on how the programmer wants to move these swsprites around. If it is only horizontal, then you can always have free 5th-colour selection in the vertical direction. In the horizontal direction one needs to be more careful, i.e. don't do 5th-colour changes between two adjacent pixels, but at least keep 3 'other' pixels inbetween, to hide colour-cell clashes.

 

 

Hello and thanks for your comments.

 

I was using first the overlays, but than I turned to Overlays.

About colours I'm using:

Backgr.- Majour colour (Ex.-Blue)

PF0-Black

PF1-White

PF2-Second colour (Ex.- Light Blue)

PF3-Any colour (Ex.- Vertical Xrays on Large Ships.) or/and Dark Gray (in all the Levels)

 

PF0 will mask PM2&3 in all the Game and PF1-White it's the Inside colour in all the Backgr. graphics and Player&Enemy Ships.

 

 

About PF3 (always the Darkest colour of PM2&3 on enemys)

1.)- Any colour - could be shown like it is or Ored with PM2&3

2.)- Dark Gray - turn all Enemys like C64 ones and get only PM2&3 colour over Backgr.

 

 

But the idea, even with just PF3 as Dark Gray must, have to be Prior0 to get 3colours in our two Space Ships:

PF1-White

PM0&1 colours

PF1 and PM0&1 Ored

 

 

Than Enemys will always be masked by ours PM0&1 higher priority.

Doing P2&3 as overlays it would be possible, but very carefully. In my idea, mostly of the Enemys using PMs are not side-by-side, but something like this:

 

This is what I am trying to prove and am getting it right to all Levels/Attacking Waves:

Allmost all Enemys are only Soft sprites (see the their colours and the ones of the incoming Large SpaceShip). Only "2PM2 & 1PM3, 1more if you'll have the Bottom Bonus Enemy).

If you Scroll all the Game you see that this 2other colour Sprites are not more than 6 on Screen at a Time, only two on a Line. I never see untill now this different colours having more than 2 at a Line.

 

And the Enemys Shapes are using the same: PF3,Backgr., PF1(White in all). As under or Overlays they are always equal. And this is the same if PRIOR0,1 or 4.

 

 

 

Returning to PF3 and Pf2 possible colour clashes, I'm putting PF2 on Large Ships and that vertical inside XRays. Working PF2&3 in Horizontal, O.K.!

And only Enemys and Vertical Inside XRays are using PF3.

On Open Space it's no problem, untill now I don't even see nothing possible to use PF2.

On Inside large SpaceShips, the Enemys aren't usually many and they start to move in Horiz. Direction, when they turn direction they could be in PF3Chars. And why, I think in this, and was waiting for an answer from you:

 

" Another thing I've been thinking is the use of PF3 on the Enemys and that it would not mess with the Backgr. PF2 Gfx(s).

I've read your Posts, but something came into my mind:

 

1Charset by 2Lines in wide 48Chars Screen Mode it's 96chars.

If you do like 96Tiles:

Line0: 0->47

Line1: 48->95

And put the different Sprites frames as different Tiles you're still using 96chars, right?

And you can do this simply because the Enemys movement is pre-defined. You only have to go changing Tiles with different Enemys frames. And now working, with Tiles you can change Enemys Tiles and they never get into PF2 Backgr.Gfx(s).

Could it be this way?

 

Now you still have 32Chars free. You're working in a 2Line/1Charset basis, soo, each of your ship is 3chars+1shiftingx2Lines=8Chars. 2Spaceships is 16 Chars.

 

96+16=112 Chars. You have 16free for the bullets, what is O.K.!

 

The C64 scren 25Lines high will be 13Kb. of Charsets (Charset 0->12).

Possible? "

 

Hope you understand my, always difficult, Post and can answer into this question.

 

Thanks and greetings.

José Pereira.

[José Pereira]

The Start of the Game.

 

In Open Space, see the only two diffrent colours to add PM2&3 and never more than two at a Line:

 

 

And now turning into more tricky thins (not much, by now), Entering the first large Space Ship:

Here you see the two Ships on the Middle are PM2&3 and that they move in the Walkways, soo, no mess with the Pf2 of the large SpaceShip.

Now about the top and bottom Enemys, again moving in Horizontal, and, as you can see, you can just add DLIs. on the Top and Bottom Lines. Just changing Backr. (DarkGray) and PF2(Middle Gray) no PM2&3 neede here.

 

 

 

On other Ships, this Inside large SpaceSphips Enemy Sips turn direction and move into LargeShip Lines, but here you have them as SoftSprites and just put a PM as overlay in the position they get into this Lines). one ex. of this is the large Snake that will be SoftSprite (on middle of the Screen) and then goes off the Screen on top after a wall Large SpaceShip (it here, near the wall you put PM2 as Underlay). Only one SoftSprite at a time, PFs overlay Double Overlay P2 and you'll get the same colours you had on the Middle DlI.

 

 

Yeah! I think the things are getting there.

Greetings.

José Pereira.

[José Pereira]

Hello.

I am a little bit stuck on the Underlays.

I I was doing with Overlays and only two PMs. on Line all will work.

But to get underlays, many of the times I'll get this when Enemys Overlap:

 

The Enemys Majour colour I can get 3colours, like Blue, Brown, Gray or even 4. Two PFs (2&3) & 2PMs. (2&3).

Doing as overlays I could get this, but as Undrelays no way:

1.)- The PM2 overlap PM3 colour(s) (PM2 higher Priority but Mask other PM3 places).

2.)- PF2 (Ex.-Brown) cannot overlap PF3(Ex.- Blue)

3.)- PMs.2&3 cannot overlap SoftSprites only using PF2 or PF3.

 

 

The overlap pixels excess will not be many pixels, you have 6Double (12 normal) and all many of the Enemys are almost 4side squares and with the Game's speed... But no. It will not be/look right.

 

 

I think, think and continue to think.

But I think I get a solution, not a bad and probably the best.

Just see this pictures:

 

And what you see here:

The Enemy overlaps another Enemy with the same colour.

You can change their direction in any place of the Screen (some/mostly of the times they don't overlap), but if you want to/need to you can overlap PF2 with PF2 ones (Ex.-Blue), PF3 with PF3 ones (Ex.-Brown) and PM2 with PM3 if the two are the same colour.

 

What do you think? It will not look bad and more free to move them. Sometimes overlap, other times don't like C64 but only the same colour overlapping on A8.

 

 

Send your ideas/comments (I need them!)

Thanks and greetings.

José Pereira.

[José Pereira]

Sorry another question I had for days.

If you take an Armalyte Screen for days you'll see that all the Playing Area uses the 25Chars Lines high.

And the Status Panel it's 3more.

And again, I think, think and continue to think...

But once again I think I discouver it.

The C64 cannot do more than 25Chars Lines High or can?

 

I think it can't. And this is an Ex. of the Sprites on the Borders.

The status Panel have 21Pixels high (like C64 sdprites) and 24Chars Horiz. Wide (3Chars=1Spritex8C64 Sprites024Chars).

Clever Guy, isn't he?

 

 

And I also get another problem today (for me...).

I cannot get the C64prites using C64Ripper. OH God!

But I think that sometimes they are not only Multiplexing more Sprites by Lines but also (Snajke as Ex.- all SoftSprite and Only Head and Back are Sprites) but also SoftSprites.

 

I'm also a clever Guy for getting this?

[PeteD]

With one PM overlapping another, I don't think it would be very noticeable at the speeds things move. In fact I'm not really seeing much of a problem with the images you've posted. It's not like a whole sprite has suddenly become another colour or had it's data corrupted. I think if you're so worried about colour that you're willing to start moving enemy positions or colours or whatever you're basically better off designing a new game than trying to imagine porting Armalyte.

 

Don't forget you can use the background colour for one of the sprite colours (rather than an underlay) as it won't be shown for most of the rest of the screen.

 

Yes, Armalyte has the "panel" in the border.

 

If you can't rip the sprites from the game then they're probably compressed somehow, at least to remove blank bytes. When they're needed in the level they'll be decompressed. I'm not sure if that's what is happening as I haven't looked but LOTS of games do the same thing.

 

 

Pete

[TMR]

I think it can't. And this is an Ex. of the Sprites on the Borders.

The status Panel have 21Pixels high (like C64 sdprites) and 24Chars Horiz. Wide (3Chars=1Spritex8C64 Sprites024Chars).

Clever Guy, isn't he?

 

If you thought that was clever, you might want to take a closer look at Delta because it has sprite status panels in upper and lower borders and the scrolling landscapes are generated with blocks of sprites as well; even the text and logos for the attract sequence are using sprites, it generates the bullets (player and enemy) and background starfield as characters and literally nothing else.

 

And I also get another problem today (for me...).

I cannot get the C64prites using C64Ripper. OH God!

But I think that sometimes they are not only Multiplexing more Sprites by Lines but also (Snajke as Ex.- all SoftSprite and Only Head and Back are Sprites) but also SoftSprites.

 

Nope, unless the player's bullets count (they're just character blocks being moved around rapidly really, but i've seen similarly primitive techniques called software sprites on some platforms!) there aren't any software sprites in Armalyte at all. At a guess, the ripper can't find them because it probably "freezes" the virtual machine at the bottom of a frame and only gets the last thing on the display that the hardware sprites are doing (the status panel) so you'll have to hunt through manually if there's an option; it's been literally decades since i last prodded around in there, but a good bet would be to start looking at $4000 onwards.

[PeteD]

There are lots in there around $4000. The reason you probably can't find all of them is it's multiload game (at least as far as I remember) so you'll need to load each level.

 

 

Pete

[PeteD]

 

 

If you thought that was clever, you might want to take a closer look at Delta because it has sprite status panels in upper and lower borders and the scrolling landscapes are generated with blocks of sprites as well; even the text and logos for the attract sequence are using sprites, it generates the bullets (player and enemy) and background starfield as characters and literally nothing else.

 

 

Yup, and there's only just enough screen on the A8 to fit it all in. It's a tight squeeze though.

 

Pete

[José Pereira]

 

 

If you thought that was clever, you might want to take a closer look at Delta because it has sprite status panels in upper and lower borders and the scrolling landscapes are generated with blocks of sprites as well; even the text and logos for the attract sequence are using sprites, it generates the bullets (player and enemy) and background starfield as characters and literally nothing else.

 

 

Yup, and there's only just enough screen on the A8 to fit it all in. It's a tight squeeze though.

 

Pete

 

 

Thanks for you answers.

I thinked in Delta because of PeteD's work when you started talking about the Underlays.

It seems to me that the only way possible on A8 is the Expanded PMs. as Underlays, burt do not to enter in others work, just some thoughts, as I only have seen videos of it.

 

Yeah! Not clever now. If it's a Multiload it will not have Sprites there.

 

I'm trying to put some 6Pixels Double on Enemys above others using PF2/3 to see what I'm getting.

 

Thanks.

José Pereira.

[José Pereira]

I'm searching for tricky overlap Screens.

But some G2F possible(?) just to do something different:

[PeteD]

hmm, ok, you've got overlay PMs that are slightly bigger than the sprite vertically and quite a bit bigger horizontally so you're causing more problems than you need to. Don't forget the PM can move to pixel positions where the chars have to stay put (apart from hardware scroll) despite the graphic in them moving left/right. It looks like you've made the PMs 32 (c64 hires) pixels wide instead of 24.

 

 

Pete

[José Pereira]

hmm, ok, you've got overlay PMs that are slightly bigger than the sprite vertically and quite a bit bigger horizontally so you're causing more problems than you need to. Don't forget the PM can move to pixel positions where the chars have to stay put (apart from hardware scroll) despite the graphic in them moving left/right. It looks like you've made the PMs 32 (c64 hires) pixels wide instead of 24.

 

 

Pete

 

The P2&3 are in Double but I forget to erase Up and more than 6Double pixels.

The idea here was just to show (not Double width PMs, I have to get/see/show more tricky ones) the idea of having 5colours on Armalyte (Spaceground point are Backgr. colour).

 

The Screen is centered with unecessary 1Line at the Top and another at the Bottom. The Status Panel also have 5colour with PF3 on the Center Scores.

 

I am also trying to get all the colours/Luminances in all Levels/Large SpaceShip that can work/good IMHO looking on the PRIOR0 underlays. And it is very difficult as you can see on this 3 PM2/3 Enemy Ships.

I am also trying to design our two SpaceShips. Because I am using PRIOR0 here as they are PM0&1 I have to use Players and Missiles. And another thing, here I must have different shapes because PM0&1 covers all. With something like Maxim. on Screen:

12(normal 6/8)Enemy+2Our Ships as Soft Sprites

+1PM0&1PM1 (in Normal width and different Shapes)

+2PM2 & 2PM3 but always underlay with no shape changing, sometimes, not many 3+3)

Will this be to much?

 

 

Thanks.

José Pereira.

[Heaven/TQA]

ok...again my experience... Pete & Co can correct me... but

 

to mimic c64 sprites (so to say when using a c64 "back engine" while putting soft sprites on top) our speed advantage of 1,77 Mhz gross vs 0,9 Mhz is not enough... and for "quick" conversion like Bomb Jack you need a 6502 engine backend...where you adapt or put "sprite routines" on top...

 

but the structure is different... screen layout will vary to c64, ram usage is higher due to prerendered sprite data but c64 can have 60k while we can have 56k... and and and... oh... and it should run in 50/60 fps...

 

My skills are not high enough but Kudos to the ones who can...

[andym00]

Just thought I'd stick my nose in quickly because José is doing an ace job here again

Just wanted to point out that from an implementation point of view that Armalyte actually only uses 6 sprites really.. The 2 sprites used for the player(s) space ships aren't split at all to avoid any flickering malarkey that might occur.. So only the 6 remaining sprites are used for the AI ships in the multiplexer, which means it's not beyond the realms you could do something fairly reasonably with a quite simple engine on the A8..

[andym00]

ok...again my experience... Pete & Co can correct me... but

 

to mimic c64 sprites (so to say when using a c64 "back engine" while putting soft sprites on top) our speed advantage of 1,77 Mhz gross vs 0,9 Mhz is not enough... and for "quick" conversion like Bomb Jack you need a 6502 engine backend...where you adapt or put "sprite routines" on top...

 

but the structure is different... screen layout will vary to c64, ram usage is higher due to prerendered sprite data but c64 can have 60k while we can have 56k... and and and... oh... and it should run in 50/60 fps...

 

My skills are not high enough but Kudos to the ones who can...

 

On PAL at least I think you could pull off Armalyte almost pixel for pixel on the A8, in fact with probably a bit more useful colour added.. But the killer comes with NTSC which I just don't see how that'd be feasible.. Not at 60FPS anyway.. And not with the numbers I've seen coming out of my software sprites..

 

I really think you can do this (in PAL at least) with a fairly conventional character based sprite system and a nice PM multiplexer

[PeteD]

Quantify fairly reasonable and simple

 

I don't think it's possible to get anywhere near it with say a PM plexer for the enemy ships, 2 per line hmmm very doubtful so you're still down to how many software sprites you'd need to draw (ignoring any PM under/overlays) and once that's written then it's simple, but fast? There are a fair few "cheat" possibilities for keeping the speed of the sofsprite routine up. It looks like most of the time the enemy sprites don't go over the background so as long as they also don't cross each other you haven't got a lot of masking to do, when they do cross you can at least draw the lower ones first and save a round of masking.

 

If there's going to be any changes in attack waves or numbers of sprites etc then I say forget Armalyte and José should design a game using what he's learned from all this G2F stuff. Use armalyte or whatever graphics for now, they can always be changed later but do something the A8 can handle without having to think about it for a month.

 

 

Pete