|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Author | Message |
---|---|
|
How do the Phantasy Star dungeons work?
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. | |
|
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. | |
|
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. | |
|
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. | |
|
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. | |
|
Posted: Sun Feb 10, 2019 9:03 pm |
Thank you haroldoop,I appreciate the information. | |
|
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. | |
|
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. | |
|
Posted: Wed Feb 13, 2019 2:52 pm |
+1! | |
|
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. |
|