Screens frComputer Games:

[José Pereira]

Oh God!... This is not my day...

 

Just saw now that I've done (...) again.

 

I want to post a Screen in A8, but now I'm on the Streets and you'll see the St one:

 

What I want to know is if I want to have just 1Player multiplexed (like Ripper but here just need one P.M., I think!...), let's say P1.

I want to know if I use P1 on that 5 small Ship. Can I multiplex it 5times as you can see on the picture (see that they are sometimes almost all on the same line)?

 

Thanks.

José Pereira.

[PeteD]

No If any part of them is on the same line as another you'll need to either "interlace" them (eg flicker/change between each one each frame) or have a mid-scanline routine to repeat the same player and that's too much CPU and not possible for sprites so close together.

 

 

Pete

[José Pereira]

No If any part of them is on the same line as another you'll need to either "interlace" them (eg flicker/change between each one each frame) or have a mid-scanline routine to repeat the same player and that's too much CPU and not possible for sprites so close together.

 

 

Pete

 

If I'm seeing things O.k. in Ripper Demo you have your ship P0&1 and the Enemys (6 Enemy Ships) as P2&3 and having 3rd colours on both because of Multicolour format.

What you call that Ripper ex. (Multiplexing?)

 

If I have one at a Line I have to turn Off, show other than this off and again the other On... But because it's very quicly you don't see the flickering... Like Ripper?

 

 

I thinks it's a problem of English and something more to learn...

 

Thanks.

José Pereira.

[PeteD]

Without special (CPU intensive) code you can only display the player once per line. Ripper "multiplexes" 2 sets of 2 Players for 2 multicolour Players. They have "sprites" on different Y lines. When it gets more than 2 on a line it flickers, I don't think there is any specific code to flicker in a "nice" way, it just happens because the hardware can't handle that many PMGs on a line.

 

If you look at ripper again, most of the time the sprites aren't in the same Y area of the screen, when they are, they flcker.

 

eg

around 12-13 seconds.

 

 

Pete

Edited March 4, 2010 by PeteD

[José Pereira]

Without special (CPU intensive) code you can only display the player once per line. Ripper "multiplexes" 2 sets of 2 Players for 2 multicolour Players. They have "sprites" on different Y lines. When it gets more than 2 on a line it flickers, I don't think there is any specific code to flicker in a "nice" way, it just happens because the hardware can't handle that many PMGs on a line.

 

If you look at ripper again, most of the time the sprites aren't in the same Y area of the screen, when they are, they flcker.

 

eg

around 12-13 seconds.

 

 

Pete

 

 

Yes I saw it one more time. For me it doesn't seem very bad. Very good indeed. You can "Fool flicker" because of the different shapes of the PMs. (When they go around, and around and at a point one is off the other on, but you still not notice. I think it is when one is just a Line that it turns off and than the other at a full size shape On.

Yes, that would work for Zybex, Armalyte,... because of the constant changing of PMs. shape and you can "fool" the Vision. Here it doesn't work, but I thinked in that... other ideas/resources left...

 

 

By the way, I only remember that Atlantis Game as the only A8 vertical Sroller with a Side Status Panel. Taking EMKAY's opinion, I don't see here any other possible solution (and good looking...)... It's possible not to mess with PF2/3 on it. A put the question again: "Without PF2/3 messed, even in this way, will be soo tricky to get that Panel work in this Game?"

 

And PeteD, the so called Mid Scanlines colour change are possible to add in scrolling games (Horiz. or Vert.). I was thinking just one more colour, here for example on the Buildings, just one colour inside that circle of the cannons (but here on Vertical wouldn't you get problem in "Bad Lines (8multiple)", when it's scrolls down you will have them sometimes at this "BadLines")?

 

Sorry to all this questions. Not anymore question today, I promise!

Thanks.

José Pereira.

[PeteD]

Flicker isn't too bad/noticable!? Damn José I think you need to get your eyes checked I know it's only a demo but yikes!

 

As I mentioned earlier there are a few ways to do a stationary panel and possibly more than I already thought of.

 

DLIs follow the hardware scroll so as long as you've handled the colour changes already scrolling won't effect them. It's really not an option doing mid-scanline stuff unless it's only for a small vertical area of the screen because it takes too much CPU and if you do it in a way that takes less CPU (although still too much imo) you can't really make it accurate so you'd need a fair amount of horizontal "buffer" where the colour change could take place and not effect anything.

 

 

Pete

[jvas]

Flicker isn't too bad/noticable!? Damn José I think you need to get your eyes checked I know it's only a demo but yikes!

 

As I mentioned earlier there are a few ways to do a stationary panel and possibly more than I already thought of.

 

