Soft sprites (isometric) on 9918A/MSX1

[Asmusr]

Do you think this would be possible on the TI?

 

 

It looks like the MSX1 game is using software sprites only.

[+adamantyr]

A marvelously complicated game... I'm impressed that it doesn't just have a 2D isometric perspective, but 3D objects and gravity as well!

 

This is very possible, if you're not worried about colors. Bit-mapping the objects over each other and under each other is very doable.

 

The only thing I can see that's complicated is how you're determining transparency in places... Each of the moving characters inner black lines are overlapping/underlapping as expected, but that would mean you'd have to map things using 2 bits per pixel, not one. (So you'd have a "transparent" pixel in addition to two color pixels.)

 

Damn I'd be keen to see the source code on this one and how they designed it...

[Opry99er]

Great looking game... Wow.

[Asmusr]

The only thing I can see that's complicated is how you're determining transparency in places... Each of the moving characters inner black lines are overlapping/underlapping as expected, but that would mean you'd have to map things using 2 bits per pixel, not one. (So you'd have a "transparent" pixel in addition to two color pixels.)

 

You would have a mask indicating which pixels to clear in addition to a pattern telling which pixels to set.

 

The issue for me is if whether it would be possible to send all the data required to update the VDP from the TI in a reasonable time. They must have had a really clever algorithm for determining if an area is 'dirty' and has to be repainted.

[+adamantyr]

Or they kept a buffer in CPU RAM and just output all of it in one stream. I notice on screens with more than two moving objects it slows WAY down but you don't see any rips or tears.

 

This is doable on the TI, if expensive in memory... the color swaps upon moving from one room to another would also be a pain...

[Gary from OPA]

Best to read thru this page:

 

http://www.icemark.com/dataformats/knightlore/

 

Grab the disassembly and work thru it.

 

Note the above is regard to Spectrum release of Knight Lore which was what the MSX was ported from and is similar in design, you can see in the page linked above how simple the graphics are really when it is broken down.

Edited April 18, 2015 by Gary from OPA

[Asmusr]

That's a very nice resource. Strange I didn't find it while I was re-making Sabre Wulf.

 

[Edit: but undocumented Z80 code is not that useful to me. Still, I could have saved many days of work if I had known this guy had extracted all the Sabre Wulf graphics. He's also explaining the data format for Jet Set Willy. It's tempting to try to do a TI version. ]

[Willsy]

It's a copy of a ZX Spectrum game from 1984.

[Asmusr]

Duplicate.

[Asmusr]

Made a little demo of isometric graphics on the TI:

 

 

The interesting part is that the hardware sprite seems to be moving behind parts of the character/bitmap layer. The only way to do this, of course, is to change the sprite pattern according to the surroundings.

 

It still has a few glitches that mainly have to do with treating the sprite as if it did not take up any space. And you can't move upstairs yet...

isometric.a99

ISOMETRIC.dsk

[palmheads]

That is amazing Rasmus!!! OMG

[Opry99er]

Geez Louise.....

[+Vorticon]

Beautiful! Please tell us you're working on the full Knight Lone conversion!

[+OLD CS1]

The ability to move a sprite "behind" foreground objects is a big thing that can be used in plethora of games.

[am1933]

Slightly off topic here but the thing about the MSX version that impressed me the most was the incredibly accurate reproduction of the Spectrum sound effects, the ZX has notoriously bad sound quality but some of the spot FX contained within certain games were actually quite good-Knightlore being a prime example.

[artrag]

Amazing ! My greetings

[JamesD]

There was a tutorial on writing isometric games on another site. If I locate it I'll post the link.

[matthew180]

The interesting part is that the hardware sprite seems to be moving behind parts of the character/bitmap layer. The only way to do this, of course, is to change the sprite pattern according to the surroundings.

I think you could also use a transparent "colored" sprite to on top of the foreground tiles to mask the player sprite. One or two mask sprites would probably be all you need, and of course they would have to dynamically move around with the player

 

Very nice demo though, I really like the black and white play field with a colored player.

 

It seems like you manage to come up with a way to do on the 9918A everything I added enhancements for on the F18A.

[+mizapf]

It seems like you manage to come up with a way to do on the 9918A everything I added enhancements for on the F18A.

 

And with all due respect for your works on the F18A, somehow achieving those things on that bare video processor which we believed to be just not good enough is a really tempting challenge, and also a bit embarrasing. There is *so* much potential behind, and all we did was to put some auto-moving sprites on the screen.

 

Wasn't there a famous quote like "We choose to use the 9918A to get all these fine graphics and do the other things, not because they are easy but because they are hard"?

[artrag]

I think you could also use a transparent "colored" sprite to on top of the foreground tiles to mask the player sprite. One or two mask sprites would probably be all you need, and of course they would have to dynamically move around with the player.

Sadly transparent sprites are just invisible, they do not mask other sprites

[matthew180]

Ah, that's right. Well, I suppose you could mask with a pair of sprites then, one with the fg pattern and one with the bg pattern of the tiles that need to cover the player sprite. I'm not sure at what point this becomes more of a pain than dynamically redefining the player sprite though.

[Willsy]

OMFG.

 

That is all.

[Asmusr]

Ah, that's right. Well, I suppose you could mask with a pair of sprites then, one with the fg pattern and one with the bg pattern of the tiles that need to cover the player sprite. I'm not sure at what point this becomes more of a pain than dynamically redefining the player sprite though.

 

The difficulty is about the same but if you use other sprites as masks you might end up having too many sprites on a line.

 

The way I'm doing this is to draw the masks for the blocks that could potentially occlude the player sprite in an off-screen buffer. I then use the combined mask to remove (SZC) the invisible parts of the sprite pattern as I transfer it to the VDP every frame. It's pretty slow (takes longer than a VDP frame for just one sprite), and I don't think you could use this method for Knight Lore, but for something like Spindizzy it should be fine.

[artrag]

Isometric level editor here, scroll the page

https://translate.google.es/translate?sl=es&tl=en&js=y&prev=_t&hl=es&ie=UTF-8&u=https%3A%2F%2Fsites.google.com%2Fsite%2Fellaboratoriodeoscar%2Fhome&edit-text=

Edited April 25, 2015 by artrag

[+OLD CS1]

Isometric level editor here, scroll the page

https://translate.google.es/translate?sl=es&tl=en&js=y&prev=_t&hl=es&ie=UTF-8&u=https%3A%2F%2Fsites.google.com%2Fsite%2Fellaboratoriodeoscar%2Fhome&edit-text=

 

Woah.