![]() |
![]() |
#1 |
Hobbyist
Join Date: Jan 2021
Location: 742 Evergreen Terrace
Posts: 88
|
![]() By JRTombRaider/RetroRaiderJohn |
![]() |
![]() |
![]() |
#2 |
Archaeologist
Join Date: Jul 2010
Location: Great Britain-Oxfordshire
Posts: 1,124
|
![]()
I'm very impressd with this on the sega saturn. looking good! I'm sure expansion ram cartridge can be benefits of improving performace on the real sega saturn hardware. That would be interesting to find out.
Love to see Tomb raider gets a overhaul on sega saturn in the future, I do believe there are so many improvement can be made that Core Design wasn't able to do in the short time of development timeline.
__________________
Rest in Peace - rr_carroll Last edited by Greatest TR; 28-02-22 at 16:41. |
![]() |
![]() |
![]() |
#3 |
Archaeologist
Join Date: Mar 2009
Location: The Netherlands
Posts: 2,314
|
![]()
Nice to see a thread about my project! Right now I'm not working on it as actively as before, but I'll continue working on it at a more regular pace soon. The latest update is that Temple of the Cat is running, but there are many room textures that I've had to reduce to half their size in order to make the level fit within the TR1 Saturn engine's tight memory limits. Here's a short video (2.2 MB, MP4 video format). Plus some screenshots:
![]() ![]() ![]() ![]() ![]() ![]() There was a bit of a setback last week after I discovered that deleting unused or redundant object/sprite textures makes (seemingly) no difference on available level memory. I was really counting on it, because this would have given me pretty much enough memory to make all (significant) textures keep their full size. I'm now forced into looking for alternative methods to conserve as much memory as possible. I've done the following so far (which is mostly necessary for the Egypt levels): - Compressing floor data. This was inspired by what b122251 did in his PS1 conversions. - Removing texture placements in inaccessible areas. - Optimizing texture placements, so that only one unique texture is used instead of extremely similar or cut versions. - Removing unused meshes. There are a few static meshes that are unused, plus some inventory items. - Re-using meshes. The land and water crocodile share the exact same mesh data, for example. - Deleting unused animations. There are a bunch of them for Lara that are unused (including the handstand, which she can't perform in the Saturn version). Also, the mummies in Egypt don't shoot or fly, so all those animations are now removed too. - Re-using animations. Like for doors opening and closing. - Reducing frames on some animations and letting the engine interpolate the missing ones. This is hardly noticeable in-game and saves a good amount of data. This idea was suggested by Troye and has worked out well. There are some other "optimization" techniques that I've yet to implement. I've also yet to look at the TR1 Saturn binary. It would be perfect if binary modification would allow me to increase the memory limits without having to sacrifice so much room texture data, even if that would require a memory expansion pack. But right now it's way too soon for me to say whether or not this is a feasible solution. Last edited by jonathanrij; 01-03-22 at 13:46. |
![]() |
![]() |
![]() |
#4 |
Explorer
Join Date: Aug 2013
Posts: 668
|
![]()
Hey jonathanrij, I love seeing a Saturn port of Unfinished Business being worked on. It looks really great (and very accurate to how I would imagine an official Saturn release of Unfinished Business would have looked, if that makes sense).
I actually started work on a Saturn port once in december 2019, but didn't want to invest the time to get texture conversion working the way I wanted, but I got as far as a playable version of "Atlantean Stronghold" (textured entirely with Lara's ballroom floor tiles). The thing I wanted to mention is that I remember from porting Unfinished Business to the PS1 that I got a lot of space out of removing collision data and mesh data where I could. I still have the project files from that port, including the optimised levels in PC format. I'd be happy to share them with you if they might help. (Also, I've kind of had to specialise in squeezing as much size out of levels as I could, so I might know a few tricks you haven't come across yet.) Just send me a message if you're interested. If not, I'll of course totally understand. ![]() Anyway, I just wanted to say I love the way this is looking, and I hope we'll someday get to play it. |
![]() |
![]() |
![]() |
#5 | |
Archaeologist
Join Date: Mar 2009
Location: The Netherlands
Posts: 2,314
|
![]() Quote:
I had a feeling you've attempted a Saturn port before, especially since some of your tools support Saturn level files, meaning you know at least some of the level format. Nice to hear you did succeed in this regard. Texture data was another difficult part to get right, and there are some illogical choices they've made that I'll address later in my post. But first, to address my remaining optimization tricks. My plan was to remove boxes/zones/overlaps data (which is related to pathfinding) in inaccessible areas and to partially remove room data in these areas. Also, I could remove floor data in these same areas, but this won't save much, since the compressed floor data is already very small anyway. (For example, Temple of the Cat's FD size is now just 7 kB.) Object mesh data is also something I have optimized for the most part, but I'm not fully done yet. I can reduce animation data a bit more as well, plus re-use some room texture data without making it obvious. What bothers me is the technical inability to optimize/remove data in the following cases: - Ground zone 2 data (pathfinding) seems to be completely unused in any TR1 Gold level, since it presumably affects human enemies only, of which there are none. And yet this data is present/expected and can't be removed in any way. Fly zone data is also only used in a select amount of rooms. Removing all this data would save thousands of crucial bytes. - Room sector data has many duplicate entries and can't be optimized like floor data, since it expects them in order and doesn't use indexes. I don't even want to know how much data this would save. - Room texture data uses no coordinates whatsoever (unlike the PC and PS1 versions), so sliced textures need to be stored separately. This is painfully inefficient and makes no sense to me, especially since the original texture data is already huge for some levels. (In the original City of Khamoon level on Saturn, the texture data actually exceeds its limits (or maybe it's a signed/unsigned issue when the engine reads the texture info), making the last few textures look corrupted when coming closer to them. Here's an obvious example.) - Mipmap textures forcefully add a bunch of extra data (and the game still lags a crazy amount, so performance would probably be abysmal without it). - Redundant object texture data could reach up to 80.000 bytes for Temple of the Cat, but removing this data makes absolutely no difference on available memory, as pointed out in my previous post. This really annoys me, since it would have made all the difference for me to keep the vast majority of room textures in their original size. Right now, it's pretty much unavoidable that many textures will stay reduced to half their size, unless of course I find a way to increase in-game memory through binary hacking. This is something I'll for sure be looking into eventually, so it's not ruled out as a possibility. Then again, I just have no idea if this is even a realistic option... Also, what seems different compared to the PS1 version is that when the memory limits are exceeded, the level might still load, but opening the inventory or the load game option will get it to crash (the latter requiring about 20 kB more memory than the former). So essentially, you could get a level to load and you still might need to remove over 40 kB of data in total to be able to even load a different level. It's quite painful and almost makes me want to disable the load game functionality in the Egypt levels altogether. But I want the complete experience for players, so I probably won't do that. Anyway, these are just a few technical discoveries I wanted to share. Hopefully it still makes sense for the most part to anyone reading this. ![]() Last edited by jonathanrij; 02-03-22 at 00:08. |
|
![]() |
![]() |
![]() |
#6 |
Archaeologist
Join Date: Oct 2017
Location: Invercargill
Posts: 1,377
|
![]()
amazing project
![]() ![]()
__________________
Call me Troye :) |
![]() |
![]() |
![]() |
#7 |
Archaeologist
Join Date: Mar 2009
Location: The Netherlands
Posts: 2,314
|
![]() |
![]() |
![]() |
![]() |
#8 |
Historian
Join Date: Oct 2011
Location: England.
Posts: 310
|
![]()
This is spectacular! Well done dude. Very impressive!
![]()
__________________
"From this moment, your every breath is a gift from me" |
![]() |
![]() |
![]() |
#9 |
Relic Hunter
Join Date: Apr 2009
Location: Perú
Posts: 8,794
|
![]()
Another incredible gift to the community courtesy of jonathanrij
![]() |
![]() |
![]() |
![]() |
Thread Tools | |
|
|