SW Sprites in screen2

Page 5/5
1 | 2 | 3 | 4 |

Par Paulbrk

Hero (611)

Portrait de Paulbrk

11-07-2011, 20:17

You know, I was working on New Frontier company, when they later called Bit Managers, from 1999 to 2001, they told me the short time they used to convert a ZX game to MSX. You know they converted Xenon, Magic Jonson, Activision games and many more to MSX.

They told me that they are making a competition with other software companies, they convert the games to MSX on one weekend.
Thats why the MSX versions of this games are so slow and bad.

I am sure you can do a very good job, go on man Hannibal

There some ZX games that deserve to convert to MSX, one of them is Turrican.

Good luck!!!

Par MäSäXi

Paragon (1884)

Portrait de MäSäXi

12-07-2011, 19:00


They told me that they are making a competition with other software companies, they convert the games to MSX on one weekend.

quite fast... oO

but well, we have seen the results... Sad

There some ZX games that deserve to convert to MSX, one of them is Turrican.

...and many older games too. Smile

Par sd_snatcher

Prophet (3642)

Portrait de sd_snatcher

12-07-2011, 20:15

@Paulbrk

You can find a lot of new and well done conversions here. :)

Par Paulbrk

Hero (611)

Portrait de Paulbrk

12-07-2011, 22:20

Yeah, I have seen some time ago, this conversions are very good.
I hoppe to see new ones from Icon Games.

Par hit9918

Prophet (2927)

Portrait de hit9918

13-07-2011, 07:04

@hit9918, Paulbrk:
the problem is that i need to find a general solution for a little number of games, that allow a easy port from ZX.
converting sw sprites to hw ones, often require a massive number of changes

write on page 0
set as visible page 0
write on page 1
set as visible page 1

In other words, a rather special solution for: all BOBs, no scrolling. Screen 2, because z80 monochrome is factors faster than blitter.

Try this: another shadow buffer in RAM. do the ZX BOB draw, except that it stores to port 0x98 instead RAM. This goes as fast as the RAM version, except that column style screen 2 got 64 linear bytes, i.e. need to split the drawing to the 3 charset windows.

And cleanup goes outi from shadow RAM. So that would be a way with zero additional copy.

Vertical scrollers without sidepanel could go by the vertical roll register (in case that works with screen 2). The RAM buffer consisting of 256 byte columns will nicely wrap around if you go "inc L instead inc HL". You then need to fill the border line of 3 buffers with scrollstuff. Still much better than one additional screencopy.

Horizontal scroll does not work because no blitter in screen 2. Well but maybe by horizontal rotate of the nametable! (which does not work vertical because different charsets, would need some bitmap copy).

On screen 5, z80 in 60 cycles per byte (as in my code sketches) means 30 cycles per pixel i.e. still faster than the 45 cycles blitter. The blitter meanwhile could do scrollcopy. To get that together with BOBs, need 4 buffers?

So all of a sudden I am into "how to make a 16 color scroller with BOBs", ending up very special - there is no general solution for BOBs. Except that I get the impression "the cpu is always faster".

Page 5/5
1 | 2 | 3 | 4 |