Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - How do the Phantasy Star dungeons work?

Reply to topic
Author Message
  • Joined: 18 Dec 2014
  • Posts: 95
  • Location: Canada
Reply with quote
How do the Phantasy Star dungeons work?
Post Posted: Sun Feb 10, 2019 6:17 am
Has anyone taken a look to see how the maze is done code wise?If you have ,can you elaborate.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14689
  • Location: London
Reply with quote
Post Posted: Sun Feb 10, 2019 7:09 am
Do you mean the 3D effect? I think it's just tilemap updates from data in ROM, but I never actually worked through that part when I was commenting the disassembly many years ago.
  View user's profile Send private message Visit poster's website
  • Joined: 18 Dec 2014
  • Posts: 95
  • Location: Canada
Reply with quote
Post Posted: Sun Feb 10, 2019 7:15 am
Yeah the 3D effect,it moves incredibly smooth was curious how it was done.I read an article that stated the programmer had to slow the 3D effect down as it was moving so fast it was causing sickness to anyone that played it.
  View user's profile Send private message
  • Joined: 18 Dec 2014
  • Posts: 95
  • Location: Canada
Reply with quote
Post Posted: Sun Feb 10, 2019 3:41 pm
I guess it's time for me to start looking at code in the debugger,thank you for the reply.
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 864
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Sun Feb 10, 2019 4:36 pm
AFAIK, the maze uses a primitive form of pre-rendered video. There's an interview with a team member that mentions that it compresses the wireframe line data and the color data separately, but does not say much more than that.
  View user's profile Send private message Visit poster's website
  • Joined: 18 Dec 2014
  • Posts: 95
  • Location: Canada
Reply with quote
Post Posted: Sun Feb 10, 2019 9:03 pm
Thank you haroldoop,I appreciate the information.
  View user's profile Send private message
  • Joined: 18 Dec 2014
  • Posts: 95
  • Location: Canada
Reply with quote
Post Posted: Tue Feb 12, 2019 9:35 pm
OK so after a couple of hours of reverse engineering the code I now know how it's being done,and also how the map data is read and how the collision is done.Thanks everyone again for their replies.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14689
  • Location: London
Reply with quote
Post Posted: Wed Feb 13, 2019 6:33 am
If you can write it up at http://www.smspower.org/Development/PhantasyStar-SMS that would be great.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 879
  • Location: Spain
Reply with quote
Post Posted: Wed Feb 13, 2019 2:52 pm
+1!
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14689
  • Location: London
Reply with quote
Post Posted: Sun May 17, 2020 8:24 pm
I did disassemble much of this recently. Each animation when walking or turning is stored as a series of references to "frames" of data. For each frame, the game decompresses the data for the tiles to either the upper or lower 8KB of VRAM, and the tilemap is decompressed to RAM. It then waits for the next VBlank to load the name table, before starting on the next frame. Thus the frame rate is determined by the time taken to do this decompression, which is a bit more when turning than when walking straight (as the tile data is more complex), and the frame rate is not consistent.

The entry function is at $6cfb, with the animation index in a. There seem to be other functions involved in drawing dungeon scenes in other circumstances.

Doors are drawn on after the animation finishes, and end walls/side turnings are not drawn when turning. When walking forwards, these are part of the tileset and the game selects a tilemap to draw based on the view needed.

The tile data is effectively 3bpp but the most significant bit of each palette index in the data is the OR of the three bits of actual data. This means it can only use indices 0 and 9-15. The data itself is stored using RLE compression.
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!