DLIs follow the hardware scroll so as long as you've handled the colour changes already scrolling won't effect them. It's really not an option doing mid-scanline stuff unless it's only for a small vertical area of the screen because it takes too much CPU and if you do it in a way that takes less CPU (although still too much imo) you can't really make it accurate so you'd need a fair amount of horizontal "buffer" where the colour change could take place and not effect anything.

 

 

Pete

 

Would it be possible to interlace the sprites not by frame but by scanline?

Let's assume there are 4 sprites in a row.

Interlacing them by frame means, that I draw 1st and 3rd in the first frame and 2nd and 4th in the 2nd frame and so on.

Interlacing them by scanline means, I draw the 1st and 3rd in the first scanline, 2nd and 4th in the next scanline, 1st and 3rd again and so on. Is there a demo that uses this technique? Or would it look worse than "frame interlacing"?

[José Pereira]

Hello to all again.

 

I taked this affernoon another attitude:

Every time I want to do something diffrent (no LNs, other Games,...) I start to redone one of the "Bilions" Zx Spectrum Hi-Resol. Platformer Games from the "M..." Game maps at World of Spectrum.

I think I can have all them re-done to all (in a way that can work as a game, like always) in 2199.

But don't be afraid that I will not post them all

 

Just this one for today:

Adam's Family:

 

 

Greetings.

José Pereira.

[PeteD]

 

Would it be possible to interlace the sprites not by frame but by scanline?

Let's assume there are 4 sprites in a row.

Interlacing them by frame means, that I draw 1st and 3rd in the first frame and 2nd and 4th in the 2nd frame and so on.

Interlacing them by scanline means, I draw the 1st and 3rd in the first scanline, 2nd and 4th in the next scanline, 1st and 3rd again and so on. Is there a demo that uses this technique? Or would it look worse than "frame interlacing"?

 

I think I have seen stuff do that before but I'm not sure what it would look like in a game situation. It'll also take more cpu to handle something like that because you'd need an interrupt on every line there were multiple sprites but if there aren't too many lines with multiple sprites/line it wouldn't be toooooo bad I'd imagine it should look at least a bit less flickery than just displaying whole alternating sprites.

 

 

Pete

Edited March 9, 2010 by PeteD

[José Pereira]

Armalyte_Zx_SpriteSheet.bmpHello to all.

 

Anyone have Computer & Video Games 12.88, that he can scan the Armalyte C64Map Armalyte_Zx_SpriteSheet.bmp

 

Thanks.

José Pereira.

[José Pereira]

I begining to be like someone else here and once more with problems to sleep.

 

I spent some hours playing/videos at almost all (the majour ones) C64 Shoot'em'Ups.

Others have diffrent approaches, but for Armalyte I can get something like this in a playable A8version:

 

 

And what you have here?

 

First, in all the Levels you'll have one colour the same (White or a lighest Brown):

It's the inside colour in all the Graphics of the background screen. Turn this into White for Levels in A8.

In A8 use this as PF0 colour.

 

The second and third colours (PF1 and PF2) will be the two shades of the same colour: like 2Blues, 2Browns,...

Backgr. colour is always Black.

 

 

If you take a look now two all the C64 Sprites they use always a DarkGray (C64 one colour in each Sprite and than 2colours the same in all Sprites: White and DarkGray here).

This Dark Gray is always the most widest colour in mostly of the Sprites.

Turn this DarkGray colour into PF3 on A8 in all the Game Levels.

Use PF3 in the Sprites borders of the Enemys and the others two colours are PF3 overlap P2 and just P2 (two greens,...) in one Enemy and P3 on the other.

You can have in this way two Enemys in the same time in the same line.

Seen the Videos at slow motion and get that this 3Enemys in a Line aren't many times, but you can have 1/2 Enemys just as SoftSprites.

 

 

The two us ships are PF0overlapP0, just P0and again PF3 (the other ship is P1 in the same way).

 

 

 

 

I just turn some part of the Backgr. Screens into PF and add some DLIs. on the PFs.

And you can also see this screen if I change some of the colours:

 

 

The conclusion is that you only have to change in Levels and/or DLIs. PF1 and PF2.

 

 

 

 

But there's a problem (or not...) If you're using PF3 than all the ships must never walk in a PF2Char.

But PF2 are in the Graphics backgrounds and you're supposed not to enter here or you'll lost a life. I think no problem here.

In this picture you'll see that inside the White Lines are the PF2Chars, I think no problem...

 

But now I'll have a question:

All the Screen Backr. Gfx. are chars and scrolling like Chars (Fine Scrolling). But what about using PF2 in the moving large ship at the Right. This one is a large Soft Sprite. I think I have to give 1char space (movement of Soft Sprites) around it.

 

Or I can (and is what I see in other Giant Enemys) use PF3 in this ones. Now I'll have also PF3 in Large "Beast" and PF3 in all Ships. And are only using PF2 in the Backgr. Gfx.:

 

 

