Screens frComputer Games:

[Rybags]

I'd think multi chsets might be the way with that game.

 

It doesn't have a massive amount of onscreen action - IMO it'd be a reasonable candidate for porting to run under VBXE.

Use VBXE bitmap to do all the sprites, and the attribute layer to add colour choices to Antic Mode 4.

[José Pereira]

They aren't always moving in the 8directions, soo, there is any way of win some Chars and have to reserve 48 for the 3Enemys?

 

In theory yes, for example the lowest enemy object in the screenshot can't move vertically (enemies in Rick Dangerous don't jump or climb upwards as far as i remember and there's nowhere for it to fall) so it could be limited to only moving horizontally and the overhead for that object goes down to twelve characters instead of sixteen. Having the engine assign an extra row of characters below an object when it needs to move vertically from a pool could theoretically work too, but it'd be fiddly to implement and requires inhibitors in place to prevent too many objects trying to use it simultaneously.

 

Another option would be to reduce the enemy width to nine pixels, that'd only requires a three character wide work area so twelve characters per object for anything that needs vertical and nine for those that only shift horizontally.

 

 

TMR that's what I was thinking/seeing last Night.

Turn into just 2Chars wide doesn't seem to look good/possible...

 

yes, indeed the Enemys only move Horizoontal:

E-1Char Enemy Shape (initial)

S-1Char for Shifting

 

EEES

EEES

EEES

or

SEEE

SEEE

SEEE

 

 

 

What it does when then came at the end of a Platform is going horizontal untill it goes totally off it and than he just moves all the Body/Shape down/vertical:

 

EEES-->EEE

EEES-->EEE

EEES-->EEE

PlatforSSS

 

Now it's still have the same 12Chars, but instead of being at the side the Shifting Chars need to be at down of the SoftSprite.

Is there's any problem in changing to a different image of the SoftSprite's Shape?

 

________________________________________________________________________________________________________________________________________________________________________

 

But there's only one time where we need to add that Area of more 4Chars of Shifting, like TMR says. It will be 36Chars (3Enemys)+4Chars (Extra Down Shifting)=40CHARS

Now we need that this only happens one time at a Screen, having allways only 4Chars reserve.

This happens only when the Enemy is hit by something and he open his Arms, Jump and then start to fall.

 

 

If only one Enemy does this at a Time would be possible.

Many of the times it's only one Enemy Hit (More than one, only seems to happen if you put a Dynamite that kill more than one at the same time).

 

_________________________________________________________________________________________________________________________________________________________________________

 

As I am seeing, it is also possible to do this like when he reaches the end of a PLatform (and more than one Enemy can be shut down at once).

 

----------(Jump)--(__Fall__)

----------->SSS-->EEE->---

EEES(Hit)-->EEE-->EEE->EEE

EEES(Hit)-->EEE-->EEE->EEE

EEES(Hit)-->EEE-->SSS->EEE

-----------------------SSS (and so on, untill it reaches the bottom)

 

 

And a good only 36CHARS.

 

 

 

 

 

 

 

Comments?

 

Thanks to all.

Greetings.

José Pereira.

[TMR]

and... the game itself is pixel perfect. can f.e. the c64 version be adapted or is the c64 version based obviously on the 320x resolution of the sprites? so reducing the sprite size to 9 pixel as suggested might impact the gameplay.

 

Only Rick himself is high res overlay on the C64 version, 9 pixels for objects is probably workable if the collisions are adjusted a bit and the Amstrad CPC version can provide at least a base to work from for Rick himself as a multicolour object. Looking at the C64 version just now, many objects seem to stay on rails so they'd only need nine characters each and could be dynamically assigned an object from the pool as the screen is scrolled into play - the only issue is where enemies can drop downwards because they can be "herded" into the same horizontal line; the one Jose converted is like that, all three enemies can end up at the bottom of the play area.

[TMR]

What it does when then came at the end of a Platform is going horizontal untill it goes totally off it and than he just moves all the Body/Shape down/vertical:

 

