Software Sprite Engine - A possible good idea

[José Pereira]

Hello.

 

Today, I think I will have more a solution rather than questions.

It's because I think I have the solution to create a Software Sprite Engine.

And, not only to my dream (LN on A8), but also to other new and conversion/port games.

The idea it's based in a kind of mathematical locical word operation.

 

 

But, let's begin with a simple example

 

In this picture, in places Ninja is on, you have cells with grey, green and black (from Ninja body) colours.

So, suppose Ninja only walks cell by cell (4 pixels in 160 resol.). You have to create 2 cells in the same place (one with Ninja and the other without Ninja). This will be harder, if you move your Ninja, not a cell but pixel by pixel. And even much more harder because Ninja has different shapes according to his movement (Up- left and Right and Down - left and right) and also, if he has a weapon or not.

 

Untill here, I think it's simple to you understand me. And I think I'm right.

 

Now, the beggining of the solution. This solution it's based in my A8 knowledge and in all my ideas for an A8 LN conversion.

 

 

 

- FIRST - THE WALKWAY - In above screen, grey colour it's where Ninja, enemy walks. So, in all my screen design I put the walkway colour as Background colour. Why? Simple, you don't have to create here any masks. This places are empty (in Level 1 and in many of other screens)

In this way you simple create the Ninja/enemy different shapes (legs, hands, weapons,...) according to their movements. Outside their shapes will always be Backr. (00 colour).

Simple, and an effective, real solution.

 

 

 

 

- SECOND - NINJA BODY (Upper parts) - Now things get a little bit harder.

When players go up and are up the walkway, their bodys will be above the other PFs. colours.

What would you do here? You begin to create different masks (like I said on "FIRST"). But here, even more number of them, because of all the different playfield objects.