What you think.

Anymore ideas/suggestions?

 

 

Greetings.

José Pereira.

[José Pereira]

 

If you want, here you'll have the .g2f/.xex Files:

armalyte_06_ais_PF3 in Enemys_2.zip

 

Greetings.

José Pereira.

[José Pereira]

 

If you want, here you'll have the .g2f/.xex Files:

armalyte_06_ais_PF3 in Enemys_2.zip

 

Greetings.

José Pereira.

 

 

Don't know why, but our two ships aren't with Pm0&1 on that above picture:

 

 

José Pereira.

 

 

(P.S. - Don't be angry with me and all this Posts after Posts. Let's me dream a little bit:sleep: )

[Mclaneinc]

Boy Jose, you really do have far too much time on your hands but I do love your passion towards this and you do a great job in general.

 

How do you manage to have so much time unless it's too personal and what keeps the buzz to do screen after screen, don't you get bored at some point.

 

All the same, thanks for the artwork..

[José Pereira]

Boy Jose, you really do have far too much time on your hands but I do love your passion towards this and you do a great job in general.

 

How do you manage to have so much time unless it's too personal and what keeps the buzz to do screen after screen, don't you get bored at some point.

 

All the same, thanks for the artwork..

 

 

A8 passion and a large free.time.

I get someone(s) to code games (we get many, many...)

 

José Pereira.

[José Pereira]

 

This one is a C64 picture of the Game Delta.

Again you'll see what I was saying:

DarkGray in the Sprites Borders and in side White colour.

 

Like the Armalyte ex. you can use Backgr.-Black, PF0-White and PF3-DarkGray.

 

From the pic. you see that you'll have 2in each line.

If you have P2&3 and move 3Up, if the bottom goes Up it can change from P2to P3.

This si what someone said here some days ago (or on AtariOnline?)

 

 

Oh! I remmember now, it was Probe.

The program detects the nºs of the PMs on the Line and change the new arrive PM at this Line into the not used nº.

Also some talk if there are all the PMs. already at that Line, but I don't remember it very well now.

This talking was about PMs. only.

 

 

But in my idea, if we can use Overlap to add colours.

We don't have 2Multicolour Sprites but 4.

Possible now:

2Players simultaneous and 2Enemys in the same Line.

1Player ship + ship add on- like on R-Type.

1Player Ship+3Enemys in the same Line.

 

 

 

The C64 12pixels wide Sprites are, like I said easilly turn into one Player+1Missile 10pixels on A8 if we use the trick of the Dark Gray colour.

 

 

And, by the way in that Armalyte ex. I only erase just one pixel in each of our Player two ships.

Where are the lost pixel in each one? You don't notice? Try to!...

The Enemy Ships are 100% the same pixels and here you have... 12pixels wide 3colour (1colour+2 the same in all) C64 Sprites into 2different colours+Gray in each Player Ship and 2different colours+DarkGray in each Enemy's Ship.

 

 

Hope you understand my thoughts (my bad, bad English!...)

José Pereira.

[PeteD]

I'm already working on Delta Trust me, it's more complex than you're making out with X number of sprites per line.

 

 

Pete