EEES-->EEE

EEES-->EEE

EEES-->EEE

PlatforSSS

 

Now it's still have the same 12Chars, but instead of being at the side the Shifting Chars need to be at down of the SoftSprite.

Is there's any problem in changing to a different image of the SoftSprite's Shape?

 

It means there'll need to be dedicated handling for both occasions (and the order of the characters being used will preferably need to change for speed of rendering) but it's at least theoretically possible; you do lose the free motion for things like the comedy "falling" of enemies after they're killed but the game itself could probably work that way.

[José Pereira]

What it does when then came at the end of a Platform is going horizontal untill it goes totally off it and than he just moves all the Body/Shape down/vertical:

 

EEES-->EEE

EEES-->EEE

EEES-->EEE

PlatforSSS

 

Now it's still have the same 12Chars, but instead of being at the side the Shifting Chars need to be at down of the SoftSprite.

Is there's any problem in changing to a different image of the SoftSprite's Shape?

 

It means there'll need to be dedicated handling for both occasions (and the order of the characters being used will preferably need to change for speed of rendering) but it's at least theoretically possible; you do lose the free motion for things like the comedy "falling" of enemies after they're killed but the game itself could probably work that way.

 

 

The comedy dead/falling still possible this way.

The Enemys just do this

 

Normally moving:

EEES

EEES

EEES

 

 

->Enemy is killed<-

First Part of "Comedy":

(He open his Arms and jumps)

SSS

EEE

EEE

EEE

 

 

Second and untill he reaches the bottom:

EEE

EEE

EEE

SSS

 

 

 

 

The only thing different is that Enemy moves Diagonal on C64, and it doesn't seems it will be needed.

Another difference is that on C64 (just sprites) the Enemy fall over the Backgr. untill the Bottom.

 

The way I am thinking it will not, just.

->Hit

->Open Arms

->Jumps (1or2 Chars Up)

->Fall (Untill he reaches the next Floor, not goes above Floor). This is what Amstrad CPC does (SoftSprites like A8)

 

 

 

The Comic is there, but not too long, dead is not comic

 

 

 

José Pereira.

[José Pereira]

The comedy dead/falling still possible this way.

The Enemys just do this

 

Normally moving:

EEES

EEES

EEES

 

 

->Enemy is killed<-

First Part of "Comedy":

(He open his Arms and jumps)

SSS

EEE

EEE

EEE

 

 

Second and untill he reaches the bottom:

EEE

EEE

EEE

SSS

 

 

 

 

The only thing different is that Enemy moves Diagonal on C64, and it doesn't seems it will be needed.

Another difference is that on C64 (just sprites) the Enemy fall over the Backgr. untill the Bottom.

 

The way I am thinking it will not, just.

->Hit

->Open Arms

->Jumps (1or2 Chars Up)

->Fall (Untill he reaches the next Floor, not goes above Floor). This is what Amstrad CPC does (SoftSprites like A8)

 

 

 

 

 

This way of doing the Death sequence can look good, just see this on Amiga version at 1:12 that's my Screen Redone with the 3Enemys (all Dead )

[MaPa]

But if you kill enemy in non char aligned position, you will have to adjust the enemy's position up to 2 pixels left/right to align it.

[Heaven/TQA]

But if you kill enemy in non char aligned position, you will have to adjust the enemy's position up to 2 pixels left/right to align it.

 

 

ok... I had a look through the c64 version.

 

before we are discussing the best way regarding sprite handling. I would be interested in how many chars are needed for the background?

 

Can someone have a quick look into the c64 font? if so we know how many are free.

 

I am assuming that 2 Players are used for Rick. The next thing is that I doubt we are able to use chars as discussed. Why? simply because there are not only 3 Enemies but you have also other things done with sprites f.e. some background tiles, rocks, traps etc.

 

but charmode would be good simply because of the 5th color for the 4th color of the background.

 

so. If I would do Rick Port... same engine like I am using for Beyond Evil. Mimic with 7 different charsets in ADGJM...format an Antic E screen but with gaining the legendary 5th color.

 

