Forum Archive

Go Back   3D Realms Forums > 3D Realms Topics > Other Apogee/3D Realms Games > Rise of the Triad (1995) Source Code
Blogs FAQ Members List Social Groups Calendar Mark Forums Read


Thread Tools
Old 07-15-2003, 08:08 AM   #1
Precaching on Big endian machines?
I noticed that precaching is disabled on big endian machines due to some problem with byte swapping. When turning it on under OS X, most of the graphics in the game indeed turn into puddles o'puke. However, the game does play smoothly, and it doesn't halt every time I open a door or look around a corner, like it uses to when precaching is disabled. So it would be great if precaching would work correctly. [img]images/icons/smile.gif[/img]

As far as I understand, the problem is that it's not trivial to determine how to convert lumps while precaching, because they are of different types. What I don't understand is why the graphics do look right when turning off precaching? This means that the necessary byteswapping is done at the moment when the graphics are used. So it can't be that hard to move these methods into the precaching code. Apparently the provisions for this are already made with the "CvtFixme" function, but it's not implemented. What would be the 'strategy' to implement this? [img]images/icons/confused.gif[/img]

I also noticed that under OS X, some of the sprites have artefacts in the form of the first row of pixels being distorted and extending downwards. I suspect this is caused by a bug in some byteswapping routine...
DrLex is offline  
Old 07-16-2003, 04:25 PM   #2
Re: Precaching on Big endian machines?
In the meantime I went ahead and fixed the precaching... Basically I added a 'type' tag to the cache list, so when loading a lump the correct conversion routine can be used. (Mind that the previous phrase gives no idea about how much work it actually costed to get all the types right [img]images/icons/tongue.gif[/img] )

It's not entirely finished yet, because things still get funky when loading a saved game. All graphics not previously precached then seem to be loaded without proper endian conversion. Weird.
The artefacts are now gone, except for a single one that shows up at touchplates (makes them a bit too visible to keep the fun in the game) and I have no idea why (I still can't figure out where and how the touchplate graphic is loaded into memory).
When it all works, I'll try to make a surveyable list of all the code changes. This time it'll be a lot more than 4 lines [img]images/icons/smile.gif[/img]
DrLex is offline  
Old 07-16-2003, 08:36 PM   #3
Re: Precaching on Big endian machines?
Send us a patch as soon as you can, please. If we can get your changes rolled in before we release a version 1.2, that would be excellent.

Our version 1.2 of Rott uses audiolib, from the in-progress OSX version of Duke3D. This may take care of some of the sound issues left over on OSX.
theoddone33 is offline  
Old 07-17-2003, 05:12 PM   #4
Re: Precaching on Big endian machines?
All right, precaching now works perfectly (except for some rare glitches which I hope are just due to old data in my saved games). It's really worth it, all graphics are now clean and the number of times that the game pauses to read something off the HD has been reduced significantly. Viewing the game map also is a hundred times faster. And surprisingly, another bug with the screen fading out and not back in was also fixed by activating precaching...

Originally posted by theoddone33:
Send us a patch as soon as you can, please. If we can get your changes rolled in before we release a version 1.2, that would be excellent.
<font size="2" face="Verdana, Arial">I have just attempted to send you an e-mail (I guess your address is your username followed by at, but the mailserver here seems to have gone nuts, so it might not arrive. In that case, the file with the changes can be found here and this is what I typed in the mail itself:

Here are all the changes required to make precaching work on Big endian machines. Because I don't know much about how to make standard patches, I just used diff between the current CVS files and my modified files. In the list, the files are indicated by "### filename".
Of course you should remove the "NEW!" comments, they were just for me to keep track of what to change.

I also implemented a way to play music directly through QuickTime, but this involved changes in fx_man.c, in code which has now moved to the Duke audiolib. It'll take some time to find out if and how I can add this stuff to the new files and if it's worth it, so don't wait on it.

DrLex is offline  


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT -6. The time now is 02:21 PM.

Page generated in 0.11172199 seconds (100.00% PHP - 0% MySQL) with 18 queries

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2020, vBulletin Solutions, Inc.

Website is 1987-2014 Apogee Software, Ltd.
Ideas and messages posted here become property of Apogee Software Ltd.