[STE'86]

Armalyte_Zx_SpriteSheet.bmpHello to all.

 

Anyone have Computer & Video Games 12.88, that he can scan the Armalyte C64Map Armalyte_Zx_SpriteSheet.bmp

 

Thanks.

José Pereira.

 

 

Ah yes u could indeed rip out the c64 sprites but to do them as software u would have to make them 32 pixels wide so that they could be pre shifted. The Spectrum ones are all designed at 20 pixels wide to accomodate 4 pixels worth of pre shifting in 24 pixels.

 

guess who Steve Day is and where they got them from?

[TMR]

But in my idea, if we can use Overlap to add colours.

We don't have 2Multicolour Sprites but 4.

Possible now:

2Players simultaneous and 2Enemys in the same Line.

1Player ship + ship add on- like on R-Type.

1Player Ship+3Enemys in the same Line.

 

It's possibly better to use underlays rather than overlays, set the player priorities to put them behind the playfield and then they can generate the mid range colour whilst the playfield itself provides the low and highlights - you won't get as much colour overall, but it saves a couple of issues. i've just found my test code (it was done in 2007 originally, if memory serves) and uploaded a

- the underlays are getting a little skewed because there's a timing issue and there isn't any AND/OR masking on the player object (it's the purple one and under joystick control), but generally speaking it's working and all four objects end up on the same scanline without issue - the "plan" was to produce something similar to Citadel on the C64, so there'd be a few extra software sprites over the top for bullets and static gun bases to keep the object count up a little.

 

The only problem is that even if you get it up to six objects (and only four can be on a scanline because of the colour generation) it needs 96 characters (4x4 characters per object times six) from the set for software sprite render space, so either the the backgrounds and bullet objects are going to have to squeeze into the remaining 32 characters or the objects need to be smaller (8x16 pixel objects would need 54 chars in total for six objects).

[PeteD]

I'm using "underlays" on my stuff. I've also basically limited it in the number of different colours so there's no need for any clever "multiplexing" or colour change DLIs. You can get 95% of what's on the C64 version with just a few of the attack waves missing one, max 2 colours.

 

As far as the 4x4 sprites thing, well that's a RAM problem for sure but not insurmountable for drawing, especially when you can have a new charset per line. You're then basically ending up with a bitmap screen but in 5 colours and you shove sprite data into the "spare" space. I've done code to prepare shifted sprites at runtime as there's never usually more than 1 type on screen at a time and they don't usually have many frames. A lot of the time on Delta you can cheat in a fair few ways, but I'll keep that quiet so when I've got a demo ready it'll seem more impressive

 

 

Pete

[TMR]

I'm using "underlays" on my stuff. I've also basically limited it in the number of different colours so there's no need for any clever "multiplexing" or colour change DLIs. You can get 95% of what's on the C64 version with just a few of the attack waves missing one, max 2 colours.

 

i think i said a couple of years back that i thought Delta was workable... so now i get to look incredibly smug! =-) i had a few different techniques in mind though, so your idea'll be more colourful - i was thinking something similar to how Guard does things perhaps.

 

As far as the 4x4 sprites thing, well that's a RAM problem for sure but not insurmountable for drawing, especially when you can have a new charset per line. You're then basically ending up with a bitmap screen but in 5 colours and you shove sprite data into the "spare" space.

 

i'm not keen on doing that personally, the work areas are arranged into columns for speed and you can't really carry that over to multiple fonts if you're treating them like a bitmap... Reaxion uses three fonts for the play area and has to render the software sprite into two of them, but it maintains the columns of characters arrangement for the work area so it's still quite fast...

[PeteD]

Sometimes it's the only way (especially with some of the stuff I've been working on) and I'd certainly rather go with font per line than every 2 or 3. At least then you pretty much know you're crossing lines all the time and can ditch the "when" check. I'm working on some code ideas that should be pretty fast I'll let you know if it works or not

 

 

Pete

[oky2000]

Sorry just this last one:

 

 

Panel lines to the Grays that don't change in all Game/Levels.

 

 

Not more screens today (I promise!).

 

 

Bye...

José Pereira.

 

 

Why copy the rubbish side panel of the C64 version...ALL shooters with a side panel even on ST and Amiga are RUBBISH. Scale up the graphics so they fit the full width of the screen and put rubbish like the score and lives etc on a single char line at the top or bottom

 

Don't copy the rubbish mistakes of the C64/ST/Amiga version of Bitmap Brothers.

 

(Xenon 2 was even worse, on an Amiga it was one of the slowest shootemups ever, BB are over-rated nobs who can't code for sh1t)

[Heaven/TQA]

Delta would be cool... but only if managable in 50/60fps? the title music is already done... so time saving there...

 

but one font per line plus preshifting means at least 50% of RAM is used?

[Heaven/TQA]

But in my idea, if we can use Overlap to add colours.

We don't have 2Multicolour Sprites but 4.

Possible now:

2Players simultaneous and 2Enemys in the same Line.

1Player ship + ship add on- like on R-Type.

1Player Ship+3Enemys in the same Line.

 

It's possibly better to use underlays rather than overlays, set the player priorities to put them behind the playfield and then they can generate the mid range colour whilst the playfield itself provides the low and highlights - you won't get as much colour overall, but it saves a couple of issues. i've just found my test code (it was done in 2007 originally, if memory serves) and uploaded a

- the underlays are getting a little skewed because there's a timing issue and there isn't any AND/OR masking on the player object (it's the purple one and under joystick control), but generally speaking it's working and all four objects end up on the same scanline without issue - the "plan" was to produce something similar to Citadel on the C64, so there'd be a few extra software sprites over the top for bullets and static gun bases to keep the object count up a little.

 

The only problem is that even if you get it up to six objects (and only four can be on a scanline because of the colour generation) it needs 96 characters (4x4 characters per object times six) from the set for software sprite render space, so either the the backgrounds and bullet objects are going to have to squeeze into the remaining 32 characters or the objects need to be smaller (8x16 pixel objects would need 54 chars in total for six objects).

 

video looks good... on a first glance I would not assume that it is actually an A8 game... so PM underlays for the nasties and the background gfx? as the inner border of the background gfx seems more colorful...

 

so another question... if you are able to do this... I suspect that Cybernoid is possible? static screen, software sprites (most of the time)... but I am not familiar with the game itself so not sure if heavy hardware sprite issues come later...

 

but good work... any chance to release the source?