Sprites were rendered like "real" softsprites so not into desired "sprite chars". Btw... why anyway? Then you are free in terms of char limit and movement. and you can handle as much as your engine is capable.

 

PMs are free to use.

 

7 chars are free to use "over the whole" screen so you can use them as the bullets and dynamite etc.

 

Scrolling would be left out but we could simply flip without scrolling. not a bad trade off as the action halts anyway while scrolling.

 

the comic animations of enemies dying can be left out, too as they do not harm gameplay imho.

 

how much RAM is used on the c64?

[José Pereira]

But if you kill enemy in non char aligned position, you will have to adjust the enemy's position up to 2 pixels left/right to align it.

 

 

Enemy Hit.

If it's Chars alligned starts COMIC, just jump, than falling

 

If not alligned continue walking:

->1Pixel to allign: 1or2pixels up (un-used pixels at the Top Char of the enemy) and 1 to side pixel moving untill allign

->Maxim. 2pixels side (some way is possible 1pixel moving to side, than 1or2Up(un-used pixels at Top Char of the Enemy) and 1 side to allign and start COMIC.

 

Add more this Shapes and have to choose/see if the Enemy Shape is or not alligned is a complicate/not doable thing?

 

 

 

 

 

But this is just some tries/thoughts because I have almost all the Chars for the first Level (South America) and it seems possible to fit all the Playing Area into 1Charset.

There are some Chars to pick up "on the fly" (like the two Pick Up things: 9Chars, Amunnition Box and Statue, only One on Screen at a time. Shot or Dynamite is another example).

 

 

 

If you go to more than 1Charset this discussion will not make sense.

 

 

 

I am just doing Chars/Charsets of the 1st Level by now.

The other 3Levels will give me the answer if it is or not possible.

 

 

 

 

José Pereira.

[José Pereira]

But if you kill enemy in non char aligned position, you will have to adjust the enemy's position up to 2 pixels left/right to align it.

 

 

ok... I had a look through the c64 version.

 

before we are discussing the best way regarding sprite handling. I would be interested in how many chars are needed for the background?

 

Can someone have a quick look into the c64 font? if so we know how many are free.

 

I am assuming that 2 Players are used for Rick. The next thing is that I doubt we are able to use chars as discussed. Why? simply because there are not only 3 Enemies but you have also other things done with sprites f.e. some background tiles, rocks, traps etc.

 

but charmode would be good simply because of the 5th color for the 4th color of the background.

 

so. If I would do Rick Port... same engine like I am using for Beyond Evil. Mimic with 7 different charsets in ADGJM...format an Antic E screen but with gaining the legendary 5th color.

 

Sprites were rendered like "real" softsprites so not into desired "sprite chars". Btw... why anyway? Then you are free in terms of char limit and movement. and you can handle as much as your engine is capable.

 

PMs are free to use.

 

7 chars are free to use "over the whole" screen so you can use them as the bullets and dynamite etc.

 

Scrolling would be left out but we could simply flip without scrolling. not a bad trade off as the action halts anyway while scrolling.

 

the comic animations of enemies dying can be left out, too as they do not harm gameplay imho.

 

how much RAM is used on the c64?

 

 

 

In my Mock-Up I used:

PRIOR0.

P0 for Rick

P1 for that Pick-Up Objects (this Statue you see on my Screen)

P2-one enemy

P3-other Enemy

(more possible using P2&P3 if not on the same Line)

 

 

 

M2andM3 joined for 3Enemys at a Line, only in later Levels and not in many Screens.

 

 

 

M0&M1 for Bullet or Dinamyte.

All the Screen is using just 5colours, some Screen by Screen can have some clever DLIs. to add some colours on some Floors,...

-------------------------------------------------------------------------------------------------------------------------------------

Backgr.-Black-(0,0)

PF0-----(colour,Luminance6)

PF1-----(colour,Luminance14)

--------------------------------------------------------------------------------------------------------------------------------------

This way Rick is using always, whatever colours you choose for PF0&PF1 on the Backgr.:

P0-(15,2)-Shoes

Ored PF0-(15,6)-Clothe and Hat

Ored PF1-(15,14)-Skin

--------------------------------------------------------------------------------------------------------

 

The same applies to the Colour you choose as P1 for the Pick-up Objects.

 

--------------------------------------------------------------------------------------------------------

 

Enemys using P2&P3(double width) are "bordered" by PF0 (the Dark Gray Line on my Picture, like C64).

Will be:

P2orP3-Trousers (in this case)

Ored PF3-Skin Colour.

 

Possible they Ored PF3 because they only move in PF3 (PF2 is one of the Rocks colours.

That's why I said we can have the "Comic scene" but more like CPC, the Enemys will not cross Rocks in Front. Possible they disapear when they reaches a Floor or CPC like, go behind.

 

________________________________________________________________________________________________________________________________________________

 

 

 

 

I think I like and would have the "Comic scene" if I was the coder.

More Charsets and it is possible. So, why take it off?

 

José Pereira.

[José Pereira]

C64 just SPRITES:

- Rick

- Bullet

- Dynamite Box

- Enemys

- Large Ammunition Box

- Pick-up Statue

- Moving Rock

- Walls Fire Lines

- Ground-Floor for Dynamite

- Rock for Dynamite

 

 

 

 

It uses them like this:

SPRITE1: Rick

SPRITE2: Bullet or Dynamite

SPRITE3: Pick Up Ammunition Box or Statue

SPRITE4: Enemy1

SPRITE5: Enemy2

SPRITE6: Enemy3 or Dynamite Floor or Moving Rock or Walls Fire Lines.

(One less Enemy at a Screen if this other things are on the Screen)

 

 

 

 

Greetings.

José Pereira.

[TMR]

before we are discussing the best way regarding sprite handling. I would be interested in how many chars are needed for the background?

 

Hard to say, one 256 character font contains two levels but without quite a bit of prodding around i can't be sure if they're getting an even 128 characters each.

 

how much RAM is used on the c64?

 

At a cursory glance, $0801 to $bfff seems to be pretty heavily packed (i don't think i counted more than five gaps of one page in length) so that's a dedicated block of 46K - the final bank appears to be where it keeps in-use graphics, there's a screen RAM at $c000 (there might be a second buffer at $c400, forgot to check), sprites and a mirror of the current font, status font and some of the enemy sprites shifted up from the lower block. With the gaps it's not using a full 64K but is well over 50K.

[TMR]

C64 just SPRITES:

- Rick

- Bullet

 

Rick's bullet is a high res character.

[José Pereira]

C64 Ripped Chars:

(includ. Pick-Up Objects)

103Chars

 

 

Rick(includ. shifting):

12Chars

 

 

Bullets or Dynamyte:

2Chars (2more Shifting?)

 

 

 

 

TOTAL=117Chars

 

But I trying to see if some later Later on the Level (like a Backgr. Brown Floor/Collumns/...) can take previous place (pick them up on the fly).

 

 

Yeah, but at least 3Enemys (or 2Enemys and Moving Ground Rocks/Moving Wall/....) an I think we need more than just 1Charset.

 

 

 

 

José Pereira.

[Heaven/TQA]

50k tough shit for A8. but not impossible.

 

so I would vote for BM4-Mode... Bitmap Mimic Mode 4.

[Heaven/TQA]

and obviously the preshifting data costs RAM, too...

 

In Beyond Evil it is handy to have all preshifted sprite data in 256 bytes (4x63 bytes). so for smooth moving you definitly need at least aditional 256 bytes per different sprite shape. if you want to handle both views (left/right) then you need additional 256 bytes.

 

in Gremlins (again my fave educational title for that) you have 256 bytes for left, 256 bytes for right, 256 bytes for up and 256 bytes for down... 1k for the Gremlin.

[José Pereira]

50k tough shit for A8. but not impossible.

 

so I would vote for BM4-Mode... Bitmap Mimic Mode 4.

 

Bitmap Mimic Mode4?

 

It's what? ANTIC4 simulate Bitmap?

 

32wide Screen.

1Charset by 4Lines is it?

And each SoftSprite replaces concrete Char nºs?

 

Screens are 24Char high on Amiga.

It would be 6Kb.+1Kb. for Status Area. 7Kb. total for Screen Gffx.

 

You just drop Tiles over the Screen?

 

CHARSET 0:

1st Line: Chars 000->031

2nd Line: Chars 032->063

3rd Line: Chars 064->095

4th Line: Chars 096->127

CHARSET 1:

6th Line: Chars 000->031

7th Line: Chars 032->063

8th Line: Chars 064->095

9th Line: Chars 096->127

(and so on untill Charset6_Lines21,22,23&24)

 

 

Like the way to get LastNinja?

 

 

José Pereira.

[Heaven/TQA]

yes. but does the c64 version use 32 byte screen? or 160x?

 

you would layout

 

char 0,4,8,12,16... font 0

char 1,5,9,13,17

char 2,6,10,14,18

char 0,4,8,12,16... font 1

char 1,5,9,13,17

char 2,6,10,14,18

...

 

3x40 = 120 so 7 are left over the whole screen as they can be defined the same throughout the 7 fonts.

[José Pereira]

yes. but does the c64 version use 32 byte screen? or 160x?

 

you would layout

 

char 0,4,8,12,16... font 0

char 1,5,9,13,17

char 2,6,10,14,18

char 0,4,8,12,16... font 1

char 1,5,9,13,17

char 2,6,10,14,18

...

 

3x40 = 120 so 7 are left over the whole screen as they can be defined the same throughout the 7 fonts.

 

 

No, the C64 uses (all versions, includ. 16bit) use 256, 32Chars means Charset by 4Lines.

Is it possible, because Soft Sprites just go taking concrete Chars places. Am I right?

 

José Pereira.

[Heaven/TQA]

you can layout the screen how you want to...

 

so if you say ok... 32 byte screen and you want to spread the fonts over every 4th line you can do it.

 

but remember that layout will always be

 

0,5,9...

1,6,10...

2,7,11...

3,8,12...

 

because in RAM chars are linear layouted so 8 bytes char 0, then 8 bytes char 1, then 8 bytes char 2, etc...

 

so your sprite routine can copy directly the sprite data per "row" without taking care of the chars itself... so it is simply a coder requierement and it is far faster then the other way around.

[José Pereira]

but remember that layout will always be

 

0,5,9...

1,6,10...

2,7,11...

3,8,12...

 

because in RAM chars are linear layouted so 8 bytes char 0, then 8 bytes char 1, then 8 bytes char 2, etc...

 

 

 

Linear: 1Line of a Char it's 8bits=1Byte, 1Char=8Lines=8bytes, 8bytes x 128Chars=1Kb.

Yes I know this, but why are you going into:

 

0

1

2

3

 

and then going again to the 1st Line to have:

4

5

6

7

and so on...

 

 

 

It's why it is Linear, all Chars Lines of the first Row Chars.

Then returning to 1st Line and so on)

 

Why doing 8Lines(1Char) of all of the first Chars Line, then the second, and so on doesn't work?

Something like

000->031

032->061

and so on...

 

Hope you don't mind for more this question(s).

José Pereira.

[Heaven/TQA]

ok... assume your sprite is 12x16 pixel...

 

= 3x chars in x and 16 bytes in y = 48 bytes in total, right?

 

so to position a sprite you need to copy these 48 sprites into the correct chars on screen. Now assume that the fonts are completly empty (so "invincible" and screen is empty for the user).

 

so when you want to position the sprite to 0,0 screen position you need to fill chars with data.

 

0+1

5+6

9+10

 

so... your sprite copy routine would fill directly 16 bytes into char 0+1 then char 5+6 and char 9+10.

 

in your other orientation you would need to copy 8 bytes into char 0, 8 bytes into char 1, 8 bytes into char 5, 8 bytes into char 6 and so forth...

 

which is 1. longer code 2. slower as you need to check boundaries later when moving in y-direction.

 

so when you want to copy the sprite to 0,1 screen position

 

you still need to copy the data but now you start at char 0 but not at byte 0 instead in byte 1... now think how complicated it get with your other layout...

[José Pereira]

ok... assume your sprite is 12x16 pixel...

 

= 3x chars in x and 16 bytes in y = 48 bytes in total, right?

 

so to position a sprite you need to copy these 48 sprites into the correct chars on screen. Now assume that the fonts are completly empty (so "invincible" and screen is empty for the user).

 

so when you want to position the sprite to 0,0 screen position you need to fill chars with data.

 

0+1

5+6

9+10

 

so... your sprite copy routine would fill directly 16 bytes into char 0+1 then char 5+6 and char 9+10.

 

in your other orientation you would need to copy 8 bytes into char 0, 8 bytes into char 1, 8 bytes into char 5, 8 bytes into char 6 and so forth...

 

which is 1. longer code 2. slower as you need to check boundaries later when moving in y-direction.

 

so when you want to copy the sprite to 0,1 screen position

 

you still need to copy the data but now you start at char 0 but not at byte 0 instead in byte 1... now think how complicated it get with your other layout...

 

 

 

Thank you so much.

I always wonder why you always talk about SoftSprites Shapes as:

ADG

BEH

CFI

 

and not the way I was thinking:

ABC

DEF

GHI

 

Now I understand why.

 

 

 

 

And now you juust drop/fill Tiles into this Chars.

 

How much different 4x8 Gfxs can we create?

This Chars are Data only, that will fill Screens.

Can you have un-limited Data of un-limited Gfxs.nºs.?

 

By the way, each DATA Line like, for example:

DATA (in Basic or DTA Assembler) 128,0,255,64,0,32,9,7 it's a 4x8Gfx.

How much Memory take each DTA line?

 

 

I am almost there, almost there.

1more Day, some new Things learned.

Will I ever get into LDA, STA,...?

Only Time will answer... but I think I'm on the right way!...

 

 

 

Thanks and greetings to all of yours always usefull helps.

José Pereira.

[Heaven/TQA]

if you are using the described layout and fonts you are using the screen like a bitmap mode... so get "chars for sprites" out of your head... you are now using "virtually" a bitmap screen which then enables you to use as much tiles as you want as you "copy" them on screen. So you need RAM for your sprite shapes. 4x more than on c64 due to the shifting. one reason why conversion need at least 128k or more RAM on XE or using the Corina Cart...

 

and calculating how much ram is needed is easy...

 

sprite x size div 4 = amount of bytes on screen are covered (think in "bitmap" terms) as 1 byte can hold 4 multicolor pixels.

sprite y size = amount of bytes per sprite "collum".

 

if you need to move the sprite in pixel resolution then you need to preshift the data. so for pixel accurate positioning 4x the sprite data shifted each time by a pixel. and for that you need the extra byte the "buffer byte".

 

ah, sorry... just saw that the c64 sprite size is 12x21 in multicolor and not x23 as i mentioned above... my fault.

 

so... a 12x21 c64 sprite has 3 collums (3*4 pixel per byte) and 21 bytes per row (3*21 = 63 bytes, the c64 sprite size in bytes).

 

if you want to mimic that and to optimise on A8 you would need data of collum 0 = 21 bytes, collum 1 = 21 bytes, collum 2 = 21 bytes) and this is only the "original" sprite without the preshifting.

 

and as you copy this data directly into the 7 fonts depending of the screen position you can copy as much you like. you can even build the background gfx out of 1024 tiles as you are not bound to "font size" only to ram...

[Heaven/TQA]

and your "data" statement are 8 bytes in general...

 

if you data statement is f.e. .word or data a(aabb) then the values are 16bit values instead of 8bit.