And now, think that you do the game in the traditional way. You create each cell, and then join cells to create the different objects. I know that you can create 1 character set for each line (like on G2F9, but in LN example, how you will get space to all the different objects with different masks (only 256 chars per line).

 

I think you don't have. In C64 the screen are chars but Ninja/Enemy/Weapons and others are Sprites. On A8 the only way possible is cerating them as software Sprites, because you need PMs. to enhance screen colours.

 

Soo, what to do?

 

First, I thought that each cell could have the same char code number. For example, a green cell, letter "a", when Ninja head is on that place, you get green+black but it will remain "a" char code.

But I thought, no way possible, because, as I know, in this way all chars "a" on that line will change to green with black Ninja head. Am I right?

 

Now, I am real stuck!... Was what I thinked. No way!...

 

But than, something came to my mind. I remembered all the time I was stucked with Pms shapes change in G2F. And you help me. and what you have on G2F? Simple: "XOR", "OR", "AND" logical command words.

 

And it's with this that I think I have the solution.

 

 

This example it's two cells on ANTIC4 mode:

 

00 00 00 00 00 01 01 00 00 01 01 00

00 01 01 00 01 01 00 00 01 01 01 00

01 01 01 01 01 00 00 10 01 01 01 01

01 10 10 01 + 00 00 10 10 = 01 10 10 01

01 10 10 01 00 10 10 00 01 10 10 01

01 01 01 01 10 10 00 00 01 01 01 01

00 01 01 00 10 00 00 11 10 01 01 11

00 01 01 00 00 00 11 11 00 01 01 11

Player's Shape Character Cell Result

 

Suppose, player's shape it's the Ninja head.

And character cell it char code of "a".

First, my idea to all the Ninja/enemy shapes it's only using PF0(Black) and PF1 (Middle Grey). Better not use "11" because of the two colour possibilities. It's because these two will always be the same in all the game screens.

 

But, returning to this example. As you can see, the "result" it's what you get in a logical operation, if Ninja is above Playfield.

In 3rd cell you get Ninja pixels and only where you don't have Ninja shape you see playfield pixels.

So, in this logic operation, the result can have 3 different possibilities:

- IDENTICAL BIT-PAIR: 00/00=00

01/01=01

10/10=10

11/11=11

 

- ANY OTHER COMBINATIONS: First one wins

(Ex. - 10/11=10 or 11/10=11)

 

-PIXELS (01,10,11) and BACKGR. (00) - Always win pixels

 

 

 

But, what you get and win with this?

Simple. You don't have to create masks to each character cell. Because you only need to have, for example: chars (playfield) from 0 to 79 and 128 to 255 and players will be from 80 to 127.

Why? See this:

A line full of chars: "aaaaaabbbbbbbgfflwekper...)

Your Ninja head: char "1"

When Ninja head it's on "a" char the program calculates the logic in the way I explained. So on that cell you will have new "1". The result it's the new player shape. So, only software sprites change their shapes, but is char number remains the same.

When Ninja go to another place, I comeback with "a" to that place and calculate new Ninja shape on the new place.

 

And if players are under the screen graphics, you simply can use a PM and/or do the inverse logic operation.

 

 

 

 

 

I think this must have some way to do, because I think I am right and it could be done on this way.

And with this logic operation you can create a engine to use in all games.

 

 

Send your thoughts!...

I'll be here waiting for them.

 

Yours ATARILY,

José Pereira.

[Rybags]

I didn't read your full post, but a software sprite engine I did shares a couple of your ideas...

 

. Background... the easiest way is when doing the render, check the destination character. If it's 0 (blank), then you just store your softsprite character there, no masking needed. Of course, your game has to use screen code 0 as a blank for that to work.

 

. Masking skip... in the case of large soft-sprites with solid areas of colour, you can just skip the masking operation altogether for that tile, since it will always be filled with solid colour.

 

Problem is, with some optimisations you spend time checking conditions which makes it slower in some cases. So, you have to analyse what environment your sprites will be in so far as clutter, and choose which methods to employ.

[Rybags]

Additional to your Last Ninja desires...

 

My feeling is that doing the player/enemy sprites would be among the least of the problems to overcome.

The backdrops are where the real work is at.

[PeteD]

Indeed, the background is the more complex thing to begin with and how that is done will probably have an effect on how the sprites would be coded.

[José Pereira]

Is there any kind of Software Sprite Engine around (But need to change players shape with playfield shapes, not just a design one)?

 

 

And, if you understand what I said, probably the screens can be done in my way.

 

In G2F eachline have a charset. G2F start saving the chars at 1to... and inverse from 128to... . So, all screens done with G2F, will have chars higher than 0 but less than 40 (or even less, because some are on inverse), the chars number horizontal wide.

If using a software sprite program based on my ideas, I can simply create the screens with G2F. Than, the Soft sprite Editor put the softw. sprites char codes above 40 or 60 untill 127 (you will always have this char numbers free). The software sprite chars code could be equal in all screen lines.

It's the program that calculates in that place the Softw.Sprite and Char=New Softw. Sprite shape(but it's char code remains the same).

 

With memory, you don't have problems. You can create the screens, one by one, and release the game in cartridge format. It don't have to be constant diskette acess.

 

If this can be done in this way, it was so simple, only someone to create that logical operations.

 

José Pereira.

[miker]

Yes, it is (or they are).

 

One was done by TeBe and is used i.e. in BombJack (and will be in modern version of "Yie Ar Kung Fu" and in "Pang", too). Char-based and huge memory-consuming.

 

And another one is done by Pr0be, less memeory consuming, but it uses often flicker to do the job.

 

Tebe's procedure is present in MADS-examples.

Edited July 20, 2009 by miker

[José Pereira]

The files from PROBE and TEBE are free use. Where?

 

And, Rybags, you have something that can share?

 

José Pereira.

[Heaven/TQA]

mads.atari8.info

 

download the archive and then you find a lot of examples in the source folders.

 

my softsprite routine is in the Beyond Evil thread the last example. sprite10.zip

