The X68000 games porting experiment

[CiH]

Works nicely here, who needs Tempest 2000

I also had the weird and interesting experience of Star Wars X68000 style on YouTube. Loads of line vectors, quite like the arcade game, but enough difference to make it interesting, and totally unlike anything you'd normally expect from the Japanese gaming aesthetic.

[Scarlettkitten]

Amazing work there, next starwars pleassssseeeeee

[dml]

super-duper-uber-productive Sascha

would be nice to see this one taken all the way to fully playable if it can be done, even if it means cutting some corners with the drawing.

dealing with all those small tiles again in bitplane mode will be interesting - coalescing them horizontally somehow?

[Anima]

dealing with all those small tiles again in bitplane mode will be interesting - coalescing them horizontally somehow?

Yes, I agree, some kind of coalescing is definitely the way to go. However, there are some important things to consider before I'll add a sprite routine.

ChoRenSha uses a special sprite library for the display which is well known for its performance (show 512 sprites instead of 128). It provides three different modes for the sprite display of which two are using HBL interrupts. One uses the X68000 native 128 sprite slots in an alternating order to simulate more sprites. Activating that mode results in a heavy sprite flicker and is actually not being used in the game at all (in fact it has been activated for the last WIP video because the other modes look "broken" without the HBL emulation). The use of this sprite library gives a chance to intercept the sprite drawing at a higher point of abstraction. The sprites for the library are more complex and flexible but that gives the opportunity to use them for the conversion. Also the whole special sprite handling could simply be skipped and there's no need to coalesce native sprites in realtime. I think this is the best way to go but then I have to read and understand the whole Japanese XSP documentation.

Short update: the game is now playable with the keyboard. I'll add the joystick support later on.

[dml]

Makes complete sense to me. Thanks for explaining the plan

[NGF]

Sounds great!

[EvilFranky]

From the small Wiki...

'The game runs at a fixed resolution of 640x480, using 256x256 internally.'

Is this the same for the Falcon port and how does that work?!

[Anima]

From the small Wiki...

'The game runs at a fixed resolution of 640x480, using 256x256 internally.'

Is this the same for the Falcon port and how does that work?!

Wikipedia refers to the Windows version which scales up the original size. The X68000 version uses the 256 x 256 pixels screen resolution.

[EvilFranky]

Bah!! They should have made that clearer [WINKING FACE]

[Dal]

Any chance of porting the x68K version of StreetFighter 2?

[EvilFranky]

That's what I've been hoping for haha

[Anima]

Any chance of porting the x68K version of StreetFighter 2?

SF2 is of course a tempting title but unfortunately it dynamically loads code to the display layer IIRC. This behaviour is not supported by the disassembling system I am using.

[EvilFranky]

Any chance of porting the x68K version of StreetFighter 2?

SF2 is of course a tempting title but unfortunately it dynamically loads code to the display layer IIRC. This behaviour is not supported by the disassembling system I am using.

That's a shame!

[NGF]

Same problem with Final Fight?

[Anima]

Same problem with Final Fight?

No, Final Fight uses some strange stack modifying code so it won't work on a MC68030 without patching.

[EvilFranky]

I read there was a patch for the X68030 for this? Not sure whether it would have made any difference to your porting effort

[Anima]

I read there was a patch for the X68030 for this? Not sure whether it would have made any difference to your porting effort

Yes, I know that there's a patch. I need to check how much needs to be patched. IIRC there's some kind of a protection routine right at the beginning. I hope this is the only part...

[Anima]

Ok guys, here's a first test version of Cho Ren Sha for the Atari Falcon 030.



This version uses a slow sprite drawing routine (emulation). In fact it converts every pixel of the sprites in realtime. So I would like to get some reports on how (if at all) this binary runs on your Falcon. I am especially interested in some figures from accelerated machines as this should run on a MC68040 and MC68060 powered machines as well.

The version also has some problems with the sprite caching (I guess) so you might see some corrupted graphics. Probably this is a result of the slow performance or the sprite display mode #1 has some bugs or whatever...

P.S.: you can play by using a joystick or the keyboard arrows, left "control" and "shift" keys. Use fire to start the game and have some fun.

[EvilFranky]

I can't get my Falcon set up just yet but tried it quickly on Hatari...

Very impressed!, and it isn't fully optimized yet

[dml]

I saw this early today just before I got on a flight, and just got home now - so not tried it yet. But it looks cool

[Eero Tamminen]

Had a quick try in Hatari. It looks nice.

Some issues:
* larger explosions cover too much of the screen, so that it's impossible to see where the ship is. Is the original game using transparency?
* when screen is really full of stuff, it gets slow pretty quickly (as expected )
* large enemies visible in the screenshot are visibly updated on screen 1/4 at the time (at least some of them)
* enemies on second wave after those are pretty much invisible
* a lot of the sprites are flickering, is this Hatari or game issue?

Maybe there should be some limit & priority for pyrotechnical effects, to avoid too many items slowing screen updates & making it impossible to see the ship?

EDIT: doesn't work with 4MB, works with 8MB. Added attachment of explosions.

grab0001.png

[Anima]

Some issues:
* larger explosions cover too much of the screen, so that it's impossible to see where the ship is. Is the original game using transparency?
* when screen is really full of stuff, it gets slow pretty quickly (as expected )
* large enemies visible in the screenshot are visibly updated on screen 1/4 at the time (at least some of them)
* enemies on second wave after those are pretty much invisible
* a lot of the sprites are flickering, is this Hatari or game issue?

Maybe there should be some limit & priority for pyrotechnical effects, to avoid too many items slowing screen updates & making it impossible to see the ship?

EDIT: doesn't work with 4MB, works with 8MB. Added attachment of explosions.

grab0001.png

Thanks for the report. Here are some notes and explanations about the issues:

The sprite drawing priority is wrong in the version above and has already beed fixed so the explosions are not covering other objects anymore.

The sprite routine in the test version uses only 128 sprites and tries to draw all objects on alternating screens, i.e. it will flicker even on the fastest machine. This "XSP mode 1" (implemented in the X68000 original game code) is the only one which shows all the objects on the screen without a proper raster interrupt emulation on the Falcon.

The invisible enemies are due to a faulty colour palette. It also affects the bullet visibility of the first wave enemies. The cause for this is still unknown.

The extreme flicker, however, is indeed an emulation problem as Hatari does not change the display screen address within a frame using the registers $ff8201/3/d.

Here's a newer version including the sprite priorities fix and a special one for Hatari which also reduces the flicker.

[f030]

i just tried it on a falcon 14mb, works better than previous version, but still with lot corrupted graphics
i hope that soon we will see an improved version
outstanding work Anima

[Anima]

i just tried it on a falcon 14mb, works better than previous version, but still with lot corrupted graphics
i hope that soon we will see an improved version
outstanding work Anima

Thanks. Here is an updated version without the "invisible" objects bug and properly working replays. Please check the version number as "20141021t" (shown in the welcome text at game start) is the most recent one. There are still corrupted sprite graphics though. I forgot to mention that these test versions need a Falcon with 14 MB RAM.

[Eero Tamminen]

Verified that invisible objects can now be seen and objects are on top of explosions. Thanks!

I also noticed the corrupt sprite graphics you mentioned. They start after those large enemies shooting rays across the screen.

Btw. This works also with EmuTOS!