[Allas]

Is there any kind of Software Sprite Engine around (But need to change players shape with playfield shapes, not just a design one)?

 

 

And, if you understand what I said, probably the screens can be done in my way.

 

In G2F eachline have a charset. G2F start saving the chars at 1to... and inverse from 128to... . So, all screens done with G2F, will have chars higher than 0 but less than 40 (or even less, because some are on inverse), the chars number horizontal wide.

If using a software sprite program based on my ideas, I can simply create the screens with G2F. Than, the Soft sprite Editor put the softw. sprites char codes above 40 or 60 untill 127 (you will always have this char numbers free). The software sprite chars code could be equal in all screen lines.

It's the program that calculates in that place the Softw.Sprite and Char=New Softw. Sprite shape(but it's char code remains the same).

 

With memory, you don't have problems. You can create the screens, one by one, and release the game in cartridge format. It don't have to be constant diskette acess.

 

If this can be done in this way, it was so simple, only someone to create that logical operations.

 

José Pereira.

 

That's exactly the same way games as Animal Party, Mappy, Bombjack were done.

[José Pereira]

Probably now, you can believe that I can do the screen im my way.

See Allas post above.

 

I must have someone that say: "I have a Software Sprite Engine" or "I can do one".

 

Now I believe I can start to put my ideas in a practical way.

 

Believe me.

José Pereira.

[PeteD]

I don't think anyone would say you can't do it a certain way if you've worked out how to do it, just everyone has their own way of coding things, as long as they work none of them are wrong I say good luck to you

[Rybags]

The sprite engine I did is oriented for horizontal movement only... adaption to vertical would be reasonably easy.

 

But... for your pre-shifted character based sprite engines, they're generally all much the same if they're the save/restore background type.

 

Differences might exist such as whether they preserve the attribute bit, and probably not many have provision for clipping (ie giving background objects precedence).

[NRV]

Well, I wouldn't call this an "engine".. but all the code is there

 

http://www.atariage.com/forums/index.php?s...=108283&hl=

 

unrolled code, heavy in memory usage but very fast..

 

Regards

 

(hi Allas!.. did you see the "human animal part" video ?? )

 

 

maybe a little off topic, but I found these two pages today.. very nice

 

http://www.spriters-resource.com/

 

http://www.spritedatabase.net/

Edited July 21, 2009 by NRV

[Allas]

(hi Allas!.. did you see the "human animal part" video ?? )

 

 

Yes,... it's the most funny I've seen for years. Fandal is a very dangerous player. Those hits must hurt so much!

[José Pereira]

Thanks to all.

NRV that site (Sprites Resources is great).

Many, many games.

 

I don't had time to see all.

But this from NES gives me some ideas. Who was the one with a SMB A8 conversion?

supermario_enemies.htm

supermario_generalsprites.htm

supermario_misc.htm

 

And the complete map for all game level.

 

 

José Pereira.

[Atarigmr]

José! Então como vai isso?

 

Olha eu acho que tu deverias começar por programar um joguinho assim simples para ir ganhando experiência e o que vas aprendendo aplicas ao teu projecto super ambicioso (Last Ninja).

 

Um motor de sprites por software é uma boa ideia. Porque geralmente a melhor tactica é começar pelos motores do jogo e não pelos gráficos, eu também peco neste ponto sempre quero fazer os gráficos primeiro!

 

Saudações algarvia

 

English

 

I think you should start by coding a simple game so that you will get experience and then what you learn can later on be used in your ambitious project (Last Ninja).

 

A soft sprite engine is a good idea. As the best practice is to start with the engines for the game and not by it's gfx , I also fail in this, I always want to make the gfx first!

 

cheers

[José Pereira]

supermario_misc.htmsupermario_enemies.htmsupermario_generalsprites.htmsupermario_mainpage.htm

[Rybags]

Can you just post links to these pages instead of uploading them.

 

It's totally pointless, and annoying.